未だにネットワークの世界では、アジャイル開発だとかウォーターフォール(WF)開発だとか騒がれていますが、プロセスはそんな単純なものではありません。
それぞれに得意分野があり、現在の多くのプロジェクトに効果的な選択ができるでしょう。 それぞれでどんな工夫をしているかはとても参考になりますが、どちらで成功しているから他方はだめだとか、どちらで自分が不幸なのかを語っても他の分野では役立ちません。
そこで、ソフトウェア開発の流れを考えて、未来の予想をしてみます。今の現場にとってふさわしいプロセスは、将来のソフトウェア開発にふさわしいとは限りません。でも、将来に向けて今から検討しておけば、いつか役に立つと思います。
厳格なウォーターフォール(WF)開発
そもそものWFは、大規模なソフトウェアを開発する方法として生まれました。大規模なソフトウェアでは全体が混乱したり、仕様変更により肥大化しがちで、予定の期日や予算で完成しなかったからです。
そこで、計画を重視して進捗を見える化しました。工程という考え方を導入して分割統治が図られ、各工程でのドキュメントを中心とした成果物や、信頼性を中心とした品質のメトリクスを管理する事で下流工程での混乱を防ごうとしました。
批判対象になっているWFはこのようなプロセスだと思いますが、巨大な一つのシステムを開発する際には一定の成果をあげてきました。
アジャイル開発の登場
20世紀末になるころには、計算機の性能向上、ネットワーク機能、オブジェクト指向を中心としたソフトウェア開発技術の向上によって、短期間、多機能、広い意味の分散処理、多様なシステムが実現可能になりました。
開発の環境や対象が変わるに伴い、従来の様に一度に大きなものを作る事が避けられる様になりました（[#TiDD] 最近のソフトウェアを考えるとアジャイルに向かう）。
ボトムアップに実装を積み上げていくアジャイル開発は、リスクを低減する方法として、自社開発企業やユーザビリティを重視する一般ユーザ向けソフトウェア開発に利用されました。
現実的なWF開発
アジャイル開発が生まれる遥か前から、厳格なWF開発が実施不可能な現場では、最適化が行われました。具体的には、工程の完了の前に次工程を開始する、仕様変更の管理を柔軟にする、プロトタイピングによりリスクを低減する、段階リリースする、などです。
このように現実に最適化された開発は、スコープを可変にするアジャイル開発になかなか移行できません。特に決められた期限までに最低限必要な「一式」の機能を実現しないといけない業務システムではその傾向があると思います。
現実的なWF開発では仕様変更に柔軟に対応するほか、請負開発ですので請負側が瑕疵担保責任を持つ事で、発注側のリスクを減らすことができます。決められた期間に必要な「一式」の機能を実装するには有利な方法です。
その反面、納期が迫ってからの仕様変更には残業や増員による対応が必要で、開発者の負担は大きくなります。批判は当然ですが、このような開発が少なくなる事はあっても、発注側にメリットがある間は無くなりはしないでしょう。
近未来の小規模ソフトウェア開発
近未来の小規模ソフトウェア開発は、以下を想定しています。
- 生産性が高く、高機能なソフトウェアを少ない工数で開発できる
- 少人数でチームが構成され、開発期間も短い
- 高度に自動化され、短時間でデプロイできる
生産性が極端に高くなると継続的にバージョンアップする環境に追随する事が難しくなり、アルゴリズムを「どのように実現するか」と考える時間よりも、最新の環境で「実現できるか」を確認する時間の方が長くなります。
リスクが高くなると請負では高価になりすぎるので、顧客にとって準委任契約の方が安価に望みのソフトウェアを得られる可能性が高くなります。準委任契約だと発注側と受注側で契約範囲の議論は少なくなり、要望を満たせる良いソフトウェアについて前向きな議論が容易になるでしょう。
その一方で準委任契約だったとしても、従来のプロセスと前提が異なるので見直しが必要になります。
近未来の大規模ソフトウェア開発
一方でこれまで規模や予算の関係で実現できなかった大規模開発も行われる様になります。クラウドで支援されたアーキテクチャを利用して、システムのスケーラビリティや分割統治が実現できる様になります。
しかし、それは管理的視点での分割ではなく、技術的視点、つまりアーキテクチャー中心の分割になります。アーキテクチャ設計が先行して行われますので、実装プロセスはともかく、プロセス全体では段階的（WF型）になります。
このような開発の特徴は「一式」の機能を一度に揃える事です。しかし、実装時のリスクはドンドン高まりますので、ある程度は実装を優先した開発になってくるでしょう。
近未来はスクラムが難しくなる
準委任開発が増えるならアジャイル開発、今ならスクラムの導入が増えそうなものですが、アジャイル開発の「考え方」と「やり方」は利用するもののアジャイル開発とは似て非なるものになると思います。
私もNode-REDの開発をして近未来感を感じていますが、新規性の高い開発ではアジャイル、特にスクラムはうまくいかないと感じています。具体的には以下のような理由です。
変更を早く反映したい：アジャイル開発では開発者が集中を維持するために、イテレーションやスプリントと呼ばれる繰り返し開発のタイムボックス中の仕様変更から守られています。しかし、技術的な問題は関連する作業の継続を難しくしますし、短期間・少人数の開発では問題は即座に解決する必要があります。
ロールモデルよりも関係者の協調が必要になる：少人数での開発では小さな問題が全体に影響します。ロールを分けて開発メンバーを守るよりも、お互いに協力して知恵をだしあうことが求められます。また、そもそもロールを兼務するようでは組織パターンを利用している意味はあまりありません。
増員も時には必要：チームビルディグは重要ですが、期限の限られた仕事では増員が必要な事や、フェーズによって減員が必要な事もあります。そこでチーム単独でなく、同じ分野のチーム間で人をプールしたり、情報共有する仕組みが必要になります。
近未来のソフトウェア開発の難しさ
近未来のソフトウェア開発を考えると、厳格なWFもアジャイル開発も厳しいものがあります。開発者に負担にはなりますが、現実的なWFが今あるなかでは柔軟にさえ思えます。
そもそもWFは肥大化しない様に外側から束縛し、アジャイルは骨組みを作って肉付けをチームビルディングに任せている事から、現実の問題にプロセスで対応することを直接支援していません。
小規模開発は工数増加による被害も小さいので、これまであまり注目されてきませんでした。しかし、近未来には実装の単位がドンドン小さくなり、品質を維持しながら現実の問題を解決できる実施方法が必要となるでしょう。
（参考：クリティカルチェーンの定義から小規模プロジェクトの難しさを考える）
近未来のソフトウェアプロセス
建築の世界では大規模で無機質な開発の後に、無秩序な小規模開発が増えて、魅力的な街づくりが難しくなりました。そこでパターンランゲージが注目され、関係者が集まって現実の問題回避に必要な具体的な解決パターンを導き出し、それらと実際の制約を元に現実的なプロジェクトランゲージを構成し、魅力的な街づくりをする方法がとられています。
ソフトウェア開発もこれまでの様に良いプラクティスを全てやるのではなく、関係者で現実をふりかえり、品質を維持するための制約、チームビルディング、開発対象の実現方法、リーズナブルな運用の方法をパターン化し、より良いプロセスを構築することで、現実問題を解決できるプロセスが構築できると思います([#TiDD] パタンランゲージで経験を活かしたプロセスを構築する)。
そして、その具体的な情報の収集源としてチケットが有効だと思います。
【告知】
すでに募集している次回のRxTstudyの講演内容を変更し、上記のような考え方とチケットの関係を説明するつもりです。ぜひ、ご参加ください。
第65回 SEA関西プロセス分科会＆RxTStudy #15
「チケット管理システムによるプロセス支援と今後の課題」 (07月30日)
