1つの解決策を永続的な決定とするのは無理がある――曳光弾とプロトタイプ、ユーザーからのフィードバック：問題解決力を高めるコツはプログラミングの原則・思考にあり（7）（2/4 ページ）

本連載では、さまざまなプログラミングの原則・思考の中から、特に問題解決力を高めるのに役立つものをピックアップ。プログラマーは、その思考法をビジネスに応用し、そうではない人はプログラマーと一緒に働く際に思い出してほしい。プログラマーは唯一の最終決定解を求める傾向にある。しかし最終決定などというものは幻想で、存在しない。いたるところに常に変化は存在する。今回は「曳光弾」「プロトタイプ」によって早くユーザーからフィードバックを得ることの重要性をお伝えしよう。

[上田勲，著]

曳光弾

　英語　　Tracer ammunition

　What　〜最終形にも残る「骨格コード」

　「曳光弾」とは、発光することで、飛んだ軌跡がわかるようになっている弾丸のことです。ガンベルト上の通常弾と通常弾の間に、数発置きに装填されています。

　曳光弾は、即時にフィードバックをもたらしてくれます。曳光弾を発射すると、銃口から着弾するまでの弾道が花火のように描き出されるため、撃ちながら狙いを修正することができるのです。

　また、通常弾と同一の環境で発射するので、外部からの影響によるズレは最小に抑えられます。曳光弾が目標にあたれば、通常弾も同様に命中するというわけです。

　これにならい、プログラミングにおいても、目標を捉えるために、「曳光弾」を打ち上げるようにします。

　プログラミングにおける「曳光弾」とは、優先的に検証したい部分を、先行的にプログラミングすることです。簡易で構わないので、実際の環境下で動作して、確認できる、エンド・ツー・エンドのソフトウェアを作成します。

　ここで作成するコードは、フレームワークであり、土台となります。プロジェクトを通じて肉付けされていき、最終的な成果物にも残る「本物のコード」です。

　Why　〜暗闇の中で道筋を照らす

　曳光弾は、実際の弾丸と同じ環境、同じ制約条件下で発射できるため、それによって得られる情報の精度が高くなります。即座に正確なフィードバックを得て、正確に目標を捉えることができるのです。経済的に見ても、比較的安価な解決策です。

　同様の効果をソフトウェア開発で得るには、ソフトウェアの最終形態に対する決定を、迅速に、目に見える形で、何度も提示できるようにしなければなりません。そのためには、一部ながらでも、本物のソフトウェアが必要なのです。

　特に、今まで構築したことがないようなソフトウェアを開発する場合、プログラマは、射撃手のように暗闇の中の目標を狙わなければなりません。元になるシステムが存在していない場合、ユーザーの要求が曖昧なものとなるからです。開発そのものも、不慣れなアルゴリズム、開発技法、言語、ライブラリを使って、未知の世界に直面します。また、プロジェクトの完了まで長い期間がかかる場合、状況や目的も変化していく可能性が高くなります。

　そうした状況下では、曳光弾のアプローチを採ることにより、以下のメリットが得られます。

• ユーザーからのフィードバックが得られる

　早いうちからユーザーにソフトウェアを見せることができます。そこでうまくコミュニケーションできれば、ユーザーからのフィードバックを期待できます。

　機能の足りない部分を教えてくれて、さらに、進捗がこの目で確認できることを喜んでくれます。自分たちがプロジェクトに寄与したことで、プロジェクトに対する思い入れも増します。

　こういった繰り返しの中で、ユーザーは、目標にどれだけ近付いてきているかも教えてくれるはずです。

• プログラマが活躍できる舞台を早めに整えられる

　早いうちからプログラマの活躍できる舞台を整えることができます。

　中身のない仕様書ほど、やる気をくじくものはありません。このような状態は、まるで「薄い空気の中」で作業をするようなものです。

　ソフトウェアのエンド・ツー・エンドのやりとりを考え出して、それをコードに具体化すると、早々にプログラマの舞台が整い、全員が生産的になることができます。

• デバッグやテストが早く正確にできる

　統合のためのプラットフォームを手に入れることができます。

　ソフトウェアがエンド・ツー・エンドで接続されているということは、本日新たに単体テストが完了したコードを、すぐさま統合できる環境が構築できたことになります。つまり、大がかりな統合を一挙に行うのではなく、毎日ないし1日に何度も統合を行うことができます。

　これにより、新たな変更点の影響もただちに明確なものとなり、変更の相互作用も限定されたものとなるため、デバッグやテストがより早く、そしてより正確になります。

• デモ可能なソフトウェアを確保できる

　プロジェクトのステークホルダーは、いつデモを見たいと言ってくるか、予測できません。曳光弾による開発では、常にデモを行うことができる環境が手に入ります。

• 進捗が明確になる

