[コラム:研究員のココロ]ユーザからみたシステム開発の疑問について

出展:日本総合研究所ホームページ(http://www.jri.co.jp/)「研究員のココロ」　(株)日本総合研究所　主任研究員　黒田　賢三 2008年4月7日付」より


　筆者はこれまで、システム構築が計画されている企業において、業務プロセスの見直しから要求定義のとりまとめ、システム開発業者の選定、システム構築のサポートまでを行ってきました。
　本コラムでは、これまでのコンサルティングの中で気づいたことやお客様から何回か質問されたシステム開発についての疑問についてお答えしてみたいと思います。

１．見積金額はどうやって決めているか

　システム開発業者は、ＲＦＰ（request for proposal）を基にシステム開発規模を見積もります。見積手法は、大型コンピュータ全盛時代からの懸案でこれといった正解はありません。昔は、システムの規模を「ステップ」というプログラムコード１行を積み上げて積算し、１人月あたりの「ステップ」生産性で割算して人月数を出し、さらに１人月あたりの要員単価を掛けて見積金額としていました。
　今は、そのような計算をしている企業は少なくなっていますが、根本にある考え方は変わっておらず「開発費用原価×安全率＋利益見込み額＝見積金額」となっています。最近の見積では人月は表に出ずに「機能数」や「画面数／帳票数」など人に依存しない数値に変化しています。

２．値引きはどの程度が可能か

　結論から言うと、見積金額には通常５〜１０％くらいの「安全率」が掛かっていますので、この部分についての値引き要求は妥当性があります。これは、ＲＦＰでは最終的なユーザーニーズの詳細を１００％表現することは不可能で、ＲＦＰからでは読み取れない詳細な要件が多くあるからです。そのため、システム開発業者では、あらかじめ隠れた部分があることを想定し、ＲＦＰの記述内容の精度から統計的（経験的？）に算出した「安全率」を掛けて見積もることになります。
　ただし、契約金額＝人月×単価＝サービス提供時間であるため、値引きは、そのままサービスレベルに跳ね返る可能性が高いことを認識しておくべきでしょう。

３．コード設計の今と昔

　昔の情報システムは、汎用コンピュータを利用した非常に高価なものが一般的でした。そのころのコンピュータは、処理速度やデータの蓄積可能容量が今のパソコンに比べて格段に劣っていました。その高価なコンピュータを出来る限り有効利用するため、コードは出来る限り短いことが必要であり、設計は非常に高い技術が要求される作業となっていました。短い英数字で構成されるコードの中に、色々な意味や仕組みが組み込まれていました。社員番号の１桁目は入社年号で、２桁目は最初の配属部門で・・・などは、そのころの名残といえます。
　今では、昔のような処理速度や蓄積可能容量を気にする必要はほとんどなくなっています。そのため、設計も簡単になり、利用する人が使いやすいことを第一のポイントとして設計されるようになってきています。
　また、コード自体に意味を持たせず、単なる連番にするのも最近の流れです。意味を付加情報としてマスターの中に持たせることで、後で意味が変わったときの対応が容易になります。

４．進捗遅れは取り戻せる？

　プロジェクトの進捗が遅れてくると、多くのリーダーは「頑張って遅れを取り戻します」と意思表明します。しかし、現実には一度遅れてしまうと取り戻すことは至難の技です。なぜなら、たとえ遅れの原因が明確になって適切な対策を打ったとしても、効果が出るのは対策後作業だけです。既に済んでしまった作業には、何の効果もありません。
　例えば１０の負荷がかかる仕事を１０日で成し遂げる計画で、計画５日目で２日遅れが判明し、６日めから対策をとったとすると

計画の作業効率：１０÷１０日＝１．０
前半の作業効率：３÷５日＝０．６
計画の作業効率に戻った場合必要日数：７÷１＝７日（合計１２日）
計画どおりに終わらせるための作業効率：７÷５日＝１．４

　上記のように、計画値の作業効率に戻しても２日遅れは取り戻せません。取り戻すには、計画値の１．４倍、前半の作業効率の２倍以上で作業を行う必要があります。すなわち、遅れの原因を解消するだけではなく、計画以上の新たな作業効率ＵＰの手段をとらないと遅れは取り戻せません。この例からみても「遅れを取り戻す」難しさが理解していただけると思います。

５．良いＳＥの見分け方

　システム開発業者として担当ＳＥに課せられる責任は、(1)システム開発プロジェクトを目的どおりの効果を上げる成功に導くこと、(2)受託した業務（システム開発）でシステム開発業者として適正な利益をあげること、です。ところが、ＳＥによっては、(2)の受託した業務の利益確保を優先し、作業工数が削減できる安易な方法を提案してくるケースもあります。現実ではそのような極端なケースは多くはありませんが、ＳＥからの提案が、安易な内容になっていないか十分説明を聞いてチェックしていくことが必要です
　ＳＥの能力には、1)コミュニケーションをとる能力、2)開発プロジェクトをマネジメントする能力、3)対象となる業務の理解力、4)ＩＴに関する広範囲な知識、などがあります。しかし、本当に大切なのはパートナーとして信頼関係の構築能力といえます。

６．バグ？

　システム開発業者のＳＥと話をしていると、よく「バグ」という言葉が出てきます。元はプログラムを食い荒らす「虫」という意味で使われていました。バグ（障害）は、プログラムの作成ミスによって起こるのですが、作った人たちにとっては作成者のミスではなく「虫」がいて悪さをした、と思いたい気持ちが入っていたようです。
　システム開発業者は、バグが発生すると「障害の原因はバグでしたので修正します」の一言で片付けてしまうことが多いようです。プログラム作成知識のない人が、細かい説明を聞いてもチンプンカンプンで無駄とも思えますが、できる限りバグの発生した原因・背景の説明を受けましょう。優秀なＳＥは、素人でもわかるようにうまく説明してくれますので、担当ＳＥの能力を測ることもできますし、バグの原因によってはある程度品質レベルを類推することができます。
　バグには色々種類があります。<1>販売管理や在庫管理などの業務知識の欠如による要件定義の理解不足や間違った理解によるバグ、<2>通常運用レベルのテストが不完全で発生したバグ、<3>数字しか入力されないと思っていたところへ文字データを入力されたケースなど、運用イメージ想定が不完全で想定しきれていなかったために発生したバグ、<4>同時入力処理やＯＳ（オペレーションシステム）の不具合など特殊なシステム状況によるバグなどです。<1>の発生が多いようでは基本設計が不完全であったと思わざるを得ずかなり深刻です。<2>が多発する場合は、システム開発業者によるテスト不足と思われるので、全プログラムの再テストを指示して品質を上げてから再度納入させるべきです。<3>や<4>は、ある程度発生することを覚悟して対処するバグといえます。


※コラムは執筆者の個人的見解であり、日本総研の公式見解を示すものではありません。

-------------------------------------------------------------------------
黒田　賢三
(株)日本総合研究所
主任研究員　情報戦略クラスター
専門分野：情報化戦略、業務改革、ＢＰＲ
-------------------------------------------------------------------------