システム開発と原価計算 プロジェクト管理に実際原価がそぐわない？

製造業の原価計算システムを設計開発することもあります。前工程から実際原価を算出し後工程に反映していきます（転がし計算）。これを連結ベースで計算することもあります。そんな高度なことしつつも、灯台下暗しで、システム開発会社で実際原価計算をしているところは滅多に見かけません（私が知るのは過去1社だけです）。

エンジニアはだいたい固定給なので実際原価把握が容易なのに、なぜでしょう？どうも原因はプロジェクト管理にあるようです。プロジェクト管理と原価計算はもちろん別物ですが、一緒にやろうとすると実績原価（標準時間単価×実績時間）でプロジェクト管理して、原価差異を足し引きして財務上の原価を出しますが、実際原価に戻ってきます（当たり前ですが）。標準原価法を使ったところでプロジェクトを推進するプラスアルファは何もありません。予定原価と実際原価がほぼ一致する業種ならいざ知らず、試験や移行の工数を漏らすレベルで標準原価法を使う意味はありません。プロジェクト計画のリアリティチェックをするだけなのですが、できていないですね・・

EVM（Earned Value Management）という進捗管理法があります。これは予定原価が信頼できる前提ですから、システムの世界ではダブルクエスチョンものです。そもそも信頼できる予定原価計算ができていればプロジェクトは成功を約束されたようなものです。すべて見通している訳ですから。形式的なプロジェクト管理も必要ないでしょう。待っていればQCDいずれも満足のいく結果が得られるます。前にも書きましたが見積、工数計算はシステム設計でも高い習熟度が求められる能力です（システム開発〈見積・工数計算〉）。　要は経験、能力が未達ということで、人材不足なのでしょう。新しい言葉、言語、開発フレームワーク、資源管理・・が出ては消え、出ては消えを繰り返して、本質に切り込めず、周りをまわっているだけのような印象です。予定原価に信頼性がない以上、システム開発の原価計算は実際原価で十分だと思います。

永島志津夫

全社のシステムを少ない人数で見ていれば時に見落としもあるかもしれません。
オフィスエヌ ショートレビュー5万円から。
連絡先 office.nagasima#gmail.com (#を@に変えてメールをお願い致します)

システム開発 〈見積・工数計算〉

システムの設計開発、工数計算をする側のお話です。”見積依頼” とか “提案依頼” の対応、なかなか手間を取ります。それでコンペだったり、価格交渉だったり、使った時間を回収できないこともあります。来ないと困るし、来たら大変だし。だからと言って、おろそかにできません。受注したら責任が発生します。納期、品質を守るにはそれなりのお金が必要で、工数計算間違えていたら大ごとです。その大事な工数計算、このAIの時代になっても進歩していません。逆に技術が細分化、ダイバースしたためトータルで工数を見積もれる人材が減っているのではないでしょうか？

設例）アクセサリーの卸販売を手掛ける企業から、受注業務のシステム化についての見積依頼があった。

出荷配送はサンプル品を除きすべて配送ベンダーに任せており、Webで出荷指示が可能である。ショップからの注文はメール、FAXおよび電話である。FAXが６割、メールが３割、電話が１割で取引先数は 2000件ほどである 

アイテム数はおよそ600、SKUとして3000程度だが、常時入れ変わりがある。オーダーは月平均2000件程度、多いときは5000件、担当者２、３名で平日の営業時間で対応している。 

情報はいったんこれだけだとして、明日までに概算見積が欲しいと言われています。システムの見積できるでしょうか？業界常識など書かれていない与件があるのですが、経験的にはこのシステム ￥５千万から７千万位になるかと思います。もちろん仕事では機能積上げ法の結果と突き合わせます。明日までに概算が欲しいと言われても、￥１千万の見積だしたら大変なことになります。また販売管理パッケージ提案したら物笑いになります。スクラッチです。
このシステム ￥５千万として費用対効果（投資対効果）は見合うでしょうか？２，３名でこなせる業務ですからそのままでは見合いません。同業者と共同利用のような形がとれるなら検討の価値ありです。発注側も見極めが大事です。

情報技術関係の資格試験も増えましたが、工数計算の問題がないのはなぜなのでしょう？工数計算ができないとエンジニアのキャリアも描けないですし、工数計算のできないプロジェクトマネージャーも困ります。直球の問題出してほしいです。細分化した知識試験を積み上げても工数計算も要件定義もできません。ということは知識の持ち腐れになります。
仕事仲間から聞いた話ですが、システムテストが開発工数の〇分の１、システム移行は見積なしという案件があったそうです。基幹系です。情報処理資格は一体何をクオリファイしたのでしょう？発注者のみなさん、お気を付けください。成功に必要なのはコンペよりもセカンドオピニオンです。

永島志津夫

全社のシステムを少ない人数で見ていれば時に見落としもあるかもしれません。
オフィスエヌ ショートレビュー5万円から。
連絡先 office.nagasima#gmail.com (#を@に変えてメールをお願い致します)

工事進行基準廃止！

