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

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

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

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

永島志津夫

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

失敗できないプロジェクト 〈急所〉

プロジェクトの “急所” 、一つ挙げるとしたらどこでしょうか？　プロジェクト計画、要件定義、設計、開発、テスト

どれも大切ですが、問題が表に出てくるのは “テスト” ですよね。結合テスト、システムテストでこんな問題が起きることがあります。

１．テストに入れない（プログラム がない！、ファイル、テーブル がない）

２．テストに入れない（テスト仕様書がない！）

３．テストに入れない（環境がない！、時間枠がない）

１番目のケース、まさかそんな！と思われますよね。でも開発の遅れで一部プログラムが揃っていないということは経験があると思います。影響のないところからテストをはじめます。またテストを始めた途端、仕様の取り違えが判明しテストにならない、ということもあるでしょう。結合テスト段階で単体テストのバグが出るというケースです。そもそも取りこぼしでプログラムを作っていなかった、リリース期日の間違え、もあるでしょう。

規模が大きくなる程、この手の初歩的なミスが増えます。

プログラムができるまでは、ドキュメントベースで確認するしかありません。要件定義書、設計書など何百ページもあるドキュメントを目検していく訳なので、ベテランであっても一定割合で、ある、なしレベルのミスが発生します。

発生割合ですが、さすがに全体の10%ということはありませんが、0.1%ということもありません。感覚的に１%はありますね。２%前後はあってもおかしくないと考えておくのが相場です。

結合テストからシステムテストと進むにつれ、ある、なし レベルのミスは全体の足を引っ張ります。影響のおよぶ範囲のテストを止めてしまいます。ミスは避けられません。早い段階で露見させるのが賢い対策です。PM（プロジェクトマネージャ）、PMOの真価は課題対策にあります。

“仮組み”

そこで開発中であっても、週の最後に、出来ている分だけ、ある分だけのプログラムを集め、中途半端なデータベースにつないでしまうのですね。私はよくやりました。ポイントは集めるにあります。

ビルドエラーも出ます。マスターのコード定義もありません。初めは動きません。それでも無いものが分かるので

「来週これは作る予定だよね？」

と確認できます。そこでドキッとします。

「忘れるところでした（本当は、忘れていました）」

というふうに。

アジャイルだと、頻繁にビルドをしているので、ある、なしレベルのミスは防止できますね。限られた時間と集中力を設計開発に回せるのは利点です。

“仮組み” はウォータフォール開発や基幹系システムでもおすすめです。「忘れている」というと、担当者に対する落ち度の指摘です。指摘された方は気分のいいものではありません。指摘する側も、言いたくて言っている訳ではありません（言いづらいです）。人間同士お互いの負の感情はコミュニケーションを阻害します。できれば避けたいものです。

 “仮組み” は「ある」「なし」を見えるようにしています。担当者が「忘れていた」ことに違いはありませんが、指摘は、仮組み環境を経由した間接的なものになります。同じことでも人から直接指摘された時のような負の感情は生じないか弱いものになります。

「見える化」とか「可視化」は問題発見の効率化と合わせて、担当者の前向きな行動や、グループのコミュニケーションを維持する効用があるのではないでしょうか。

“仮組み” 試してみてはいかがでしょうか。

永島志津夫

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

失敗しない要件定義 その２ 〈コミュニケーション〉

コミュニケーションについてのエピソードをご紹介します。

あるお客様から課題要望事項をまとめた一覧表がEメールで届きました。課題と思われること、課題ではないが実現できればなお良いと思われる要望があれば、ご連絡くださいと、前回の打ち合わせで私がお話したことを受けて送っていただいたものです。 

