二百四十七本の追加開発要望を、一本ずつ人の名前に置き換えた

最初に渡されたのは、A4で二百四十七行あるExcelだった。列は十一。要望内容、要望部署、要望者、優先度、それから空欄が六列。

平木です。二十七歳、入社五年目。前の案件は事業戦略で、パワーポイントばかり触っていた。この案件では、半年間ほとんどExcelしか開いていない。

アサイン ―― 「Excel速いよね」

マネージャーの筒井さんに呼ばれたのは、二月の木曜だった。

「平木くん、Excel速いよね」

そう言われた時点で、内容を聞く前に中身がだいたい分かった。行数の多い仕事だ。

クライアントは、手術用の器具と検査装置を作っている会社だった。売上は三百八十億円、従業員は千二百人ほど。国内に工場が二つ、販売は代理店経由が七割。基幹システムは十九年前に入れたもので、それを標準パッケージに載せ替える。総額は数億円規模、期間は二年半。私たちが入るのは、その最初の八ヶ月、要件定義の工程だった。

実装は別のベンダーが担う。私たちの役割は、業務要件をまとめ、標準機能で満たせるか（Fit）、満たせないか（Gap）を判定し、満たせないものをどう裁くかを決めること。裁き方は三つしかない。標準に業務を寄せる、運用でカバーする、追加開発をする。

「追加開発は、少なければ少ないほどいい」と筒井さんは言った。「作るとバージョンアップのたびに直さないといけない。十九年前のシステムがこうなったのは、それを二十年やった結果だから」

理屈は完全に理解した。理解したうえで、私は半年後に、その理屈だけでは一件も減らないことを知る。

立ち上がり ―― 千九百十二件

最初の六週間で、部門ヒアリングを回した。営業、営業事務、購買、製造、品質保証、物流、経理、それから薬事。全部で二十二部署、延べ六十回。

出てきた要件は千九百十二件だった。

このうち、標準機能でそのまま満たせるものが千四百件強。設定の変更で満たせるものが二百件ほど。残った二百四十七件が、Gapとして表に載った。

要望の書きぶりは、部署の性格がそのまま出ていた。営業は短い。「得意先ごとに納品書のレイアウトを変えたい」で終わっている。品質保証は長い。一件で十二行使って、なぜそれが必要かを法令の条文まで引いて書いてくる。経理はいちばん少なく、七件しかなかった。少ない部署のほうが、あとで厄介になる。要望を出さないのは、いまのやり方が変わらないと思っているからだ。

私は最初、この二百四十七件を優先度で並べ替えようとした。高が九十四、中が百三、低が五十。並べ替えても、何も分からなかった。優先度は要望した人が付けているからだ。

ヒアリングそのものは、思っていたより楽しかった。二十二部署を順に回ると、この会社がどう回っているかが立体になってくる。

物流の担当者は、出荷検品で使っているハンディ端末を持ってきて、「これ、十四年前のです」と言った。画面は緑色の文字だった。押しやすいらしい。「新しいのは押しづらいんですよ、平面だから」と言われて、私は初めて、指の腹が要件になりうることを知った。

薬事の若い担当者は、届出書類のフォーマットを見せながら、「ここ、システムから出ないので、毎回手で打ってます」と言った。年に何回ですか、と聞いたら「九十回くらい」と返ってきた。要望票には、その件は書かれていなかった。要望を出す習慣がない部署は、要望を出さない。二百四十七件は、困っている総量ではなく、声を上げる習慣の分布だった。

最初の四回 ―― 原則論で殴られた

Fit&Gapの判定会議は、部署ごとに開いた。一回二時間、扱うのは十件から十五件。

一回目、私は原則から入った。「今回の方針は、標準機能に業務を合わせることです。追加開発は、それがないと業務が成立しないものに限ります」

営業部門の会議だった。部長は五十六歳で、この会社に三十四年いる方だった。黙って聞いて、それから言った。

