ウオーターフォール中心の企業が見直すべき4つの課題：特集：「差別化」をリードする、アジャイル時代のプロジェクト管理（1）

先が読めないニーズの変化に対応しながらITサービスを開発するためには、どのようにプロジェクトを管理すれば良いのだろうか？手作業中心の「静的な管理」がもはや通用しない理由と、今求められる「動的な管理」の要件を考える。

» 2016年03月01日 05時00分公開

[編集部,＠IT]

大企業にも強く求められる、アジャイルやDevOpsのアプローチ

　今、ソフトウェア開発の在り方があらためて見直されている。背景にあるのは、ニーズに対応する「スピード」が差別化の一大要件となる、昨今の市場環境変化の速さだ。

　今やおよそ全てのビジネスをITが支えている他、Webやモバイルが社会に深く浸透し、社外に提供するITサービスも収益、ブランドを左右する重要な顧客窓口になっている。加えて近年のIoT、FinTechトレンドにおいては、ニーズの変化に迅速に対応するだけではなく、センサーなどから得たデータを分析して潜在ニーズを掘り起こし、ITサービスとしてスピーディにリリースする、その反響を見て機能を改善するといった、PDCAサイクルを高速で回すスタイルも求められている。

　だが何より重要なのは、こうしたシステム開発の在り方が、スタートアップやベンチャー、Webサービス系企業だけではなく、一般的な大企業にも強く求められていることだろう。

　近年、システムに求める特性を「高度な安定性、信頼性を重視するSoR（System of Record）」と、「ニーズ対応のスピードや使いやすさ、楽しさなどを重視するSoE（System of Engagement）」に分けて、最適なシステム開発、運用方法を適用するやり方が浸透しつつある。SoRとSoE、共に「エンドユーザーの満足度向上を狙う」ことは同じだが、システムの特性によってそれを実現するための要件は異なる。この点を見据え、開発・運用という“手段”についても最適なものを適用しようという考え方だ。

　その点、ウオーターフォール型開発は、「ニーズの変化を読み、次の打ち手を考え、実行する」といった「ビジネス展開のペース」に合わせてスピーディかつ柔軟に変化に対応することが基本的には難しい以上、SoE領域には自ずとアジャイル開発やDevOpsのアプローチが求められることになる（無論、SoR／SoEにどの開発手法を適用するかは各社の目的・組織次第であり、必ずしもこの限りではない）。

　つまり、エンタープライズには多種多様なシステムがある以上、ウオーターフォールとアジャイル開発／DevOpsを、システムの目的・特性に応じて使い分けることが「システムのビジネス目的」を達成するポイントになるわけだが、多くの国内企業はウオーターフォールのスタイルが主流。目的に最適な手段を適用できるか否か――これが大規模な企業が勝ち残るための一大要件になっていると言っても過言ではないだろう。

ビジネス展開に連動した開発、リリースを阻む4つの課題

　だがウオーターフォール主体でやってきた企業が、アジャイル開発やDevOpsに取り組む上ではさまざまなハードルが存在する。中でも大きなハードルの一つがプロジェクトの進め方だ。

　例えばアジャイル開発では、ビジネス部門と密にコミュニケーションを取り、2週間などの短いスパンで“動く開発成果物”を都度確認することで、手戻りを抑制しながらスピーディに開発を進める。それを安全にリリース、運用、モニタリングする上では、運用部門や基盤部門など、各関係部門との連携が不可欠だ。こうしたコミュニケーションを取る上では、SIerなどに開発を委託している例も含めて、社内外の組織体制やコミュニケーションの在り方を考慮しなければならない。

　特に問題となるのは「プロジェクトの進捗をどう管理するか」だ。まず、部門の異なる関係者間でどのようなKPIを設定するのか。部門が異なれば、利害が異なることも多い。こうした中でも「共通のビジネスゴール」を設定し、関係者間で「共通のKPI」を持たなければ、プロジェクトは各部門でサイロ化してしまう。

　また、市場の動きを見通しにくく「何が当たるか分からない」中では、最初に要件を決められないこともあれば、途中で要件が変わることもある。だがビジネスを推進する上で、普段使われている知識や言葉、ビジネスを見る観点も部門によって異なるのが一般的だ。そうした中でもお互いの考えやプロジェクトの進捗、成果を正しく認識するためには、どのようなコミュニケーション体制があれば良いのか。「動的なプロジェクト」が求められる中で、どのような体制があれば、ビジネス、開発、運用など各関係者間で確実にコンセンサスを取り、変更に正しく対応できるのか。

