コレジャナイ感 撲滅運動！

納入された業務アプリケーション。作ってくれたIT部門、SIerの皆さんには感謝しつつも、「コレジャナイ感」が否めない... 何でだと思います？　というご相談をいただくケースがあります。

大概の場合、思いつく要因として

• 要件定義が甘かった
• ユースケースをもっと提示すべきだった
• 我社の業務をよく知っている業者に出すべきだった

等が出てきます。業務側の視点に立つと、わからなくはないのですが、これ、全部間違ってます。この視点で考えていたらいつまで経っても同じ感覚に陥ります。視点を大きく変える必要があります。

要件定義をもっと柔軟に

まず、プロジェクトがWarterfallであること自体を考え直したほうが良いです。要件定義を「最初に」完璧に出せるところってあるんでしょうか？そんなスーパーレディ・スーパーマンがいたら、地球上から炎上プロジェクトなんて存在するはずがありません。人間、過去にやってきた内容の全て事細かに覚えている人はいません。全てをドキュメント化されている事業者も見たことがありません。それが「今回だけのちょっとした変更」であれば、なおさらのことです。事業をやっていれば、「明日、明後日、毎日新しい要件が生まれる」可能性だってあります。

つまり、最初に要件定義を行うというプロセス自体を変えればよいのです。

ある日を境に業務の根幹が全く変わることはないはずです。例えば、昨日まで医療用マスクの販売業務をしていたけど、今日から製鉄業になります！とか、ありえないですよね。ということは、業務の根幹となる部分は、その会社の事業部に属する人なら誰もが知っている業務のはずです。いかなる例外も一切切り捨て、まずそこだけに集中して業務要件を整理します。

この業務の整理は業務部門の方々と一緒に行います。よくSIerだけでやっているのを見ますが、「絶対にSIerだけでやるべきではない」です。いや、そんなこと言ったって今まで付き合ってきた業務部門の人たちは、忙しいからとかシステム部門の人のほうが知っているから、とかの理由で参加してくれないんですよ、聞けないんですよ... という話をよく耳にします。もしそれが本当であると仮定すると、心を鬼にして申し上げますが、それは「あなた方が業務部門から信頼されていない」んですよ！気づいてください！私はそうじゃなく、SIerが「お客様に対して聞く行為をしていないだけ」だと思っています。

我々はある特定のお客様の業務をずーっとやってきたということは1例も無いのですが、この作業を行う時に「不明点があったら聞きますから！覚悟しておいてね！」と言うと、100%、業務部門の方は苦笑いしつつも付き合って教えてくれます。恐縮なことに、事業の勉強会まで開いていただいています。業務部門の方はちゃんと教えてくれます！プロジェクトが始まる前までにいかに業務部門の方々と仲良くなり、技術観点などで信頼関係を築いておくかは担当営業や担当プリセールスの責務ですから！上下関係ではありません。関係性は一緒に仕事をする「パートナー」です。

設計

次に行うことは、枝葉の業務要件整理... ではなく、その業務要件を満たすための要素技術とのマッピングです。

• データの入出力→Web画面とする判定部分はできるだけ自動化
• 法令改正に対して5日以内で対応できる仕組みとする→データ・ルール・プロセス・画面の疎結合化
• 最大1,000人の同時アクセスがあるが、昼間の同時アクセス数はせいぜい10人→コンテナ化でAuto Scale Out/In

... などです。

さらに、各要素技術をどのように実現するのかのマッピングをします。

• WebであればHTML5をベースにJSPサーブレットとシングルサインオン
• 判定部分はルールエンジン
• データのリアルタイム処理にはStream Queueとマイクロサービスによる連携
• コンテナ化によるコンテナの管理はKubernetes

... などです。そして、その実現方法をどのメソッドで行うかを決定します。オープンソースを主軸に考えるのであれば、WebやJDKはRed Hat Runtimes, ルールエンジンはRed Hat Decision Manager、コンテナはRed Hat OpenShift Container Platform等です。ここまでくると、要件定義から設計段階に踏み込んでおり、概略設計が出来上がっている状態になります。大筋の見極めをつけておきます。

そして、次にすべきことはこの概略設計の確からしさの検証です。設計が正しくないと最後のテストの段階で地獄を見ます。なので、幹となる業務部分で、典型的なパターンのデータで一気通貫に業務が行えるプロトタイプを作成します。今までこの部分は机上の検討だけで済ませてきているのが多いと思いますが、実物を作って検証することを強くお勧めします。画面は超絶簡素なもの、ロジックは数パターンのみの実装、データもCSV形式で読み込み・書き込み程度のものでよいです。しかし、とりあえず動けばいいだけのものを作るのではなく、ITのプロフェッショナルとして将来のシステムはこうあるべきだ的な考えは存分に入れるべきです。その上で、機能的に満たせるものが想定したメソッドなどで「カスタマイズすること無く」作れて見通し良くできるかどうかを検証します。

