ちゃぶ台返しの被害を最小限にする方法
上司の鶴の一声で、今までの仕事が全部ムダになった、という経験はないでしょうか。
つまり、あの恐ろしい、「もっとこうして欲しかったんだよね」です。
だったら早よ言えや！！ って言いたくなりますよね。。。
や、もう、どうすりゃいいんでしょうね、アレ。
皆さんこんにちは。
そしてお仕事お疲れ様です。
私は 絶対バグらないシステム作ろうぜの会 を執筆しております、エンジニアの中島と申します。
当コラムでは、トラブルの起きないシステム、トラブルの起きないチームビルディングをしていくために必要なノウハウを、なるだけ面白く読めるようにお届けする主旨となっております。
上司の一声で今までやってきたことが全部ムダになって、大幅なやり直しを強いられる。
こういうのをＩＴ業界では “ちゃぶ台返し” といいます。
このちゃぶ台返しって言葉、国語辞書にもちゃんと載ってて、個人的には割と広く知られてる認識でした。
けど検索してみると、案外製造系の業界、それもＩＴ系にほど近い会社じゃないと使われてないみたいなんです。
ちゃぶ台返しの発生そのものはやむを得ない（たまにであればね）
もちろん大幅なやり直し自体はどこの業界でもあるのでしょうが、でもなんでＩＴ業界にだけこんな言葉があるのかというと、ひっくり返されたときの被害が他の業界より大きいからじゃないでしょうか。
一般に多くの上司にはコスト意識というものがあり、部下が大幅なやり直しをすることを好みません。
この考えはＩＴ業界に限らず、世界中どこへ行っても同じです。
でも上司が機械音痴で、部下に対して「あいつらは こんぴぃたぁ っちゅーモン使ってかる～く仕事しちょる」なんて認識でいたりすると、コスト度外視でのやり直しを命じられたりするわけですね。
あるいはセルフちゃぶ台返しなんてケースもあります。
プログラムがある程度できあがってから基本的なミスに気づいたり、余りにも素晴らしすぎるアイデアが浮かんだりして、自ら大幅なやり直しをするパターンです。
もちろん、ちゃぶ台返しそれ自体を防ぐことが大事ではあるのですが、でもどれだけがんばっても完全にゼロにはできません。
それが仕事というものです。
だとすると実際にちゃぶ台返しが発生したとき、その被害を最小限にするにはどうすればいいんでしょうか。
修正範囲は I/F の変更によって延焼する
プログラムに修正が発生したときよくあるのが、ここを修正するとこっちも修正しないといけないという理由で、どんどん修正範囲が広がってしまうケースです。
こういう状況を今回はモジュールにまたがる修正と呼ぶことにします。
ホントにたまになんですけど、このモジュールにまたがる修正を、防ぐべきことだと認識していないケースをお見かけすることがあります。
とりわけエース級のプログラマーの方で、あまり部下を育てた経験がない人に多い気がしますね。
そういう人と話をしていると、だいたいどっかで「１ヶ所修正したら全部確認しなおすのが当たり前」とおっしゃいます。
でも、そういうことじゃないんですよね。
そりゃ確認自体は全部やるんでしょうけど、だからってどうせ確認するなら全部修正しても構わない、なんて理屈にはなりません。
プログラムの不具合修正において、テストは修正したモジュールの１つ外側の層までをテスト対象とするのが定石です。
ですので、どうせテストするからといって周辺モジュールまでぜ～んぶ修正してしまうと、テスト範囲自体はさらにその外側まで膨れてしまいます。
そうなるのを防ぐためには、問題が起こっても、それがモジュールをまたがって伝播しないように設計しておくことが大事です。
なぜならプログラムとは、根本原因の修正それ自体は問題があったからという理由で行うわけですが、
でもその周辺モジュールの修正はインターフェースが修正されたからという理由でやっているだけであり、これは問題がないのに修正していると言った類のものだからです。
つまりプログラムとは、以下の２つ以外の理由では基本的に必要ありません。
何か問題があった
インターフェースが変更された
だってモジュールにはあらかじめ定められたビジネス上の役割というものが決まっているものであって、この役割それ自体は不変ですからね。
（すでに出来上がったプログラムのビジネス上の役割がコロコロと変化するようであれば、それは機械ではなく扱う人間側の精神状態が不安定なのが問題ということになります）
業務を受け取り、適切な状態に編集して、次の担当者へ手渡す。
この、業務のバケツリレーともいうべき流れがキチンとできているかぎり、プログラムは気分で変えるものではありません。
ですから、インターフェースを変えなければ、隣接するモジュールの修正の必要性はなくなるはずなのです。
修正の発生しないインターフェースの作り方
では修正の発生しにくいインターフェースというのは、どうやって作ればいいんでしょうか。
コツは、あなたが作るモジュール１つ１つについて、このモジュールが受け取る（or吐く）データは “一言でいうと何？” という質問に一文で答えられる状態にしておくことです。
もし、プログラムの作り手であるあなたの頭の中で一文では説明しようがないとすると、それは設計が十分に整理されていないことを示します。
なおかつ、その一文は「○○のとき、○○が、○○を、○○する」のフォーマットに基づくようにします。
たとえばこんな感じ。
良い I/F のまとめ例:
- 申請IDを受け取って、申請データを取得する
- 日付データを受け取って、年月日形式の文字列にして返す
入力情報と出力情報が（ビジネス的に）それ以上分割しようがない状態にまで整理されているとき、それがインターフェースが簡潔な状態です。
逆に以下のような設計は、ちゃぶ台返しがあるとデグレを起こしやすくなります。
悪い I/F のまとめ例:
- 本人の勤怠情報を全部受け取って、その日の勤務実績を計算して返す
- 支店の顧客情報を全部受け取って、それを一般従業員向け・上司向け・上層部向けそれぞれ用に整理して出力
上記の悪い例の場合、“勤怠情報” や “顧客情報” というものの中に、（おそらく）それぞれ別人が作った（であろうと思われる）情報がバラバラに混ざって入ってきているんじゃないかと思います。
そういうの全部いっぺんに処理しちまえばたしかに最初に作るときは楽でしょうし、その気持ち自体は大変よく分かるんですが、それをやってしまうとあとで苦労するのは自分です。
個人的に過去に関わった範囲では、周辺モジュールの修正の影響を受けやすいのは圧倒的に “複数種の情報を取りまとめる” あるいは “１つの情報を、複数種類に分配する” という形態の処理です。
なぜならそのような複雑な情報を１ワンステップで処理するプログラムは、その複数の情報同士の整合性をとる処理が、（望む望まざるに関わらず必ず）本来やりたい処理の合間合間に挟まってくることになるからです。
そういう意地悪な実装は、ちゃぶ台返しのときだけでなく、そのプログラムをメンテナンスする後続の担当者や、半年後に自分自身で見直したときなどにも苦労することになります。
（恨みでいっぱいの会社を今週限りで辞めるときなんかは別かもしれませんが、、、）
つまり入力情報が複数あったり、または出力情報が複数あったりすると、圧倒的に周辺モジュールの修正の影響を受けやすいということです。
当然、入力と出力の両方が複数あるパターンともなれば、かなりカオスなことになります。
はっきりと申し上げると、設計が理想的な状態にまで整理されているシステムでは、“入力が複数種” あるいは “出力が複数種” なんて状態はありえません。
設計者による整理がちゃんと行われていれば、この世のあらゆる業務は入力１個 ＆ 出力１個にすることができるはずです。
その入力１個がシステム的に完全なアトミックである必要はまではさすがになくても、ビジネス的にこれ以上分割すると仕事にならなくなる単位くらいまでは分解しておかないといけません。
複数種の情報を同時に受け取るということは、複数の仕事を同時にやろうとすることと同じことです。
あなたが組んだプログラムの中にもし、入力が複数、または出力が複数のモジュールがあるなら、何かがおかしいからそうなったと考えるべきです。
どうしても複数必要な場合は重みづけをする
業務上どうしても複数種類の情報が必要で、それが絶対に不可分な場合、情報に重要度をつけてあげると巧くまとまります。
たとえば、以下は私が過去に経験した実際の業務で登場した情報です。
申請書を処理する業務で必要な情報
1. 申請書のフォーマット
2. 申請内容
3. 申請者
4. 承認者
この４つの情報のうち、一番重要な情報はどれでしょうか。
ちなみに全部重要は絶対ダメです。
どんなに大量の情報を使う処理であっても、絶対にそれがなくなったら業務自体が成立しなくなるものがあるはずです。
若かりし頃の私の場合、上記のようなケースでは “4.” をもっとも重要と判断することが多かったように思います。
なぜなら、大事にされるべきなのはいつだって “人” であり、社内での立ち位置的には通常、申請者よりも承認者の方が立場が上のことが多いですから。
なので “4.” が重要となります。
当然ですが、上記の判断は誤りです。
プログラミングにおける「情報の重要度」とは、社会的な立場とか、一般通念とか、ましてや社内で偉いかなんて無関係です。
情報として最も重要とは、つまり他の情報に依存していないということです。
たとえばある情報Ａが別の情報Ｂなくしては存在意義がなくなる状態にあるとき、“情報Ａは情報Ｂに依存している” などと言います。
今回のケースでは、“1.申請書フォーマット情報” は “2.申請内容情報” に依存しています。
なぜなら申請とは、行いたい申請があるからフォーマットを作るわけで、フォーマットがあるから申請してみるのではないからです。
同じように、申請しなければならない事由があるから、そこに申請者と承認者が現れるのであって、通常は逆ではありません。
もちろん “そこに人がいるから仕事が生まれる” という考えから “申請者情報” を最重要と見なすこともできそうに見えますが、今回はその考えは成り立ちません。
なぜならこのプログラムは申請書１枚を処理するために作ったものであって、申請を要する業務が発生するところがスタート地点だからです。
ですから、上記４種類のうちもっとも重要な情報は “2.申請内容” となります。
なので申請内容を頂点として、その付随情報として “1.フォーマット” “3.申請者” “4.承認者” の３つをぶら下げるように設計すれば、私がかつて作った申請処理プログラムは晴れて “入力は１種類” の状態になることになります。
このような状態でリリースしておけば、内部的にも申請内容とフォーマットが分離した状態となります。
申請内容に影響を与えずにフォーマットだけを変更したりすることもできるようになるわけです。
といっても、言葉の説明だけではなかなか理解は難しいかもしれません。
なので次に機会があったとき、ぜひ試してもらいたいと思います。
ポイントは、全てのモジュールを入力１種だけ、出力１種だけにすることです。
それが、プログラムのクオリティアップの近道になるんじゃないかなと、私なんかは思うわけです。
ではまた。