　曳光弾によるコード開発では、ユースケース単位で開発に取り組むことができます。1つ終われば、次のものへと進みます。このため生産性の報告やユーザーへの進捗報告が簡単になります。

　また、それぞれの開発単位が比較的小さなものとなるため、巨大な一枚岩のようなコードの発生を避けることもできます。

　How　〜最初に動作する土台を作る

　まず土台を作り、徐々に肉付けしていきましょう。

　土台のコードは、最小限に留めます。とはいえ、動作するものであり、ソフトウェア最終形の骨格の一部をなすものとして作成します。つまり、使い捨てではありません。

　また、土台コードに付け足していく時、大切なのは、目標とのズレをチェックすることです。常にチェックを入れて、必要に応じて軌道修正を行います。いったん目標を捉えてしまえば、後の追加は簡単です。

　発展　〜プロトタイプとの違い

　曳光弾とプロトタイプはアプローチが似ています。しかし、この2つは明確に異なる点があります。

• プロトタイプ

　プロトタイプは、ソフトウェアのコンセプトや最終形態についての「理解を検証する」ためのものです。したがって、コンセプトの確認を終えた後は、作成したものをすべて捨て去り、得られた情報を使って、もう一度正しい形で再構築します。

　例えば、配送センター用のソフトウェアを開発しているとします。そこには、様々な大きさの荷物を、うまくトラックに積載するための機能があります。ここで、問題が2点あります。1つは「直感的なユーザーインタフェース設計が難しい」こと、もう1つは「最適な積載方法を導き出すアルゴリズムが難しい」ことです。

　この場合、まず、画面を簡単に構築できる開発ツールを使って、ユーザーインタフェースのプロトタイプを作ります。

　ここには、エンドユーザが使い勝手を確認できる程度の、画面のレイアウトや疑似操作を組み込みます。ボタンを押したとき、本物の機能が動作しなくても構いません。それを利用しながら、ユーザーインタフェースが同意できた時点で、そのプロトタイプを破棄します。その上で、決定したユーザーインタフェースで、最初からコードを書き直します。

　同様に、積載アルゴリズムも、いくつかのプロトタイプを作成します。このプロトタイプを使って、エンドユーザと要件を合意できたら、決定したアルゴリズムで、最初からコードを書き直します。

• 曳光弾

　曳光弾は、ソフトウェア全体がどのように連携するのかを明らかにします。そうして、プログラマに対して、今後も使い続けるアーキテクチャ上の骨格を提供し、ユーザーに対して、どのような使い勝手になるのかを提示します。

　例えば、前出の配送センター用のソフトウェアの場合、曳光弾では、シンプルながらも動作するユーザーインタフェースと、シンプルながらも動作する積載アルゴリズムを作成し、統合します。まだ洗練されていないとはいえ、いったんソフトウェア中のすべてのモジュールがつながれば、ユーザーやプログラマにとって、土台となるフレームワークが手に入ったことになります。

　このフレームワークには、開発が進むにつれ新たな機能が追加され、シンプルに仮作成したコードは、徐々に完全なものに置き換えられていきます。しかし、フレームワーク自身は、そのままの状態で残り続けます。ソフトウェアは、曳光弾によって作成された当初のコードと同じように振る舞い続けるのです。

　以上のように、プロトタイプは、使い捨てのコードを生成します。部分的で、しかもハリボテなコードです。これに対して、曳光弾は、最小限度とはいえ、動作する本物のコードであり、システム最終形の骨格の一部をなすものです。この違いは重要です。

　プロトタイプとは、すなわち経験学習です。プロトタイプの真の目的は「学び」にあります。その価値は生成されたコード中にあるのではなく、学習した教訓にあります。それがプロトタイプの本当の目指すところです。

　よって、プロトタイプは、曳光弾を発射する前に開始する「偵察」「諜報活動」という位置付けになります。

　関連　〜プロトタイプは試供品と試作品

　プロトタイプの本質は学びですが、大きく2つの側面があります。

• 1．試供品としてのプロトタイプ

　これは、ユーザーのニーズを正確に把握することが目的です。プロトタイプの試用を通してユーザーのニーズを把握します。

• 2．試作品としてのプロトタイプ

　これは、開発方法を検討することが目的です。

　今まで未経験の、新しいタイプのソフトウェアを開発しなければならない場合、未知の部分が多くなり、リスクが高くなります。どのように開発していくかを見極めるため、プロトタイプ作成の過程を通して、開発方法を模索します。

出典書籍

『達人プログラマー―システム開発の職人から名匠への道』アンドリューハント他, ピアソンエデュケーション（2000）

関連書籍

『効果的プログラム開発技法』國友義久, 近代科学社（2009）

『Ship It! ソフトウェアプロジェクト成功のための達人式ガイドブック』Jared Richardson 他, オーム社（2006）