キーボードを使おうその１～ホームポジション～

もう10年ほど前になるが、左右の人差し指だけを使って、すごい速さでコンピュータのキーボードを打つ人がいた。「北斗の拳」のケンシロウもかくあらんというような勢いであった。

思えば、最近は周りにそのような人も見かけなくなった。タイピング練習ソフトも充実しているし、皆、自分で体得しているのだろうか。

そんな時代に、こんなところに書くまでもないかもしれないのだが、今回はタイピングについて書いておこうと思う。プログラマにとって、タイピングが重要なスキルであることには違いないが、タイピング練習の研修をしてくれる開発会社も少ないだろうと思うからだ。

★
タイピングの基本となるのは「ホームポジション」である。ホームポジションとは、F のキーに左手の人差し指、J のキーに右手の人差し指をあわせ、キーボードに自然に手を置いたときの位置のことである。

タイピングで最も重要なことは、このホームポジションから、なるべく手を動かさないことだ。何かキーを押す場合は、原則として、ホームポジションから最も近い指を使う。

ただし、ホームポジションからは届かないキーもある。例えば、カーソルキー（矢印キー）がそうである。また、マウスを持つときにも手を動かさなければならない。そういうときでも、すぐにホームポジションに戻して、次のタイピングに備えることが必要である。

キーボードをよく見ると、F と J のキーに突起がついていると思うが、これを人差し指で確認するようにすれば、キーボードを見なくとも、確実にホームポジションに戻すことができるだろう（※１）。

このようなことに気をつけながら、タイピングを続けていれば、キーの配置などは指が勝手に覚えてくれるはずだ。

★
私がパソコンを始めたころは、周りにパソコンを使っている人もおらず、キーボードを見ないで打つなどという芸当は、テレビや映画でしか見たことがなかった。自分にはできない特殊な技術だと思っていた。

それでも、雑誌に載っていた、読者投稿のタイピング練習プログラムのソースコードを打ち込んで練習しているうちに（※２）、いつの間にか出切るようになっていた。人間、やればできるもんだと思ったものである。

今では、ゲームとしても楽しめる練習ソフトが沢山売られていて、初心者でも楽しくタイピングを身につけることができる。いい時代である。

※１
実は、キーボードによっては、この突起が D と K のキーについているものもある。F と J に慣れている人は、そうしたキーボードでは、ホームポジションを間違ってしまう（もちろん、逆のケースもある）。これはかなりのストレスなので、キーを取り外して入れ替えてしまう人もあるようである。

※２
当時は、付録の CD-ROM はもちろん、フロッピーディスクも無かった。データやプログラムは、音楽用のテープに保存していた時代である。

北斗の拳激打 2 ~タイピング覇王~ 価格改訂版

posted with amazlet on 06.04.23

トリスター (2004/09/02)
売り上げランキング: 827

おすすめ度の平均:

我が生涯に一片の悔い無し

Amazon.co.jp で詳細を見る

キーボード革命―情報電子化時代への基本技術

posted with amazlet on 06.04.23

諏訪邦夫
中央公論社 (1997/01)

おすすめ度の平均:

タッチタイプ取得にはかなり有効です

Amazon.co.jp で詳細を見る

やってみなきゃわからないという現実

システム開発の見積金額を提出して、「どうせ言い値でしょう？」といわれたことはないだろうか？

もちろん否定するだろう。ビジネストークとして。しかし、言い値といわれても仕方がないのが実情でもある。

システム開発の見積は、全くでたらめというわけではないにせよ、全く正確でもない。KKD（勘と経験と度胸）による主観的な見積はもちろん、COCOMO やファンクション・ポイント法といった客観的な見積手法を使っても、100% 正確な見積は不可能だ（※１）。

開発工数の見積は天気予報に似ているが、おそらくもっと難しいだろう。「ひまわり」や「アメダス」に相当するものがないからだ。開発の進捗に影響を及ぼす因子は無限にあるが、そのほとんどは測定することすら出来ない（※２）。

結局のところ、システム開発は、どこまでできるか、やってみないとわからないのである。

★

そんないい加減なことでビジネスとして成り立つか！　とお叱りを受けそうである。しかし、いいかげんなのは、現在、多くのシステム会社が行っている見積のほうである。

システム開発業界は、自分たちが「いい加減なビジネスをしていない」と思い込みたいがために、半ば意識的に現実から目を背け、「開発工数は見積可能」という幻想を作り上げている。そして、同じ幻想を顧客も見ている。