大量のデータを流してみて、簡易的なパフォーマンスも計測しておきます。作ったものに対して振返りを行います。この時に重要なのは、業務に関わる人も一緒に検証に参加することです。「コレジャナイ感」があるかどうか、このプロトタイプの時点で忌憚のない声を聴かせてもらいます。

その検証の場で、ここはもうちょっとこうすべきだったとか、これは要らないんじゃないか？等が、必ず出てきます。私の経験上、ここでの会話で「この業務って要らないよね？」「これができるなら、A課でやってたチェックはシステム化して業務負荷を減らせるよね？」「もしかしてアプリケーションでこんな事できたりする？」等という、「業務の整理(改革)」が始まります。ほぼすべてのお客様で。ホント、面白いように！

業務部門の方も、何ができるかわからない中でひたすら要件の書き出しをやっても、不安だしそこで責任を取らされても...と感じているわけですよ。これが、ITのプロが考えた動くプロトタイプを目の前にすると、業務部門の方々の脳はドーパミンが溢れて、建設的な考えと喜びに満ち溢れるわけです。僕らITで仕事をしている人間は喜び組なのですよ！（非科学的ですが、そういうのは絶対あると思います）

皆さんもお気付きの通り、「業務部門がシステムを縛っていた」のではなく、実は「システムが業務を縛っていた」のです。新しいアプローチ・機能などを紹介することで、業務の無駄・不合理が見つけられ、プロジェクトがもっとシンプルな方向に動き始めます。

イテレーション開発

不要な機能などが削ぎ落とされ、本当に欲しかった機能が追加された状態で、もう一度、入れるべき要件を検討します。そして、それを設計し、先に作ったプロトタイプを拡張する形で作り、また検証を行います。あとはこれをお客様が用意した入力データと期待値を使って、100%マッチするまで作るだけです。毎回、検証時には業務部門の方に参加いただき、意見を聞いていくことで、業務部門の方々の「コレジャナイ感の撲滅」に持っていく事が可能です。

一つ重要なこと。このイテレーションの中で業務部門の「わがまま」を全て聞くのは間違いです。業務部門の方はITの限界や苦労をわからずに要望を出してきます。それを聞き入れるのに、基本方針とした立てたアーキテクチャを変える必要があるのであれば、それは残念ながら受け入れるべきではありません。現実、結構あるんです。その機能いる？的な。

一番多い例としては、「部長承認の後、事業部長が却下したら、関係するコミットしたデータを全部元に戻して部長に差戻しして。」みたいな流れ。部長の承認があったために一度コミットしてしまったデータ（例えば発注指示）を、他のシステムが参照して物事が進んでしまってしまったかもしれない状態（サプライヤーへの注文書の発行）に戻すなんて、担当してるシステムだけではできません。出来たとしてもめちゃめちゃ面倒で、そのケースだけならまだしも、課長の場合とか他部署での場合とか、他のケースまで全部洗い出すなんて不可能です。

この場合は、承認・却下した人が責任を持って仕事をしたのであり、却下された時点でその「案件」はボツなわけです。もし再検討が必要というのであれば、ちょこっと直す程度のものではなく、きちんと考えてもう一度新たにプロセス（稟議）を起こすべきです。え？そんなこと面倒？　いえいえ、その面倒さを回避したいなら、ちゃんと考えてから稟議起こしなさいということです。

ITのプロフェッショナルは、そのようなわがままご要望に対してはシステムでやることの限界をお伝えし、代替策を考えるか、そのご要望を実現するための費用や工数などをきちんと提示します。技術的に製品の基本機能で実現でき、かつ、本当にどうしても必要な場合は、次のイテレーションでやるべき内容かどうかをプロジェクトマネージャがハンドリングします。

最終的に、「コレジャナイ感」ではなく「コレなのよ！感」が出てくることで、お客様の満足度も向上し、開発する側も無駄な心労もなくプロジェクトは成功します。そのための鍵としてあるのが、ルール・プロセス・データ・画面の疎結合アーキテクチャであり、マイクロサービス化であり、CI/CDであり、コンテナ環境であり、ルール駆動開発であり、イテレーション開発なのです。

まとめとして書いておきますが、

• Waterfall開発はせず、イテレーション開発とする
• 幹となるプロトタイプを作成して検証、次の目標を策定する
• お客様の業務部門を巻き込んで一緒に検証し考える（お客様は自分たちの業務改善につながるので積極的に参加する）
• 要望を出すのは事業部門、ITの専門家の視点で実現の可能性を考えるのはシステム部門(もしくはSIer)の役割

みなさんも一緒に、コレジャナイ感の撲滅運動にご参加ください！