180日で会社をやめるワニ、あと162日

今回もIT業界のお話を。今の私の会社の主な業務は受託開発です。要は各お客様のニーズに応じたオーダメードのシステムを作る業務ですね。その開発手法は伝統的なのはウォーターフォールモデルです。最近、ここ数年になって、やっとジャイル/スクラム開発のプロジェクトが出始めてきました。それでもまだ少数派です。

今、開発しているシステムもスクラムで開発しています。30年近くこの業界にいて、スクラム開発は初です。しかし、世の中、よその国では・・・

私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い - メソッド屋のブログ

そうですか、ウォーターフォールモデルには何のメリットも無いと言い切ってしまいますか。よその国ではスクラム開発が既に主流で、「ウォーターフォールモデル？今、この時代に？」ってかんじなんでしょうが、何故、日本ではウォーターフォールモデルが主流で、スクラム開発が浸透していないんでしょうか。そこには、この著者は言及していません。

私が思うにやはりそれは日本独自の商習慣なんだとおもいます。日本のIT業界にはよその国にはない「システムインテグレータ」という業種が存在します。それが、「お客様のニーズに応じたオーダメードのシステムを作る」業種なんですね。と言えば聞こえがいいですが、要はお客様の我儘を目いっぱい引き受けて作るやり方です。日本ではこのやり方が主流のため、同じ業界同じ業種であっても、会社毎に全く違うシステムになっています。勿論、業務フローも違います。これが、最近問題になっているDX化が他の国にくらべ大きく遅れる原因になっています。

日本では終身雇用という制度が昔から根強く残っているため、簡単に社員を解雇できません。システム開発の体制は山、谷が大きく、山に合わせると人が余るし、谷に合わせると人が足りないし・・・といった感じで簡単に人を雇用/解雇できない日本企業にとってやりずらいものがあります。

そこを埋めてくれるのが、「システムインテグレータ」。ここにお願いすれば、システム開発の山、谷に合わせて人を調達してくれて、うまいことやってくれる・・・という都合のいい業者です。

こんなシステムが欲しいという発注側と、「お客様のニーズに応じたオーダメードのシステムを作ります」というシステムインテグレータ側（受注側）は伝統的に、請負契約です。最初にどんなシステムを作るかを決めて（要件定義）、大枠を決めて（基本設計）、じゃこれを〇〇〇〇万円でお願い（発注）するわけです。請け負った側は「じゃ、完成までに〇〇月かかりますから、それまで待っててね」って（受注）、完成したら出来ましたとなります。（完成、納品）請負契約だと開発手法はほぼ100%がウォーターフォールモデルです。

つまり、システムを発注する側が丸投げしやすいので、請負開発、ウォーターフォールモデルが主流なのです。

外国では終身雇用のような文化はないので、システムの山、谷に合わせて人を調達して、自分の会社で開発部隊を持って開発します。開発が谷になると、徐々にプロジェクトは人をリリースし、その人達はよその会社の開発部隊に移っていきます。なので、外国には「システムインテグレータ」という業種は存在せず、システムは内製が基本です。

なので、日本は請負契約/ウォータフォールモデルがやりやすい風土、外国はアジャイル/スクラム開発がやりやすい風土なんじゃないでしょうか。

私も最近になってやり始めがアジャイル/スクラム開発で、昔から思っていたウォータフォールモデルの悪い所、限界というのを再認識しました。

請負契約/ウォータフォールモデルは請負契約なので、発注側と受注側の駆け引きが必ず生じます。発注する側はできるだけ安い費用で最大の効果を出そうとします。受注側は自分達の利益を最大にしようとします。同じモノを作るのであれば原価（そのほぼ100%が人件費）を極力下げて、利益を生もうとします。よくある話が、要件定義が曖昧のまま契約をし、あとから発注側が追加仕様をねじ込もうとし、それが、当初の要件定義に含まれるのか、含まれないのかでよくモメます。当初の要件定義に含まれるのであれば、発注側は追加費用を払う必要はありません。含まれていないのであれば受注側は追加費用を請求します。と、簡単に言っていますが、実際は色々な政治が絡んでこんなに簡単ではありません。受注側と発注側でモメることが多々あります。請負契約は受注側が頑張って、効率を上げればその分多く利益を挙げれるという建前はありますが、ほとんどはそんなことはなく、ほとんどが受注側に一歩的に不利な不平等条約です。

請負契約/ウォータフォールモデルでは、本来のシステム開発以外にもこんなところに無駄なエネルギーを使っています。

一番大きいのはお互いのゴールが違います。受注側はシステムを完成し、納品し、発注側に受入してくれること。ここをゴールとします。受け入れしてくれないと売上が上がりませんから、全くのただ働きになってしまいます。

発注側はシステムの完成はゴールではありません。むしろ、受け入れて使い始めてから、そこからがスタートです。ゴールはそのシステムを導入してやりかったこと（受注○%増、利益○%増とか）が達成されてゴールです。

請負契約/ウォータフォールモデルでは発注側と受注側のこの絶対的な価値観のズレはどうしようもありません。埋まることはありません。

それに対しアジャイル/スクラム開発は大抵は委任契約です。アジャイル/スクラムは発注側のPO（プロダクトオーナ）がやりたいことを整理し、発注側と受注側で同じゴールに向かって生きます。委任契約なのでPOの判断で柔軟にやることの優先順位の変更、方針変更、仕様変更が可能です。委任契約なので、方針変更、仕様変更があってもウォータフォールモデルの様にモメることもありません。アジャイル/スクラムは短いスパン（2週間くらい）でスプリントを回していきます。

請負契約/ウォータフォールモデルでは早くても数ヶ月〜半年、1年というスパンなので、変化が早い今の時代には向かないと思います。1年前の要件定義で作ったシステムは使い始める頃にはもう、古くなっています。そういう意味でアジャイル/スクラムは今の時代にあった開発手法だと思っています。今までシステムインテグレータに丸投げしていた発注側の会社も最近は開発部隊を持って、内製する方向になっているので、今後は日本でもアジャイル/スクラムが主流になっていくのではないでしょうか。

会社をやめるまであと162日