オペレーション・ITの中期的変革アジャイル開発のポテンシャル最大化

アジャイル開発が注目を集めている。デジタル化の進展により顧客ニーズや競合環境が急速に変化する中で、企業もビジネスモデルの再構築やCX向上の施策を迅速に打ち出し、環境適応を図る必要があるためだ。しかし、レガシーシステムや保守的な風土を抱える大企業が、新たな手法を拙速に採用してもなかなかうまくいかない。トップマネジメントの強いコミットメントの下、アジャイルの特性を理解し、そのポテンシャルを最大限発揮できるような仕組みづくりが必要である。具体的には、アジャイルを活かせる領域の見極め、開発優先度の明確化、アジャイルに適合したガバナンス構築が求められる。さらに、組織・文化もアジャイル型に転換していくことが肝要である。
この記事をシェア
2019.01.11

アジャイル開発とは

アジャイルとは、直訳すると「素早い」「機敏な」「頭の回転が速い」などを意味する。アジャイル開発はシステム開発手法の一つであり、企画・開発・設計・テストを短期間に何度も繰り返して開発を進めていく。このアジャイル開発は、2001年にソフトウェア開発の思想的リーダー17名によって「アジャイルソフト開発宣言」が公表されて以来、スクラムやXPといった方法論を中心に広がりを見せてきた。

アジャイルソフト開発宣言
  • プロセスやツールよりも個人と対話を
  • 包括的なドキュメントよりも動くソフトウェアを
  • 契約交渉よりも顧客との協調を
  • 計画に従うことよりも変化への対応を

これまでのシステム開発では「ウォーターフォール」と呼ばれ、全体の機能設計・実行計画を最初に策定し、この計画に従って実装していく手法が主流であった。アジャイル開発は「アジャイルソフト開発宣言」にもある通り、最初に立てた計画に従うことよりも変化への対応を重視している。

課題意識

デジタル時代の到来を背景として、システム開発手法にアジャイルを適用しようとする企業が増えている。アジャイル開発では、計画に従うことよりも変化への対応を重視しており、ビジネス環境変化への柔軟な対応や手戻りリスク軽減といった効果が見込まれるからだ。一方で、従来に比べてよりタイムリーで正確な情報把握と迅速な意思決定、それに対応するスクラム(少人数チーム)が求められる。こういった点がうまくいかず、大幅な遅延やスコープ縮小が発生してしまうケース、ひいてはプロジェクト自体が中止に至ってしまうケースも少なくない。

要因として、大規模で複雑なレガシーシステムの存在が挙げられる。これらの影響・整合性確認、およびその改修を従来よりも短期間で対応するのだから、当然品質リスクは大きくなり、障害が多発するケースが散見される。さらに、多くの障害対応をこなすためにITリソースの枯渇を引き起こし、コストを投入して納期を優先することも往々にしてある。アジャイルを適用しようとしたものの結果として、Q(品質)とC(コスト)を犠牲にD(納期)だけを優先したウォーターフォール開発を超短期で繰り返しているだけ、といった非常にリスクが大きいプロジェクトになりかねない。

別の要因もある。アジャイル開発要員のスペック不足だ。アジャイル開発では少人数・短期間でチームプレイによってタスクを捌いていく。そのため、要員には主体性とマルチなスキルが求められる。しかし、そのようなエース級の人材をアジャイルの取組みに集結させるのは難しい。また、要員がのびのびと活躍する上では、失敗を許容する文化も欠かせない。この状況を打開するには、トップマネジメントのリーダーシップの下、短期的には組織制度に、中期的には企業文化にも手を入れる必要がある。

アプローチと成功の要諦①:レガシーシステムとアジャイルを共存させる仕組みづくり

そもそもアジャイル開発は、ニーズや要件が不明確な場面における柔軟性を期待されているものであり、リスクマネジメント手法の1つともいえる。それにもかかわらず、経営層は「アジャイル開発を用いればとにかく早くリリースでき、早急な効果が見込める」という妄信から、逆にリスクが大きくなる判断をしがちに見える。ではどうすればよいか。
 
アジャイル開発を成功させるためには、3つのキーポイントがある。
A)やみくもに全てをアジャイルで開発しようとしない
アジャイル導入を急ぐばかりに、場当たり的になんでもアジャイルで進めようとしてもうまくいかない。そのプロジェクトが、どこがウォーターフォールに、どこがアジャイルに適合するのか、正しく判断することが必要だ。判断の視点としては、大きく2つある。「システム開発範囲」と「要件確度」だ。システム開発範囲では、連携先のシステムとその特性を吟味する。要件確度では、要件の詳細部分の確度はもちろんのこと、今後の変更可能性や頻度にも着目することが必要である。

