プロジェクトを成功に導く4つのベストプラクティス：アジャイル時代のプロジェクトマネジメント入門（終）

プロジェクト管理の基礎からアジャイル開発の理想と現実、成功例と失敗例、を紹介し、ベストプラクティスを提案する連載。最終回は、失敗するプロジェクトの“あるある”を示し、それを解決するための4つのベストプラクティスを提案します。

[後藤進，株式会社Cuon セールスディレクター兼プロジェクトマネージャー]

連載目次

　本連載では、これまで、プロジェクトマネジメント／プロジェクト管理の基礎知識から、アジャイル開発の理想と現実、成功例と失敗例までを紹介してきました。

　前回の「失敗するプロジェクトと成功するプロジェクト」では、「うまくいくプロジェクトはコミュニケーションのプラットフォーム化が重要である」と説明しました。今回は、その点を踏まえプロジェクトを成功に導くベストプラクティスを紹介します。

失敗するプロジェクトの“あるある”

　当たり前の話ですが、顧客、プロジェクトマネジャー、プログラマー、デザイナーなど、全てのステークホルダーは、「プロジェクトの成功」を願っているものです。しかし、不幸にもプロジェクトでは「失敗」も起こり得ます。その多くは、以下の2点に原因があると筆者は考えます。

1. プロジェクトマネジメントの役割が整理されていないこと
2. 要件定義・設計フェーズに技術的な裏付けがないこと

　1.は契約条件や商流が複雑なプロジェクトに多く見受けられるように思います。「プロジェクトマネジメントの範囲は課題管理や進捗管理だけなのか？」「ある程度の顧客要件をヒアリングして取りまとめるべきなのか？」などが整理されていない場合、設計・実装フェーズへのしわ寄せが多くなるのではないでしょうか。

　2.は特に重要です。例えば日本では「建築工事請負契約」の締結前に設計図書（設計図面・設計書・仕様書など）と見積書を確定した後に押印するなど、“実現可能性”を担保するように建築士法や建設業法などで取り決められています（参考：日弁連住宅建築工事請負契約約款）。

　一方でITの場合は、ビジネス要件・サービス要件の定義段階で、ITを「ツールにすぎない」と考えているためか、「仕様書はあるが設計書はない」ことはよくあるのではないでしょうか。加えて、関係者の物差しとなる業法もないため、品質や工期などで多くのトラブルが生じやすいのではないかと思います。

　このような事態に陥らないためには、どうすればいいのでしょうか。筆者が所属するCuonが心掛けているベストプラクティスを紹介するので、参考にしてみてください。

【その1】プロジェクトマネジャーはプログラミングの知識があるべき

　まずCuonでは「プロジェクトマネジャーはプログラミングの知識があるべき」としています。

　これは、プロジェクトが失敗する原因の多くは、プロジェクトマネジャーの仕事がリソース管理・スケジュール管理に特化してしまい、“実現可能性”を担保できない、想像できないところにあると考えているからです。

　ウオーターフォール型のプロジェクトならまだしも、ビジネスの拡大に寄与するITを駆使したサービス系のシステムは迅速な開発・方向転換が求められます。その時に必要なものは“実現可能性”ではないでしょうか？

　また、プロジェクトマネジャーはプログラミングの知識があると、プログラマーと適切なコミュニケーションがとれることもメリットです。これにより、アジャイル開発という“ブリッジ”を「プロジェクト」と「成功」に架けることができると考えます。

　これらの考えにより、後述しますがCuonでは、社内勉強会にプロジェクトマネジャーも参加しています。

【その2】自社の開発スタイルに合わないプロジェクトの提案は行わない

　加えてCuonでは「自社の開発スタイルに合わないプロジェクトの提案は行わない」をアイデンティティーとしています。

　例えばCuonではRuby on Railsで開発をすることが多いのですが、下記の3つを常に心掛けています。

1. 「The Rails Style Guide」などを参考にしRuby on Railsのコーディング規約に従うこと
2. 自社の中で品質や効果を検証したGemやデバック系、開発支援系のライブラリ群を適切に使用し、効率良く開発すること
3. 実装方法を社内で共有化しメソッド化すること

　特に最後のメソッド化に関しては勉強会を毎週設け、プログラマーだけではなくプロジェクトマネジャーも参加してコーディングについて意見を交わしたり、日頃コーディングでハマったところやその解決方法をコミュニケーションツールの「ChatWork」「esa」などで共有したりしています。そして、その結果を「標準ライブラリ」としてドキュメントにまとめています。

　このように、自社の“開発スタイル”を確立し、独自の提案を行うことで、プロジェクトマネジメントとコーディング両面から、顧客の期待に応えることを担保できると考えています。

【その3】自社の開発スタイルからプロジェクトマネジメントの役割を整理する

　今までお話ししたようにCuonでは“実現性”を担保することを自社プロジェクトマネジャーにプログラミングベースで求めます。またプロジェクトと自社の“開発スタイル”の適性を重視します。

　そのことにより、プロジェクトを実現するための“スケジュール”と“リスクマネジメント”が可能です。プロジェクトマネジャーが技術的な裏付けを持ったプレイングマネジャーであることにより、課題や要望を正確に診断・検知してスケジュールをコントロールできると思っています。

【その4】アジャイル開発をするときは画面遷移図を共有する

　最後に連載第3回『「アジャイル」という言葉が一人歩き――アジャイル開発における理想と現実』でお話しした「請負契約でアジャイル開発の手法を採る場合にどうするべきか？」について回答し、本連載の締めとします。

　Cuonが請負契約でアジャイル開発を採用した場合は、イテレーション割当実施前に「リリース時の機能と効果に関して合意し」「合意内容を反映した画面遷移図を作成する」フェーズを設けます。

　アジャイル開発は特に、UIデザインや見た目の動きなど細部へのこだわりが本来の要件自体に影響する場面に多く遭遇します。そのような場合、画面遷移図をベースにそのアプリケーションの目的や効果を再確認することで、要件のブレを直したり許容したりします。こうすることで、アジャイル開発の本来のメリットであるイテーション開発が効果を発揮する環境にしています。

　また、この際の画面遷移図の活用は、【その2】で説明した“開発スタイル”を裏付けにすることが大前提です。

自分の会社でもベストプラクティスを考えてみよう

　このように、サービスの実現可能性をプログラミングベースでイメージできることを大前提とすること、そして、自らの開発スタイルがプロジェクトの目的・サービス・機能に合致していることで、開発プロジェクトの最大の目的である“顧客のビジネスを成功に導く”ことを支援できると思っています。

　本連載で紹介してきた、プロジェクトマネジメントの基礎知識やアジャイル開発の基礎知識、プロジェクトの成功例と失敗例、そしてCuonの考え方を参考に、皆さんの会社でもプロジェクトを成功に導くベストプラクティスを考えてみてはいかがでしょうか。