 |
「工事進行基準」対応でソフト開発プロジェクトを「見える化」する ― 新会計基準対応への追加工数圧縮と、ソフト開発プロジェクト管理の先端化を同時に進める ― |
2009年4月1日以降から新たな会計基準として、システム・インテグレータ（SIer）などの受注ソフトウェア開発業に「工事進行基準」が適用される。開発終了時に売り上げと原価を一括計上するこれまでの「工事完成基準」から、決算時点でのプロジェクトの進ちょく率などから経費（原価）や利益・損失を明確化し、企業の財務諸表に反映する「工事進行基準」が原則適用となる。
 |
| マイクロソフト デベロッパー＆プラットフォーム統括本部 デベロッパービジネス本部 デベロッパーソリューション部 テクノロジースペシャリスト 熱海英樹氏 |
工事進行基準は、直接的には企業会計に影響を及ぼすものだが、その根拠としてプロジェクトの進ちょく状況などから収益と原価を明確化するとあり、現実には開発プロジェクト管理と密接な関係を持っている。
開発が終了してから収支を一括で計上する現在の方法では、途中まではいわゆる「どんぶり勘定」式の管理でも、最後につじつまを合わせればよかった。しかし工事進行基準ではこれが通用しなくなる。今後は開発プロジェクトの進ちょくを詳細に計測し、管理しなければならない。具体的にどのような管理が必要なのか、管理工数圧縮の方法はあるのか。本稿では、現場でソフトウェア開発の指揮を執る開発プロジェクト・マネージャを対象に、「工事進行基準」対応の問題点と対処法について、マイクロソフトの熱海英樹氏に話をうかがった。
| 工事進行基準がソフトウェア開発に導入されるインパクト |
―― 工事進行基準が2009年4月からソフトウェア開発にも原則適用されるということですが、工事進行基準が適用されるメリットは何でしょうか？
熱海 ：ほとんどのSIerや受託開発企業は、開発が終了して、検収が終了した時点で収益と原価が確定する「工事完成基準」を適用していました。この方法は、開発が終了した時点で収支計算するので、経費や売り上げが正確に算出でき、会計上の客観性と確実性も維持しやすいというメリットがあります。しかしプロジェクトが複数年など長期間に渡るような場合は、その期間の企業活動が会計上はまったく見えないというデメリットがありました。例えば、プロジェクトの見込みがしっかりと黒字であっても、その健全性は開発が終了した時点でないと表面化しないわけです。
一方「工事進行基準」では、企業の決算期に合わせて、プロジェクトの進ちょく状況などを見積もって、そこから売り上げや経費などを算出します。長期に渡るプロジェクトであっても、少なくとも決算時点（四半期決算の会社ならば年に4回）での状況が企業会計に反映されることになります。これによって、プロジェクト終了後に、突然大きな収支変動が明るみに出る（突然、巨額の赤字が発覚する）などのリスクを低減できます。工事進行基準を適用することで、より正確な企業活動の実態が財務諸表に反映されることになるわけです。
―― 工事進行基準の適用は、ソフトウェア開発にどのような影響を与えるのでしょうか？
 |
