要件定義の障壁。あるいはビジネスロジックの複雑さが招くプロジェクトの悲劇
現時点でシステム構築の最大の障壁は
「ユーザー（業務部門）の人間であっても、システムに実装したい要件を明確に語れないこと」
である（断言）。
一応確認しておくと、「どんなシステムを作ってほしいか？」を語る責任は、ユーザー側にあると一般的に言われている。外部のベンダーにシステム構築を発注する際は、ベンダーではなく、発注者の責任となる。
だが、近年ほとんどの業務部門はこの責任を果たせない。自分たちが欲しいシステムをこと細かに説明できるユーザーは「その業務の主」みたいな方に限られるし、そういう方がいないケースも多い。
もう少し補足する。
「自分たちがやっている業務を、自分が担当している作業の上流も下流も含めて、通しで説明する。何のためにその業務をやっているとか、プロセスの途中で誰がサボると何が起こるか、などを理解し、部外者に説明する」
はできて当たり前のように思うかもしれないが、これがちゃんとできるだけでも、業務担当者としては、かなり頼りになる。なぜなら、業務の大半をITシステムがサポートするようになった現代の大企業では、システム化が進んだことでこの「何のために何をやっているか？」が見えにくくなっているから。
でもそういう人でも、「ITシステムに実装されているビジネスロジックの詳細」まで語れないことが多い。
多くの人に馴染みがある人事業務を例にすると、
・社員が勤怠システムに労働実績を入力し、
・それを所属長がチェックし、
・NGならば差し戻しして・・
みたいな業務プロセスをゼロから語れる人はいる。
だが「徹夜をしたら次の日は代休を強制的に取る制度になっているが、それでも稼働してしまった時に、残業時間や深夜手当は何時間とするのが正しいのか？代休日数は増えるのか？減るのか？」みたいな詳細ロジックを語れる人が、近年とても減ってきている。
※ちなみにこの徹夜の事例は20年前に遭遇して苦労した例。その頃からこの問題はあったが、年々つらくなっている感覚がある。
当然、人事部のひとであれば、自社の人事制度（就業規則）をちゃんと理解して、語れるべきだ。一方で規則には、上記のようなケースについて全てを網羅的に記載していないケースが多い。つまり多くのグレーゾーンがある。
就業規則に細かいことを書いていない会社（シンプルな人事制度の会社）に多くのグレーゾーンがあるのは直感的に分かると思う。でも超複雑な人事制度の会社だったとしても、グレーゾーンはなくならない。複雑な制度になればなるほど「じゃあ、これとこれが重なった場合はどうなるの？」みたいなグレーゾーンは余計に増える。
（上記の徹夜後の代休のケースを例に取ると、そもそも「徹夜後は強制代休」というルールが存在していなかったら、20年前に僕らを悩ませたグレーゾーンは生まれていない）
で、ITシステム構築プロジェクトでは、人事にまつわるビジネスロジックの詳細を人事部の担当者が語れない場合、かなり困ってしまう。どういうシステムにすればいいのか、誰も決定しないのだから。
結局「現行システムのままでお願いします」というざっくりリクエストとなり、現システムの仕様書や、ひどいときにはソースコードを解析し始めることになる。超大変。
何が辛いって、詳細設計をやるべきフェーズで、（1年以上前に終わっているはずの）現状調査に時間を取られることだ。当然スケジュールは崩壊する。
そしてそういう調査をエンジニアがする場合、当初予定していた仕事ではないし、本来は発注者側が果たすべき責任なので、費用負担をどうするかで揉める。双方にとってしんどい。
なぜこういう状況（担当者なのに自社のビジネスロジックを語れない）に陥ってしまうのか？
それは、現代企業では、ITシステムがサポートすることを前提にビジネスロジックを決めているからだ。つまり「システムに計算させればいいでしょ」という感じで、ソロバンしか使えなかったら絶対に複雑すぎて運用できない制度に進化させてしまう。良かれと思って。
それが繰り返され、ビジネスロジックの複雑さは年月がたつうちに、
「システムがなければ到底把握できないほど複雑だが、システムに実装できないほどは複雑ではない」というレベルに収束する。
僕自身は、ビジネスロジックを複雑にすることは、その会社の競争力Upにたいてい貢献しないと考えている。そもそも自分たちで把握、説明できないほど、制度を複雑化してしまうのは、極めて不健全だ。たとえシステムを使えば表面上、運用できているように見えたとしても、ビジネスの継続性が担保できていない状況だ。
だから自分の会社では細かいルールを作ることに常に反対する立場だし、お客さんのルールをシンプルにするお手伝いをしている。
でもほとんどのサラリーマンは「制度やルールを複雑にすることは、ビジネスにとって悪である」とまでは考えていないようだ。特に情報処理能力が高い（賢い）人であればあるほど。だから「システムに計算させればすむのに、白川さんははなんでそんなに攻撃的なんですか？」なんて目で見られたりする。
こうした事情が積み重なり、よほど強い意志で制度の複雑さを拒絶し続けない限りは、企業のビジネスロジックは複雑になる一方だ。ほとんどの大企業では、ビジネスロジックは担当者の方々が語れない、把握できないレベルまで複雑化する。（難しげな表現をするなら、複雑性の下方硬直性）
全ての読者に馴染みがあるかと思って人事制度を例に説明したが、もちろん全ての業務にこの命題は当てはまる。例えば、
・B2Cの値引きロジック
・物流における配車や、生産設備における生産順などを最適化するロジック
・在庫管理における発注アラートのロジック
みたいなロジックも、最初はベテラン社員が勘でやっていたことを言語化し、システム化したのだろう。
しかし、人が入れ替わるに従いブラックボックス化し、今ではどういうロジックか？なぜそうしているのか？を語れる人がいなくなっていたりする。
このブログで訴えている「要件定義の障壁」は、システムを再構築する際に大きな問題となるのだが、これは以前のプロジェクトでの偉業の成果でもある。
だってベテランのノウハウを明文化するのって、属人化を防ぐという意味で、企業にとってはプラスでしかない。
そして「ロジックを隠蔽することで、仕事をする人が、普段は気にしなくてすむようになる」というのは、システムの主要な利点の1つですらある。
誰も悪くない。切ない。
このブログの趣旨は、「僕が要件定義の障壁と呼んでいる問題」があるよ、を広く知らしめることなので、対策をこと細かに書くには余白が足りない。
いくつか端的に書いておこう。
1)複雑な業務システムの再構築プロジェクトでは、「要件定義の障壁がある」と決めてかかって構わない。それを前提にスケジュールと予算を組もう。
2)プロジェクトを始める際の現状分析では、業務の中身だけでなく「詳細なビジネスロジックを記述したドキュメントは信頼できるか？最新か？読みやすいか？」「それを解説してくれる、頼りになるキーパーソンは存在しているか？」などのメタ情報もしっかり調べよう
3)頼りになるドキュメントやキーパーソンが存在しない場合は、相当な覚悟（コスト）が必要。現状のロジックを文書化するフェーズを明示的に挟んだ方が良い（リバースエンジニアリングと呼ぶ）
⇒以前のプロジェクトでは、コンサルタントである僕らが業務上の現状調査をやっている横で、ベテランエンジニアさんがリバースエンジニアリングをやってくれていた。そのためにこの「要件定義の障壁」から逃れることができた。当時はその価値を理解していなかったが、振り返ると超絶ナイスプレーだった・・。
4)とはいえ、この問題への特効薬はない。更にわるいことに、上に書いたように、構造的にますます深刻になるはずだ。だから「ITシステムに自社独自のビジネスロジックを詰め込みまくる」というスタンス自体を見直すべき時が来ているのかもしれない。まだこの問題の深刻さが周知されていないので、そこまで踏み込んで考えている会社は皆無だと思うが、10年ごはきっと違った様相になっているだろう。
※このタイトルもChatGPTにつけてもらいました。「悲劇」とかそういう煽情的な言葉すきですよね。（僕が彼にお願いしているから、というのもある）