アイロベックスメールマガジン　携帯版

今回は、NHK出版　畑村洋太郎著『だから失敗は起こる』の紹介です。

久しぶりに物凄く面白い（興味深い）と思った本でもありました。

ちょうど「リスク管理」のことを考えていた、というタイミングもあったかもしれませんね。

しかもNHKで放映された8回の番組のDVD付きなので、2,800円という値段も高くないと思える内容です。

人間はいつの時代も失敗を繰り返してきた。

なぜ同じような失敗が繰り返されるのであろうか？

これは、社会共通の問題でもあり、プロジェクト管理の問題でもあるわけです。

第一章では、六本木ヒルズの回転ドアで起こった、痛ましい死亡事故について例示されています。

もともと、ヨーロッパから回転ドアが取り入れられたとき、ヨーロッパでは、「ドアは軽くてゆっくり動かなければ危ない」という暗黙知があったそうです。

それを日本に取り入れたときに、「風圧が強くても耐えられるものにしたい」「見栄えよくしたい」といった要求があり、骨材がアルミから鉄に変更され、ステンレス板で飾られ、その重みに耐えるためにドアの外周にモーターやブレーキを取り付けた結果、当初の3倍近い2.7トンもの重量になってしまったということなのです。

そして事故の防止策としてセンサを取り付け、何かが挟まったときに、ストップするようにしたということなのです。

つまり、要求に応えることで、つぎつぎと設計を付け足す「付加設計」を行ってしまったのです。

安全性を実現しながら機械やシステムをつくるためには、「本質安全」と「制御安全」があるそうです。

一つ目は、事故が起きたとき、たとえ安全を守るためのシステムがうまく作動しなかったとしても、大きな危険を及ぼさないようにする考え方、これを「本質安全」といいます。

二つ目は、安全を守るためのシステムを取り入れて、危険を防ごうという考え方です。これが「制御安全」です。

まさに、六本木ヒルズの回転ドアは、暗黙知であった「ドアは軽くてゆっくり動かなければ危ない」という「本質安全」をないがしろにして、「制御安全」だけを考えて設計されてしまったというわけです。

しかし、このメーカーでは、この失敗をもとに、「本質安全」の立場に立ち返り、ドアに触れれば、ドアが折れ曲がるといった形に変えているそうです。

そしてその上に、緩衝ゴムや透過式センサをつけて、「制御安全」を補助として追加したそうです。

私たちのシステム開発においても、同じことが考えられます。

つまり、どんなに単体テストを繰り返そうとも、他人テストを行おうとも、100%のバグは取れない、ということを心に焼き付けてシステム設計する必要があるのです。

これは、「テストは、いい加減でよい」ということとは全く違います。

しかし、「本質設計」として最低限、安全な設計をする。

つまり、バグが出ても、最悪のことが起こらないような設計をする。

ということが求められているのだと思うのです。

その上で、バグが出た場合に、どのようにエラーメッセージを表示させるか、どうやって処理を止めるか、といった「制御安全」が付加されるべきだと思うのです。

単に「制御安全」だけのシステムは、本末転倒なのです。

起こってしまった失敗を、社会全体の共通の財産だと考えてこそ、失敗が初めて生かされる。

徹底的に失敗の原因を究明する。

失敗を活かし、失敗に学ぶ。

失敗が起きると「誰が悪い」「何がおかしい」といった責任の追及に走りがちな私たちですが、まず原因の究明をしてから、責任の追及というように、価値を変えていくことも必要なのだと語っています。

年末が近づいてまいりました。

忘年会も頻繁に行われるし、年明けの納品を睨んでいる人たちにとっては、厳しいスケジュールが続いていることでしょう。

今年の年末から来年のお正月にかけてのお休みは、9日間という企業が多いようです。（当社も、珍しく9連休とさせていただきます）

この休みを嬉しいと思っていたSEも、いざ休みを目の前にすると、スケジュール通りに仕事が進んでいない現実を目の当たりにして、どうしようと悩んでいる場合が多いのではないでしょうか。

休みになると、好きなときに、好きな時刻に会社にやってきて、ちょっと仕事をして、すぐ帰ってしまうという技術者を見かけます。
（こういう人達が出社するのは、午前中ということは、決してありません）

彼らが単に「前倒し作業」を心掛けて、部下が少しでも仕事をしやすいように準備しているのだとすれば、それはとても良い心掛けです。

しかし、そういう人ばかりではありません。

遅れてしまっている作業を行うためであったり、タスク一覧には載っていなかった作業で、人には言えない作業を行うために、会社に来る人もいます。

また、納期を守るためという御旗のもとに、納期前日になって徹夜をする技術者がいます。
私には、納期前日の徹夜作業という事態が、疑問に思えるのです。

例えば、その作業が工数24時間以内程度の小さな仕事であったならば、多少の見積もりミスが生じて、徹夜作業になってしまったということはあるでしょう。

しかし、数人の作業者が何週間もかかる作業が、最後の1日に徹夜して、ぎりぎりで間に合うということがあるものでしょうか？

要するに、何を言いたいかというと、納期の前日になって徹夜しなければならなかったという仕事は、完全に作業を終えていないのではないか、ということなのです。

納期直前になって、到底終わらないことに気づき、徹夜作業になったが、結局、時間切れになってしまったのではないか、ということなのです。

あとどの位で作業が終わるかを、勘に頼ってスケジューリングしていると、こういう事態になります。

もちろん、システム開発の仕事というのは、スケジュール通りに進むことが難しい仕事です。

たからといって、それまで徹夜していなかった作業者が、最後に、つまり納期の前日に徹夜して、ちょうどぎりぎりで間に合った、などという偶然を信じることはできません。

納期の前日の昼間にきっちり終了していない仕事については、どう考えても、徹夜をするのではなく、1日、2日伸ばしてもらうべきなのではないか。
徹夜をすれば、ぎりぎり間に合いそうだと思ったとしても・・・。

いやいや、その何日か前に交渉すべきだとか、もっと生産性をあげるとか、仕事を調整して減らすとか、他にできることは1週間前ならもっとあったはずです。

