54-見えないものを見えるように - やさしいデスマーチ

「プログラマが知るべき97のこと」の54個目のエピソードは、ソフトウェア開発の可視化に関する話です。ソフトウェア開発において可視化（見える化）はマネージャ層にとっては特に興味のある話題です。本文でも書かれているように、ソフトウェア開発の難しさの本質は、ソースコードや設計と言ったものが実体を持っているようで持っていない為、定量化・可視化が難しい所にあります。
ソフトウェア開発の定量化や可視化については、様々な方法が考えられ、試されてきました。ソフトウェアが複雑になればなるほどソースコードの量は増える傾向があるため、ステップ数という定量化手法が生まれ、ステップ数に対してどの程度の不具合が含まれているかの傾向を分析した結果、バグ率といった手法が生まれたわけです。また、エンジニア１人当たりの生産性をすステップ数で割れば正確に工数も計算できる、そんな方法は誰もが聞いたことあるでしょう。これらの手法は、忌み嫌われ、現在のソフトウェア開発の効率を下げる原因と言われます。しかし、それらの手法は、現代のソフトウェア開発に適していないだけです。過去はその手法でそれなりに正確に定量化・可視化できていたので間違いではありません。
それでは、どのようにして現代のソフトウェア開発を定量化・可視化するべきでしょうか？まず、過去の定量化手法は一旦リセットすることが重要でしょう。現代のソフトウェア開発においてステップ数が意味をなさないことは誰にも明らかなことです。過去の経験やノウハウを捨てるには勇気がいることですが、ソフトウェア開発に携わる以上は時代の進化に対応しなければなりません。自分も某開発においてはリファクタリングを行いコード量を減らした事が大問題になったことがあります。ステップ数が減る事は受け容れられなかったようです…。結果としてその会社は辞める事になりましたが、説得しても無駄と言うことはよく解りました。
次にタスクを細分化して見える形にすることです。タスクはプロジェクトの規模にもよりますが、数ヶ月程度のプロジェクトまたはイテレーションであれば、半日から数日で完了する粒度にするのが良いでしょう。それ以上細かいとタスクが多くなりすぎて管理しきれませんし、大きすぎると見積もりが難しくなる上に正確性が失われるからです。タスクの管理はissue管理システムやチケット管理システムを使えば簡単に行う事ができます。慣れていないと導入に抵抗がありますが、強引にでも導入し慣れさせる事が重要でしょう。また、システムよりもより形として見えるようにタスクかんばんを作り、ポストイットで手書きする事も効果があります。ブラウザを開いて確認するよりも常に誰の目にも見える事で、プロジェクト外の人にも確認しやすく、なにより意識が高まります。
そしてユニットテストは実体の見えにくいコードを色々な視点で可視化します。ユニットテストのないソースコードは実行することにより「ある」という実感を与えます。しかし、そのボリュームや仕様に関する部分について実感する事はありません。コードの動きが目に見えるようになり、テストしやすいかどうかも浮き彫りにします。ちょっとした修正であっても大量のユニットテストコードに影響を与えるならば、それはちょっとした修正ではないのです。逆に大きな修正であってもユニットテストに影響がないのであれば大きな修正ではありません。コードの修正量ではなくユニットテストも含めた修正量を計ることで現代のソフトウェア開発に適した作業量を知ることができます。
GUIなどユニットテストの難しいコードであるならば、ユースケースシナリオやユーザマニュアルが鍵となります。そのGUIを動かすための事前条件・ユーザシナリオなどがスクリーンショット付きで用意されているならば、誰もが何が正しいかを正確に知ることができるでしょう。ユースケースシナリオやマニュアルを最後まで着手しなかったら、誰も何が正しいのかを把握できません。細かい画面仕様書や詳細設計書はあれば有用かもしれませんが、ユーザの価値を重視する現代のソフトウェア開発では正確な記述よりも実用的なマニュアルの方が適している筈です。
残る問題はプロジェクトメンバーのスキルと意識です。メンバーが言われた事をやれば十分と感じているチームでは実現できません。うまく文化を形成していく事が重要ですが、変えられないならば諦めて新しい環境を探すべきと思います。

ソフトウェア開発プロジェクトを進める際はいつでも、目に見える証拠がたくさんあるという状態を維持すべきでしょう。目にみえる証拠があれば、進捗状況も正確に把握できます。決して思い込みで判断はしなくなります。

目に見える証拠を揃えるにはプロジェクトを正確に把握することが重要です。その為にはプロジェクトに関連する技術的なスキルだけでなく、見積もりの技術が不可欠だと思います。49-見積りとは何かにあるように、プログラマは技術的スキルだけでなくプロジェクトを俯瞰できるスキルを身につけてください。まずは「アジャイルな見積りと計画づくり」を読むべきです。