ただ一覧表を見ると担当のスタッフは驚いてしまいました。そこにはとてもご契約期間内（1ヶ月）で完了できないほど多くの事項、初めて聞く内容などがあったからです。これを一つ一つ実使用に耐える品質で実現することなど到底できません。担当者は途方に暮れかけていました。少し時間をおいてから私もそのメールと課題要望事項の一覧表を確認しました。 “まずは電話で課題要望事項として挙げた背景、理由であるとか、是非とも必要なことなのか、きいてみてはどうだろう？” と担当スタッフに話しました。幸いすぐ電話で連絡がつきました。30分程お話した内容は以下のようなものでした。  

“社内から色々と要望、課題が出てきており、その量を認識、把握する意味合いもあり一旦全て表にまとめた。要望として挙げているものも、すぐ実現が必要という認識ではなく、これから数ヶ月の中での改善を考えていく上での検討材料という位置付けである。もちろん要望を実現できるに越したことはないが、なかには相矛盾する要件も存在している。要するに、表に挙げたような要望は現在もあるし今後も出てくるであろう、そのような状況にあることをまず共有、理解してもらいたかった。”  

また、課題とされているものも一つ一つに対応するというよりは、業務に与える影響、代替手段（人手で回避、工夫できないか）、そもそも課題として挙げていることの理由、妥当性などの検討を一緒にしたい。それから現実対応できるものを絞り込んで、順次対応していくプランを作ることができたら、と考えられていることが理解できました。 

いかがでしょうか？電話でのコミュニケーション。リアルタイム、インタラクティブですから効率がいいですね。テキストよりもはるかに情報量が多い分、相互理解に有利ですし、お互いの時間を共有したこと自体が価値になります。逆に、お客様から時間をとるに値しないと思われたら要件定義失敗です。電話が苦手なスタッフが増えていると聞きます。ボイスコミュニケーション、もっと活用して欲しいと思います。

永島志津夫

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

工事進行基準廃止！

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

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

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

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

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

永島志津夫

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

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

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

失敗できないプロジェクト 〈成功の秘訣〉

システムプロジェクト成功のポイントは要件定義にあります。では要件定義の成功のポイントは？　プロジェクト開始前の事前ヒアリングです。規模の大小、期間の長短問わず、1,2回の事前ヒアリングの有無が、プロジェクトの運命を決めます。全体の費用対効果、QCDを大きく左右します。

“ 事前ヒアリング ” 、うちでもやっているよ、と思われるでしょう。それがプロジェクト成功のポイントになるのか？

事前ヒアリングの断片的な情報から、必要とされるもの・ことを具体的に想像して、仮説レベルの全体像をイメージ。要件定義の限られた時間で、検討すべき課題を具体化し、キーメンバーのアサインを決める。

これが、事前ヒアリングからのアウトプットです。

要件定義の重要検討テーマ、セッション・スケジュール、そして仮説レベルですがシステムの全体像、おおまかなデータモデルまでイメージします。要件定義はその仮説検証となります。一般的には要件定義フェーズの計画書ですが、この段階で高い品質を目指し、ゴールに近づいています。

成功しますよね。だから事前ヒアリングが重要です。仮説作りです。

プロジェクトリーダには業務知識、システム設計経験もですが、コミュニケーション能力、ドキュメンテーション能力が重要です。仮説作りは、インプットからロジカルにアウトプットするという思考法ではありません。課題解決型の非日常的な思考法です。プロジェクトの初期段階はお客様、ベンダー共にお互いのことが分かっていない、情報不足した状態ですから、仮説作りの思考法が効果的です。

事前ヒアリングもう一つの利点はベンダーの実力が、早い段階でお客様にはっきり分かることです。不幸にも実力のないベンダーを選んでしまったら、お客様側がそれに合わせるしかありません。
初めて要件定義をするリーダーがアサインされているかもしれません。業界、業務知識ゼロかもしれません。お金を払っているのはお客様。でも、ほとんどお客様がベンダーに仕事を教えて、チグハグなドキュメントをもらって、真っ赤になるほど赤入れをしているかもしれません（アジャイルとかスプリントがどうとか言って、ドキュメントを出さないベンダーもいるかもしれません）。事情はともかく、あいみつ（相見積もり）なり、コンペなりをして、事情了解の上で、契約、注文書を発行してしまったのですから、元には戻れません。