B)開発の優先度を明確にする
要件の優先度判断はユーザー部門が主体で行うが、要件をなんでも詰め込みすぎると、リリース遅延のリスクが発生してしまう。プロジェクト目的との紐づけや効果の早期実現(=Quick-Win)を考慮し、要件の優先度を切り分けた上でスケジュールを策定しなければならない。また、要件の整合性や充足性を担保するため、重要度の高い機能から段階的に、レビューのマイルストンを設定することも必要だ。

C)従来のガバナンス標準に固執しない
アジャイルでの開発を行う際は、従来のガバナンス標準を無理やり適用しようとせず、例外を許容することが重要だ。従来と同等の成果物や報告を求めていてはうまくいかない。迅速な意思決定・判断を行うために、最少人数での意思決定体制を構築することも求められる。ステアリングコミッティなどのマネジメントの確認・承認プロセスをむやみに重たくせず、能力のあるリーダーに意思決定権を委ねるのだ。それにより、機能・コスト・要員のスムーズな調整が可能となり、迅速なリリースを実現することができる。
 
また、アジャイルの開発手法を社内でスタンダード化していくためには、アジャイル開発にチャレンジして得られたナレッジにより、既存のガバナンス標準をアジャイル向けにブラッシュアップする必要がある。さらにはガバナンスの観点から、それらのブラッシュアップした標準を遵守・活用できているかをモニタリングすることも求められるようになってくる。そこは従来からのPMOが活躍できる領域であり、彼らが既存のプロジェクトマネジメント標準のオーナーとして培ってきた整備・展開・統制のノウハウやナレッジを活用し、自社に即したアジャイル開発のスキームを作りあげるのだ。

アプローチと成功の要諦②:組織・文化のアジャイル型への転換

アジャイル開発を社内のスタンダードとして浸透させるためには、「組織」や「文化」といった面にも目を向けることが重要だ。

組織の観点
アジャイル開発は、高い専門性を持った人材を部門横断的に集め、それぞれのメンバーに主体的に行動してもらう自律型の組織を前提として初めて、その真価を発揮する。しかし、本業との兼ね合いもあり、リソースの確保が難しいことも多い。高い専門性を持ったエース級の人材ともなると、本業の所属長も易々と手放したくない。この場合、兼務として参画することが多いが、人事考課としても本業が重視される中、アジャイルチームの活動に本気で打ち込む人は多くない。また、兼務でのメンバーが多くなると、アジャイルチームへの参加人数も多くなるが、これにより各メンバーへの責任が分散され、主体性が薄れていく。このようにならないために、アジャイル専任組織の設置や人事評価の見直し等、会社組織全体の設計が必要となってくる。

文化の観点
「自律型組織」というキーワードを挙げたが、そのような組織を構築するには、各メンバーに権限を委譲した上で、主体的に物事を進めることが必要である。しかし急に権限を与えられても、当人は困惑してしまうことが多い。日本は欧米と比較して、意思決定が階層的で合意を大事にする傾向があると言われるが、物事を決めるのに多くのステークホルダー、上司にお伺いを立てて意思決定を形成してきた人が、いきなり権限を与えられてもどう仕事を進めてよいか分からないのだ。また、アジャイルはスピーディーな振り返りで阻害要因を取り除き、生産性を向上させる。しかし、この振り返りがうまくいかないことが多い。自分と違う意見を敵対意見と感じてしまい、なかなか建設的な議論ができない。社歴や社内のパワーバランスに応じて忖度してしまうことで、表面的な議論に留まってしまう。さらには、減点主義的なことも阻害要因のひとつとしてあげられる。計画通りにいかないことを失敗と捉えていては、変化への対応を重視するアジャイルが浸透していかないことは明らかである。これら文化面での課題にはプロダクトオーナー等のリーダー層が、アジャイルをよく理解し、チームをエンパワーメントしていくことが重要だ。

このように、アジャイルを浸透させるためには、従来の組織や文化も大きく変えていく必要がある。そして、これら企業体質を変革するためには、トップの深い関与が何よりも不可欠であることは間違いないだろう。トップの強いコミットメントでアジャイルを社内のスタンダードとして浸透させ、その効果を最大限発揮させたいものである。