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

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

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

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

永島志津夫

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

失敗しない要件定義 その３ 〈要注意な言葉 アカウント〉

アカウント（Account）という言葉、あまりに意味が多過ぎて困ることありませんか？ただでさえ、業界、会社ごとの業務用語 “方言” があって、システム泣かせなのに、基本的な言葉の指す意味が複数あるのってどうなんでしょうか？

クイズです。それぞれアカウントはどういう意味で使われているでしょうか？

シーンその１ 

システム屋：「現状のアカウントの一覧ご用意頂けますか」 

ユーザ部門：「分かりました。財務でいいですよね？」

シーンその２ 

システム屋：「現状のアカウントの一覧ご用意頂けますか」 

ユーザ部門：「全支店分ですか？何のためですか、許可は取ってますか？」

シーンその３ 

システム屋：「現状のアカウントの一覧ご用意頂けますか」 

ユーザ部門：「国内なら今週用意できると思います。海外現法はちょっと聞いてみないと・・」

シーン１では勘定（科目）の意味です。財務会計の勘定科目ならあっという間に出せますよね。項目数でも1000ないくらいで意味のブレもそうそうありません。業種により多少違いはあっても経理さんに聞けば大丈夫です。（ただし補助勘定はローカル運用なのでご注意を）

シーン２は銀行口座の意味ですね。ペイオフ制度のため名寄せが進んだとはいえ、口座は支店別管理です。定期預金口座は普通預金口座と別になっています。なので振替で資金移動をします。同一名義の別支店口座も振替であり、振込ではありません。振替とか、繰越とか会計と同じニュアンスで使われていますね。（あまり遭遇しないと思いますが、医療機関も施設別患者管理です。患者情報の施設外持出は原則不可です）。

シーン３は得意先の意味で、銀行以外の業種でも得意先のことを口座といったりします。業務システムでは一般的な使われ方です。販売管理のキーとなるマスターですから、要件も盛りだくさんです。すぐ思いつくだけでも

・請求先か、届け先か、関連付けはどうしているか？

・与信（枠）管理はどの範囲で行っているか？
・仕入先は別管理か？
・グループ会社取引はどうフラグ付けしているか？
・国・地域、通貨、関税などとの関連付け・・・

新しく導入したシステムでは減ってきていると思いますが、コードが８から始まるものとか、必ず確認していました（ニヤッとされる方もいると思います）。

英語のミーティングでは Accounts of BS,PL, Bank account, Cusomer account と確認すれば良いかと思います。届け先は Address になります。

アカウントの話、ITっぽくありません。システムと全然関係ないようで、知らないと要件定義１回目からアウトです。コンシューマとビジネスで考え方が丸っきり違います。アカウント＝ユーザーではありません。以前、顧客コードを電話番号にしようとしていた人がいました。今なら E-mail でしょうか。絶対だめです。

永島志津夫

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

失敗しない要件定義 その１

IT / システム部門の方とお話をするのですが、苦労が絶えないのは相変わらず要件定義のようです。開発になるとパソコンに向かうことが多くなるので技術者という感じですが、要件定義は対人業務です。ストレス解消法も良く話題になります・・

要件定義には、コミュニケーション能力とドキュメンテーション能力（とストレス耐性）が求められます。業務要件を言われた通りに丸写しすればいいというものではなく、システム化、シンプル化のインタラクティブな現場対応が必要です。コンピュータは賢くありません。だからといって闇雲に要望を切り捨てたら使えないシステムになります。実現性、工数などを勘案して、賢くないコンピュータを不便でない程度にブラッシュアップして、費用対効果に見合うようにするのですが、実は要件定義で大方結果が出てしまいます。*

設計フェーズで見直すという考え方もあるのですが、予算が決まっている以上、要件を膨らます訳にはいかないのです。要件精査でもたついたら設計フェーズの時間が削られてしまいますし、そもそも忙しい業務の合間をぬって検討会に参加してもらった業務部門のキーメンバーとの関係にひびが入るなど、デメリットばかりです。

すべては無理にしても要件検討会のその場その場で問題処理をしてしまわないと時間切れになります。データもあいまいでは困るので定義を明らかにしていきます。データ間の依存関係、上下関係も大事です。幹をクリアにしないと例外要件なんかまず出てきません。

プロジェクトは要件定義開始2週間が勝負です。最初の2週間でセッションをリードできれば要件定義をスケジュール通りに進めることが出来ます。失敗するプロジェクトは、要件定義が終わっていないのに時間切れで次のフェーズに進めている場合が多いです。設計フェーズで吸収しよう、ということですが、設計フェーズの方が投入工数は増えるので進捗の遅れのインパクトが大きくなります（工事進行基準廃止！）。要件定義が終了しているモジュールから五月雨式に設計に入ろう、としますが、データモデルを共有している以上、影響が伝播します。結局、設計修正、手戻りが発生し二重コストになります。データモデルが確立していない段階でのアジャイル開発が失敗するのはこの点にあります。MVC ( Model, View, Controler ) のModelについてはウォータフォールに利があります。データモデルを精査するためにはユースケース（システム利用、操作仕様）の理解が必要で、業務シーンではその重要なインプットの一つに業務フロー（業務フロー）があります。

業務フロー図にやり取りされるデータは定義されているでしょうか？失敗しない要件定義の分かりやすい Howto を一つアドバイスさせて頂くとしたら、

業務フロー上のデータを精査

することです。あまりうるさく言われていないようですが、成功のカギの一つです。
大変かもしれませんが、必ず報われる苦労ですので。是非一度レビューしてみて下さい。

永島志津夫

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

* 顧客サービスですから、ここをうまくお話ししないと仕事が終わってしまいます。状況をフェアに説明し理解を得て、妥協点に落ち着かせる交渉事でもあります。

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

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

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

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

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

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

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

永島志津夫

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