8． 受注側 開発責任者の心得
8.1 アジャイル開発を受注するときに確認する
■ 本質的には受注側にプロジェクト・マネージャ(PM)は不必要な存在になります。
成熟したアジャイル開発において受注側の開発責任者、ウォーターフォール開発で言えばプロジェクト・マネージャ（PM）の出番は、本質的にはありません。ただし、日本におけるいくつかの事情と不都合に対応するために存在しなければいけないケースがあります。
■ 最大の役割は、請負開発契約になりそうになった場合の阻止です。
日本の主流のソフトウェア開発のスタイルはウォーターフォール開発です。多くの顧客も従来ウォーターフォール開発スタイルで実施してきています。その流れと無思考主義者・前提主義者等の抵抗で、アジャイル開発スタイルであっても請負開発契約を求めてくることがあります。アジャイル開発を請負開発契約で受注してはいけません。目先の売り上げに目がくらんで、不良プロジェクトを発生させてはいけません。
図8-1 開発スタイル判定フロー
■ アジャイル開発を実施するのであれば、準委任契約に修正してもらうのはあなたの役割です。
1章で述べたように、アジャイル開発を請負開発契約で実施しようとすると合理的に考えて失敗します。それを準委任契約に変更してもらうことこそ、あなたの役割です。たとえば、その際にこの書籍の1章・2章が顧客との交渉の一つの参考になることを願っています。なお、日本では準委任契約の中に「瑕疵条項」を加えることも可能なので油断は禁物です。その場合、契約書の件名が準委任契約だからといっても結局、製造請負契約と同等の問題が発生します。契約書の各条項を精査し、リスクが無いことを確認することはあなたの役割です。
■ もし製造請負契約で受けてしまったら、あなたの役割はウォーターフォール開発スタイルを貫いて開発を進めることです。
万が一、製造請負開発契約で受けることになった場合には、仕様と見積りに対して納品する姿勢を貫きましょう。POの仕様変更・追加の要望に対して、「それは仕様に含まれていません」、「それは見積りの条件とは異なるのでできまません」、「仕様は既にFIXしましたので、新たな要望は契約変更をご検討ください」、を連発することがあなたの役割となってしまいます。
■ 受注側からアジャイル開発にしましょう、と誘導するのは無責任です。
アジャイル開発は、ソフトウェア完成責任が発注側にあります。そして、1章で学んだように発注側の幹部の意思・価値観、制度の整備、責任を持てるPOの存在などの準備が必要です。気軽に言い放つものではありません。発注側にはメリットも多いが責任も大きくなることをきちんと伝えて、順序良く発注側の意思を固め、制度を確認してもらうことがWin-Winになる近道です。
■ 非常に信頼できるPOが、請負開発でもなんとかする、と言って来たら・・・
もし、非常に信頼でき、これまでも良好な関係を保ってきた納品物検収の権限も持つPOがアジャイル開発を（発注者側の経営幹部価値観や組織制約の都合で）請負開発契約でやりたいと言って来たらどうするべきでしょうか？仕様を上手く書くことによって柔軟な変更に対応する開発物を許容することも不可能ではありません。受注側としても非常に難しい判断を求められるでしょう。
最大のリスクは、そのPOが異動・転籍した際に誰が正常納品を担保できるか、の合意形成です。あるTVドラマのフィクションですが、銀行員が長年をかけてお年寄りと心からの信頼関係を構築し、絶対に損はさせないと口約束で投資信託を買わせます。銀行は売買手数料を稼いでいきますが、数年後に元本割れでお年寄りは大損害を出しました。そのとき、銀行は、その担当者を突然地方の支店に異動させるのです。口約束だけというのはトラブルが発生した後では、大変もろいものなのです。企業としてはリスクに備えざるを得ないでしょう。未完成リスク、低品質リスク、瑕疵リスク等についての回避策が記録を残す形で合意できれば請負開発契約でアジャイル開発をすることもありでしょう。
ただし、その特別な力量と信頼関係に基づくこの行為は、それを真似た近隣のプロジェクトを惑わせ失敗させるかもしれません。また、発注側幹部の組織問題の気づきを遅らせてしまうかもしれません。
■ 前半はアジャイル開発を準委任契約で作り、後半はウォーターフォール開発を製造請負開発で実施して品質を確保したいと言って来たら・・・
前半のアジャイル開発は進めて問題ありません。しかし、当初、前半の契約を実施する際に予め伝えておくべきことは、前半の成果物が完成後にその成果物の出来具合を見極めて費用・期間を再見積りすると宣言することです。
最初から、全体の費用・納期ありきで、前半だけアジャイル開発受けることは避けるべきです。どんなに誠実にアジャイル開発に協力しても、POの判断が失敗すれば、前半のアジャイル開発は失敗することがあります。試験の議論以前に、動くものが何も作成されないことだってあることを忘れないでください。
アジャイル開発でプロトタイプ・システム等が動いた後のタイミングに、ウォーターフォール開発で実施すべき要求仕様の提示を受け、改めてKKD法で見積ることになります。すでに顧客の調整能力、ステークホルダとの関係、主要なアーキテクチャの合意、機能開発や非機能開発上の課題がより具体的に見えていれば、それらを十分勘案して見積りましょう。それが顧客の予算と期間に納まるのであれば、ウォーターフォール開発で実施することも可能でしょう。KKD法の「K＝経験」が増加し見積りの精度が上がっているためです。逆に、前半の経験で、重要機能の実現の目処が立たない、結局何を作りたいのかわからない、ステークホルダに対して発注者側の立場が弱く仕様がよく変わる等を知ったことで撤退という判断もあるでしょう。前半のアジャイル開発部分の「品質見解」を表明するのは発注者側POの責任になります。どうしても受けざるを得ない場合には、試験した結果だけを請負契約で担保することが懸命です。
■ 初回はウォーターフォール開発、その後は、アジャイル開発という進め方は、妥協可能な進め方かもしれません。
その場合、初回のウォーターフォール開発は、作るべきものの仕様が最初からほぼ見えていること、期間には余裕があること、受注側がそれを経験等によって見積れること等の条件に合えば不可能ではありません。初回の開発物をあまり先進的なものにすると失敗のリスクが高まりますので、類似のシステムが既に存在するようなものの開発が望ましいでしょう。その後のアジャイル開発によって、機能改善を実施していくことで後々の開発スピードアップは可能でしょう。
ただし、この進め方には弱点があります。ウォーターフォール開発とアジャイル開発では開発者への要求スキルが変わることです。最初からアジャイル開発の人材を集めて実施した方が良いソフトウェアができる可能性は高まるでしょう。アジャイル開発の人材を集めて、最初の数ヶ月はウォーターフォール開発の各開発工程をそのままスクラム開発でいうスプリントとして実施し、一旦、試験工程まで完了させるのです。その間、アジャイル人材としてのスキルの問題があればその対応も実施しチーム力を向上させていきましょう。
■ 契約種別に応じた見積りの違いを理解しましょう。
契約種別によって、見積り手法は変わります。
- 請負開発契約なら、仕様を受けて、その完成に必要な金額(リスク対応費込み)と、必要な期間(リスク対応期間込み)と、見積りの条件を提示します。
- 準委任契約なら、技術者のスキル要望と期間を受けて、各スキルに対応する単金の和と求められる期間の面積を提示します。
■ POの力量は見極めて受注しなければいけません。
POがアジャイル開発の成功の鍵を握ります。たとえ受注側に完成責任が無いといっても、成功しそうも無いシステム開発プロジェクトに優秀な技術者を割り当てるほど、優秀な技術者は余っていません。船頭のいない船に乗らないために、POに対していくつかの観点で事前に確認した方が良いでしょう。事前に指摘することで、改善できればWin-Winの世界に繋がるでしょう。
2章 経営幹部、3章 POの各心得を確認しましょう。
■ POチェック観点１： 幹部の意思・価値観、会社制度、PO人材育成・援護
- 経営幹部＆POがアジャイル開発をやりたいと思っているか。
- 発注側組織が準委任契約によるソフトウェア開発を認めているか。
- POが発注側組織においてステークホルダとの交渉権や開発管理者としての権限を持っているか。
■ POチェック観点２： POの自覚
- POがゴールのイメージを持っているか。
- アジャイル開発の完成責任が自分にあることを理解し納得しているか。
- POが主体性を持ち、迅速かつ適切な優先順位を判断し続けないと、良いソフトウェアの完成に至らないことを理解しているか。
■ POチェック観点３： ウォーターフォール開発との違いの理解
- ウォーターフォール開発とアジャイル開発のスタイルの違いを正しく理解しているか。
8.2 POをサポートする
■ POを全力でサポートしましょう。
アジャイル開発では、POが完成責任を負います。しかし、受注側は責任がなくなったことを喜ぶのではなく、Win-Winを目指し、POが完成責任を全うできるよう全力でサポートするべきです。（そう思わせてくれるPOであるべきです）
■ 顧客側幹部にPOへの援護を依頼することもあります。
POに起因して現場のモチベーションが低下している場合など、アジャイル開発が失敗しそうなときには、まずはPOに改善を求めるべきですが、それでも改善しない場合には、あなたが顧客側幹部に直接エスカレーションしなければいけないかもしれません。それを行えば最悪の場合には、アジャイル開発は中止と判断され受注契約が途中で打ち切られる可能性も発生します。しかし、悪い情報を早めに共有して次の進め方を相談するのが、アジャイル開発です。
顧客側に完成責任があるのがアジャイル開発です。現実は正しく共有し、顧客側企業とはWin-Winのための姿勢を貫くべきだと考えます。顧客側幹部がアジャイル開発を理解し推進してくれているのであれば、POに対して適切な援護をしてくれるはずです。
■ あなたのウォーターフォール経験も、アジャイル開発を邪魔します。
注意しましょう。詳細は7章を参照してください。
8.3 作業管理責任者として行動する
準委任契約で受注する場合には、派遣契約とは異なり作業管理責任者の設置と、作業管理責任者を通した作業指示が求められます。その役割は放棄することができません。
■ プロフェッショナルとして善管注意義務は果たさなければいけません。
受注会社は、情報処理技術についてプロフェッショナルでなければいけません。準委任契約では、プロフェッショナルとしての 善良な管理者としての注意義務（善管注意義務） を果たさなければいけません。
■ 突然のプロジェクト中止に注意しましょう。
準委任契約は、月額精算などの仕組みを利用すると、契約中止の判断は非常に気軽になります。しかし、プロジェクト中止の場合には、最低でも前月末までに中止の旨をメールなど記録に残る形で通知することを合意しておきましょう。
■ 維持管理はDevOpsを念頭に発注側と交渉しましょう。
システム開発の後には維持管理が発生します。アジャイル開発と同時に維持管理の進め方についても合意しておくことが望まれます。
製造請負開発であれば、仕様に違反していれば瑕疵対応で無償改修を要求することが可能でした。しかし、日本では仕様も曖昧であり、瑕疵を明確に指摘することは意外に困難な作業です。さらに、瑕疵対応のパッチが提供されたとしても、それを運用中サービスに導入適用するコストは別途発生します。それらの混乱を避けるべく保守サービスを締結し、開発費用の10％～20％を支払い続けることが行われているでしょう。場合によっては、次期開発の中に保守サービスを含めてしまうこともあるでしょう。
アジャイル開発では、受注側に瑕疵が発生しません。商用サービスであれば必ず保守サービスが必要になります。その時、世に言うDevOpsの世界がそれを効率的に解決してくれる枠組みになるかもしれません。
■ ウォーターフォール開発経験のある担当者がアジャイル開発に上手く適応できるとは限りません。
ウォーターフォール開発では情報処理能力が高くない人材でもプロジェクトに参加させることが可能でした。アジャイル開発ではコミュニケーション・ロスを少なくするため少数精鋭が求められることもあり、設計からコーディング、テストまで全工程の能力が求められます。テストしかできない、Javaコーディングしかできない等のスキル幅が狭い担当者については発注者から厳しいスキル査定を受ける可能性がありますし、当の本人もモチベーション維持が難しい旨の申告がある可能性があります。
■ アジャイル開発の合理性を知った高スキルの技術者は、不合理なウォーターフォール開発に戻りたくないでしょう。
アジャイル開発では、3Kが発生するような不合理は発生しません。また、POの価値観を理解できた開発担当者は、POとの一体感と達成感を得ることが可能でしょう。そんな担当者がウォーターフォール開発に戻ることになった場合、著しくモチベーションが低下する事態が発生する可能性があります。人事制度見直しなどと連携して企業と高スキル者とのWin-Winの姿勢を実現していかなければいけません。
■ アジャイル開発では、従来とは人材の育成方法が変わります。
アジャイル開発では、開発担当者は受身の姿勢が強くなるケースがあります。POが優秀な場合に全てを指示してくれるから、そこに依存してしまうからです。しかし、開発人材の育成として望ましくはありません。いつでもPOの代わりになれる視界とスキルを持つビジネス・リーダ人材を育成していきましょう。
■ 人材の育成に伴うプランを発注側と早目から共有し、ロックインを避けておきましょう。
アジャイル開発では、開発におけるキーマンが固定化されることが進みます。長期に渡るプロジェクトにおいて、属人化はプロジェクトの弱点となります。ソースコードから読み取りにくい情報はドキュメントに記録し、共有し、自動リグレッション・テストの整備を実施して属人化を防いでいかなければいけません。さらに、優秀な開発キーマンには次の育成ステージに進むための人事異動が避けられないかもしれません。育成プラン等については、それが発生することを予め顧客側へ伝えておくことも大切です。なお、準委任契約において、顧客側が個人を指定することはできません。けれどもプロジェクトの継続にできるだけ影響のでないような備えと関係を維持していくことが大切です。
8.4 受注側組織の体制・価値観をVerUpする
発注社側の経営幹部はアジャイル開発に適合する組織に変えていかなければいけません。同様に受注社側の経営幹部もアジャイル開発に適合する組織にしなければいけない場合があります。
■ 「口利き」と「背取り」ビジネスは高利益ですが、続けると、体力が落ち、最後には「中抜き」されます。
昔、総合商社が全盛を極めた時代がありました。商社のビジネス・スタイルは売りたい会社と買いたい会社を結びつける「口利き」ビジネスです。両者を仲介し手数料をもらう「背取り」をするビジネスモデルを持ち、世界中の商品の取引をつなぐことで莫大な利益を得ていました。しかし、海外の資源素材会社と日本国内の製造・販売会社、製品出荷先の海外市場間で直接取引できる時代が訪れると、「口利き」の価値が薄れ商社は「中抜き」によって一気に苦境に陥ります。その後、商社は自ら鉱山等の資源を開発し権利を所有し、それらに付加価値を加える能力を自らが持つことによって復活を遂げてきました。
一方、ソフトウェア業界における請負開発契約によるソフトウェア開発は、ゼネコンモデルとも言われる多層請負で実施されてきました。発注者から受けた製造請負を、同じ製造請負で下請け社に発注できれば、口利きと背取りによって苦労せず大きな利益を得ることも可能でした。巨大なプロジェクトであれば複数社に分割発注するための分割調整や、基本設計などの上流工程の実施によって付加価値を出すこともありました。そのビジネス・スタイルを極めている会社において、準委任契約をベースとするアジャイル開発では高い利益率を実現できないビジネスだと認識されるかもしれません。もし、特定の発注先を独占的に維持できる能力があれば口利きと背取りは最高のビジネスモデルでしょう。
口利きと背取りを長く続ける組織に起こる問題は、ソフトウェア開発基礎体力の喪失です。若いうちから口利きと背取りが評価される風土では、ソフトウェア開発本来の基礎力と経験はいつしか失われ、付加価値としていた設計力さえも失われます。ソフトウェア発注者の市場・競合のグローバル化と情報処理技術のコモディティ化、インターネットを活用したビジネスの進化の中で付加価値が見えない組織を間に挟み続けることは難しく、徐々に中抜きされていくでしょう。
■ 市場の変化にも負けない企業体力を維持するために、アジャイル開発を受け入れていきましょう。
インターネットによる技術革新（OSSやクラウドなど、さらにはIoTやAIといった最新技術）を活用するソフトウェア開発では、より試行錯誤のフェーズが必要になるでしょう。また、ソフトウェアによって実現されるサービスも益々PoC作りから開始される比率が高まります。そのとき、自らの組織で調査・設計～製造・試験までの工程を実施できる能力あることが市場競争力のあるスピードを実現します。若手を中心として、きちんと製造（プログラミング）の能力がある組織を目指すことが、良い設計者を維持し続けることに繋がるでしょう。
■ 顧客と同一場所で開発することは必要です。
繰り返しになりますが、アジャイル開発はコミュニケーションが大切です。ソフトウェア開発の中で発生する様々な課題に対して、直ぐにホワイトボードを囲んだ議論ができる環境が大切です。そして、報告ではない場での会話や、双方の気づきが理解を深めモチベーションを高め開発を加速していきます。原則として同一の場所で作業しなければいけません。それは、顧客側の場所であっても、開発側の場所であっても、中間地点の別の場所であっても構いません。特に、開発プロジェクトのゴールが十分に全員に理解されるまでの初期には極めて大切です。
■ POが現場と遠い場合には、開発チーム側にも技術面の代理POを置くことも考えましょう。
各メンバによるゴールの理解が進み、各メンバの主体性が発揮されるようになれば、様々なコミュニケーション・ツールによって代替していくことが可能かもしれません。しかし、ツールは大切ですが、それを過信しすぎてはいけません。POとの技術面のコミュニケーションを取り仕切る現場技術リーダを受注者側にて用意することも一つの方法です。POの価値観を理解し、設計の中心的メンバあって、コミュニケーション・スキルにも長けたメンバを代理PO・作業管理責任者として配置しましょう。
■ 複数の業務の掛け持ちをする場合には、同一顧客からの業務に限定しましょう。
ウォーターフォール開発では、一人の高スキル技術者が複数の案件を掛け持つことが可能でした。しかし、アジャイル開発では、それは避けるべきでしょう。全く異なる顧客からそれぞれ最優先として与えられた仕事を調整することは困難な作業です。もし、複数の業務を掛け持つとしても、それは同一の顧客からのものとし、優先度の判断で対立が発生しないものにすべきです。たとえば、開発プロジェクトと、維持管理プロジェクトを９：１の割合で掛け持つことは良い進め方です。提供サービス側で発生した重大故障に際して、開発プロジェクトの優先度を一時的に下げることは顧客と同意がしやすいでしょう。
8.5 品質保証（QA）部門の役割は、・・・微妙
アジャイル開発を製造請負契約で受注しないことを監視する必要はあります。しかし、製造請負契約のウォーターフォール開発に比べ、準委任契約で行うアジャイル開発でのQAの出番は明確ではなさそうです。もし、存在感を発揮するとすれば、以下の対応が必要でしょう。
■ POの視点でアジャイル開発を観測し、問題を抽出しましょう。
そのためには毎朝のミーティングに参加して、チーム状態を観測する必要もあります。
■ 発注側のPOにアドバイスしましょう。
アジャイル開発の進め方の問題があれば、POに対して意見する必要があります。スクラム開発には、スクラム・マスターというポジションがありますが、それに近いポジションにならざるを得ないかもしれません。
しかし、ウォーターフォール開発の時のような活躍の場があるのかについては、不明です。
2022.9.25 改版に向けて