　「動的なプロジェクト管理」という点では、多くの企業で使われているMicrosoft Excel（以下、Excel）を使った手入力による管理も課題となる。Excelは基本的に個人利用を想定したツール。ファイル単位で情報を管理するため、情報共有用途においては、バージョンの異なる情報が散在し「どれが最新の情報か分からない」といったことが起こりやすい。ファイルサーバなどで共有する方法もあるが、勝手に上書きされ、正しい情報が共有されない可能性もある。

　変更が発生する中でも成果物の品質を担保する上ではトレーサビリティも大きな意味を持つ。変更があるたびにファイル名を変えて保存するExcelでは、ファイル数が増え、何かあった際に履歴をたどることが煩雑化しやすい。

　いずれにせよ、スピーディかつ柔軟なプロジェクト推進が求められる中、情報共有に「人の注意」が不可欠となるような属人的な管理では、それ自体が大きなリスクになると言えるだろう。立場や観点の異なる関係者同士が、どうすれば「動的に移り変わるプロジェクト」の進捗を、正確・確実に把握できるのか？――この問題を解決できなければ、開発のスピードダウンや成果物の品質低下、すなわち機会損失やブランド力低下に直結してしまうのだ。

「プロジェクトマネジメント」は、「プロジェクト管理」ではない

　しかし、こうした中でもニーズを読み取り、条件反射的にシステムを開発・改善できる体制を築いている企業は存在する。彼らに共通するのは、各部門が情報と成果物を正しく共有できる「仕組み」を築いていることだ。DevOpsやアジャイル開発に関する過去の取材でも、共通して以下のような考え方が聞かれた。

　例えば各種設定をする上でも、「ここにこういうルートでモジュールをリリースしたいのでポートを開けてください」「この実行権限をください」といった具合に、細かな調整を（開発と運用の）両部門の間で行うことになります。また、リリースされたサービスの評価指標を基に測った、性能測定などの結果をいかにリアルタイムに分かりやすくビジネスサイドに返せるかというログ解析の仕組みも不可欠です。

　企画、開発、運用、フィードバックといった円環が回るような土台を作る上では、こうした対話を密に行う必要がある。それは一連の円環に他社が入る場合も同じです。アーキテクトの観点を持った人間が、全体観を基に、全ステークホルダーと調整することが不可欠です。（グロースエクスパートナーズ　ビジネスソリューション事業本部本部長執行役員でITアーキテクトの鈴木雄介氏／出展：「DevOpsというバズワードに流されないために」2013年12月）

　想定ユーザー数が100万～1000万人規模のサービスになると、快適なレスポンスを担保したり、新機能を追加したりと、ニーズに応えながらサービスを運用していく上で、どんなアーキテクチャを採用するかが、その後の収益構造に大きく響くことになります。しかし最初の段階で判断を間違うと、後から修正することが非常に難しくなる。従って、早い段階からビジネス部門、開発部門、運用部門が、それぞれの視点で、ともに計画を考えることが重要なんです。（DeNA システム本部本部長茂岩祐樹氏／出展：「DeNAのサービスが強い、速い、本当の理由」2013年6月）

　彼らは以上のような考え方を基に、自社の組織や特性に応じた“自社なりのコミュニケーション基盤”を築いている。詳しくは上記記事を参考にしていただきたいが、重要なのは、冒頭で述べたように、こうした開発・運用体制がベンチャーやWebサービス系企業に限った“特別なもの”ではなく、金融、流通、小売り、製造など、業種を問わず一般的な企業にも強く求められているということだ。

　また一般に、「プロジェクトマネジメント」は「プロジェクト管理」と訳されることが多いが、「マネジメント」とは単なる「管理」ではない。組織の目的を実現するために、現状を評価、分析し、ゴール達成に向けて組織をリードすることを意味する。この点も、昨今の状況に照らしてあらためて認識し直す必要があるのではないだろうか。

　だが市場環境はわれわれの変革を待っていてくれるわけではない。また、IoTやFinTechトレンドでは、「これまでになかったようなサービス」を作るために、複数の技術を組み合わせたり、APIを通じて他社のITサービスと連携させたりと、プロジェクトはますます複雑化する傾向にある。

　ではこのような中、一体どのような体制を整えればニーズの変化に対応できるのだろうか？本特集では複数の企業事例を通じて、IoT、FinTech時代、差別化に寄与するプロジェクト管理の具体的なノウハウを明らかにする。