結局、検索して、表示して、CRUDするだけ

※この記事は全文無料公開しています。もし気に入っていただけましたら、チップをいただけますと幸いです。

先日、ある案件の要件定義書を読んでいて、ふと思った。

結局これ、検索して、表示して、CRUDするだけだな、と。

CRUDというのは、Create(作る)、Read(読む)、Update(直す)、Delete(消す)の頭文字で、データ操作の基本4動作のこと。業務システムと呼ばれるものの中身は、突き詰めるとほぼこれで説明できてしまう。販売管理も、原価管理も、債権債務も、マスタメンテも、全部そう。データを検索して、画面に表示して、作って読んで直して消す。以上。

IT歴20年の人間がこれを言うと語弊があるかもしれない。でも、語弊を承知で言えば、これは20年やったからこそ言えることでもある。

若手の頃は、まじでわけがわからなかった

新人の頃、要件定義書や仕様書というものが本当に理解できなかった。

何百ページもある。目次は立派。でも読んでも読んでも、「で、何を作るの?」が頭に入ってこない。内容が高度だから理解できないんだと思っていた。自分の勉強不足だと。

20年経ってわかったのは、そうじゃなかったということだ。

わからなかったのは、内容が難しかったからではない。あの文書が何のために存在するのかが見えていなかったからだ。

仕様書の本体は、CRUDではない

システムの中身がCRUDだけなら、仕様書は10ページで済むはずだ。なぜ何百ページになるのか。

答えは、仕様書の本体がCRUDそのものではなく、「誰が・いつ・どの状態のデータに・どこまで触れていいか」の場合分けだからだ。

権限。ステータス遷移。排他制御。承認フロー。例外時の運用。

CRUDは動詞にすぎない。あの分厚さは、全部修飾語でできている。

そしてもう一段めくると、仕様書には3つの層があることに気づく。

• 1層目:何を作るか。 CRUDとインフラの層。技術的には、この層だけあればシステムは作れる。

• 2層目:誰がどう使うか。 5W1Hの層。業務の実態が書かれる場所。

• 3層目:いくらで、誰が責任を取るか。 予算と工数と体制の層。

で、身も蓋もないことを言うと、仕様書の本当の主役は3層目だ。プロジェクトが揉めたとき、最終的に読まれるのはこの層だから。

仕様書とは、設計図の顔をした契約書である。

若手の頃に読めなかったのは当然だった。設計図だと思って読んでいたのだから。合意と責任の配置図だと思って読み直すと、あの文書の全部に理由がある。文書は変わっていない。読み手のレンズが変わっただけだ。20年かけて手に入れたのは、知識ではなく解像度だった。

20年、同じ話が繰り返されている

もうひとつ、身も蓋もない事実がある。

若手の頃に見たものと同じもの、同じ話が、20年経った今も繰り返されている、ということだ。

技術はこの20年で何周も入れ替わった。オンプレがクラウドになり、ウォーターフォールの横にアジャイルが並び、ローコードだのAIだのが登場した。なのに、プロジェクトの揉め方は一ミリも変わっていない。

• 責任分界が曖昧なまま進む

• 「合意したつもり」の理解が、実は人によってバラバラ

• 業務の歪みを直さずに、そのままシステムに押し付ける

全部、技術の問題ではなく構造の問題だ。だから技術をいくら入れ替えても再発する。人を入れ替えても再発する。構造に手を入れない限り、同じ形で何度でも出てくる。

ちなみに、要件定義書を読んでいて「これはCRUDに還元できないな」と引っかかる箇所があったら、そこは大抵、業務の歪みをシステム化しようとしている痕跡だ。構造を直さず、人の運用の複雑さをそのまま仕様に書き写した場所。レビューするなら、まずそこを見るといい。

「全員が頷いた」と「全員が同じ理解をした」は別物

繰り返される揉め方の中でも、いちばん質が悪いのが「合意したつもり」だ。

会議で誰も反対しなかった。全員が頷いた。だから合意した——これが罠で、責任分界のような話は、各自が自分に都合よく解釈したまま「合意した気になる」ことが簡単に起きる。

対策は地味だが、ひとつしかない。最後に誰かが言語化して読み上げること。

「つまり、この処理の正はあちらのシステムが持つ。うちは結果を保持するだけ。この理解で全員OKですか?」

これを言うだけで、事故はかなり減る。黙って頷くことと、同じ文章を承認することは、まったく別の行為だからだ。

繰り返しの上に、飯がある

ここまで書くと、業界への皮肉に見えるかもしれない。20年進歩してないじゃないか、と。

半分はそうだ。でも、もう半分は違う。

同じ話が繰り返されるのは、それが人間が組織を作ると必ず発生する歪みだからだ。技術の問題なら技術が解決した。20年解決されなかったということは、これは技術の問題ではないという、かなり強い証拠だ。

そして私の仕事は、まさにその歪みの整理でできている。流行りの技術に賭ける仕事は技術と一緒に陳腐化するが、「構造の歪みを直す」仕事の賞味期限は、たぶん人類と同じくらい長い。

結局、検索して、表示して、CRUDするだけ。

そう言い切れるほどシステムの中身が同型だからこそ、毎回変わる部分——金と責任と人間の配置——の歪みがよく見える。仕様書がつまらないおかげで、私はごはんが食べられている。

ありがたや。