要件定義を誰も出来ないという不都合な真実
現時点でシステム構築の最大の障壁は
「ユーザー（業務部門）の人間であっても、システムに実装したい要件を明確に語れないこと」
である（断言）。
それが出来れば自分たちで既存のパッケージであったりの評価ができるはずなんで、システム導入はもっとスムースに行くはずなんだけど、業務内容をシステム構築のために必要なメッシュで分析できるわけがなく、利用体験をイメージさせるしか方法がございません。
これ、提案側にすごいコストかかる行いなんですよ。
白川さんも書かれているように、人の動きについては誰でも語れます。承認や決裁フローとか受け渡しであったり帳票の種類などにおいては。これらは形式知であるため。
語れない人が本当に多いのが、ビジネスルール。白川さんは「ITシステムに実装されているビジネスロジックの詳細」と表現してるけど、詳細とはルールのことです。ルールに基づいてプログラムは実装されます。
そのようなルールで最も重要なのは、エッジケースです。勤怠管理で徹夜で働いた翌日の勤怠はどうなるのか、みたいなやつ。見積系でいうと、こちらの商材に限り〜このお客様に限り〜この組み合わせに限り〜みたいなやつ。
エッジケースって5%ぐらいしか発生しないんだけど、天災と同じで発生する確率がある以上、準備が必要。でも、誰もエッジケースを語れない。それらに対応されている人も身体で覚えているので（自分の脳内の断片なロジックを揮発的に組み立てているだけなので、覚えてない）ルールとして整理できないから、引き出せないわけ。
というわけで・・・こうなるわけ。
で、ITシステム構築プロジェクトでは、人事にまつわるビジネスロジックの詳細を人事部の担当者が語れない場合、かなり困ってしまう。どういうシステムにすればいいのか、誰も決定しないのだから。
結局「現行システムのままでお願いします」というざっくりリクエストとなり、現システムの仕様書や、ひどいときにはソースコードを解析し始めることになる。超大変。
何が辛いって、詳細設計をやるべきフェーズで、（1年以上前に終わっているはずの）現状調査に時間を取られることだ。当然スケジュールは崩壊する。
そしてそういう調査をエンジニアがする場合、当初予定していた仕事ではないし、本来は発注者側が果たすべき責任なので、費用負担をどうするかで揉める。双方にとってしんどい。
仕様書というのは、作った当時のままメンテナンスされない。そんなもの、いらん。それより動作環境そのものが複製できることが極めて重要で、特にデータベース。DBの中身が確認できれば、UIから逆算できる。
困るのは、UIで入れたとおりにデータが入らない場合。計算結果を入れたり、ステータスに応じて何かを変えたりというのは、目に見えないんだな。裏でやっているおもてなしだから。ソースコードをあたるしかない。
僕は今あるプロダクトのリプレイスをしているけど、本來ソフトウェアってソースコードの解析が仕事。パッケージソフトを入れた場合はメーカー責任でねサポートされるけど、スクラッチで作ったやつは規模の大小に関わらずコードを追うしかない。
なぜなら、ユーザーがソースコードの上に乗っている仕様を、説明できないから！！！ 白川さんがおっしゃるとおりで！！！
こんなんばっかです。辛いのはデスクトップアプリケーション系。VB6かよみたいなやつ。ソースコード持ってる会社が飛んで中身がわからないやつ。ちょーーーーーーーー苦労したけど、納めました。Webアプリならば、FTPさえ出来ればなんとかなるんだけど。デプロイ先にコードがあるから。Winデスクトップアプリ、バイナリしかないので。
かといって、「ITシステムに自社独自のビジネスロジックを詰め込みまくる」のは悪だとは思わない。特級呪物になるから既製品入れましょうは単純バカだと思う。SalesForceゴリゴリゴリラカスタマイズも特級呪物だと思うが。
自社のビジネス貢献のためにシステムがあるのでスクラッチしか満たせない要件なら、作ったらええねん。しかしながら！特級呪物として忌み嫌われるリスクと表裏一体なのは、100%事実。
特級呪物にならないためのリスク・コントロールが必要かどうかは、経営の判断になる。なったことがないと、判断できないんだよね。天災と同じだと思うけど、同じ天秤にはかけられへんわけ。リスクの意味が伝わらない。
僕はそういう話を勧めてまとめて推進できる人材を「ITプランナー」としてラベリングしていた時期があり、こういう人材絶対いるはずなんですって、今でも思うけど、それを語るモチベーションが枯渇しました。
上記の話が理解できない顧客が99%なので、コンサルとして入る理由を伝えられなくて、諦めちゃった。全く刺さらなかったんすよ。わっからないのよシステム構築したことが過去もこれからも、一生ないわけだから。
特級呪物の前には無力でお金で解決とパワーバランスの現行踏襲でしわ寄せすればいいじゃんには勝てない。そもそも、プランニングの抽象度が高すぎて、具体に落としても腹落ちできないユーザーが多い。これも大きかった。なので、もうこの話はやめ！
しかし、今まで非常に苦しかったソースコードのリバースエンジニアリングに革命が起きるかもしれない。LLMにソースコードを全部食わせて仕様書が出来る時代になれば、DXが加速されると思う。僕がLLMに期待しているのはここです。
要件定義でトラブルになるグレーゾーンやローカルルールの整理が、LLMでやれるようになれば僕も嬉しい。LLMの社会実装が本当に楽しみです。
やれることたくさんあるぞ〜
この記事が気に入ったらサポートをしてみませんか？