不透明なソフト開発価格の解決への第一歩は“相場”を示すことだという意見もある（※３）。いかにも正論に見えるが、それでは「幻想」を補強するだけのことだろう。

本当の解決への第一歩は、「どこまでできるか、やってみないとわからない」という現実を受け入れることである。

★

例えば、XP (eXtreme Programming) という開発プロセスは、実際にそのような現実を受け入れている。

システムには沢山の機能があるが、頻繁に使われる（必要性が高い）ものと、ほとんど使われない（必要性が低い）ものがある。XP では、必要性が高い機能から順番に作って行くことになっている。

また、突然開発プロジェクトが中止されたとしても、いつでも納品できるように、常に「システムが動く状態」をキープしながら作っていく。

こうすることで、たとえ作っているうちに、納期が来てしまった（顧客が開発予算を全て使い果たしてしまった）としても、本当に必要な機能は揃った状態で納品することが出来る。開発が間に合わなかった機能があるかもしれないが、それは、必要性が低い機能ということになる（※４）。

もちろん、開発期間があまりに短いと、必要な機能すら作ることが出来なくなるので、ある程度の見積は必要だろう。しかし、見積には、それほど高い精度を期待しなくてもよいのである（少なくとも、ウォーターフォールのような従来の開発手法に比べれば）。

XP は開発現場から生まれた手法である。現場の人間が、システム開発は「やってみなけりゃわからない」ということを身にしみて知っているからこそ、こういった方法が生み出されたのだと考えてよいだろう。

※１
ここでは、受託開発で作業工数（人月＝開発者の労働時間）を基準にした見積を行う場合の話。工数とは無関係に、導入効果などからシステムの「価値」を判断して、金額を設定することもあるらしい。また、パッケージ・ソフトには、市場価値というものがあるので、工数に直結はしないだろう。

※２
システムの規模は？　納期は？　技術的な難易度は？　要件がどれだけ明確化されているのか？　仕様変更はどれくらい発生するのか？　顧客とのミーティングにとれる回数や時間は？　開発者のスキルはどれくらいか？　管理者のスキルは？　開発者のチームワークはよいか？ .... 開発効率に影響する要因は無数にある。しかし、簡単に数値化したり、予測したりできるものは少ない。

※３
daxanya さんの関連記事にトラックバックしてます。

※４
もちろん、「必要性の低い機能は出来なくてもよい」という判断は顧客が行うことである。XP では、顧客が開発チームに参加することが必須とされているので、このような方法が可能なのである。
なお、ここで紹介しているのは、XP のほんの一側面に過ぎない。XP には、システム開発を良くするためのアイデアが満載である（→ おすすめ参考資料「オブジェクト倶楽部 Xp-jp 」）。

■関連記事
・システム開発費を値切る理由
・システム開発費の削減方法教えます

失敗のないファンクションポイント法

posted with amazlet on 06.02.26

アレア
日経BP社 (2002/09)
売り上げランキング: 14,360

おすすめ度の平均:

私はこれでFP法を覚えました

ファンクションポイント初心者でも

このような入門書を待っていた！

Amazon.co.jp で詳細を見る

情報システム投資の基本がわかる本―図解企業ユーザーとSE必携

posted with amazlet on 06.02.26

小笠原泰森彪小野寺清人
日本能率協会マネジメントセンター (2003/11)
売り上げランキング: 87,545

おすすめ度の平均:

ユーザだけでなくＳＥ，ＰＭが理解しておく事項

これだけではなぁ・・・

教科書として適切

Amazon.co.jp で詳細を見る

プログラミングが好きですか？

若いプログラマに、どうしてこの職業を選んだのか、という質問をすると、「これからはＩＴの時代だと思いまして」などという答えが帰ってくることがある。

それがいけないとは言わないが、ひそかに「プログラミングが好きだから」という答えを期待している私は、拍子抜けしてしまう。

最近では、入社してから初めてプログラミングを経験するという職業プログラマも増えているように思う。

確かに、会社の求人広告は、「未経験者歓迎」となっているかもしれない。しかし、入社した後で自分が向いていないことを知ったのでは遅い。人生、何度でもやり直せるとはいうが、無駄な過ちを犯すことはないだろう。