「じゃあ、成立しないって書きますよ」

四回目までに、九十四件あった「高」は百二十一件に増えていた。減らそうとした結果、増えた。

筒井さんに報告したら、しばらく黙ってから「聞き方が悪い」と言われた。それだけだった。何が悪いかは言ってもらえなかった。私は自分の議事録を四回分読み返した。自分が同じ問いを七十件連続でしていたことに気づいた。「これは本当に必要ですか」。必要ですかと聞かれて、要りませんと答える人はいない。

やり方を変えた ―― 「誰が、何分」

五回目から、質問を変えた。

「この機能がなかった場合、誰が、いつ、何分余計にかかりますか」

これを、二百四十七件すべてに聞いた。答えは相手に書かせた。書く欄を表に足した。列が十一から十四になった。

書けない要望が、ここでかなり落ちた。「誰が」が書けないものは、要望者が現場を代弁しているつもりで実は誰も困っていない。「何分」が書けないものは、頻度が年に一、二回しかない。

営業の納品書レイアウトは、書けた。「営業事務が、月末に、得意先四十一社ぶん、一社あたり十分」。月に七時間弱。これは残した。

品質保証部だけは、この問い方が効かなかった。

薬事と品質の要件は、「困る人」が社内にいない。困るのは、監査が入ったときの会社そのものだ。「誰が、何分」を聞くと、担当課長は困った顔をして、「これは分数の話ではないので」と言った。そのとおりだった。

私はそこで、この部署の要件だけ別の表に分けた。列を変えて、「根拠となる社内規程または公的な要求事項」と「満たさなかった場合に何が起きるか」の二列にした。二十九件あった要望のうち、根拠が書けたのは十四件だった。残りの十五件は、規程ではなく前任者のやり方だった。

課長は自分でそれを整理して、「十四でいきましょう」と言った。分けたことで減った。あとから思えば、部署ごとに問いの形を変えるという発想を、私は最初の四回で持てていなかった。全部署に同じ表を配ったのは、効率のためというより、自分が判断を減らしたかったからだ。

いちばん長く揉めたのは、購買の発注書の承認ルートだった。いまは金額と品目で八通りに分岐している。標準機能では三通りしか作れない。購買課長は「八通りないと回りません」と言い、私は「三通りに寄せられませんか」と言い、それを三回繰り返した。

四回目に、課長が自分で分岐の一覧を持ってきた。八通りのうち、直近一年で実際に使われたのは五通りだった。残り三つは、十年前の組織にしか存在しない部署が絡んでいた。

「これ、消していいわ」と課長は言った。私が説得したのではない。自分で数えたら消えた。以後、私は「数えてもらう」ことを主な手口にした。

会議は四十八回あった

半年で、判定会議は四十八回開いた。扱った件数は延べ三百件を超える（差し戻しがあるので実数より多い）。一件あたりの平均は、あとで数えたら十一分だった。

会議室は、社員食堂の隣だった。十一時半になるとカレーの匂いがしてくる。金曜はカレーの日だった。二百四十七行のExcelを見ながらカレーの匂いを嗅ぐ、というのを半年やった。いまでもカレーの匂いで、あの列幅を思い出す。

声が枯れた。三ヶ月目に一度、完全に出なくなって、二日だけ筆談で会議に出た。それが逆に良かったらしく、その二日は相手のほうがよく喋った。

四十七本

最終的に、追加開発として残ったのは四十七本だった。

内訳は、帳票が十九、外部システムとの連携が十一、データ変換が八、既存機能の拡張が九。二百四十七本のうち、標準に寄せたのが百三十一、運用でカバーが六十九だった。

運用でカバーの六十九件については、私は「誰が」「月に何時間」を全部書かせた。合計すると、月に四十一時間ぶんの手作業が新しく発生する計算になった。この四十一時間は、ステアリングコミッティの資料に一枚使って報告した。報告した理由は、正直に言えば、隠すと自分が後で責められると思ったからだ。