SEは、プログラマを抱え、部下の管理だけでなく、お客さまとのやりとりをしなければならない、日々、常に多くの仕事があります。

その日常の中で、雑用に追われ、仕事で「やっていないこと」が見えてないことがあるのです。
だから、こういう長い休みのときに、1日、会社に出て、客観的に全体を見直すこと、役割、分担、売上、原価、手法などあらゆる面から見直すのは、良いことだと思うのです。

そこで提案です。

「休みの日に、プログラムを作る、直す、チェックするなどの現場作業をしない。」と、一度、宣言するのはどうでしょうか。

その上で、自分がしなければいけないタスクを再度洗い出して、チーム全員で残作業を常に共有していく。

本来のPMの仕事は、潔く、真実を見つめることから始まるのです。

新しいプロジェクトが始まるとき、顧客は、素晴らしい成果を思い描き、その成功を期待します。

そのプロジェクトを請け負うシステムエンジニアも同様に、顧客の期待に応えるため、また、自分自身のためにも、最高の成果を挙げようと思うものです。

ところが、実際にプロジェクトが始まるや否や、その想いは、数々の困難に直面します。

納期までの残された時間、スタッフの能力や人数、顧客の社内の制約条件など、
どれをとっても理想通りにいくわけもなく、顧客もシステムエンジニアも、プロジェクトが始まったその瞬間から、何かを諦めていくことを求められるものです。

従って、当たり前のことですが、プロジェクトを成功に導く唯一の選択は、すべての仕事に優先順位をつけていくことなのです。

しかし、開発側にとっての優先順位と、顧客側にとっての優先順位が違うという、難解な問題も含んでいます。

今回は、顧客側との意識の摺り合わせは横において、開発側だけの問題について考えてみたいと思います。

開発側のシステムエンジニアにとって一番先に解決可能なことは、自分のこと、つまり、開発側の「コスト」であったり「時間」であったりするわけです。

ましてや、自分自身の時間の使い方については、
一番先に解決可能なことなのです。

ところが、システム開発において人を使って実行していく為に、「様々なことを決断していく」ということは、リーダー自身に精神的にも肉体的にも、かなりの重労働を課する仕事です。

ましてや自分が、「重要だけれども、どうして良いか分からない」問題にかまけている間に、チームスタッフたちの作業がどんどん遅れてしまうことが見えてきます。

そこで、若手SEにとっては、簡単なこと、出来ることから作業をしていくことが、目先の生産性をあげるために必要だと思えてきます。

確かに「できることからやる」というのは、スケジュールを遅らせないためには、唯一の方法であるかのように思われます。

しかし「できることからやる」ということにのみ集中してしまうことは、絶対に許されません。

中長期的に見れば、「重要なことを後から決断する」というやり方はリスクが大きく、
取り返しのつかないような工数で、後に修正を強いられる原因にもなるものです。

迷っている状態で走り始めるべきなのか、それとも無理やりに決めて走り始めるべきなのか。

どちらかが正しいというわけではありません。

決めることは、怖く、つらい作業なのかもしれません。

時に、顧客が決めてくれることだけを待っているSEには、自分達の問題さえ、まるで誰かが決めてくれるのを待っているように見えるときさえ感じます。

直感で感じることもSEの大事な資質であると知ることです。

もちろん、その前には、考え、考え抜いて、人にも相談し、情報を集めるという作業が伴う必要があるのは当たり前です。

しかし、最終的には、捨てる物は捨て、決めなければいけないことはきっちりと決めることが「SEの仕事」なのです。

それが「仕事」ともいえます。

全てのシステムに同じ時間が流れているわけではありません。

しかし、プロジェクトに臨むリーダーの態度は、同じものが求められています。

余裕はない、だが実行すれば、終わる。

実行することは、決断することである。

決断して、実行する。

するべきことを正しく選択し、実行し続ける。

そして、しなくていいことを正しく選択し、顧客に理解を求め、部下に指導し続ける。

正しい方向に進んでいるかどうか、必ずレビューとスポットチェックで確認する。

「決断しなくて実行することほど、悪い手はない」ということを、SEは常に意識するのです。

来年、2009年の4月から、システム開発会社も「工事進行基準」会計を求められるようになりました。
日経BP社やマイクロソフトなどで、工事進行基準に関するセミナーが大流行です。
そこで、今回は「工事進行基準」について考えます。

これまでの会計処理は、「工事完成基準」会計でした。
つまり、システムが完成して、納品、お客様の検収により、売上計上してきたわけです。

もちろん、すべてのシステムやプロジェクトにおいて、作業開始から終了、売上日までが、1年間という会計期間の中に、きれいに収まってしまえば、特に問題になる処理はありません。

しかし、すべてのプロジェクトが、期末に終わっているということは、あり得ないわけです。

この場合、売上できないプロジェクトについて、つまり、当期中に売上しないプロジェクトに掛かった労務費（SEやプログラマの給料）は、仕掛品という、在庫と似た意味の、資産勘定科目を用いて計上し、売上原価とはできませんでした。

こういう会計処理を行うと、通常は、売上月（期）に多くの利益が出ることになります。

なぜなら、2年掛かりのシステム開発では、最初の期は、売上も売上原価も発生しません。
ひたすら労務費という費用がそのまま、仕掛品という資産に代わっているだけです。
それが、売上期には、売上金額が全額計上され、仕掛品が売上原価に振替えられるからなのです。

実際には、企業の経営といった側面から見れば、売上のタネは労務費だけではありません。
技術者の教育費、福利厚生費用、水道光熱費であったり、家賃であったり、営業費用なり、そのプロジェクトが、分担すべき販管費は、もっと多くあるのです。

売上を計上した期に、その売上を生んだ元となる直接の費用と、間接の費用すべてが計上されてこそ、正しい会計となるわけなのですが、そうなっていないわけです。

そこで、大規模なシステム開発があった場合には、特に利益が正しく計算されない、ということになってしまうのです。

単純に考えれば、最初の期は、利益が少なく評価され、次の期の、売上があった期に利益が過剰に評価されるということです。

しかし、システム開発では、プロジェクトによっては、納品後（検収後）に多くの問題が出ることもあるわけです。

