Build Insiderオピニオン：長沢智治（6）
要求の変化に適応できる現場
素早く継続的なソフトウェア（＝ビジネス価値）の提供が求められる現在、要求の変化に迅速に適応できる開発の現場とするには、どんなことが必要になるのだろうか。
はじめに
皆さんの開発現場は、「要求の変化」にさらされていないだろうか？
実感がない皆さんは、実は企画や営業、プロジェクトリーダーがこれらから皆さんを守ってくれているのかもしれない。
実感のある皆さんは、それらをどう捉えているだろうか？ 2つの観点があるだろう。
1つは、「ビジネスやそのソフトウェアの重要なニーズ」として捉え、それらに適応することを意義と感じることだ。もう1つは、「ソフトウェアの仕様変更」といういまいましい事項と捉え、忌み嫌い、疲弊し、予測不可能な外圧と感じることだ。
皆さんがどう感じるか、どう捉えているかは、ここではこれ以上議論はしない。なぜならば、それは現場にしか分からないことだからだ。
今回のコラムでは、「要求の変化」と「変化への適応」について書いてみたいと思う。そう思ったきっかけは、このコラムの最後に触れる書籍が発売されるからであり、私がその書籍を監訳したからだ。
変化に適応できるコードとは
さて、皆さんのほとんどが、開発者であり、コードの設計と実装ができると仮定しよう。日々の開発業務の中で数多くのコードを生み出してきたことだろう。そのコードには、当然価値があり、それは、何かのビジネス上の課題を克服したり、新たなビジネスのアイデアを実現したりしてきたことだろう。そう、ソフトウェアというチカラに転換してだ。
変化する価値のあるコード
では、そんな皆さんのコードは、要求が変化したときに「適応できるだろうか」と考えたことはあるだろうか？
もちろん、「要求が今後将来にわたって一切変化しない」と断言できるか、あるいは「それは自分の仕事ではない」と割り切れる場合は、以降は読まなくていい。きっとそれは、双方にとって「時間の無駄」という残念な結果となるからだ。
コードは白黒はっきりしているので、書いた通りに動く。従って要求が変化すれば、書き直さなければならないのも必然だ。書き直しが多ければ多いほど、コードの依存性は複雑化していく傾向にある。
コードの複雑度を知るためにコードメトリックスを測るという手もある。これは、クラスの依存関係の深さや、適切なインターフェースの設置、if文などの循環的複雑度などを知ることだ。
変化に適応できるコードにするためにはコードの変更量と変更範囲を最小限にすることが必要になる。
SOLID原則
そこで役に立つのが、デザインパターンであり、SOLID原則だ。これらを正しく活用することで、変更の影響を最小限にするコーディングが可能になる。
デザインパターンとSOLID原則の活用とはすなわち、コードの複雑度の軽減を意味しているし、テスト可能性の向上を意味しているし、可読性の向上も意味している。
ぜひ、SOLID原則についてご存じない皆さんは、この機会にこれらについて学んでみていただきたい。SOLIDとは下記の原則の頭文字を取っている。
- S 単一責務の原則（Single Responsibility Principle，SRP）
- O 開放/閉鎖の原則（Open/Closed Principle，OCP）
- L リスコフの置換原則（Liskov's Substitution Principle，LSP）
- I インターフェース分離の原則（Interface Segregation Principle，ISP）
- D 依存性反転の原則（Dependency Inversion Principle，DIP）
技術的負債
今のご時世、開発に多くの時間を費やすことが許されていない場合も多い。要求の全体像が十分に定まっていない状態から機能を積み上げて開発し、デリバリーし続けることも増えてきている。よい設計、よいコーディング方法が分かっていてもそれをやる猶予がない場合もある。
この妥協は、実はとても重要な観点だ。「妥協は悪」ではないのだ。この妥協は、技術的負債と呼ばれるものの一部となる。技術的負債とは、開発をしているときに出てくるさまざまなゆがみと呼んでもよいだろう。気付かぬうちに生み出してしまったモンスターコードや、コードバグ、マジックナンバー、未テストのコードなども含まれる。
技術的負債もまた必ずしも悪ではない。要は、これらを認知しているのか、していないのか、いつ返済する予定なのか、返済する必要がないのか、そのコンセンサスが取れているのか、そうではないのかなのだ。
要するに、ビジネスのニーズ、ソフトウェアのニーズ、現場のチカラを適切に把握し、それに合わせた技術的負債の運営をすることが大切であり、それこそが現場の経営だということだ。その経営戦略に応じて、先に紹介したSOLID原則の適用も変わってくることになる。
Let's 議論
ここまで読んでくれた皆さんは、さっそくそれぞれの現場で、自分たちのコードで変化に適応できるコードについて議論してみてほしい。
変化に適応できるプロセスとは
では、変化に適応できるコーディングをしていれば万事OKなのだろうか？ 私の答えは否だ。
ビジネス上の課題を克服したり、新たなアイデアを実現したりするのは、変化を伴うことであり、その変化はそもそもプロジェクトの開始前から始まっているかもしれない。
定期的な価値のデリバリー
第2回目のコラム「ビジネスは変わった、ソフトウェアはどうか？」でも述べたが、ソフトウェアがビジネスにとって不可欠な世界観では、ビジネスモデルが固まりきる前からソフトウェアを原動力として必要とする。そして、ビジネスモデルが固まりきることがないならば、ソフトウェアも変化し続けることになる。すなわち、継続的デリバリーが求められるということだ。
継続的デリバリーということは、ビジネスのリズムに合わせてソフトウェアをデリバリーしないと意味がない。なぜならビジネスの価値はタイムリーに打ち出していかねばならないし、ビジネスの現場を正しく計測し、次の一手を他社への先手としたいからだ。
従って、ソフトウェアは、ビジネスのリズムに合わせて定期的にデリバリーされることが期待される。機能追加、致命的な不具合の改修、他サービスとの連携強化など、ソフトウェアに求められる変更はさまざまだが、ビジネス側が要求するのは、デリバリーの安定性となる。なぜならば、ビジネスの側でも全ての要求を体系立てて網羅することはできないと十分承知しているからだ。自分たちがうまく要求として出せないものを「ソフトウェアとして、ビジネス価値として提供するように」とはいえない。
従ってビジネス側も、その都度、欲しい価値を提示し、それを次の（定期）リリースで実現してほしいという欲求になっていくはずなのだ。
皆さんは、それに適応できる開発をできるだろうか？
話を単純化してみよう。ビジネス側からの要求項目として、A、B、C、D、E、Fがあったとしよう。このうち、Bは現時点であいまい性があり要求が固まりきれていないとしよう。Aは非常に大きな機能であり、今の開発チームには、苦が重いものだとしよう。そしてビジネス側の優先順位は、そのものズバリ、今述べた順序だとしよう。
さて、この優先順位で開発チームがこれらについて以下のように見積もったとしよう。
| 要求項目 | 規模 | 見積もり結果 |
|---|---|---|
| A | Large | 実現には、いくつかへの分割が必要だが今は見い出せていない |
| B | n/a | あいまい性が高いので、見積もりできない |
| C | Small | 十分に実現可能。恐らくこの規模なら2つは次のリリースで対応できそう |
| D | Medium | 十分に実現可能。恐らくこの規模なら1つは次のリリースで対応できそう |
| E | Small | 十分に実現可能。恐らくこの規模なら2つは次のリリースで対応できそう |
| F | Small | 十分に実現可能。恐らくこの規模なら2つは次のリリースで対応できそう |
皆さんなら、どの要求項目を次のリリースに向けて、選択し、デリバリーするだろうか？ いくつか例を考えてみよう。
お客さまに従います
この場合は、Aを選択したということだろう。もしくは、ビジネス側が2つの実装を望むならば、AとBを選択するかもしれない。
結果を想像してみよう。そう、開発チームの今の能力では手に負えない要求を実現しようとしたら、結果は、遅延か、品質低下か、その両方かとして出てくるだろう。さて、それは本当にビジネス側が望んでいることだろうか？ 結果としてビジネスが側の期待値に応えたことになるのだろうか？
開発側のロジカルな判断に従う
この場合は、AとBは恐らく選択されないだろう。Aは手に負えないので、今後の展開を待てるならビジネス側と交渉し、再検討したいところだ。Bはあいまい性が取り除けるまで保留としたい。結果として、次に優先順位の高い、Cを選択することになるだろう。
ただし、Cは機能としては比較的小さめなので（規模が「Small」）、もう1つ機能を実現できたらビジネス側も満足することだろう。
そこで次に選択すべきは、Dだろうか？ Eだろうか？
Dを選択したら、次のリリースまでにCとDを実現しなければならないことになる。Dは大きめの機能なので（規模が「Medium」）、Cとの両立は難しそうだ。結果としてCとDの両方をデリバリーできないか、Cのみを何とかデリバリーする結果となりそうだ。これは、ビジネス側の期待に応えているといえるだろうか？
Eを選択したら、次のリリースまでにCとEを実現しなければならないことになる。Eは、Cと同様に小さめな機能なので（規模が「Small」）、何とか実現できそうだ。結果として、CとEを無事にデリバリーできた。この結果はこのリリースの計画当初と一致しているので、ビジネス側の期待にも応えているといえるのではないだろうか？
大事なのはコンセンサス
ここで大切なことは、そのビジネス、そのソフトウェアの目的が何かについて、ビジネス側と開発側の双方でコンセンサスが取れているか、それに従って意思決定しているかだ。それが成立していれば、上述のような意思決定も可能になるであろう。
プロセスとコード
さてさて、話をまとめていこう。ビジネスにタイムリーに価値をデリバリーし続けるには、要求項目に実現可能な優先順位を付けて、ビジネス側とコンセンサスを取りながら、開発をし続けるということになる。
そのときに、「この機能は、以前の機能に依存しているので、変更できません」とか「この機能を変更するには、アーキテクチャ上、事実上の作り直しとなります」といえるだろうか？
明言できるならまだいいのかもしれない。「No」というべきかどうかはコミットしたあとに気付くことの方が圧倒的に多いのではないだろうか？ なぜならば、技術的負債の返済計画が十分ではなく、要求に対して「No」とも「Yes」ともいえない状態のまま「Yes」とコミットしてしまうことが圧倒的に多いからだ。
恐らくその理論は通用しない。実装上の問題は、ビジネスとは基本的に無関係だからだ。
従って、ビジネス要求に応じた十分な変化に適応できるコードであることが必要となる。変化に適応できるプロセスにしたとしても、変化に適応できるコードでないと机上の空論になってしまう危険性もあるということだ。逆もしかりで、変化に適応できるコードを心がけてきたところで、そもそも要求が変化に乏しかったりしたら、作り込みのコストに見合わないということになりかねない。変化に適応できるプロセスでないならば、そのコードは効力を発揮しないかもしれないということだ。
Let's 議論
ここまで読んでくれた皆さんは、さっそくそれぞれの現場で、自分たちのプロセスが変化に適応できるプロセスかどうかを議論してみてほしい。
『C#実践開発手法』
冒頭で述べたように、これらについて体系立てて学べる書籍が発売する。それが、『C#実践開発手法～デザインパターンとSOLID原則によるアジャイルなコーディング』（日経BP社，Gary McLean Hall 著，株式会社クイープ 訳，長沢智治 監訳）だ。
本書は、『Adaptive Code via C#: Agile coding with design patterns and SOLID principles』（Microsoft Press，2014）の日本語版だ。
本書は、以下のような構成をしており、初学者からベテランの開発者まで広く読んでもらえるものだ。また、クラウド時代のサービスとプロダクト開発において、本書で取り上げているテーマはどれも今を生きる開発者にとって見逃すことができないものであると確信している。
- アジャイル基礎
- SOLID原則
- 仮想現場での例
読書会や輪講のススメ
本書は、開発現場や、C#関連のコミュニティでの読書会や輪講に向いている。それぞれシンプルな章立てになっており、テーマを絞って勉強し、議論できるようになっている。ぜひ1人で読んだ後は、議論と実践の機会として活用していただきたい。
長沢 智治（ながさわ ともはる）
革新的なビジネスモデルでソフトウェアデリバリーを実践し続けるアトラシアン株式会社のエバンジェリスト。
ソフトウェア開発のライフサイクル全般を経験したのちに、日本ラショナルソフトウェア、日本アイ・ビー・エムなどでプロセス改善コンサルティングに従事。2007年より７年間、マイクロソフトのエバンジェリストを務め、2014年1月よりアトラシアンで初のエバンジェリストとして活動中。
- ブログ: Re:WorkStyle ITとビジネスの可能性@ITmedia オルタナティブブログ
- メール: tnagasawa@atlassian.com Twitter: @tnagasawa Facebook: Tomoharu.Nagasawa
※以下では、本稿の前後を合わせて5回分（第2回～第6回）のみ表示しています。
連載の全タイトルを参照するには、［この記事の連載 INDEX］を参照してください。
3. あなたのコード届いていますか？ 開発現場は見えていますか？
コードを完成させる「Code Complete」から、ユーザーが求めている何かの提供を完了させる「Feature Complete」へ、開発現場の意識を変えていこう。
6. 【現在、表示中】≫ 要求の変化に適応できる現場
素早く継続的なソフトウェア（＝ビジネス価値）の提供が求められる現在、要求の変化に迅速に適応できる開発の現場とするには、どんなことが必要になるのだろうか。