泣くのはお客様側、特に業務の現場のみなさんです。こうならないように、事前ヒアリングでベンダーの実力をみてください。コミュニケーション能力、ドキュメンテーション能力も伺い知ることができるでしょう。人柄、第一印象も重要です。そういう相談の仕方、提案依頼をしてみてください。

永島志津夫

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

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

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

システムの費用対効果 〈 RFP 提案依頼 〉

RFP ( Request For Proposal ) 提案依頼 という 仕事の依頼の仕方があります。背景、前提、希望などを伝えたうえで、“良い提案をして下さい” というものです。システムやプロジェクトという無体物を相手に何と大胆なことでしょう。

この世界で仕事を始めた頃、そう思いました。安い予算ではないのです。大きな仕事程、この RFP を使います。RFI ( Request For Information ) 情報提供依頼というのもありますが、ほとんど同じようなものです。要件が定まる・定める前段階で、望ましいゴール、そのためのプロジェクトの概要をシステムベンダーに考えてと依頼を出すのですね。契約に基づく依頼ではないので応じる義務はありませんが、大きな仕事や、取れそうな仕事とみると、それなりに手間ひまかけて、提案書を作ったり、プロトタイプまで用意したりすることもあります。当て馬とみると簡単に済ませます。なので、あいみつ（相見積もり）と同じで、前提が揃いません。結局は予算に収まるとか、価格の安いところに出すという判断になります。無体物ですから、本当は値段以前に必要なもの、ことが足りているかが大事です。

もうお分かりだと思います。問題が露呈するのは最終段階、移行のところです。 “ それはお客様でやって頂きます。 ” 　これが決まり文句です。他社が導入しているからといって安心は禁物です。新システムへのログインのタイミングが少しずれただけで移行に失敗することもあります。ユーザーにアナウンスしたつもりでも、ちょっとした隙にトランザクションロス、マスターロスが入り込みます。今はもうないと思いますが、オンプレのADから365のADへの移行でエライ目に遭ったことがあります。移行は準備も含め、時間もお金もかかります。経験も必要です。ここを端折れば当然安くなります。

安易なRFP止めましょう。安いところ選ぶのお待ちください。移行に不安はありませんか？

永島志津夫

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

システムの費用対効果 〈 仮説 〉

仮説　－　大きなテーマです。仮説なき行動、時には必要かもしれませんが、仮説なり道筋があるに越したことはありません。納期、予算が決まっているプロジェクトであればなおさらです。

仮説を暫定的な成果イメージと言い換えてもいいかもしれません。全くの白地から挑戦するよりは、下書きが欲しい。それに沿って、というより、その仮説の妥当性を検証するという進め方だと、調べること、考えることのポイントをおさえることができます。仮説は修正されますが、それでも場当たり的に手を動かすような無駄はありません。いい仮説をプロジェクトの初期、もしくは開始前にイメージできるかどうか、プロジェクトリーダーの経験と力量に掛かっています。（データサイエンスも同じで、ゼロからマイニングができたら儲けものですが、実際は現場やお客様の声のから閃いた直感を仮説検証して新しい取り組みにすることがほとんどです）

フューチャーアーキテクト（当時はフューチャーシステムコンサルティング）にいた頃、調査、計画立案というプロジェクトフェーズでは最初の2週で成果イメージ、仮説ができていなければアウトでした。毎週の検討会でお客様と話しができなくなります。初めはインプット大、アウトプット小で許されますが、１、２回で終わりですから。
大変ですけど仮説とかストーリーができていると、あとが楽なのですよね。次のフェーズの準備もできるので費用対効果も向上します。

仮説作りの段階から参加させてください！

永島志津夫

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