熱海 ：工事進行基準を導入するために、個々のプロジェクト管理において原価の管理情報に会計上の合理性が必要になります。また、プロジェクトの完了予測を決算の都度、見積もらなければなりません。現時点の開発現場では、新会計基準が求めるレベルの管理は行っていないと思われます。つまり多くの開発現場では、工事進行基準対応のために管理の統一化やレベル向上をしたり、場合によっては、プロジェクト管理自体を根本的に変更したりする必要に迫られます。
具体的に工事進行基準では、決算時点でのプロジェクトの進ちょく状況によって、原価や計上される収益（仕掛かり）が大きく影響を受けます。これには、常にプロジェクトの進ちょく状況を説明可能な状態で管理しなければなりません。もちろん、従来のプロジェクト管理でも、進ちょく状況は管理されていたはずです。しかし従来はある程度大雑把な管理かつ担当者レベルでの主観的な報告であっても、それは社内に閉じた話であり、対外的な影響はありませんでした。一方工事進行基準では、進ちょくに応じた金額面の管理が企業の決算に直接影響します。従来のような「どんぶり勘定」では、決算の会計上の根拠を説明できません。
―― 工事進行基準に対応するために、開発プロジェクト管理には何が求められるのでしょうか？
熱海 ：繰り返しになりますが、まずは原価管理の厳密化です。工事進行基準の要は、原価総額と進ちょく率 を基に進ちょくした分の収益を財務に計上することです。原価総額は当初の見積もりだけでなく決算日に再見積もりを新会計基準では要求されているので、実績と予定に対する管理精度を向上させなければなりません。特に完了見込みである予定については、従来はプロジェクト・ マネージャが工数を経験から「人月」で適当に見積もるというケースが多いと思いますが、これでは対応できません。
理由は進ちょく率 の求め方にあります。会計基準では当期に計上する収益を算出するための進ちょく率 の測定方法の１つとして原価比例法を推奨しています。原価比例法とは、原価実績÷原価総額×100で求めるいわゆる予算の消化率になります。ここで重要なのが原価総額で、先ほど説明したように実績原価＋予定原価になりますので、予定に対する客観的な見積もりが必要になるからです。当然ながら発生した原価実績の管理精度向上も必要です。
具体的な対応としてまず求められるのは、プロジェクト管理のルールや業務フローなど、開発業務プロセスの標準化です。ルールや業務フローが属人的な状態では、企業として客観的な進ちょく評価はできません。
プロセスが標準化されたら、次にプロジェクト・メンバの作業時間管理を徹底し、同時にプロジェクトの状態をさまざまな角度から客観的に評価します。具体的には、残存タスク数やバグの発生数／解決数などです。
| 開発者の負担軽減には適切なツール活用が不可欠 |
―― さらなる管理の必要性と、管理の要点は分かりましたが、管理レベルを上げようとすると、本来の開発作業とは直接は無関係な手間を現場のプログラマに強いることになりませんか？
熱海 ：時間管理やタスク管理などは、現在でも何らかの方法で実施されていると思いますが、精度向上には、より詳細な情報が不可欠ですから、例えばバグ管理をExcelで行っているなど、情報収集やレポートを手作業に頼っていると大変な負担増になってしまうでしょう。
何にせよ、負担がまったく増えないということはあり得ないのですが、その負担を大幅に圧縮することは可能ですし、同時に、開発プロジェクトの生産性向上を図り、リスク管理能力を向上させることが可能だと思います。
―― 負担は増えるが、生産性やリスク管理能力が向上するとは？
熱海 ：答えは、開発プロジェクトの管理ツールを最大限に活用することです。開発プロジェクトの進ちょく管理に必要な情報は、開発プロジェクトの管理ツールを使って開発していれば、ほぼ自動的に収集、レポートできます。ソースコード管理やバグ管理などを、ばらばらのツールや手法ではなく、1つのプラットフォームで組織的に管理可能なツールを使うことで、工事進行基準に必要な情報は半自動的に用意できるのです。そしてこうした管理ツールにのっとってプロジェクトを運営することで、開発業務プロセスも標準化され、進ちょく状況もメンバで容易に共有できるので、プロジェクトの「見える化」が進み、開発生産性とリスク管理能力が向上するわけです。
―― どのようなツールが使えるのでしょうか？
熱海 ：開発環境にVisual Studio（以下VS）を使っているなら、弊社が提供しているVisual Studio Team System 2008 Team Foundation Server（以下TFS）との親和性が高いです。現場のプログラマは、作業時間や作業状況、バグ発生／対応状況などを、あくまで自分たちの開発プロジェクトの管理のために入力します。プロジェクト・マネージャは、必要に応じてTFSからレポートを取得し、プロジェクトの健全度を計測します。TFSだけでは原価管理まではできませんが、別途Office Project 2007と連携すればこれが可能になります。
 |
| 開発における管理システムの構成例 TFSとProjectを組み合わせることで、プロジェクトの一元管理が可能となる。 |
TFSには、ソースコードの変更とそのバージョンの履歴を管理する「変更管理機能」、バグやタスク（＝作業項目）の担当の割り当てや対応状況を追跡可能な「作業項目トラック機能」、プロジェクトの進ちょく状況を管理する「プロジェクト管理機能」、TFSが収集した各種情報をレポート化してプロジェクト全体のさまざまな情報を可視化する「レポーティング機能」、ビルドとテストを自動化して問題の早期発見に役立つ「自動ビルド機能」、TFSの情報を閲覧、手動入力するためのポータル・サイトを提供する「プロジェクト・サイト機能」など、チームでの開発およびプロジェクト管理を支援するさまざまな機能を一括で提供しています。TFSを利用すれば、開発者はVSから各種情報を効率的にTFSへ入力できます。入力された情報は各種のレポートとして瞬時に出力できますし、開発チームのポータル・サイトで情報共有できますので、開発者自身が細かな報告書を書く作業から解放されるとともに、プロジェクト・マネージャは効率的に情報を取得、分析できますし、プロジェクトの見える化も進みます。
―― TFSを利用することで、具体的にどのようなレポートが得られるのでしょうか？
熱海 ：TFSによるプロジェクト管理機能、レポート機能を実感していただくために、具体的にいくつかのレポートの例をご紹介しましょう。まずは、残存作業レポートです。これは、タスクやバグといった各作業項目に対して、総数を時系列かつステータス別の積み上げで推移を示します。終了しているもの（作業が完了しているもの）、解決済みのもの（レビュー／テスト待ちのもの）、アクティブのもの（未着手／作業中）の3種類に分けた分析結果を出力します。これにより、作業がどの程度残っているのか、いつごろ作業が終了しそうなのかを把握できます。この例では、すでに80項目の作業が終了しており、おおむね10月29日あたりに全作業が終了しそうだということが予測されています。
 |
