アジャイル開発における受注者の裁判リスクと実務上の備え3 キックオフ
2025.09.15UP!
１．開発体制の取り決め
重要になるのは、責任者の取り決めであり、誰がどのように報告をするかはそのまま開発業者の重しになるものであり、重要な話である。そこの取り決めをしないで開発を粛々と行うと、俺は聞いていないというケースが増える。俺は聞いていないは非常に厄介で、プロダクトオーナーが聞いていないというのは、もはや業者とユーザとの関係の悪化につながりやすい炎上ものと言ってよい。
この点、ユーザは、他の業者に任せているので、そこに聞いてと流しやすい。これが非常に曲者で、後で俺は聞いていないと言いやすいのだ。他の開発業者は、ユーザにはいい顔をするが、そもそも手を抜きたいので開発業者をコントロールしないし、自分の開発さえしっかりやっておけば良いと考える。そして、プロダクトオーナーの他の業者に任せているからそこを通してという依頼は、見事にはしごを外される。すなわち、その業者に報告をしても、なんらの反応もなく、オーナーに報告されているかといえばされていないケースもある。又は、その基本設計をした会社がオーガナイズして、スケジュール管理をすることで、ユーザーサイドにちゃんとした計画が伝わり、透明化がはかれるところ、逆に情報の非対称性を狙い（ユーザに報告する権限）、悪い報告をユーザにするケースもある。しかも、基本設計をしている会社は、相手と喧嘩したくないので、ミーティングではいい顔し、嫌な仕事だけを押し付けるケースもある。自分の開発を優先させ、他社に責任を押し付け、スケジュールが押したら他社責任にしてしまう。
実はキックオフこそが、方針をより決めるときに決定的な権利関係を決めるものになりやすく、逆に、契約はオペレーションと離れていると重視されないケースもある。だから、契約だけを重視した開発は危険なのである。
オペレーションで重要なのは、計画であり、積極的に計画を提示したところはそれだけ責任を取らされる結果となる。だから、計画を提示すべきということではない。
寧ろ、力関係、その他が開示されるように、議事録を作り、ケースによっては録画をして、何が起きているのかを明らかにしておく必要があるのだ。
基本設計をしている会社の方が基本的に発注者の近くに立つため、発言権が強かったりする。ついついその設計者の言う通りにして、うやむやにすると、後で責任を取らされるのは自分になりかねないことに留意すべきだ。
基本、サイコパス的な人材が入ると炎上しやすく、その部分を予想して、紛争にならないようにプロテクションを逐次考えておくと、後々役立つことが多い。
その例としては、相手の漏れが多く、任せるよと言っておいて、聞いていないというケースは、以上の報告を事前にしており、それを受け取った旨のコメントをしてもらっていますが、どうしましょうかなど言及するなどがある。
これに対して、無理な締め切りと量を依頼するケースは人月にあわせてみるとどう考えても難しい。他でできる会社があるなら紹介して欲しいなど述べるなど、やんわりと述べつつ、記録に取っておくと、感情の機微なども含めて裁判資料になる。事前に何を用意するかで、結論は変わりやすい。
２．スケジュールの点
気の弱い人及び休みがちな人はマネージャーやスケジュール管理側にいてはならない。
プロダクトマネージャーから色々言われて怯むと、内部の人間は病む場合がある。この点、過去の車のナビゲーションシステムと今の車のナビゲーションシステムで大きな転換があるが、それは期待値調節が今のナビゲーションシステムの方が優れているため、参考になりやすい。運転時間が記載され、少しだけ早めに信号を通過すると到着時間が少しだけ変わる（この点過去は、大幅に変化しやすく期待値的には運転者の負担が大きかった）。
作業量が増えるとそれが可視化されてこうなるという（時間と料金）状況を見せて（見せた証拠を作る）、調整をしてもらう。この繰り返しが、鎮静化を呼ぶ。
この点、難しいのはプロダクトのトータルでのケアは見落としが必ず出ること。そして、その見落としを誰の責任にするかの話である。往々にして、立場の弱いものの責任になりやすい。この点、議事録には、責任者は以下のように述べた。・・・・。この点精査しなければ分からず、その精査については時間をおいて、例えば１５日２０日かかって報告をすることもあると伝えた」など記載をするしかない。その後に抜け漏れを探し、抜け漏れとともに、他にも抜け漏れがある可能性などを一応指摘しておくしかない。
キックオフにおいては、テストについて誰がやるのか、その仕様についても話し合う必要があり、その仕様についてギリギリになってから対応しなければならない場合、期限から３０日以上かかるケースもあることは伝えておく必要はある。ギリギリになってから、テスト仕様及びテストをしなければならないとすると、色々想定していない問題が発生するケースも多い。
この点、裁判官などは、工事と同じように考え、建物や道路のようにテンプレの通常のものがあると想像しがちである。それは大きく異なり、基本作り込みが必要であり、かつ、手戻りを考えて作る必要がある。意外と、裁判官の肌感とエンジニアの肌感は違うので、エンジニア側も話せばわかるという記録にしないことが大事である。この点、エンジニアよりも、GPTの方がメモを分かりやすく且つ第三者にもはっきりわかりやすく書くケースもある。
スコープをはっきりとさせる、作業時間や費用をはっきりさせ、かつ、納得感を作っていくのは契約後においても必要なのである。
開発の人、スケジュールの人は出来るだけ分けて、スケジュールの人はできるだけ開発の人を追い込まないようにバッファーを作り、メンタルケアをできるようにしておくことが肝要である。そうでなければ自分の首を絞めることになる。スケジュールの人はバッファー要員とし、必要に応じて入るという仕組みを作らないと、その開発要員が足らなくなったときに積む現象も出てくる。
同様に、スケジュールの人は、ユーザサイドが本来出すべきものを出さない場合は、その点について詰めて、延長を理解させる手腕も必要である。この点、基本設計の業者が窓口になってプロダクトマネージャーのように振る舞い、後でその業者が遅らせるだけ遅らせて、後に責任を負わせるケースもあるので、用心に用心を重ねることは必要である。
プロダクトログなどに記載するだけではなく、書面としてそうした状況を伝えたことを残していくことも肝要である。
無論、こんなことばかりすると、ユーザーに嫌われるよという人もいるが、裁判所に行けば必ず嫌われる話なので、ならば適度に釘を刺してうまく交渉で裁判所に行かないようにする方が費用対効果が良いことは理解しておく必要がある。
