アジャイル開発における契約前のコミュニケーション
2016/05/24
僕が一番したいシステム開発のスタイルは、アジャイルな開発 です。
それは、自身の 役割/立ち位置 が「企画側/発注側」だろうが「開発側/受注側」だろうが、変わりません。
決して順風満帆なアジャイル開発ライフでは、御座いませんでした。
いや、いや、、、お恥ずかしいですが、順風満帆どころか、かなりの 波乱万丈なアジャイル開発ライフでした。
「失敗体験から学ぼう」一括請負でのアジャイル でもご紹介させて頂きましたし、それ以外にも何度も何度も、ハチャメチャ痛い経験を積み重ねてきました。
色んな人を巻き込んでしまいました。
巻き込んでしまった人の数より 更に多くの人に迷惑を掛けてきてしまいました。
そんなイケてない自分が腹立たしくて腹立たしくて自暴自棄になり、精神崩壊気味になってしまったこともありました。
でも、まだ「僕が一番したいシステム開発のスタイルは、アジャイルな開発です」。
そんな、ド M な僕ですが・・・
そろそろこの状況に真っ向から挑戦し、改善するための動きをするのだ!と決めました。
この好ましくない現状に真っ向から挑戦し、この状況を変えるための動きをする事にします。
契約締結前の コミュニケーションを丹念に錬金し、それをシンプルにし、研ぎ澄ます ことで、この状況を変えるための第一歩を踏み出そうと思います。
その結果を、素晴らしい提案書に纏め上げることが、最初のゴールですが、その前に「絶対に外せないとおもうコミュニケーション」のポイントを整理しておきたいと思います。
スポンサーリンク
契約前の「絶対外せないコミュニケーション」ポイント
そのゴールへの第一歩として、アジャイル開発における契約前のコミュニケーションについて、私見を整理してみました。
アジャイルの特徴、進め方や顧客に期待することの合意が得られているか?
- 「アジャイルソフトウェア開発宣言」の4つの優先すべき価値に同意してくれているか?
プロセスやツールよりも 個人と対話 を、
包括的なドキュメントよりも 動くソフトウェア を、
契約交渉よりも 顧客との協調 を、
計画に従うことよりも 変化への対応 を、価値とする。すなわち、左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。
- 「アジャイルソフトウェアの12の原則」を説明した上で、特に顧客の協力が必要な下記事項について合意が得られているか?
環境と支援を与え仕事が無事終わるまで彼らを信頼します。
情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。
動くソフトウェアこそが進捗の最も重要な尺度です。
アジャイル・プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。
チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。
- ソフトウェア開発の進め方を理解して貰った上で、顧客に期待する役割について合意が得られているか?
“作ること” が最優先になっていないか?
- システムを、最初に決めた計画どおりに「作ること」を最優先の価値とするのか、それとも、作ったものから「得られるもの」の価値最大化を最優先とするのか?
- 顧客がどちらを優先するのか、見極める必要があります。
- 意思決定が苦手なタイプの顧客や、複数の部門に跨ったプロジェクトは危険度が増します。
開発の真最中においても、リリース時期を競合、市場の動きや投資対効果の状況にフィットさせ、フレキシブルに調整出来ることのメリットを、意思決定者が理解しているか?
- 最初に作りたかったシステムの完成像の前に、競合や市場の動きに併せてリリース出来ることのメリットを理解しているか?
- 自社の投資を最大化させる為に、フレキシブルにリリース時期を調整出来ることのメリットを理解しているか?
意思決定者は、上述した「フレキシブルなリリース」を念頭に置き、開発したい機能の優先順位をダイナミックに検討し確定する事を継続可能か?
- リリースしたい時期をフレキシブルにする為にも、機能の優先順位を検討出来るか?
アジャイルな進め方のメリット/デメリットを説明しているか?
- メリットだけではない、ウォーターフォールにはウォーターフォールのメリットがあるし、アジャイルにもデメリットはある。そのことをちゃんと説明出来ているか?
契約は、準委任もしくはレベニューシェアで締結出来るか?
- 請負では無い契約の場合、極端に言うと「キャッシュアウトは発生するが、一般公開出来るシステムは出来ない」可能性があることを、ちゃんと説明出来ているか?
動作するシステム以外に必要なものについて、それの具体的な内容と役割分担を顧客と合意出来ているか?
- 顧客側で必要とさせるドキュメントは?
- ユーザー教育はどうする?
- システムの運用保守はどうする?
ビジネスの変化へ柔軟に適応することと、当初の計画を死守することとは矛盾した要求だと、きちんと理解して貰えるか?
- 顧客にとって一番大切な目標を達成する為には、プロジェクトの計画を変更する可能性がおおいにある。
- 当初の計画は、「希望」でしかない、ほとんどの場合において、アテにならないもの。
上記までを馬鹿正直に説明した上で、顧客に信頼してもらう為の情報を、真摯に説明しているか?
- 今までの開発プロジェクトの実績(システムの種類、生産性)
- 他の顧客からの評価
顧客と仲間になれそうか?丸投げ体質で無いか?顧客の人間性を信頼出来るか?本音で議論出来る相手か?開発チームを信頼してくれているか?
- アジャイルで開発し、プロジェクトの目的を「作ること」ではなく、「作ったものから “得られるもの” の価値最大化」を目指すには、強力な信頼関係が必要
- この人達と一緒にやれるのか?