破綻したSIer業界の内実 —— IT後進国日本の裏側から
今日も今日とて後始末
またしても私は問題プロジェクトの「後始末」を頼まれた。 今回もクライアントが直接選んだ開発会社による開発案件で、すでに大きく行き詰まっている。 システムはフロントエンドがreact、バックエンドがpython+Djangoで構築されていると聞いている。
最初に求めたのは当然、設計書だ。 だがそれが存在しない。 おそらく作成する能力が開発チームに欠けているのだろう。 要件定義書に至っては、初めはA4用紙1枚で済まそうとされた。 私が作成した見積依頼書が20ページに及ぶのに対し、彼らが提出した「システム設計書」と称するものはPowerPointで4ページのみ。 これは営業資料の間違いだろうと一蹴せざるを得なかった。
あり得ない。
文句を言っても仕方がない、これが今の日本のSierの現状だ。
そもそもこれは私が選定した業者ではない。クライアントが選定した業者だ。 当初は私抜きで進められていた案件だ。 関わりたくなかったから助かったと思ったら、甘かった。 それがグダグダで、ぐちゃぐちゃで、困窮したクライアントから後始末と尻ぬぐいを依頼された。
開発会社の営業は何でもハイハイ、開発は「何も聞いてません。」。 社内で確認すべきことまで、担当者が捕まらないからと、こちらに聞いてくる始末だ。
ちなみに開発会社の社長が営業担当だ。これで上場を目指してるとか、VCから資金調達してるとか、言っている。 脳内お花畑か？日本のVCはそんなに見る目が無いのか？
はあ、愚痴をこぼしても仕方がない。
ドキュメントの欠如と技術的負債
pythonは使い慣れているが、djangoは使ったことが無い。 私はFastAPIを使っているからだ。 納品されたシステムのREADME.mdに書いてあるとおりにデプロイする。 ちなみに説明は英語で書いてある。 オフショアだと肝心なドキュメントが日本語で書かれていないことが多い。
手元にあるのは、コンテナの起動方法とデータベースのマイグレーション手順だけ。 アプリケーションの構造、データモデル、ビジネスロジック、APIの仕様書？ そんなものはどこにも見当たらない。まさか頭の中にあるとでも言うのだろうか。
いわゆる「属人化」の極みだ。このシステムに手を入れるには、作った人間の頭の中を解読するしかない。 しかも、ベトナムの開発チームなので、私との直接コミュニケーションは許可されていない。
人間とAI、情報の更新の違い
起動手順を見てみると、古いdocker-composeコマンドが指定されている。 今回は新規の開発案件なのに、非推奨のコマンドを使用している。 つまり、この開発チームのDockerに関する知識が古いままだということだろう。
はあ、なんか新車を買ったら、型落ちだった気分ですなあ。
なんて偉そうなことを言っているが、私もずっとdocker-composeを使っていたので、人のことは言えない。 これを機に、docker compose V2に移行しよう。pythonよりGoの方が実行速度も速いだろうし。
残念なことに、これを窓口のSEに伝えても無駄だろう。 彼は管理者SEだから、なんのことかわからないはずだ。 実際、彼らに実装のスキルは無い。 海外で開発したシステムが、仕様書通りに動くかどうかチェックして、クライアントに報告するだけだ。
人間だと使い慣れているコマンドが古くなっていることに気づくためには、 情報をアップデートしなければならない。 しかしAIは作業しながら常に裏側で情報をアップデートしている。 これは人間にはできないことだ。
「使い慣れた」という盲点
最近、別案件でも同じようなことがあった。 phpでの開発案件で、帳票出力に私はAIと相談してplateとDomPDFを採用した。 帳票のフォーマット以外は私が実装してから担当者に引き継いだ。 担当者はphp+Laravelの開発を10年以上続けている猛者である。 その彼がミーティングで驚いたように言った。
「このDomPDF、すごいな。今まで知らなかった。plateと合わせることで、すごく簡単に帳票が作成できます。 今、作っている別案件も、今後の保守を考えてbladeからplate+DomPDFの組み合わせに変更します。」
私はAIと相談して、最新の情報を取り入れた。 彼は使い慣れている既存のライブラリを使っていた。 その差が、ベテランでも驚くほどの効率化を生んだのである。
管理者SEという名の通訳
日本のIT業界、特にSIer業界には「管理者SE」という役職が存在する。 彼らの多くは、自らコードを書くことはなく、海外の開発者とクライアントの間の「通訳」として機能する。 しかし、その「通訳」は技術を理解していないことが多い。
私が関わったプロジェクトの管理者SEは、フロントエンドとバックエンドの違いすら理解していなかった。 Reactのコンポーネントがサーバーサイドで動くと思っていたのだ。これが現実だ。
そして彼らは、「技術のことはわからないので」と平気で言う。 それなのに、技術的な決定権は彼らが持っている。 なぜなら、クライアントとの窓口だからだ。
このねじれ現象が、日本のIT業界の技術的負債を増大させている。 技術を理解しない人間が意思決定を行い、実装を理解しない人間が検収を行う。 そして、問題が発生すれば、技術者が責任を負わされる。
後始末の日々は続く
今回のプロジェクトでも、私はまた尻拭いをすることになった。 設計書のないシステム、ドキュメントのない実装、連絡の取れない開発者。 この状況で、クライアントが望む機能を追加し、バグを修正する。
これが日本のIT業界の現実だ。 この構造が変わらない限り、日本のIT産業は世界から取り残され続けるだろう。
だが、変化の兆しもある。 AIの登場によって、情報の非対称性は大きく減少した。 かつては、技術者の経験や知識に依存していた部分が、AIによって補完される。 これが業界全体の底上げにつながることを期待している。
とはいえ、現状はまだまだ厳しい。 私のように、この現実を知っている人間が、技術を適切に理解し、 適材適所で活用していくしかないのだろう。
今日も今日とて、後始末の日々は続く。
まとめ
日本のSIer業界の現状は、設計書の欠如、技術的負債、管理者SEの問題など、構造的な課題が山積している。 これらの課題を解消するためには、技術者個人の努力だけでなく、業界全体の意識改革が必要だが、現状は厳しい。
特に、AIを活用したAI拡張型開発は、技術向上の一助となる可能性を秘めている。 しかし、現状ではプロンプトエンジニアリングと混同されるなど、技術の本質的な理解が不足しているのが実情だ。 （プロンプトエンジニアリングはAIへの指示の最適化であり、AI拡張型開発はAIを活用した開発プロセス全体の効率化を指す。）
最新技術やトレンドのキャッチアップは手段であり、その目的はシステムの品質を見極める「目利き能力」を養うことにある。 この目利き能力こそが、日本のIT企業において決定的に欠けている要素であり、業界全体の課題を象徴している。
私にできることは、技術者として常に自分の技術を磨き、AIを適切に活用しながら、システムの品質向上に努めることだけだ。