日経SYSTEMS 10月号のコラムは「似ているからといって機能統合してはいけない」です。
たとえば「●●検索機能」というのがあったとして、それが複数のアクターから使われるという場合があります。よくあるのは一般ユーザ向けと管理ユーザー向けといった形で分けますが、場合によっては一般ユーザーの中でもロールごとに変えるべきときがあります。
そういった場合の判断基準に将来的な「要件変化」を含むべきです。そういった判断を失敗すると、次のような問題が起こり得ます。
（ロールAとロールBで比べた場合に、）要件変化のギャップが小さければ機能統合したほうがよく，大きければ機能分割したほうがよい。この選択を間違うと保守フェーズで問題が発生する。要件変化のギャップが小さいということは，要件変更が発生するとしても，そのタイミングと内容はほぼ同じということだ。それなのに機能を分割していると，同じ内容の仕様変更であるにもかかわらず，機能ごとにプログラム改修を行う必要があり，実装コストはもちろんのこと，テスト工数まで増えてしまう。
逆に，要件変化のギャップが大きいと，異なるきっかけで要件が変更し，時間が経つと要件のズレが大きくなっていく。にもかかわらず機能統合していると，その機能の仕様はどんどん複雑になっていく。結果として，特定のエンジニアでないとプログラム修正できないとか，変更のたびにデグレード（品質の低下）が起こってしまいがちである。
記事では監査部というロールがある場合に、要件が変更されるきっかけが違うだろうという指摘をしています。
重要なのは、未来に起こりうることを想定し、それに可能なリスクヘッジをするということです。現時点の要件だけを聞いて作ったところで、それが保守段階でだんだんと利用者との不適合をおこすのであれば、それもまた作り手としては能力が低いということになります。
何度も繰り返していますが、小学生のお使いじゃないんだから「言われたとおりに作りました」じゃダメなんです。そんなSIerは駆逐されていきます。要件を正確に聞くことは本質じゃない。そうではなくて、要件の先にあるユーザーの真のニーズや将来的なベネフィットまで踏まえていくことが大事なのです。
一度作られた企業システムとは少なくとも5年は付き合っていかないといけません。未来を見るといっても予測しきれないこともあるし、逆に失敗することもある。それでもユーザーときちんと話をしていけば解決策は見つかります。要件はコミュニケーションの手段でありプロセスです。それを結果のように受け取ってしまっては、相互の対立関係を変えていくことはできません。
最後のまとめです。
機能の統合や分割を検討する場合，検討時点で機能が似ているかどうかだけでなく，時間の経過とともに，どのように変化するのかに注意する必要がある。企業システムは長く使われる。企業の環境変化に対応するには，その変化が起こる原因や粒度に合わせて機能を定義していく必要がある。
