敢えて言う、アジャイルがSIerによる受託開発に適さないということを

何を今更？という感じかもしれませんが、言いづらいことをはっきり書いたほうがいいと思ったので、「アジャイル開発が日本のSIerの受託開発には向いてない」ということの理由を整理しておきたいと思います。

はじめにこの記事の前提として、筆者はSIerのAI系の案件を主に実施している部署で、データ分析からモデル作成のためのPoC、そしてAIモデル運用のためのシステム開発をやっています。AI絡みのプロジェクトではウォーターフォール的な動きができないことが多いので、アジャイルもどきの開発をやっています。

なぜ、ウォーターフォール的な動きができないのかというと、AIプロジェクトでは契約時に開発するAIシステムの要件をまとめることが不可能だからです。AIプロジェクトの要件定義にはAIやデータサイエンスの知識と業務に対するドメイン知識をかなり要求されます。さらに、AI自体の性能や特性もPoCを実施して検証するまで未知数です。これらの情報をすべて持っている人間が顧客側にもベンダー側にもいないので、最初からカチッと要件定義→設計→実装→テストの流れに則ってプロジェクト進めるのではなく、細かいプロジェクトを複数回実施し、情報を整理しながら継続か撤退を判断しつつ、AIを適用する業務の分析、データの準備、AIモデルの開発、AIの運用システムの開発を並行しながら徐々に進めることになります。じゃないと、プロジェクト自体が未知数過ぎて契約を結ぶことができません。

そうなると自然にアジャイルというかスクラム的にスプリントを区切って、要求をバックログとして管理しながらプロジェクトを進めることになります。

結論から言ってしまうと、社内で内製でプロジェクトを進めるのではあればこのやり方でも可能だと感じますが、ベンダーとして、請負契約のもと顧客の指示でアジャイル的にプロジェクトを進めるのは無理だなと感じます。更に言うと、AIプロジェクトではウォーターフォール的に開発を進めることもできないのでハイブリッド的な動きになりますが、ウォーターフォールでもアジャイルでもない開発の進め方を確立するきだと思います。

そのために、なぜSIにおける請負プロジェクトでアジャイルをあってないかを説明します。尚、ここでいう請負開発とは顧客から要件を出されて行う開発であり、SIerの中でも自社パッケージや自社システムの開発のことではありません、むしろ自社で開発しているもの（決済者やプロダクトオーナーが社内のメンバー）ならアジャイル適していることが多いと思います。あと、筆者はウォーターフォール開発の経験もアジャイル開発の経験も不十分で中途半端な知識しかありません。

チーム全体の意思疎通（特に会議）に工数がかかりすぎる

最初に最も重要なことを書きますが、SIerで顧客や協力会社のエンジニアを交えてアジャイル開発をやると一番問題になるのがコミュニケーションコストがかかりすぎる。という言うか、コミュニケーションが成立しないという問題です。

ここは、本当に大事なことで、これから発注するまたは、請け負うプロジェクトでアジャイルをやろうとしている方は真っ先に考えてください。

アジャイル開発ではリアルタイムかつ細かい同期的なコミュニケーションを必要としてます。そしてスクラム的にやろうとすればするほど、その回数はどんどん増えてきます。特に開発チームの代表者であるスクラムマスターと発注者の代表者であるプロダクトオーナーは頻繁に会議を実施する必要があります。

プロダクトオーナーをベンダー側のPMや営業に実施させるという考え方もありますが、これはほぼ成功しないと思います。理由はSMとPOの会議で最終的な決定ができないからです。たとえばPOがベンダー側の営業だと、内容を確定するために会議後に発注者側とコミュニケーションを取ることになりますが、そこにも時間がかかりますし、顧客側が受け入れず決定がひっくり返されることもあるので、そのたびに開発がストップしプロジェクトが進みません。

POは発注側の企業の中でも、ただの担当者ではなく実質的にプロジェクトの最終決定を行えるいわゆるキーマンである必要があります。

また、アジャイル開発というかスクラムではSMとPOの会議以外に、開発側のメンバーが集まるデイリースクラムやスプリント事に実施されるスプリントプランニングやスプリントレビューがありますが、このとき関係者がなるべく全員参加することを要求されるので、会議の実施コスト（会議時間*参加人数）が高くなりすぎます。

筆者の経験だと2週間区切りのスプリントを実施したところ、顧客とベンダーの関係者全員が集まる会議(スプリントプランニングやスプリントレビューを兼ねた報告会)が週1回、顧客のSMとベンダー側のPM、PLが集まる会議が週2回、ベンダーのPM、PL、作業メンバーが集まる会議が週2回実施され、それでも会議時間が足らず、会議が延長して残業ということが結構ありました。

自分はデータサイエンティスト兼エンジニアとして参加していましたが、週1の報告会のために資料を作るのに毎週1日以上かけて、毎週半日かかる会議に臨んでいました。会議のあとは半日かけて資料の修正と議事録の作成をし、残りの時間でデータの分析加工のためのスクリプトを組んで、モデルに学習させて、次の資料にまとめるために結果を出力することを、他のプロジェクトを掛け持ちしながらやっていて、どんどん残業が増えていくデスマーチ的な状況に陥ってました。