★
もちろん、実際に働いてみなければ経験できないこともたくさんある（※１）。しかし、プログラミングするための環境が簡単に手に入る時代である（※２）。プログラマを目指すなら、どうしてプログラミングをしてみないのだろうか？

「プログラマはこんな仕事」といった紹介文や、プログラミングの入門書を読むだけでは、プログラミングがどんなものか、本当のところは分からない。最初は小さなものでもいいから、自分自身がコンピュータを使う上で、役に立つと思うものを作ってみよう。簡単なゲームでもいい。それが出来たら、徐々に思いつく機能を追加してみるといいだろう。

そして、プログラミングをある程度経験したら、自分が仕事としてやっていけるかどうか、色々な面からよく考えてほしい。

もちろん、実際の仕事では、自分の思い通りのプログラムが作れるわけではない。誰かに指示された機能を作るのだ。それも、毎日、１日中プログラミングを行うことになる。少なくとも、プログラムという「作業」自体が好きだと感じられないならば、プログラマとしての仕事は辛いものになるだろう。

※１
そういったことは、実際のプログラマの体験談を聞くのが一番よい。このブログも、何かの役に立てば幸いである。

※２
例えば、最近の Windows パソコンなら、何もしなくても「Windows Scripting Host (WSH)」というスクリプト機能が入っている。また、Microsoft Word、Excel などが入っていれば、VBA というマクロ機能が使える。より本格的には、Ｃ言語や Java のコンパイラもインターネット等を通じて無料で入手・利用することが出来る。

■関連記事
・嬉しいこと

アルゴリズムの絵本-プログラミングが好きになる9つの扉

posted with amazlet on 06.04.16

(株)アンク
翔泳社 (2003/08/05)
売り上げランキング: 49,095

おすすめ度の平均:

アルゴリズムとは・・・

入門書には向いてる

図解は馴染みやすいがＣ言語の基礎は必須

Amazon.co.jp で詳細を見る

Cの絵本―C言語が好きになる9つの扉

posted with amazlet on 06.04.16

アンク
翔泳社 (2002/03)
売り上げランキング: 46,329

おすすめ度の平均:

初心者というけど・・・

学生さんにお薦めします。

超初心者ですが・・・

Amazon.co.jp で詳細を見る

ステップ数

「ステップ数」というのは、プログラムのソースコードの行数のことである（※１）。

ソースコードの行数が多いほど、プログラムの規模が大きい。当然、開発に掛かる時間も大きくなるだろう。というわけで、ステップ数は、プログラミングに必要な工数の見積や、進捗の管理に使われることがある。

しかし、実際には、ステップ数だけで工数を把握することは不可能である。

そもそも、完成したプログラムのステップ数がいくつになるのか、開発を始める前には分からない。プログラムは、ソースコードが何行になったら完成、というものではない。

たとえ、完成後のステップ数をある程度予測できたとしても、そこからプログラマの作業時間を予測することは更に困難なことである。プログラミングでは、ソースコードを書いている時間（手を使っている時間。ステップ数が増える）より、設計や技術調査をしている時間（頭を使っている時間。ステップ数は増えない）のほうが多いからだ。

また、同じ機能のプログラムであれば、多くの行数で書くより、少ない行数で書くほうが、良いプログラムである場合が多い（※２）。プログラミングに無駄が多いとステップ数が増えるからである。言い換えれば、プログラムの動作を変更せずに、ステップ数だけを不正に増やすことも簡単にできるのである。

このような理由から、プログラマの中には、管理者からステップ数の報告を求められることに反感を抱く者もある。

★

では、なぜ、ステップ数という単位が工数管理に使われ続けているのだろうか？

おそらく、決定的な代替案がないからだろう（※３）。ステップ数のような不確実なものでも、数値的な尺度が何もないよりはましだということであろう。

確かに、何にせよ、収集するデータは多いほうがよい。ステップ数に限らず、開発作業において簡単に測定できる数値情報があれば、何でも測るべきだろう。様々なデータが集まれば、有意義な解析も出来るかもしれない（もちろん、測定自体に手間が掛かるようであれば、その限りではないのだが）。

そういう意味では、プログラマは、ステップ数を報告することに反対すべきではない。ステップ数が測定されること自体には、何も問題はないはずだ。

問題があるとすれば、その数値がどう扱われるか、という点においてである。

