ビジネスやテクノロジーの変化に備える

近視眼的な最適化

 人づてなので誤りも含まれるかもしれませんが、結構前にあまりの低品質で話題になっていた某スマートフォンについて、なぜそうなったかという開発サイドの内情を関係者から話を聞く機会がありました。その原因として色々なものがピックアップされていましたが、大きな方向性の誤りとして「近視眼的な最適化」を挙げられていたのが特に印象的でした。


 具体的には、その開発元メーカーでは前々からオフショアや受託体制を整備していて、それによりコスト競争力のあるソフトウェア開発体制を実現していたそうです。ただコストカットの代償に、丸投げによるメーカー側の技術力低下や、下請け先(オフショア等)の職域の最適化が進行しました。それによりビジネスの変化に弱く、変化に柔軟に対応できない開発体制ができてしまっていたそうです。

 そのためフィーチャフォンの垂直統合型開発からAndroidのオープンプラットフォーム型開発への劇的なパラダイムシフトに、体制として対応できず、結果として微妙なスペックで信じられないような低品質の製品が出荷されることになったとのことでした。


 まとめるならば、「改善で成果がでていた」「ただ目先の最適化を進めすぎて、ビジネスやテクノロジーの変化に合わせて自らのやり方や体制を変える力を失った」「そして実際に変化に直面した時に、どうしようもなくなっていた」ということです。


 工数面のコストカットによりプロジェクトが炎上するのは、ソフトウェア開発の現場では全くありふれた現象です。ただ上記では、「最適化は成功と思っていた」「問題発生発生時は既にどうしようもなくなっていた」という要素があるのに留意が必要です。

業界の傾向

 こうした問題は、巨大で複雑な携帯電話のソフトウェアならではという要素もあるかもしれません。が、それ以外の業種でも人ごとでないところも多いと思います。
 例えば自分のいる製造業にしても、固定費削減のため、アウトソーシングや下請け、オフショアの活用が進んでいます。それにより利益の上下にもある程度対応が可能になりましたが、代償として技術の外頼り状態が生まれています。そこでビジネス・テクノロジーの大きな変化に直面すると、当然として諸々の問題が出てきます。
 例えば親会社では、世の中が変化しても技術蓄積を積む機会が縮小するため、変化前の古い開発経験しか持っていないエンジニアが上流設計や開発管理を行うことになります。そうなると採算性に優れ競争力のあるデザインや仕様をスピーディに生み出せなくなりますし、開発管理においてもリスクや問題を見逃しやすくなります。これらは進行すると後追いの製品コンセプトや開発遅延といった問題を常態化させることになります。

袋小路に陥る

 なおこの変化への対応力の低下で特に問題になるのが、変化に直面した際に「どうしようもない」という袋小路状態に陥ることです。
 というのも、大きな変化に直面した時にダメージが発生するのは仕方ない面があります。ただ、そこでダメージが致命的なレベルに蓄積されるまでの間に、変化に合わせて自らを変え問題を根本解消しないと、冒頭の例のような、大きな品質低下や開発遅延といった深刻な結果を招くことになるためです。

対策の難しさ

 しかしこうした袋小路への転落を回避するのは大変な場合があります。
 まずビジネスやテクノロジーの変化は予測困難で、可能性は無数にあります。かけられるコストは有限であるので、全ての変化に対応できるようにするのは非現実的です。
 また変化への事前対策は、導入・運用に手間がかかることが少なくありません。例えば冒頭の例のようなテクノロジーの大きな変化に対しては、単にコードの保守性改善だけでは力不足で、マネジメントや人員確保、品質保証など、様々な領域で支えなければ克服できません。
 また変化への対策を組み込むと、中短期的に保守性を低下させることがあるのも問題です。例えばYAGNIの格言の通りですが、将来の変更リスクのためといって、コードの抽象化、汎化を必要以上に進めると、かえってプログラミングや保守の効率をしばしば貶めます。

 上記のような難しさがある上に、さらに変化への事前対策が無駄になりコストが増えるだけという可能性も存在します。このような背景から、時にビジネスやテクノロジーの変化に対しては、リスクがあっても盲目的になってしまう場合もしばしば見られます。