ベンダーのPMは富永さんという方で、四十代の方だった。四十七本の一覧を見て、「よく減らしましたね」と言った。それから、「ただ、この十九本の帳票、たぶん本番前にもう十本増えますよ」と言った。増えた。最終的に本番までに帳票は二十六本になったと、あとで聞いた。

ステアリングコミッティは月に一度あった。役員が四人、情シス課長、富永さん、筒井さん、私。

三回目のステコミで、常務が「二百四十七が四十七に減ったのは、現場が我慢したということですか」と聞いた。私は一瞬詰まって、「はい」と答えた。筒井さんが横から「我慢した内訳を、次回お持ちします」と足した。

次の回に持っていったのが、運用でカバー六十九件の一覧と、月四十一時間の内訳だった。常務はそれを見て、「営業事務が十九時間か」と言った。それから、「人を減らす前提で投資を通してるんだけどな」と続けた。誰も何も言わなかった。私も言わなかった。

その一枚は、たぶんこの案件でいちばん意味のある資料だった。同時に、いちばん歓迎されなかった資料でもある。両方が同時に成り立つことを、私はこの案件で覚えた。

生活 ―― 五年目の平日

朝は七時前に起きて、七時四十分の電車に乗る。常駐先は乗り換え一回で五十分。座れることはない。車内で前日の議事録の続きを打つ。

夜は、その日の判定結果を表に反映してから帰る。二十一時前後。終電になるような案件ではなかった。この案件で徹夜は一度もしていない。それでも三ヶ月目に体重が四キロ落ちた。理由は分かっていて、昼を食べないからだ。会議が十一時半から十三時まで入るので、隣からカレーの匂いだけ嗅いで食べ損ねる。

家賃は八万二千円、二十三区の端のほうで、駅から徒歩十四分。年収は八百五十万円台。同期のうち二人が去年辞めて、一人は事業会社、一人はもう一度大学に行った。

ジムは、この案件の二ヶ月目に解約した。月八千八百円を四ヶ月払って、行った回数は三回だった。

要件定義の終わりと、その後

八ヶ月目に要件定義書を納めた。私たちの契約はそこまでだった。設計から先はベンダーと情シスで回す。

私は次の案件に移った。稼働は一年二ヶ月後だと聞いていた。実際、そのくらいで動いたらしい。

稼働から半年ほど経ったころ、情シス課長の尾坂さんから、私の携帯に電話が来た。用件は、製品の回収が一件発生したときの、ロット単位の出荷先追跡だった。

その要件は、二百四十七本のうちにあった。私は「運用でカバー」に分類していた。頻度が年に一回未満で、「誰が」の欄には品質保証部の名前と、月ではなく「発生時のみ」と書かれていた。だから落とした。落とすとき、私はそれを合理的な判断だと思っていたし、いまも合理の範囲ではあると思っている。

尾坂さんは責めなかった。「二日がかりでしたけど、追えました」と言っただけだった。二日がかりだった、というのが答えだ。

後記 ―― 数だけが残っている

この案件で私が身につけたのは、たぶん、要件を減らす技術ではない。減らした要件が誰の手元に移ったかを書き留めておく癖のほうだ。

二百四十七、百三十一、六十九、四十七。この四つの数字を、私はいまも暗記している。暗記していることに意味があるかは分からない。次の案件で似た仕事が来たとき、私はまた最初に行数を数えるのだろうと思う。

一つだけ、あの表について後悔していることがある。「運用でカバー」の六十九件に、私は工数は書かせたが、その作業を引き受ける人の名前は書かせなかった。部署名までで止めた。名前まで書かせていたら、たぶん六十九は六十九にならなかった。

いま入っている案件でも、同じ形の表を使っている。列は十六に増えた。名前の欄は、まだ作っていない。