この場合、例えば、3期に渡るプロジェクトについて、考えてみましょう。
1期目は、仕掛品計上のみなので、利益が少ない状態、2期目は、期末月に売上があったとすると、利益が大きく出る状態となります。

そして、翌月から、納品後のトラブルに追われてしまったとなると、3期目は、売上のない、原価の垂れ流しということになります。

これだけが原因というわけではないのですが、こういった会計では、外側から見た場合に、この企業が優良なのかどうかが、わかりにくくなるわけです。

また、この売上や利益の構造が良くわからないことを逆手にとり、「売上や利益をごまかす」といったことが、上場企業でも行われていることが何件か発覚しています。

・ニイウスコー
http://www.tokyo-np.co.jp/article/national/news/CK2008050102007972.html

・アスキーソリューションズ
http://www.nikkei.co.jp/news/main/20080428AT1G2700P27042008.html

・アクセス
http://www.yomiuri.co.jp/national/news/20080428-OYT1T00347.htm

一方、システム開発の仕事と、非常に似ていると言われる建設業界では、「工事進行基準」の会計が、ずっと行われてきているのです。

そこでIT企業が、投資家から、「正しい企業の業績」を判断されるためにも、グローバルスタンダードである「工事進行基準」での売上処理が求められているというわけなのでしょう。

下請だから関係ないとか、小さな案件の仕事しか行っていないから関係ないというわけではなく、わたしたちの業界の仕事が、どのように会計処理されるべきなのか、その為には、どのようなプロセスを経て、作業をしていかなければならないかを知り、実行していくことは、緊急に求められていることなのです。

前回は、工事進行基準会計が求められるようになった背景について、述べました。

長期請負工事に関する収益の計上については、これまでは「工事進行基準」または「工事完成基準」のいずれかを、選択適用することが認められてきたので、ほとんどの会社が「工事完成基準」を選択してきたわけです。

「どんぶり勘定」と呼ばれるようなシステム開発の請け方には、工事完成基準が一番合っていたというわけです。
ところが平成20年4月からは、工事進行基準に会計基準が統一されることが決定しました。

では、工事進行基準会計をどういう方法で行えばよいのでしょうか？

工事進行基準会計の先駆者である「建設業界」のシステムを得意とする、当社取締役の小幡に聞いてみました。
（以下、聞いた話です）

「建設業界では、工事進行基準における進捗度は、出来高という考え方が一般的です。
工事を請け負ったときには、工程別の実行計画と連動した、”実行予算計画の入力”を行います。
そして毎月、工事現場監督が完成度合いを、出来高（金額またはパーセンテージ）として査定し実績とするのです」

そして、こうも語ってくれました。

「しかし、工事の進捗で形あるものが出来上がっていく、ビルやプラントならともかく、
形が見えず完成できなければ意味をなさないソフトウエア開発において、出来高を明確にして、どこまで完成しているかを管理することは、非常に困難です」

「同じようにITの場合においても、各工程での成果物をあらかじめ数値で明確にしておき、設計工程であれば、ドキュメントが何ページ完成したのか、製造工程であれば、プログラムが何機能を完成したのかを
完成度合いを査定できる能力のある人間が査定することになるのだろうと思います」

なるほど、確かに成果物が何ページ、プログラムが何ステップと、予測できるのであれば、その数値を入れておいて、何パーセント出来上がったのかを測ることは出来そうです。

しかし、建設業界と違って、要件定義、基本設計、どの部分においても何ページ作ったら終わり、
何ステップ作ったから何パーセントということは予測はできません。

プログラムを大きく機能単位に数えることはできても、何ステップまでなどという予測はできそうにありません。

しかもプログラムの場合は、最後の機能が完成してみたら、「基本部分に仕様漏れがあったので、大きく改修しなければならない」ということさえあるわけです。

せいぜい、基本設計書の成果物を細かく分類して、「画面設計書」「帳票設計書」「ビジネスルール定義書」などと、分けて作業成果単位とするのでしょうか。

ところが、企業会計基準委員会（ASBJ）では、進捗を計るのに、建築業界と同様に「原価比例法」を挙げて、推薦しているのです。

----ちなみに、原価比例法とは----------------------------------------
決算日における工事進捗度を見積る方法のうち、決算日までに実施した工事に関して発生した工事原価が工事原価総額に占める割合をもって決算日における工事進捗度とする方法をいう。
（企業会計基準公開草案第20号「工事契約に関する会計基準（案）」より抜粋）
--------------------------------------------------------------------

もうおわかりでしょうが、実際の発生原価をもって進捗を知るためには、契約からして実質的な正しい見積りに沿ったものである必要があります。
契約範囲や作業分担を明確にすることが確実に必要になります。

「なんでもやります」といった営業は、あり得ないというわけです。
また、成果物も細かく精査される必要があるでしょう。

そして当然のことながら、実際の原価がそのまま進捗度になるのは危険すぎます。
原価の累計が必ずしも出来高（完成の度合い）となるわけではないからです。

そこで出来高（進捗度）の実績値を登録し、計画値と常に比較することになります。

値はパーセントでも、工数（時間）でも、金額でも良いでしょう。
つまり、信頼性をもって工事原価総額を見積ることが重要となり、そのためには、工事原価の実行予算計画が実際に発生した、出来高と比較できる形のシステムまたはツールが、
必ず必要になるわけです。

また、実行予算計画も随時、見直しが行われることが、必要になるわけです。

だからといって、予算超過してしまった増額分を、お客様に転嫁できるわけではありません。
あくまでも、システム開発の損益を、会計基準にのっとってスタンダードで処理するということが、
求められているのです。

これからは、完成基準の適用も全く無いわけではありませんが、契約書において「なぜ完成基準なのか？」の正しい記述が、必要とされるようです。

ちなみに、「日経ソリューションビジネス5月15日号」によると、元請け企業が下請けから集めるデータは2つだと言っています。

・開発のコスト
・開発作業の進捗率

これは、ほとんど元請けが必要なものと同じではありませんか？

結局、「自社と同レベルのプロジェクトマネジメント体制を求め、進捗の実態を把握するのが基本である」とも書かれています。

要するに、すべからく、システム開発会社は、この考え方に慣れ、ノウハウを身につける必要があるというわけです。