| 「残存作業」レポートの例 この例は「シナリオ」作業項目を抽出したもの。 |
次に「プロジェクト速度」を見るレポートを見てみましょう。これは、1日ごとに何件の作業が解決したか（担当者による作業が完了してテスト／レビュー待ちの状態になったか。図の黄色の折れ線）や、何件の作業が終了したか（テスト／レビューが問題なく完了したか。図の緑の折れ線）が出力されます。「平均解決済み」の値を見ることで、その開発チームが1日にどの程度の作業を終了しているか、作業の消化状態を把握できます（この例では、5.14件と算出されています）。別の言い方をするとチームのキャパシティを把握できます。プロジェクト・ チームの作業能力は常に一定ではありません。先ほどの残存作業レポートと合わせて見ることで完了見込みの精度向上に役立ちます。
 |
| 「プロジェクト速度」レポートの例 この例は「バグ」作業項目を抽出したもの。 |
次の「バグ率」のレポートでは、バグの登録済総数（図の赤い折れ線）と解決数（開発者による修正。緑の折れ線）、日ごとの新たに発見されたバグ（黄色の折れ線）の推移が分かります。バグの発生が収束に向かっているのか、テストが有効に機能しているのかなどが分析できます。一般に正しく管理された開発プロジェクトでは、バグの登録総数はプロジェクトの中盤以降で減少に転じ、以後は少数にとどまります。逆に、そうでないプロジェクトであれば、既存の設計やコード品質の見直しが必要だといえるでしょう。
 |
| 「バグ率」レポートの例 |
これらは一例でしかありません。このほかにもTFSは、プロジェクトの現在の状態を多角的かつ容易に把握できるような、さまざまなレポートを提供します。
―― TFSはVSによる.NETアプリケーション開発以外では使えないのでしょうか？
熱海 ：VSとTFSの親和性が高いと説明しましたが、TFSの各種管理機能がVSに依存しているわけではありません。従って実際には、.NETアプリケーション開発以外、例えばJavaやPHPベースの開発でも、TFSを利用したプロジェクト管理は可能です。国内事例はまだ確認していませんが、海外ではTFSをJava開発で採用したという例があります。
また、Visual Studio 6.0などの旧バージョンのIDEに統合してTFSを利用できるモジュールも無償で提供しています。
―― 開発担当者からすれば、工事進行基準対応は余計な仕事だが、プロジェクト管理をスマートにするチャンスでもあるということでしょうか？
熱海 ：大切なことは、工事進行基準に対応するためだけの作業を、現場開発者に単純に負担させない仕組みを作ることです。開発者の本来の仕事は、品質の高いソフトウェアを効率よく、かつ期限内に開発することです。単に事務手続きが増えて、自分に何の見返りもないのでは、気力もそがれますし、何より全体の開発生産性が落ちます。
まずは開発業務プロセスを標準化して、企業で統一されたプロジェクトを管理可能にすること。そして管理のために多少の手間が増えることは避けられないが、ツール利用でそれらを最小化すること。そしてかけた手間は、自分たちの開発プロジェクトの精度向上、生産性向上に返ってくると実感できること。開発プロジェクト・マネージャとして重要なのは、開発現場からの率先した工事進行基準対応ができるかどうかだと思います。
■
すでに開発業務プロセスが標準化され、しかるべきインフラで開発プロジェクト管理が実施されているなら、工事進行基準対応はそれほど困難ではなさそうだ。しかし現実の開発プロジェクトでは、歴史的な経緯や企業独自の都合などに依存した旧態依然とした開発手法をそのまま使っているケースが多いのではないか。細部を詰める以前に人月計算で作業工数を見積もったり、開発タスクやソースコード、バグなどをバラバラのしくみで管理したりするなどだ。現状はこれでも何とかなっているかもしれないが、旧式で非効率な管理体制をそのままに、工事進行基準対応を進めることは難しい。
このような問題を抱えているなら、工事進行基準対応を契機に、開発プロセスの再評価と標準化を進めてはどうか。そして開発プロジェクトの計画や実績などをプロジェクト・メンバで共有し、プロジェクトの進ちょくやリスクなどを「見える化」してはどうか。変革をいちから進めるのは簡単ではないが、幸い現在では、開発プロジェクトを効率よく管理するためのノウハウが集約された管理システムを利用できる。その1つがVisual Studio Team System 2008 Team Foundation Serverである。
セミナー情報 |
||||
| 工事進行基準に向けた プロジェクト マネージメント実践セミナー 2009 年 4 月から会計基準が変更され、作業の進捗度に応じた収益と原価を、四半期決算のたびに計上していく「工事進行基準」が、IT 企業の SI 業務 (プロジェクト) にも適用されます。企業はシステム開発業務の開発プロセスの標準化、個々のプロジェクトの精緻な見積もり、リアルタイムな進捗の把握を実現する事が求められて来ます。 このセミナーでは、より具体的に開発現場において工事進行基準に向けたどのような準備が必要になるのかを、ご紹介してまいります。
 |
提供：マイクロソフト株式会社
企画：アイティメディア 営業本部
制作：デジタル・アドバンテージ
掲載内容有効期限：2008年9月25日
関連記事 |
|||
|
|||
セミナー情報 |
||
|
||
関連リンク |
|||||||||
|
|||||||||
関連記事 |
|||||||||||||
|
|||||||||||||
ITmediaはアイティメディア株式会社の登録商標です。
