プログラマが知るべき97のこと/見えないものを見えるように

提供:Wikisource

ソフトウェアの世界には、とにかく「目に見えない」ものが多く、目に見えないことが良いとされることもよくあります。目に見えないことに関連して使われる語彙も非常に豊富です。たとえば「メカニズムの透明性」、「情報隠蔽」などはその例でしょう。ソフトウェア自体、元々形がなく、目には見えないものですし、それを開発する過程で何が行われているかも見えにくいものです。ダグラス・アダムズの小説のタイトルをもじって言えば「ほとんど透明」ということになるでしょう。「目に見えない」ということに関しては、次のようなことが言えます。

  • ソースコードは元来、実体というものを持っていません。また物理的な意味で動くわけではないので、当然、物理法則にも従いません。エディタに読み込ませた時だけは目に見えますが、エディタを閉じれば消えてしまいます。どこかの森で木が倒れても、誰もその音を聞かなければ何も起きなかったことと同じように、ソースコードは目に見えないために、存在はしていても、存在している実感が湧きません。
  • プログラムを実行すれば現実世界に物理的な影響を与えることもあるので、その時は存在を実感できます。しかしプログラムを実行したからといって、プログラムの元になったソースコードが少しでも目に見えるようになるわけではありません。Googleのホームページは、見た目は気持ち良いくらいあっさりしたものですが、その後ろでは恐ろしく複雑なことが起こっています。ホームページの外見からそれを窺うことはまったくできません。
  • コードが90%書けると、つい「仕事が90%終わった」と考えがちです。しかし残り10%のデバッグに手間どり、いつまで経っても作業が終わらなかったとしたら、「90%終わった」と思ったのは間違いだったということになるのではないでしょうか。バグ修正をしている間は、開発は前に進みません。プログラマが給料をもらうのは、コードを書くことに対してであって、デバッグに対してではありません。そう考えれば、デバッグの分の作業は無駄とも言えます。そういう無駄は、できるだけ目に見えるようにすべきです。デバッグ作業で具体的にどういうことをしていて、どのくらいの時間がかかっているのかが明確になれば、そもそもはじめからバグを作り込まないようにすべき、と意識するようにもなるでしょう。
  • 順調そのものに見えたプロジェクトが突如、「実はこのままだと完了が半年遅れになる状況」だと判明する、そんなことがあれば大変な問題でしょう。しかし最も問題なのは半年遅れるということではなく、半年遅れそうという事実が何らかの理由で目に見えなくなっていたということです。進捗が目に見えないということは、進捗しないということにつながります。

何事にしろ、「目に見えない」というのは危険です。人間は目に見えるもの、具体的なかたちのあるものについてはよく考えますが、そうでないものについてはあまり考えない傾向にあるのです。存在や変化が目に見えていれば、それにうまく対処することができます。

  • ユニットテストを書くことによって、対象コードのテストが容易か困難かがはっきりと目に見えるようになります。また、開発中のコードが持つべき特性(「疎結合性」「高凝集性」など)を実際に持っているか否かが明確になります。
  • ユニットテストを実行すれば、コードの動きが目に見えるようになります。実行した時の品質が自分の期待したとおりになっているかが明らかになります。定められた仕様通りに動くかどうか、エラーや例外などによって暴走しない「堅牢性」を備えているか、といったことが目で確かめられるようになります。
  • プロジェクトの進捗は、掲示板やカードをうまく使えば可視化できます。作業ーつ一つが「未着手」なのか「進行中」なのか「完了済み」なのかが一目でわかるようにすればいいのです。そうすれば、いちいちプロジェクト管理ツールで確認しなくても、またはいちいちプログラマに報告を求めなくても、すぐに進捗を知ることができます。管理ツールやプログラマの報告に頼る体制だと、進捗が隠蔽されやすくなってしまうのです。
  • インクリメンタル開発の手法を使うと、開発の進捗が目に見えやすくなります。頻繁に、目に見える成果によって進捗を確かめることができるからです。「いつ頃完成しそう」という見積もりは確実なものにはなり得ませんが、たとえ全体の一部であっても、リリース可能な品質のコードが目の前にある、というのは進捗の確かな証拠になります。

ソフトウェア開発プロジェクトを進める際はいつでも、目に見える証拠がたくさんあるという状態を維持すべきでしょう。目に見える証拠があれば、進捗状況も正確に把握できます。決して頭の中だけの思い込みで判断はしなくなります。突然思いがけない事実が発覚して予定が変わってしまう、ということがなくなり、意図したとおりにプロジェクトが進行するようになります。