「ユーザー企業がシステム開発を考えた場合、最も安く上げる方法は、開発しないことである」
これは、もはや常識とされています。

出来ているものの中から、自社に最適なものを選ぶ。
つまり、パッケージを購入して、一切、カスタマイズしないで使う、これに限るわけです。
住宅でいうなら、建売住宅を購入するといったイメージです。

それでも、選択のミス、安物買いの銭失い、思っていた成果が出ない、といったリスクは伴います。

しかし、パッケージを購入し、カスタマイズせずに使用している企業はどのくらいあるのでしょうか。

これは、システムの種類によりけりでしょう。

たとえば、会計システムや、勤怠システム、給与システムは、パッケージを、そのまま使用することが多いシステムです。

また、たとえカスタマイズしたとしても、企業にあわせてプログラムを作る部分は、そう多くないと思われます。

特に、会計システムは、中小企業においては、どちらかというと、税務署へ提出する決算書等作成のためのシステム、といった度合いが大きく、ルールは簡単で一律なので、パッケージそのままで、使用することができるのです。

これまで、大企業（特に歴史のある会社）は、基幹系システム化の歴史において、過去に手作業で行っていた業務を、テーラーメイドのシステムで、システム化してきました。

しかし、ダウンサイジング（懐かしい響きです）が言い出された頃から、なるべく、共通で使える機能はパッケージを採用し、且つ、カスタマイズで独自の業務を作り出そうとしてきたのです。

パッケージありきの商談でも、カスタマイズの重さによって、金額や納期が決まります。
本体価格の、10倍以上になることさえあるのです。

それでも、パッケージはテーラーメイドよりも安いのでしょうか？

実は、そうとは言えません。
パッケージのカスタマイズであれ、何であれ、システム開発は、30機能を超えた辺りから、大プロジェクトになってきます。

人間のコミュニケーションを考えてみてください。
2人の人間が、コミュニケーションをとるのに比べて、5人の人間が、コミュニケーションをとるのには、10倍の力が必要です。

それは、プログラムも同じです。
10機能くらいであれば、少人数のプログラマだけで、短期間で、設計も開発もできるのですが、50機能、100機能となれば、何十人月といった工数が必要になってくるのです。

これは、プログラム間のコミュニケーションの整合性をとるために、大きな力が必要となるからなのです。
加えて、開発以外のマネジメント、人と人のコミュニケーションのための時間も、大幅に増えます。

正直、システム開発に慣れていなかったり、専任の情報システム担当者がいらっしゃらないお客様に、最初から、大きなテーラーメイドのシステム開発をするのはお勧めしません。

同様に、パッケージのカスタマイズも、30以上の機能を変更・追加するということであれば、やはり、お勧めしません。

むしろ、同じ見積金額であれば、パッケージのカスタマイズの方が、テーラーメイドよりもリスクが高くなります。

自宅を作る場合も、何度も作ると、作るコツがわかって、良いものができるというではありませんか。
システム開発も同じです。

小さなものを作ってみて、経験して、初めてわかることがあるのです。

お客様が思うことに、「システム開発会社はプロだから、注文しなくても、かゆい所に手が届くように、教えてくれるはず」というものがあります

確かに、プロフェッショナルとしては理想です。（わたしもそういう理想のプロのSEになりたいと常々思っています）

しかし、口に出して言わなくても100％理解される、本心を酌んでシステムを作ってくれる、そのような、システム会社を求めるのは、ギャンブルに近いと思います。


《システム開発を成功させる方法》

鉄則 その1．
システム開発は小さく始める。機能は30以下。

「SEには、どんな情報も開示する。システムに関わる基本データは、なるべく早く渡す。ゴミをとって整理してからという考えは良くない」

例えば、パッケージをそのまま導入するとしても、ユーザー側の作業というのは、簡単ではありません。

通常は、システムで使う各種マスタを登録する作業が、一番先に課せられます。

マスタ登録を画面から行う、もしくは、記入用紙に手書きする、はたまたExcelシートで作成する、他のシステムからデータを抜いてきてCSVを作成する。

マスタ登録作業には、こういった作業が考えられます。

データ加工だけであれば、開発会社に請負ってもらうことも十分に考えられます。

しかし、過去のシステム資産にどんなデータが入っているのか、また、それは正しいのか、使っていいのか、といったことを判断できるのは、ユーザー側のシステム管理者、もしくは現場でそのシステムをお使いの人であるはずです。

マスタ登録作業というのは、雑用でもありませんし、誰がやっても良い作業ではありません。

非常に重要な作業であると認識して下さい。

これを、新人など、業務が分かっていない人に任せたり、全営業マンに全部の得意先リストを紙やExcelに書かせて分担したものを自動で入れてしまったりとすることは、あまり良い方法とはいえません。

（もちろん、誰か業務が分かる人が責任をもって行う分には良いのですが）

たとえ移行作業は自社でやるという決まりになっていたとしても、開発会社側を引きずり込んで、「本当に、集めたデータで動くのか」「お互いにシステムについて思い違いはないのか」といったことを検証することが大事なのです。

また、そういったデータの収集は、本番の直前や、尻に火がついてからではなくて、システムのスケジュールが決まった直後に、設計書が出来るかどうかの段階で、なるべく早く行うべきなのです。

（システム設計書ができあがった場合に印を押しますが、この直前直後です）

というのは、ユーザー側から見て、「別に重要でないから」と思って言わなかったことが、システムとしては「超・重要事項」であり、それを聞いているのと聞いていないのとでは、大違いという場合があるのです。

システムの基本情報の真実を知らずして、満足のいく設計はできないのです。

以下、非常に私的、個人的意見だと思って聞いてください。

政府系の仕事に関与したときに「おかしい」と思ったことがあります。

それは、「彼らはマスタ登録を請負い業者に任せて、自分達では登録しない」ということでした。

確かに、優良企業で大会社の場合はアウトソーシングで、そういった場合もあります。

しかし、ほとんどの会社が少しでも経費節約のため、そして、システム構築にも自分たちで参加するために、マスタ登録は自分達で行っているのです。

