【通算109｜要求AI 26】「日々決算」って何ですか——それが、たどり着いた解決策だった

ta_kawano

2026年8月10日 21:19

前回108で、SDDが回せるのは要求・仕様・コードという3つの輪のうち右側までだと書いた。仕様からコードへは回る。だが要求と仕様を回す機能は、Spec KitにもKiroにも無い。

ならば要求の側は、道具が無かった時代にどうやって決めていたのか。自分の案件を4つの視点で振り返り直すことにした。目標・人間・システム・データ。今回は目標を扱う。

問題解決の構造と、言葉の定義をしておく

107で4つの視点に表現を1つずつ割り当てたとき、目標だけ図にしなかった。文章のほうが分かりやすいと思ったからだ。

いま振り返ると、理由は別のところにあった。他の3つは「つながり」を描く道具だった。 組織図は関係、業務フローは順序、ER図は関連。ところが目標は単独の記述なので、線を引く相手がいない。だから図にならなかった。

つながりを持たせる方法が1つある。現状と並べることだ。

問題とは、現状と目的のギャップのこと
目的を具体的な数値にしたものが目標
ギャップを生んでいるのが原因
原因を取り除くのが解決策
そして、その問題は誰のものか

この5つが決まって、初めて目標が書ける。以下は、それを40年近く前の現場で実際にやった話になる。

当時のこと

1980年代後半、神戸製鋼所（現コベルコ）エンジニアリング事業部の案件だ。石油精製プラントや化学プラントのような一品受注の設備を、世界中の関係会社に発注して作らせ、中東などの現地で組み立てる。着工から竣工まで10年単位、コストは数百億円規模。プロジェクトマネージャーの積算単価が月300万円という桁の世界だった。

この現場のことは、自分史のシリーズでも書いた。

そちらはWBS（作業分解構成）と現場の話で、動かしていたのはApple LisaとMacintoshだった。1台100万円を超える機械だ。今回書くのは、そのシステムで何を実現したかったのかをどう決めたか、という話になる。

(1)｜渡されたのは、論文1本だった

依頼はグループのシステム会社の担当者から来た。渡されたのは、1960年代前半のアメリカのプロジェクト管理の論文だった。

「これをシステムにしてください」

三人のチームで、まず論文を読み込んだ。WBSを使った、いま読んでも通用する内容だった。

だが、そこにはこのシステムが成功したと言える条件が一行も書かれていなかった。

いまの言葉に直すと、現状も目的も書かれていなかったということになる。論文が教えてくれるのは「プロジェクト管理とは何か」であって、「この会社のいまがどうで、どこへ行きたいのか」ではない。

(2)｜現状と目的は、現場に会って初めて出てきた

実際に使う現場のプロジェクトマネージャーに会わせてもらった。話を突き詰めていくと、2つがはっきりした。

現状は、実績が月末にまとまって上がってくること。目的は、毎朝システムを開いたときに前日までの実績が埋まっていること。

そしてそれを実現するやり方を、現場の人たちは「日々決算」と呼んでいた。

正直に言うと、初めて聞いたときは何のことか分からなかった。決算というのは年に一度、多くても月に一度やるものだと思っていた。それを毎日やる、と言われてもイメージできない。

聞いてみると、こういうことだった。その日までに動いた金額を、翌朝には全部積み上げて見られる状態にしておく。 会計の締めをするという意味ではなく、進みぐあいを毎日お金に換算して見る、という意味だった。

そしてギャップが1か月だと分かった。数年から10年動き続けるプロジェクトで、桁違いの金額が動く。1か月のズレは、完成後に予定されていたすべてを後ろへずらす。ギャップに金額がつく形になっていた。

(3)｜プロジェクトマネージャーが欲しかったのは、この図だった

では毎朝、何を見たいのか。聞いていくと、1枚の図に行き着いた。

横軸がスケジュール、縦軸がコスト。計画の線と実績の線を引いて、今日の時点でどれだけ離れているかを見る。

実績が計画より下にあるとき、費用が少なく済んでいるわけではない。そこまで進んでいない、ということだ。同じ高さに計画が届いていたのはもっと前の時点で、その差がスケジュールの遅れになる。

そして遅れは、放っておいても縮まらない。完成の時期がその分ずれ、最終的な費用も膨らむ。

プロジェクトマネージャーがやりたいのは、この2つの矢印を早く見つけることだった。そして遅れの原因が、あらかじめ想定していたリスク——為替や現地の情勢——によるものなら、そのリスクに対する手を打つ。

このシステムの目的は、この図を毎日出すことだった。 何のために作るのかと問われれば、それに尽きる。

(4)｜「日々決算」とは、管理会計のことだった

財務会計では月次決算だが、管理会計では「日々決算」だった。

会計には財務会計と管理会計がある。日々の実績を金額換算して積むことは、管理会計で行われていた。

既に管理会計のシステムが動いていたので、実績を拾って、プロジェクト管理システムへ流し込む。

これが解決策だった。

(5)｜その問題は、誰のものだったか

同じシステムを作るのでも、経営者の問題として見れば「案件ごとの採算が締めてみないと分からない」が現状になる。プロジェクトマネージャーの問題として見れば「実績が月末にまとまって上がる」が現状になる。どちらを取るかで、作るものが変わる。

この案件は、エンジニアリング事業部のプロジェクトマネージャーの問題として解いた。だから日々決算という答えになった。

いまのAIに当てはめると

ここから先は、まだ答えが出ていない。考えながら書く。

108で、4つの視点で書いた仕様をSDDの道具に渡して、実装まで通した。渡した仕様には成功条件を6つ書いていた。締め日時点で当月分の100%が処理完了している。提出から最終承認まで平均3営業日以内——といったものだ。

道具はこれをきれいに受け取った。機能要件を38本導出し、そのすべてに出どころの列を付けてきた。仕事としては正確だった。

だが、やったのは写すことだった。現状はどうなのか、6つのうちどれが一番大事なのか、それが達成できるといくらの効果になるのか、それが誰の問題なのか——そのどれも聞かれなかった。

もっとも、これは特定の製品の出来の話ではないと思っている。いまのところSDDという考え方そのものが、この手前を扱う形になっていない、というほうが近い。仕様を受け取ってから先を速くする道具なので、仕様の手前は守備範囲の外にある。

いま同じ論文をAIに渡せば、驚くほど立派な仕様書が返ってくるだろう。それでも「日々決算」にはたどり着かない気がする。資料の中ではなく、人の意思決定の中にしか無かったからだ。

ただ、たどり着かせる方法が本当に無いのかは、まだ分からない。現状を聞く。目的を一つに絞らせる。金額を出させる。誰の問題かを確かめる。 そういう問いを最初から持たせておけば、届く余地はあるかもしれない。このシリーズを書きながら、そこを探っていきたい。

抜き出したもの

目標の視点から、1つ抜き出す。

現状を書かせる。目的を書かせる。その差を数値にさせる。そして、それが誰の問題かを書かせる。

4つのうち1つでも空いていたら、目標は書けていない。

自分の仕様に当てはめると、現状が書かれておらず、目的は6つ並び、効果額も無く、誰の問題かも書いていなかった。当時やっていたことを、いまの自分がやれていない。