“ 2021年4月以降開始の会計年度から工事進行基準廃止（強制適用） ” 大規模なシステムを請負開発している会社（の経理部）さん大変です。いまからソフトランディングできるよう調整かけていると思います。今回はシステム開発、プロジェクト管理を会計、原価管理面から触れたいと思います。

そもそもですがシステム開発の進捗って、計量可能でしょうかね？計量可能だとしたら尺度、単位は何でしょうか？禅問答のようですが、これがシステム開発の進捗把握を困難にしている要因の一つです。答えは工数なのですが、その工数が曲者で、意味ある仕事をした時間、生産的にソフトウェアを生産（設計、開発）した時間です。その中には顧客打ち合わせ、設計書などの資料作成も含まれます。これらが原価計算でいうところの直接労務費になります。他の業界では間接費にあたるものが、ソフトウェアの場合、直接費であり原価のほぼすべてを占めます。ベテランと新人では生産性は桁違いです（もちろん仕事の質、役割の違いもあります）。ベテランといえどもお客様やチームメンバーとのコミュニケーションに難があるとパフォーマンスが落ちます。要員をアサインしていれば工数は日に日に増えていきますが、その通りに進捗している訳ではありません。予定工数（予定原価）と実績工数（実際原価）の乖離が広がるだけです。予定工数の信頼性が失われた時点で、もはや工数は進捗計量の用をなさなくなります。いわゆる炎上です。

経理部の人が聞いたら驚かれるかもしれませんが、経験あるリーダー（プログラマーからのたたき上げ）は、投入工数をあてにしていません。毎週のソースレビューや小規模な動作試験の結果で完成度をざっくり評価しています。機能単位・難易度別に未着手(0%)、着手(10%)、仕掛中(20-60%)、完成検査待ち(70-80%)、検査終了(90%)のようなステータスを置いています。あたかも建物のような構造物のごとく、システムの仕上り具合を目視しています。感覚的に評価することもありますが、メンバーの顔を見ながら話しをしているので、そんなに外れません。ソースレビューはメンバーの実力や弱点が良くわかります。支援のポイントもわかります。その点でもプロジェクトを推進するのにプラスです。
ただし手間がかかりますし、たたき上げのリーダーでなければこのスタイルはとれません。リーダーの仕事、それだけではないですからね、大変です。ですがシステムの品質は確実に向上します。

スクラッチ開発からパッケージソフト導入に時代は変わりました。手間のかけどころも変わったと思います。工事進行基準は廃止していいと思います。こんなことまでやれというのは酷です。完成基準で、受入検査合格、不合格でいいのではないでしょうか。

ただ事業の命運を握るようなシステムは工数で進捗把握をしないでください。目利きをいれて実際の進捗把握を行いつつ、高い品質のシステムを作ってください。

永島志津夫

全社のシステムを少ない人数で見ていれば時に見落としもあるかもしれません。

オフィスエヌ ショートレビュー5万円から。

連絡先 office.nagasima#gmail.com (#を@に変えてメールをお願い致します）

システムの費用対効果 〈 工数計算 〉

工数計算、見積を作る側のお話です。実はシステムエンジニアの実力が、数値としてはっきり表れるのが工数計算です。要は難しいということです。

難しさその１　実務経験が必要（設計開発、後工程の経験）
Windowsアプリでも、Webアプリ（フロントエンド）でも、サーバーサイド（データーベース、ビジネスロジック、フレームワーク、基盤構成・・・）でも、実務経験のないことは工数のイメージが湧きません。要素技術偏重の昨今だと全体を見通すことが難しいと思います。

難しさその２　仕様理解が必要（要件定義、前工程の経験）
何行程度なら何時間というものではないんですよね。あくまで業務要件とその実装というイメージで工数建てしていくので仕様理解が必要です。ファンクションポイント、積み上げ法も使いますが、細かく機能分解しても見積精度は上がりません。経験ベースで業務要件から工数建てしていく方が的確に出ることが多いです。なので積み上げ法の場合、過去事例、類似事例との比較で妥当性チェックもします。

特に重要なのは特殊性、例外要件の理解。
時々あるのですが、要件定義と設計開発が別のチームリーダーの場合。うまくいかないですね。ひどいのになると、前工程と後工程が別の会社という場合があって、前後でお互いの責任はありませんから、損をするのはお客さんです。
要件定義と設計開発を同じ会社にやってもらうのが一番です。時間単価が高くなるかもしれませんがトータルで納期、金額とも少なく済みます。それができない場合はお客さん側でしっかり仕様把握、設計レビュー、工数管理をすることになります。

昔はみんなこれでやっていたのですが要素技術の広がりとともにベンダー任せになってしまいました。要素技術を絞るのはシステムの費用対効果を上げる近道です。クラウド＆ウェッブサービスの組み合わせもいいのですが、費用対効果は発注者自身が見極めないといけません。悪気はないのですが、ベンダーは自分の得意なことは言っても、不得意なことは言いません（不得意なことの方が圧倒的に多い）。

システムの費用対効果、一度見直してみませんか？

永島志津夫

全社のシステムを少ない人数で見ていれば時に見落としもあるかもしれません。
オフィスエヌ ショートレビュー5万円から。
連絡先 office.nagasima#gmail.com (#を@に変えてメールをお願い致します