他の仕事がどんなに大事であろうとも、国民のために仕事をしている人達が、自分たちの使うシステムを、金を使って第三者にお任せして良いのかと思ったのでした。

「厚生年金のシステムが雑であった」といったニュースを聞いて、本当にその思いが強くなりました。

感情的になってしまいました。

では、思い直して。

「ユーザーはマスタやデータの中身をなるべく早く、紙でもいいし、元のデータでもよいので、明確にSEに示すべし」

恥ずかしいから見せたくない、後からでいいや、は厳禁なのです。

そして、システムを成功させるために、基本情報は自分で整備し、チェックしましょう。

もちろん開発側も、アドバイスや、ツール作成など、できることは協力いたします。

システム開発の見積金額ですが、最初のお打合せから最後の納品立会い運用支援までを考えた場合、一番お金がかかるところはどこかご存じでしょうか。

「何のシステムを作るか」がわかっている場合にはなんと、プログラミングの金額が一番高くなるのです。

だからこそ、プログラマの人件費が安いオフショアが話題になるし日本国内の開発においても、外国人を使ってOKなのかNGなのかといったことが言われてしまうのです。

オフショアのお話については別の機会に譲って、今回はプログラミングを考えた場合に「何が高いか？」を説明します。

内容によっては設計とも関わってくる部分もありますがまずはプログラミングの視点、つまり、自分がプログラマだったら高く見積るというところ、そして、市場的に高いと思われているところをご紹介します。

▼こうするとプログラム費用は高くなる。

（1）OSやツール、DB（俗にいう開発環境）が「ニッチ」な場合は高くなる。

これは、開発環境、テスト環境を指します。
安く抑えるためには、OSであれば、Winows, Linux, Unix のいずれかそして、最新のバージョンから2、3バージョン前までのものとします。