ビジネスやテクノロジーリスクのリスクマネジメントで備える

 なおこうした課題を踏まえたうえで、変化に備えるためにはどうしたらよいかについてですが、基礎となるアプローチとして、規律ある適切なプロセスで支えられた、ビジネスやテクノロジーリスクのリスクマネジメントが挙げられると思います。


 少し話がそれますが、発電所や自動車といった高品質が求められる開発では、品質リスクの軽減のため製品リスクのリスクマネジメントに力が入れられます。そこでは例えば以下のような活動が、開発ライフサイクル全体で継続的に何度も実施されることになります。

  1. リスクの識別:FMEAやFTAブレインストーミングマインドマップ、リスクモデル、類似製品のリスク等を元にリスクを網羅的にピックアップ
  2. リスクの評価:リスクをグルーピング・整理し、それぞれの頻度や重大度、事前検知度などを評価。リスクの優先付けを行う
  3. リスクの対応:優先度に応じてリスク軽減策を検討し、実施する
  4. フォローアップ:リスク軽減策によりリスクが軽減しているか、残留リスクが発生していないか評価・対策する。

 こうしたアプローチは、アドホックに行われがちなプロジェクトリスクのマネジメントと比べ、より厳格にリスクを管理していきます。これをビジネスやテクノロジーの変化リスクに対して実施すると、変化がどのような結果を招くのか、あるいは変化への対策として何が有効か明らかにできますし、変化への対策も管理できます。例えば簡単に説明すると以下のような活動が、変更への対策として有効になります。

  1. 開発の最初から最後まで、ビジネスやテクノロジーの変化リスク(変化するリスク、変化が発生した際のプロジェクト・リスク)を網羅的にピックアップしていきます。変化リスクとしては、フレームワークやOSの変化、部品のディスコン、コア人材の流出等々です。また変化が発生した際のプロジェクト・リスクとしては、知見の陳腐化、技術力ある人材の不足等々です。
  2. リスクがピックアップされたら、それぞれの発生可能性や損害を評価し、リスクを優先付けしていきます。
  3. リスクの優先度に応じて、リスク軽減策を検討し、実施していきます。
  4. 節目ごとにリスク軽減策が有効か、残留リスクがないか評価し、問題があれば対策します。

 こうしたリスクマネジメントで重要なのは「網羅的なリスクのピックアップ」「客観的なリスクの評価」「リスクの優先度に基づいた軽減策の検討と実施」「残留リスクや軽減策の有効性の評価と、そのフォローアップ」の活動を、継続的に続けていくことです。「継続的に」というのは特に重要で、計画、要求定義、設計、実装、テストと、開発活動それぞれでリスクがないか、リスクをどう扱うか考えていくことで、変更リスクへより広く対策できるようになります。

リスクマネジメントの運用

 ちなみにテクノロジーやビジネスを対象とした倍、リスク軽減策は多種多様です。
 例えばアジャイル開発の導入、プロトタイピングの拡充、変更管理プロセスの効率化、といった開発プロセス改善もリスク軽減策です。またフレームワークの変更・アップデートを許容するアーキテクチャ設計も有効な手段です。自動テストの拡充やWモデルの導入といったテストプロセスの改善も有効ですし、仮想的に変更を行って変更性を検証する評価も選択肢としてありえます。さらに人員のスキル向上策、技術蓄積の場の確保なども扱うべきテーマです。


 なおビジネスやテクノロジーのリスクマネジメント手法は、品質リスクのマネジメント手法と比べて形式化あまりが行われていません。ただ参考にできる手法は色々存在します。
 例えばKPTなどによるレトロスペクティブの頻繁な実施などは、かなりアドホックですがリスクマネジメントの小規模な運用形態になりえます。またFMEAは、そのまま使えません(特にリスクのピックアップ部分)が、リスクマネジメントの流れやリスクの管理方法として、かなり参考にできる手法です。
 その他マインドマップブレインストーミングによる課題出し等は、リスクのピックアップ手法として有用です。


 ちなみに、適切なリスクマネジメントの運用は、個人でなく、チーム・プロジェクトとして実施すると有効です。というのも、以下のようなメリットが得られるためです。

  1. トップダウンでリスク軽減策が実施されます。リファクタリングよる保守性改善や、コードレビューでの変更性チェックといった活動も、開発計画上必要なものとして工数を割り当てられます。
  2. リスクの優先度に基づいてリスク軽減策の優先度を評価できるため、必要な保守性作りこみ、無駄な保守性作りこみの判断が容易になります。これによりスピード重視で劣悪なコードを書く人が評価され、少し手間を増やして保守性に優れたコードを書く人が評価されない状態を、ある程度防止できるようになります。
  3. トップダウンで変化に強いアーキテクチャやインターフェースを設計することができます。