[#プロセスプログラミング] 探索アルゴリズムとソフトウェア開発

アルゴリズムという言葉を初めて聞いたのは高校のとき、物理の先生と「図書館のレイアウト変更とか大変そうですね」と雑談していると「わしらは大学でアルゴリズムを学んだから効率よくできる」と言われていました。

オスターワイル(Leon J. Osterweil)氏が「ソフトウェアプロセスもソフトウェアである」とプロセスプログラミングを提唱して、ソフトウェア工学が大きく進歩しました。しかし、そもそもアルゴリズムは、現実世界の問題の解決法だったのです。

今回は探索アルゴリズムを基にソフトウェア開発を考えてみたいと思います。

ソフトウェア開発の可能性を探索する

ソフトウェアの実現方法には様々な可能性があり、開発を決めた時点をルートととし、実現する機能を横方向に、下に行くほど具体化する木構造で表す事ができるでしょう。

ソフトウェアの可能性を示す木構造からどのような実現方法が良いか探索するには、２つの基本的なアルゴリズムがあります。幅優先探索(Wikipedia)と深さ優先探索(Wikipedia)です。

幅優先探索は従来（ウォータフォール）型開発の他、アジャイル開発の初期に行われるアーキテクチャの決定、ストーリーの抽出、イテレーション０など、イテレーティブな開発にあたります。

深さ優先探索はアジャイル開発のような反復開発に置けるインクリメンタルな開発にあたり、機能やストーリー毎に実現していきます。

これらの２つの方法は木構造全体を探索する場合の効率は同じですが、途中で最適解が見つかる場合は深さ優先探索の方が効率的だと言われています。ウォータフォール型開発とアジャイル開発の関係ですね。

ボードゲームの判断

より効率的な探索法を参考に、効率的にソフトウェア開発する方法を考えてみます。

オセロのようなボードゲームでは状態の組合せが多いので、全ての手を計算して最適な答えを得る事が難しいとされています（すくなくとも昔は、、）。

次の手は一定時間内に打たないといけませんので、時間内に全数を探索できるような局面までは探索する手数を限定した上で、なるべく効率的に探索します。効率的な探索法としてアルファベータ法(何もないから何かみつかる: オセロゲーム開発 ～アルファベータ法（alpha-beta search）～)が有名です。

具体的には、今後の展開を時間内で計算可能な木構造で表現しておき、かどのマスを狙う、数を狙う、など局面に応じた評価関数に基づいて、負けそうな枝を削除（いわゆる枝刈り）して、より有効と思われる方法を実施します。

ここまでのアルゴリズムから学べる事は、全てを探索しない場合は幅優先探索よりも深さ優先の方が効率的と言われているものの、一定時間内に結果を得るには深みに入らない、局面に応じて判断や枝刈りをする、必要があるという事です。

では、ソフトウェア開発に当てはめて考えてみましょう。

深みに入らない

全体に影響を与えそうなアーキテクチャの決定や技術的な課題は早めに見通しを立てるべきです。深みに入らない様にプロトタイプやスパイクと呼ばれる技術検証を実施します。

少なくとも最低限価値が提供可能なMVP(minimum viable product)に至る重要成功要因（Critical Success Factor：IT用語辞典）の技術的課題は、確認しておくべきでしょう。

もちろん、従来型の開発におけるマイルストーン、アジャイル開発ではイテレーションのタイムボックスが守れるなら、正式な開発を実施する事も可能です。ユーザビリティの確認などがそれにあたります。ただし、全体に影響を当てる課題が残らない場合です。

局面に応じて判断や枝刈りをする

ゲームの評価関数は局面によって変わります。ソフトウェア開発においても、完了までの期間や業務、体制、使用する環境によって、判断を変えないといけません。

とはいえ、ゲームにおいてのゴールが、最終的なコマの数や王将の獲得など、局面によって変わらないように、ソフトウェア開発においても価値のある動くソフトウェアの実現である事は変わりません。そのゴールに至る可能性を高める、逆に言うとゴールを達成できないリスクを下げる判断が局面によって変わるのです。

ある事を実施するなら、その時間分だけ他の作業ができません。実現可能性が高まる様に、実施するリスクと実施しないリスク、ある方法と別の方法のリスクを見極めて、ゴールに向けてリスクが低減する様に判断や枝刈りをすべきでしょう。

つまり、その時点、その時点で、残りの工数と実施しない作業を考慮して、それぞれのリスクに対してどこまでリスク低減のための作業を深くまで実施して良いかを考えます。

木を小さくする

このようにプロジェクトの初期は難しい対応が求められます。これをより簡単にするには、自由度を下げて木を低くする、コードを減らして木を小さくするという方法があります。

自由度を下げる方法の一つは、いわゆる標準化です。確立された技術を用いる事で、考えないといけない事を減らします。お客様から与えられる制約も同じ様に自由度を減らして、検討する内容を減らす事ができます。

コードを減らせば実装範囲がへりますので、 木を小さくできます。ライブラリやフレームワーク、ミドルウェア、などが考えられます。もちろん、初めて利用する際は技術的な検証が欠かせません。

プロセスの特性も忘れずに

探索アルゴリズムで考えるとソフトウェア開発のポイントをうまく説明できますが、プロセスの特性も忘れてはいけません。プロセスを実行するのは人間ですので、情報や知識の共有、技術の習熟に時間がかかります。

開発中に得られた情報や知識は、その人数によって対面、レクチャ、文書などふさわしい方法で効率的に伝える必要があります。伝える人数は全体の規模のほか、増員タイミングや担当の割り当てなどによって変わります。

また、技術の習熟の考慮も必要です。顧客・開発者・技術共に経験者ばかりなら1度だけのリリースでもうまくいく可能性もあるかも知れません。しかし、未経験者や初めての要素があるなら、経験値が向上する様に複数回のリリースも検討すべきでしょう。

まとめ

探索アルゴリズムを基にソフトウェア開発プロセスを考えてみました。ソフトウェア開発は、業務、ソフトウェア、環境、納期、チームの構成、など、様々な要素の組合せがあり、ゲームで用いられる探索アルゴリズムも参考になるでしょう。

いわゆる90%シンドロームや動かないコンピュータなど、古くから語られる失敗プロジェクトは、 プロセスをきちんとプログラミングできないことから生じています。

たとえば進捗を管理しているから大丈夫と思っていても、リスクがコントロールされていなければうまくいきません。見た目の進捗を求めて、わかるところだけ深く探索しているかもしれないからです。

プロジェクト管理者に求められるプロセスプログラミングは、簡単ではありません。様々な要素を考慮しつつ、プロジェクトに関わる人たちが不幸にならない様に、より良い方向に導くセクシーな仕事なのです（参考：チームを守り育てる - セクシーな中間管理職 -）。