もしも、管理者が、ステップ数だけを基準に、プログラマの生産能力を評価したり、進捗状況を管理しようとするならば、実態の把握を誤るばかりか、プログラマ達に不信感を抱かせることになるだろう。そうならないためには、特定の数値だけに頼るのではなく、もっと質的な情報も収集し、総合的に進捗を判断することが必要だろう。

※１
実際には、行の数え方にも細かいルールがある。例えば、コメント（注釈）だけの行を数えるのか数えないのか、など。開発会社やプロジェクトなどによって、決まっていることが多い。

※２
ソースコードの読みやすさを犠牲にしても、行数を少なくするような場合はその限りではない（プログラムのサイズに上限がある場合などは、そういったことが必要な場合もあるかもしれないが）。

※３
個人的には、プログラムの規模を測りたいのなら、ステップ数よりもソースコードのサイズ（バイト数）や、実行ファイルのサイズを測るほうが素直ではないかと思う。また、オブジェクト指向開発においては、ステップ数よりもクラス数、メソッド数のほうが妥当かもしれない。いずれにせよ、工数を管理する上で、不確実な単位であるということには変わりはないのだが。。。

■関連記事
・やってみなきゃわからないという現実
・どのくらいでできる？

SEのための数字・数学

posted with amazlet on 06.04.01

山村吉信
翔泳社 (2003/09/06)
売り上げランキング: 176,809

おすすめ度の平均:

実践本というよりも、「意識強化本」だな。

難しい話もあったけど……

Amazon.co.jp で詳細を見る

ソフトウェア開発の定量化手法

posted with amazlet on 06.04.01

Capers Jones 鶴保征城富野寿ケイパー・ジョーンズ
構造計画研究所 (1998/04)
売り上げランキング: 133,749

おすすめ度の平均:

たくさん勉強させてもらいました

買ったけど読んでない。

Amazon.co.jp で詳細を見る

「バグ」の使い方

コンピュータの画面表示が乱れてしまったり、文字が意味不明の記号などに変わってしまったりすると、「バグった」と言う人がいる。

しかし、「バグ」というのは、本来、設計やプログラミングの間違いのことである。つまり、「バグっている」というのは、ソースコードの記述が間違っているという意味だ（※１）。画面や文字が崩れることではない。また、プログラムの「動作」がおかしいことでもない。

もちろん、ソースコードが間違っていると、プログラムの動作はおかしくなってしまう。しかし、別の原因でおかしくなる場合もあるのだ。プログラムを動かしたときの「現象」だけを見て、「バグっている」と言ったりしていると、それを聞いた開発者がへそを曲げるかもしれない。

同様の誤解からか、プログラムを動かして動作がおかしいところを探す作業を「デバッグ」と言う人もいるようだ。しかし、本来、デバッグは、バグ（つまり、ソースコードの間違い）を修正することである。

問題の現象が発生する「原因」を突き止めることは、デバッグという作業に含まれる。しかし、問題の現象自体を探す仕事はデバッグではない。それは「テスト」と呼ぶのが正しいだろう。

★
・・・とここまで書いてから、いろいろと Web を眺めたりしていたのだが、「画面がバグった」といった記述は、コンピュータゲーム関連のページに、非常に多いようだ。

また、ゲーム業界では、「デバッグスタッフ」という名目で、テスト要員を募集しているところも結構ある。

「バグ」という言葉の使い方について私が感じていた違和感は、ビジネスソフト開発業界と、ゲームソフト開発業界の、文化の違いから来るものだったのだろうか。

ビジネスソフトの動作がおかしいという場合、プログラム以外に原因があることも多い。例えば、実行環境（パソコンや OS の設定など）がおかしいとか、投入したデータがおかしいといったことだ（※２）。

しかし、ゲーム専用機の上で動作するゲームソフトでは、動作がおかしいという時には、プログラム自体がおかしい、つまりバグである可能性が高いのだろう。

そういった背景を考えれば、ゲーム業界で、「バグ」という言葉がソフトの動作がおかしいこと自体を意味するようになってしまったとしても、不思議なことではないのかもしれない。

※１
ソースコードが間違って記述される瞬間を目撃することは少ないので、「バグった」という言い方はほとんどしない。「バグっている」とか「バグっていた」といった使い方が多い。または、「バグがある」、「バグがあった」というように、名詞としてもよく使われる。

※２
あるいは、設計の元になる、顧客の提示した要件自体がもおかしかった、ということもある。そのような場合は「バグ」ではなく「仕様」と言うことになっている。