Windowsでいえば、Vista, WindowsXP, Windows2000です。
(実際には、まだまだVistaは制限付きとなっているようですが・・・）

言語でいうと、Java, .NET（ドットネット）, PHPくらいがセーフです。
これ以外は、開発者も経験者も限られてしまうため金額が高くなってしまいます。
需要と供給の関係から、開発者を探すのが難しい場合は高くなるのです。

ニッチな場合には、金額だけでなく「何かあった場合」の問い合わせ先が限られているので、リスクが伴います。

これに関連して、新システムを組む場合は、「JavaとOracleで作ってほしい」という要望よりは、「ツールは何でもいいから」の方が安くなりますね。

（2）納期が短期の場合は高くなる。

開発者がたまたま空いていて、短期でも、通常のシフトで間に合う場合は例外です。

今月末までに絶対納品というようなタイトなスケジュールを提示され「社長命令だ」、「これが条件です」など、「絶対」と言われてしまうと最終的には「金で人を探して」集めるしか方法がなくなってしまうので高くなるのです。

（3）帳票や画面照会系よりも画面入力系が多い場合は高くなる。

システムから出力するものと、入力するものとのリスクの違いという意味もあるのですが、一般的に「入力画面」は技術度が高く難しいことが普通です。

ただし、次の（4）とも関係してきますが、画面の動き、設計についてはシステム開発会社にお任せして、それで納得できる場合は別となります。

（4）画面の動きにこだわり過ぎると高くなる。

インターネットのGoogleや、ネットショッピングのサイトで見た使い方がよかったから同じ動きをしてほしい、今まで使っていたパッケージと同じ動きにしてほしい（今までのシステムはWEBでは無かったにも関わらず）といった場合には、プログラマの持っている技術資産がそれに対応していないことがあります。

プロが行う見積りは、すでに標準的に持っている技術資産で仕事をしていくらという見積りです。
例外的に、新しく技術を磨いて作成するという時間が含まれていません。

この場合はプロトタイプを作ってもらい、確認、承認して互いに納得してから着手することをお勧めします。

この確認を曖昧にすると、互いに幸せにはなれません。
開発側も1本目は慎重にゆっくりと作るのが通常ですから、データ更新（画面で入力したデータを呼び出せるところ）を含めないで画面の動きだけであれば、プロトタイプを作ることをいとわないはずです。

（5）個々の画面プログラムの繋がりを複数持とうとすると高くなる。

システムにもプログラムにも、セオリというものがあります。
メニューから機能を選んで起動する、機能が終了したらメニューに戻るといった動きを、通常はセオリ通りの動きとします。

しかし、売上伝票を入力しながら得意先マスタを登録したい、という複数のプログラムから互いに自由に呼び出せるような仕組みを作ると設計、そして確認作業、テストも複雑になります。

（6）後から設定を自由に変更できるようにすると高くなる。

例えば、商品マスタを区分けする商品分類を自由に追加、修正するこれは通常の要求です。

しかし、どんなものでも同様にということは、プログラマに負担をかけることになります。

例えば、画面に初期表示する対象期間範囲を「1週間前～当日」で表示するという仕様があったとします。

この仕様を、将来的に変更する可能性がある場合（実際にはあるかもしれない程度です）、このときに後からのプログラム修正料金を恐れて管理者がいつでも自由にこの期間設定を変更できるようにすると後からのプログラム修正の方が、よっぽど安かったということもあります。

（7）仕様が不明確で、いつまでも決まらないと高くなる。

例えばの話ですが、誰が運用しているのかわからないような機能があったとします。

以前のシステムには、その処理が入っていたので入れておきたい。
しかし、プログラミング設計をする前に、お客様の運用仕様が明確でない。

「後からこの仕様のこの部分については引き継ぎますから残りの部分だけで動くようにしておいてください」とお客様が営業に頼みSEも承諾したとします。

プログラマは、実はこういった仕事が一番嫌いなのです。
彼らのモチベーションを高めるためにも、曖昧な部分になるべく早く決着をつけるようにしてください。

プログラマは、「わからないものがある」ということに大きな不安を抱くのです。

以上、7つの金額が高くなる条件を書いてみました。

結局は技術者一人一人の意識や技術、そしてチームワークが大事な仕事です。

彼らがやる気になって、全力を尽くせるような発注の仕方がよいシステム発注のコツともなるわけです。

プログラマも技術者ですから、「難易度が高い仕事がしたい」という気持ちがあるのが普通です。

しかし、本当にその意味があるのか難易度を高くしてまでプログラミングする意味があるのかということも彼らは非常に気にしています。

コストパフォーマンスを気にしているのは、実はお客様だけではないのです。

餅は餅屋に任せる。

しかし、餅屋を選ぶ責任はユーザーにあるのである。

「何を言っているんだ」とお思いでしょうか。

このメルマガでは、かなり突っ込んだこともお話していこうと思っているので、あまり触れたくないところでも入っていかざるをえません。

システム開発をどこかの会社に頼むといったときに、一番良いことは、その会社のSEを信じて、短期的、長期的な視点からのアドバイスを受けるということでしょう。

ところが、相手がアドバイスしてくれないとか、どうもそんなに経験がなさそうだといった場合には、その親方なり上司に相談できるようなところが望ましいでしょう。

システム開発でも何でもそうだと思いますが、お客様とSEの間に信頼関係が無いということが、徹底的に大きな溝を作ってしまうように思います。

初めてのシステム開発でSEへの信頼を持て、と言っても、おそらく無理でしょう。

だからこそ、2週間前の記事で、初めての場合は小さく始めるということをお勧めしたのです。

（参照：2008/06/17-Vol.00148「～ユーザー編　その2～」）
http://www.ilovex.co.jp/mobile_mailmagazine/2008/06/2.html

そこで、大事なことなのですが、「信頼を持てそうもない」ということであれば、素直に申し出て、早めに担当者を変えてもらったほうが良いでしょう。

とにかく、医者でも、建築家でも、SEでも、お客様と担当の間の相性が一番大切なんだと思うのです。

どんなに頑張って考えても出来上がらなければ分からないことはあります。

何度、何時間、ユーザ－と開発側が会議を繰り返し真剣に討議したとしても
そして、どんなに優秀なSEが設計したとしても納品されてから気づくこと、納品されなければ分からないことが双方に必ず残るものです。

それを修正したり追加したりするのに総機能工数の半分もかかるというのでは明らかにおかしい。

しかし、それが10％の工数で追加できるということであればむしろ、これは当たり前のこととして準備しておく方がお互いの為なのです。

当然、経験のあるシステム開発会社であればこのくらいの工数がかかるといったリスクを想定して見積りをします。

ところが最近では、どんな仕事も合見積りなど競合相手がいる場合が多いため、あらかじめその工数を上乗せした見積りが「高く」なってしまって仕事が取れないということにもなってしまうのです。

もちろん、ユーザーとしてシステム会社から後に追加工数を請求されて納得がいかないという話がよくありますが、それは、原価ぎりぎりの見積りであったかあるいは、どう考えても全くの追加機能であったかのどちらかなのです。

いったん、システム発注をしてしまえば後からの追加修正を全くしないで使いこなすということは、むしろ「テーラーメイド」のシステム開発の良さを享受しないことにも繋がるのです。

「一括納品でいくら」という見積りが出てきた場合ユーザー側には是非、最低でも総額の10％は予備費として追加機能予算をとっておくことを勧めます。

もしくは、そういったことまで「あ・うんの呼吸」でやってくれるシステム開発会社と長く付き合うこともひとつの手なのです。

「月末締め」「請求締め」「期末締め」といったように、企業の基幹システムには「締め」という観念や仕組みが、必ずともなうものとなっています。

また、締めを一つのタイミングとして、各種の他システムとの連携が図られています。

例えば、販売管理システムから会計システムに連携データを渡す場合、月末締めをタイミングとして渡すことが多いのではないでしょうか。

また、連携してしまった伝票は、元のシステムでは修正できないというのが通常のルールとなっています。

販売管理システムにおいて、「借方：売掛金 4,200,000円／貸方：売上 4,000,000円、借受消費税 200,000円」という情報を引き渡してしまってから、返品伝票が抜けていることが分かった場合、この情報を取り消すことはできません。

一番良いのは、抜けていた伝票だけ追加で引き渡すことです。

しかし、間違っていた（抜けていた）と分かったときに追加伝票が入力できないシステムも、世の中には多く見受けられます。

要するに、操作で間違えることを前提としていないのです。

人間は、間違えミスをする生き物なのに・・・です。

「良く考えられたシステム」というのは、正しい値を算出するだけではなく、こういった人間のミスに対処するようにできたものを言うのです。

間違えてしまった伝票を直したり、追加修正したりすることが可能なシステムが、その「良く考えられたシステム」であると言えます。

しかし、もっと便利なシステムがあります。

それは、ミスを予知し知らせる、「見える化システム」です。

人はミスをするものだという前提に立って、ミスしないように、一目で分かりやすいように現状を開示するシステムです。

例えば、締日が20日、25日、月末と3つあって、それぞれの締更新、請求書印刷、締め繰越が別々に機能として動くシステムがあるとします。

締日を入力して請求日付を指定して実行ボタンを押すといった処理を3パターンきちんとやったかどうかは、運用者が記録帳をとって管理する方法だとします。

これが一目でわかるように画面に表示されていたらどうでしょうか。

全締日と取引先件数、請求書枚数、金額、その処理を行った日付・時刻が一目で確認できるのです。

締め繰越をおこなっていない締日は強調して表示されています。

こういった画面で締処理を指示するのであれば、ミスをすることが非常に少なくなりますし、何よりも、安心してシステムの運用を行うことができるのです。

ブラックボックス化したシステムではなく、運用情報を常に開示して、「何をいつ行って、何をしていないのか」が、一目でわかるシステムを構築したいものです。

システム開発においてプログラミング作業は、いかに細かなことに気づいて漏れがないように論理的に表現するかといったことが求められます。

それは、本当に細かな緻密な作業でもあります。

そこでSEとしてプログラムに詳しくないと思い込んでいる人や、SEとしての仕事はプログラムとは関係ないと思いこんでいる人が陥る罠があるのです。

それはプログラミングの詳細な部分については、プログラマに「お任せ」するべきであり、自分がいちいち口を挟んではいけないと思っていることです。

いけないとは思っていなくても、自らのの多忙にかまけてお任せになってしまうのであれば、結果は同じです。

しかし、こういった仕事のやり方には、プロジェクトチームに新参者やキャリアが豊富でない技術者が参加しているときには、大きな問題がはらんでいます。

そうは言っても、「ドキュメントは詳細に作られるはずだ」「ドキュメントさえ正確に細かく記述されていれば問題ないはずだ」という意見があるかもしれません。

ところがプログラムの詳細設計、特に画面周りの詳細設計については、ドキュメントに書いて表そうとすると、ボリュームがどんどん増えるのに従って、読みこなせない代物に成長していくことが
分かるはずです。

そこでSEは、ありとあらゆる知恵を絞り、定型のドキュメントだけでなく、どうしたらプログラマ同士やSE、テスターを含めてチーム全員の意識を統一させるかを考えることに専念することになります。

たとえ同じ内容を理解していても、人は、文章にすると全く違う表現でものを書くのです。

ここに、「ドキュメントに”愛”があるかどうか」が実は重要だと私は思っているのです。

「愛があるか」それは見ればすぐ分かります。

例えば、「リストボックスの一覧からグループもしくは1行をクリック指定して選択した行を、別のリストボックスに移す処理」があるとします。

左のボックスには、対象となる全ての一覧が表示されています。

ここからグループもしくは1行指定すると、その指定された箇所だけが右のリストボックスに移ります。

仕様書には、「”→”のボタンを押した場合に右に表示される」と書いてあります。

さて、この仕様から質問が生まれます。

(1)右に移した情報は、左のリストボックスから消すべきか

(2)右に移す場合に同じものがダブって右に表示されてよいのか

(3)画面の登録ボタンを押した場合に、どのようなチェックをするのか

こういったプログラミングにおける画面の詳細な動き、例えば、

・どんなイベントをどこで感知して、どんなチェックをどの場所にコーディングするのか

・どんなメッセージが表示されるのか

といったものは、実は仕様書では別々のページに書かれるものであり、また、SEによっては、くどくどと何か所にも同じことを書く人がいたり、必要最小限なことだけを書いて、「あとは想像しろ」とばかりに質問を待つ人がいたりするのです。

実は、どちらの場合も、プログラマはそのドキュメントを読みこなすのに余分な時間がかかり、悩むものなのです。

もちろん、プログラマが経験者であれば問題なく、「質問と確認」といった作業を行うことで、SEが考えていることを理解することが可能です。

ところが、先に述べたような、新参者やキャリアが豊富でない技術者は、こういった作業ができなかったり、気付かなかったりすることが多いのです。

そこで、SEは、ルールに従ったドキュメントを書くべきであり、ルールに従いながらも、もう一つ踏み込んで細かな意思の疎通をとことん行うべきなのです。

実は、プログラミングや単体テストの生産性というものは、SEの詳細設計とその引き継ぎ方法にもヒントがあるのだと考えているのです。

「100年に1度」、「世界恐慌」などという恐ろしい言葉が飛び交っています。
正直、マスコミの報道にはうんざりします。
一部の政治家の言葉に国民が嫌悪感を持ってしまうのも、彼等が所詮、お金に苦労しない人だということも大きいのかと思います。

最近聞いたIT業界絡みの話で、「無理して大規模システムを受注してしまったのが原因で企業が倒産してしまった」
というものがありました。

あまりにもありふれた話なので「またここに書かなければいけないようなことなのか」と思ってしまいます。
この話から理解出来るように、システム開発会社には得意とする規模があるのです。

例えば、ある会社がこれまで機能数20で500万円くらいのシステム開発を行ってきたとしましょう。
（あくまでも仮定なので、この金額から当社の見積もりを想定するのはやめてくださいね。）

この会社が機能数100のシステムを2000万円で請けるとします。

この値段を、お客様や開発会社の中で「2500万円のシステムの2割引き特価」だと考える人がいるかもしれません。

しかしこの開発はおそらく失敗します。
他でも書いてきましたが、20本のシステムの5倍が100本では無いのです。

そして、もっと大事なことがあります。

2000万円以上のシステムを納めた経験が、その会社に何回あるか？ということです。

最大1000万円で機能数40以下のシステムくらいしか経験が無いとすれば、100機能の仕事をまともに納品出来るかどうか疑わしいものです。

つまり、
(1) 工数は機能数に比例するよりも、ずっと増える
(2) 慣れていない規模の開発は難しい

という2つの高いリスクがあります。
どう考えても成功する確率は低くなってしまうのです。

一方、100の機能の仕事をやったことがあるシステム会社であれば、10機能の仕事は確実に出来ます。
ただし、一般的に少し高額な見積もりになってしまうのです。
それは、大規模システムで必要となる「万が一」のリスクへの対処がどうしても入ってしまうからなのです。

システム会社を探す場合は、そのシステム開発の規模に合った会社、経験あるプロジェクトマネージャーを選びましょう。
決して金額で選ばないように。

そしてシステム開発会社は、このような不景気な時代だからといって、背伸びをして大きな仕事を安く取ったりしないようにしたいものです。

自分の得意な規模の仕事であれば、特別値引きをしても大丈夫ですがね。

IT業界の常識をそのまま鵜呑みにして行動していると幸せになれない、そう気づいたのはいつのことだったでしょうか。

そのひとつが、外部からプロジェクトメンバーを募るときのやり方です。

自社で要員を確保できない場合、派遣会社や同業のシステム会社に人の手配をお願いすることがあります。

・仕事の概要（業務内容、OS、DB、言語）
・期間（○月○日から○ヶ月）
・応募人数（○名）

という内容でお願いすると、先方の営業が、自社や知り合いの会社のSEの職務経歴書を送ってきます。

そして、発注側が気に入れば「採用面接」になるという手順です。

この採用面接ですが、名の通り、面接だけのことが多いようです。

つまり、これまでの業務経験について質問し、その応対能力を見て判断するのです。

しかし、これが企業の入社試験であれば、どうでしょう？

筆記の能力診断テストが課されたりして、1対1の簡単な面接だけで、あっという間に採用したりはしないはずです。

たとえ、明日からプロジェクトが走り出そうとしていて、技術者が一人も決まっていないという状況だとしてもこういった安易な方法を採るべきではありません。

まず、プログラミング技術者を採用しようとしているのであればとにかく、簡単なコードを書かせることが先決でしょう。

簡単なアルゴリズムや、数十行のコーディングで実現できる（慣れたプログラマであれば5分くらいで書き終えてしまうような）問題を出すのが良いでしょう。

それは基本的なアルゴリズムの問題であり、たとえどんなに緊張して本領が発揮できなかったとしても、間違えたり、スペルミスをすることは問題外です。

テストをすることは、発注側にとって応募者がコーディングにどのくらいの時間をかけるかを確認することができるというメリットもあるのです。

「巧遅は拙速に如かず」

どんなに教科書通りの素晴らしいコードを書いたからといって、普通の人が5分で書き終えるものを、5分待ってから書き出し、書き終えるのに10分かかるようでは、採用してはいけないのです。

また、コードを書かせることで、会話だけでは気付かない面も見えてくるはずです。

採用面接で1時間、どんなに真剣に質問を考えたとしても技術者の能力を見抜くのは難しいものです。

確かに、一緒にいて楽しい人や、気の合う仲間を採用するという意識も多少は必要なのかもしれません。

しかし、技術者を助っ人として雇うのであれば、気のいい仲間ではなく、結果を時間内で出してくれる人を求めるべきではないでしょうか。

決して、コードを書かせるテストをはずしてはいけません。

ついに連休も終わりました。

新型インフルエンザ、高速道路渋滞などの影響で出掛けるのにも躊躇することが多く、今回の連休はおとなしく過ごしました。

遊びすぎなかった連休というのも、体調だけでなく精神的にもいいものだと実感しました。

さて、連休前に私が出した質問、覚えていらっしゃるでしょうか。

システム開発を行う場合の工程別のコストの割合についてです。

今の私自身の考えは

1）客先での打ち合わせと外部設計　20
2）内部設計　20
3）開発（プログラム作成とテスト）　50
4）納品　10

ということもお話しました。

本当に残念というか・・・仕方がないというか、開発の比重が大きくなることが気になります。

開発の比重を小さくするためには、今や開発部分を切り分けてオフショアして単価を下げることが当たり前なんですね。

しかし、オフショアもいつまでも単価が安いままが続くのでしょうか？

安いというのは、日本が他のアジア諸国に比べて先進諸国であるという理由だけで感じる相対的物差しのはずです。

システム会社としては、この内訳の比率の意味を理解し、常に見直すことが必要です。

私の経験からお話しましょう。

出来の悪い、もしくは進捗がうまくいっていないシステム開発があるとします。あくまでも仮定ですが。

こういったシステム開発の場合、目に見えてわかることがあります。

外部設計、内部設計、開発、納品が工期としてダブることが多いのです。

ひどい場合には、隣り合わせの工程がダブるだけでなく、仕様が戻ってしまい、「 1）客先での打ち合わせと外部設計」と「 3）開発」が同時に行われていたりするのです。

理想の開発では、1）→ 2）→ 3）→ 4）と順番に進むものが、「 3）開発」の段階で未だ 1）のヒアリングが終わっていなかったりするのです。

それは、開発途中で、ユーザー企業のおかれている状況が変わり、否応なしに仕様修正が入るということもあるかもしれません。

しかし、もともとの仕様を開発側とユーザー側でしっかり確認していなかったために「 4）納品」になってから発覚したという場合があります。

これが最悪のパターンです。

しかも、ウォーターフロー開発の場合開発途中で誰かが気づくということが非常に少ないのです。

また、開発途中で気がついたとすると、開発期間が延長になってしまいます。

開発期間は、その期間だけ人員増加することが常識ですので長期戦に持ち込むことが、そのままコスト高の理由になってしまうのです。

そこで、プロマネの重要性や上流工程の価値が再評価されるのですね。

やり直しが許されるのであれば、開発に入る前までをやり直したいとシステム会社が思うのは当然のことといえます。

ただ、私個人としては、もっともっと開発のコスト率を下げる方法が他にあるのではないかと思っているのです。

経営コンサルタントとしてあまりにも有名な神田昌典氏が新刊を出しました。

「全脳思考」ダイヤモンド社刊です。
http://www.amazon.co.jp/exec/obidos/ASIN/4478008361/ilovex-22/ref=nosim/

マーケティングを勉強したいと思っている技術者っていますでしょうか？

現在のこんな状況であれば、技術を高めるのも大事ですが、マーケティングを勉強することが、貴方の将来にもっと大きな力を与えてくれると思いますよ。

私が理想とするITコンサルタントに近いですね。

技術だけのITコンサルタントだと、売上管理、粗利管理といったマネジメントに関与できても、突出した新しい価値をもたらすような仕事に関与するのには運を天に任せないといけないでしょう。

でも、技術の上にマーケティングが加わったら、運ではなく自分自身で新しい価値を作りだすこともできるのです。

そんなわけで今週のお勧めは、この「全脳思考」。

450ページという厚さですが、軽々と読めるはずです。

この本を1冊読むことでマーケティングの重要なポイントがほとんど網羅されている。それも分かりやすく説明されているのでお勧めするわけです。

さて、本の宣伝はこのくらいにして、このメルマガはあくまでも「システム開発」についてのメルマガ。

片寄って一部分だけズームインしてみます。

では、本文63ページと64ページから

つまり、クオリティの高い思考には、論理の積み重ねだけでは
説明できない領域があることは、経験上わかっていたのであるが
どうすればその高みにいたれるのかを説明する明確な体系はこれまでなかった。

システム開発のプロジェクトで、詳細設計から全容を理解するのが無理な理由はこれだとわかりました。

で、その解決方法として、神田氏は、こう語っています。

ジグゾーパズルの完成後の全体像を見たあとは、どんな小さなピースにも全体が見いだせるようになる。
・・・・（略）
つまり、一度、全体像を理解してしまうと、部分には全体を完成させる強烈なエネルギーが宿りはじめるのである。

プロジェクトを成功に導くコツは、とにかく全体像を理解させること。

まずはこれなんです。

今日のシステムを成功させるポイント

積み重ねで全容を理解するのは難しい。

全容を見せて考え理解させよ。