総HLRだけでは、よく分からない
ある橋梁の100年間のHLRを計算したところ、結果が19人年だったとします。
数字は出ました。しかし、この数字だけを見ても、使い道に困ってしまいます。建設に何人年かかるのか。点検に何人年か。補修に何人年か。更新はどうか。19人年の内訳が分からなければ、この数字がどんな仕事の積み重ねでできているのかが見えません。
総量だけでは足りない。その内訳が必要だ。HLR Calculation Engineの開発を進める中で、私はそう気づきました。
建設工事には積算書がある
建設工事では、工事費の内訳を積算書で確認できます。
積算書は、工種ごとに費用が分かれています。さらにその下には、数量、単価、歩掛（作業量あたりに必要な労務や資機材の量）といった情報が並びます。これらをたどっていけば、「なぜこの金額になったのか」を後から確認できます。
工事費の総額だけを渡されても、発注者は判断できません。内訳があり、根拠をたどれるからこそ、金額の妥当性を検討したり、設計を変えたときの影響を見積もったりできます。建設工事に携わったことのある方には当たり前の話ですが、この当たり前の仕組みが、HLRにも必要なのではないかと考えました。
HLRにも、内訳をたどれる構造を
HLRの場合も、同じように考えられます。
まず総HLRを、建設、点検、補修、更新といった段階に分解します。さらに建設であれば、土木工事、機械設備工事、電気設備工事などに分かれ、その下には個別の作業ごとの必要労働量があります。総量から内訳へ、内訳からさらに細かい作業へと、上から下へたどっていける構造です。
単に合計値を表示するだけでは不十分です。「19人年」という数字が、どの工事、どの作業の労働量を積み上げた結果なのかを、利用者が自分でたどって確認できる。なぜその数字になったのかを、下へたどって説明できる。そのような構造を作りたいと考えています。
これは前回までに考えてきた、入力条件や係数、計算ルールを記録して結果と結びつける話とも地続きです。計算の根拠を残すだけでなく、その根拠が結果の中でどこに効いているのかまで見える形にする。それが、今回の気づきの中心です。
計算するだけでなく、説明できるエンジンへ
数字の根拠をたどれるようになれば、できることが広がります。計算条件を一つ変えて、どの部分の労働量がどう変わるかを確認できます。別の工法を採用した場合に、どの工程の労働量が増減するのかを比べることもできます。
ただし、そのためには、計算結果を階層的に管理する仕組みが必要になります。結果を一つの数字として保存するのではなく、内訳の構造ごと保持する。第6回で考え始めたHLR Engineのシステム構造に、また一つ必要な要素が増えました。
19人年と表示されても、その中身が分からなければ使いにくい。だからHLRにも「積算書」が必要だと思った。それが、今回の開発日記の結論です。
コメント