2年間近く続きましたが、二度とやりたいくないプロジェクトですね。最終的に顧客の担当者であるPOとベンダー側でSMとして動いてたPMが根負けしてプロジェクトは途中で終了してしまいましたが、関係者（顧客、ベンダー、協力会社含め）がやめていくことが多く、やめないにしてもプロジェクトから離れっていったメンバーもいたので、お金はあるけどやる人（というかプロジェクトをやりたい人）がどこにもいないという状況になりました。

企業間の会議での決定には法的な拘束力があります。ですので、もちろん資料作成などの準備を行いますし、議事録も最低限作成する必要があります。そこには社内では発生しない精神的なコストが掛かりますし、社内にメンバーに説明するより、業界の常識が通用しない顧客と会議するほうが同じ説明するのにも労力がかかります。

チームの目的意識を統一できない

「そんなこと当たり前やんけ」と言われそうですが、アジャイルの中でもスクラムの具体的な取り組み（スプリントを数週間で区切ったり、デイリースクラムを実施したり、バックログを顧客と管理したり）をプロジェクトに当てはめるのには無理があります。それ以前にノリが全然合わないです。

入社当初（2020年）をお世話になったメンターがスクラム推進派だったので、スクラムの勉強させられました。メンターは社内メンバーで内製しているパッケージソフトを開発していたので、前述したように自社で開発しているパッケージにはアジャイル開発が適用できていましたが、その後自分が経験した顧客を交えた開発では、学んだ考え方を適用するのはかなり難しかったです。

これはノリの話ですが、スクラムが前提としているマインドセットが意識が高すぎて誰もついていけません。発注者である顧客は、いくつもあるプロジェクトの一つとして担当者システムを発注していて、例えば去年までいた部長の肝いりで始めたプロジェクトを引き継いだが自分は必要性を感じないとか、現場部門で業務効率化のためにシステムを発注したが、正直定常業務が忙しすぎて発注したシステムまで頭が回らないとか、そんな感じでプロジェクトに思い入れがない場合が多いです。

開発する側も、目的意識を統一するのは無理だと思います。プロジェクトに参加する理由は人それぞれですし、サラリーマンである以上、上から命令されたからやっているというのが正しい考え方だと思います。それに、メンバーにとって大切なのは、応援している野球チームの次の試合の結果とか、高校受験を控える子どもの成績とか、推しの韓流アイドルのツアーのチケットの当選結果とか今期たまたま見て予想以上に面白かったアニメの２期があるかであって、プロジェクトの成功は2の次、3の次です。

確かに、自社プロダクトの開発に絡んだことがないわけでもないので、自社で開発しているものに対して精神的に深入りしていく感覚はわかります。しかし、プロジェクト限りの付き合いの顧客から請け負った何件も抱えているプロジェクトの一つにスクラムで求められているようなコミットするのはむしろ不健全だと思います。さらに、SIerのプロジェクトでは様々な企業のメンバーがプロジェクトに参加していて、2次受けや3次受けの企業も存在することがありますが、企業をまたげば目的意識を統一するなど不可能です。

属人化により進行に支障がでる

アジャイルというかこちらもスクラムですが、ドキュメントを充実させる前に開発するというがあります。結局企業間でアジャイルをやっていると最低限契約上必要なドキュメントは法的に必須なので、削減できるドキュメントは少ないですが、要件や設計に関するドキュメントが不十分になるというか、目まぐるしく変わる現状にドキュメントが対応できてないという状態になります。

となると、重要なことは各作業者の頭の中にしかないという状況が発生しやすしいです。特にAIプロジェクトは各データベースのテーブルごとのデータ分析の結果やデータの整備加工の指針や実施内容、またモデル構築のプロセスについて、ドキュメントがないと作業者しかしらないという状況が確実に発生します。

となると、あの人がいないと進められない状況が発生します。

SIerではアサインは流動的でプロジェクトに専任で人がつけられることはないです。例えば契約の都合上2ヶ月間プロジェクトが開けばその間別のプロジェクトにアサインされ、そのプロジェクトが終わるまで動けないということは日常茶飯事です。引き継ぎなんてことも全然考えられてません。

協力を依頼している協力会社も常に変わりますし、派遣として参画しているエンジニアも一定期間で交代していきます。まぁ、ただでさえ転職等で人材の移動が多い業界ですし・・・。

そうなると、この人しかわかないがその人がいない！という状況が発生した時点でプロジェクトが詰んでしまいます。人の離脱によってそれまで実施していた成果が完全に失われ最初からリセットという光景を何回か目にしました。

というわけで、SIerの請負開発は誰がいつ実施してもタスクが遂行できる状態にしないといけないです。さらに言うとある程度アサインメンバーのスキルに差があっても支障がないようにすべきです。そのためにはドキュメントによる情報の管理が必要になりますが、アジャイル開発ではそれが難しいというかドキュメント管理を重厚にやろうとするとウォーターフォール化していってしまってアジャイルの良さが失われます。