プロジェクト計画を考える 〜スーパーSEのプロジェクト管理の実際
＜目次＞ プロジェクト成功の秘訣
1. 今「プロジェクトリーダがいなくなった」(2002年5月3日)
2. 管理と言う言葉とプロジェクト管理 (2002年5月3日)
3. いい加減のすすめ（2002年6月30日）
4. 超概算（いい加減の進め その２） （2002年7月28日）
5. 事実－推論－結論のスパイラル（2002年9 月7日）
5.1 事実 （2002年9月7日）
5.2 推論 （2002年10月13日）
（Ｎｅｗ 2002年12月日 (3)項 パレート図）
6. 日本の方法論と輸入方法論
1. 今「プロジェクトリーダがいなくなった」(2002年5月3日)
- Ｍ銀行の自動振替、ATM等の故障 -
国産機での銀行システムのオンラインは、1968年頃の全国地方銀行協会であろう。それから、約35年経って、システム開発の難しさを理解している人々が居なくなってしまったのでは無かろうか。
私は、1967年にSEになったので、日本のオンライン化の歴史と同じに歩いた。私は、全国地方銀行協会も、M銀行も担当していないが、いくつかの巨大銀行システムのプロジェクトリーダから設計者までを、様々な立場で担当してきた。
状況を知らないので、直接この問題には立ち入れないが、単に銀行の問題と言うよりは、これが、日本の現状(実力)になってしまったのでは無かろうかと感じている。
(1) 日本に、巨大プロジェクトをやれるリーダは、ほとんど、いなくなってしまった。
l 普通コンピュータシステムは、買ってきて、インストールすれば動くが、・・・・。
l ビジネスルールを新規にシステム化するプロジェクトは、あまりないので、経験不足は否めない。
l コンピュータ技術、専門（コンピュータ化対象）分野、人間の3つの分野に通じているＳＥが本当は必要なのだが・・・。
(2) プロジェクトリーダの能力を評価出来る人も組織もなくなってしまった。
某社が、大規模プロジェクトのリーダが出来るＳＥを、常務待遇にすると言う記事があった。分かっている会社は一社だけか？
(3) 日本的議論下手(誰かに従う文化と言葉の使い方)が、問題を先送りにしている。
近い将来、ミッションクリティカルなシステムが、経済的に、あるいは物理的に限界を迎えるはずだ。その時、システムは、数十年におよぶ機能追加により、多くの機能を満載している。これを、切り換えることになる。
小さな独立した小単位に分割する技術など、技術開発に加えて、プロジェクト管理にも、スパイラルな進化が起きるようにしておくべきだ。プロジェクト管理を理論にまで高めて、教えられるようにしておくべきである。
プロジェクト管理は、「スーパーSE」に書いたので、それも読んで下さい。
2. 管理と言う言葉とプロジェクト管理 (2002年5月3日)
管理という言葉から、仕事の後追い、前例を重視する、仕事の邪魔をする「必要悪」というイメージがわいてきます。プロジェクト管理と言う言葉はあまり使いたくない。コントロールとかマネージメントなど英語もどきがあるが、カタカナ英語は意味を不明確にする。結局、適当な言葉が無いので、仕方なく「管理」を使う事にします。
会社の管理もプロジェクト管理も、人、金、時間、もの、情報などを制御して、目標を達成することなので、目的は同じである。しかし、規模や分野にもよるが、プロジェクト管理の方が、会社の管理よりは易しそうだ。一般に、プロジェクト管理は、会社の管理に比べて、目的が単純で規模が小さいので、容易なはず。
プロジェクトを制御する制御可能な変数は、人、装備、金、時間、組織、プロセス、やり方、外交、品質などなどである。この制御可能な変数を変えることで、プロジェクトを制御して、プロジェクトの目標を達成することが、プロジェクト管理である。
例えば、プロジェクトが、うまくいかないから誰かの応援を頼んだのも、チームが機能していないので、組織を変えるのも、制御可能な変数を制御したことだ。この場合、人事と組織が制御可能な変数になっている。この、変えたことが管理である。
人によって、制御可能な変数の種類は異なる。チームや個人のモラールを制御可能な人もいれば、出来ない人もいる。技術的にも、同じだ。あることが、それが得意な人も出来ない人もいる。
大抵の場合、人はそれぞれ良さを持っている。何かが出来て、何かが出来ない。従って、様々な人材に、適材適所適時に働いてもらい、その力を相乗的に出して、プロジェクトを進めることが管理である。
以上の如く、プロジェクト管理における管理は、後追いだけでは無い。事実を事実として認識し、そこから演繹あるいは、帰納して、あり得る可能性を予測する。たいていの場合、あるべき姿とかけ離れているので、制御可能な変数を通じてそれを、あるべき姿に近づけ、あるいは、ゴールを実現可能な線に導くことである。ＰＤＣＡ（Ｐｌａｎ Ｄｏ Ｓｅｅ Ｃｈｅｃｋ Ａｃｔｉｏｎ）を回すことである。
プロジェクト管理は、もっと理論になると考えている。要求定義、モデリング、システム設計、言語など技術的な問題、人と人のコミュニケーションの問題、事実を認識する問題、演繹・帰納等々、様々な理論化できそうなテーマが転がっている。プロジェクトをやる時に、すべての段階で、挑戦的で理論化できそうな技術的、人間的、学際的、業際的な目標を持って、プロジェクトをやってみよう。プロジェクトリーダだけではない。将来プロジェクトリーダになる人も、日々の高い目標とその実現に知恵を絞ることが自分を育て、理論を育てる。
3. いい加減のすすめ（2002年6月30日）
時々思うのですが、人は、何でもきちんとやらなければ済まない人と、いい加減な人がいます。同様に、仕事も、きちんとしていなければいけないだけではなく、いい加減さが必要な場合があります。でも、一般に、きちんと好きの人は、いい加減が出来ない、逆も同様です。そのあたりが問題です。
いい加減さには、いくつか種類があります。プロジェクトを想定して、例を考えてみます。
10本のプログラムを開発する必要があったとしましょう。10本あることに気がつかず、8本だと思い込んだ場合、２本は、後工程で見つかる。対象物の量を、間違えた事になる。そこで、この個数の軸の事を、「間口」と言うことにする。
もう一つの軸、10本の個々の定義の厳密さを、「奥行き」と言う事にする。例えば、10本のプログラムのどれかに、エラー処理の仕様が書かれていなかった場合は、間口が不正確であるということになる。
「間口」と「奥行き」の両方に、いい加減さが潜んでいる。その組み合わせは、次の４つである。
(1) 奥行き、間口共にきちんとしている
「完璧型」と言うことにする。
(2) 奥行きはきちんとしているが、間口に漏れがある。
「奥行型」と言う事にする。
(3) 間口には漏れが無いが、奥行きの詰めが甘い。
「間口型」と言うことにする。
(4) 両方共、いい加減だ。
「駄目型」と言う事にする。
では、仕事の面から、いい加減さを分類してみよう。
(1) きちんとしていなければならない仕事
例えば、原子力発電所の施工・運転・管理がいい加減だと沢山の人が死ぬ事もあり得る。すべてのシステムは、基本的にこれに属する。
(2) きちんとしたつもりで、実はいい加減にすぎない仕事
例えば、ソフトウェアの開発プロジェクトでは、計画と実績で、200%狂った等と言うことがおきる。このようになる大抵の場合は、計画段階では、明確に見えていなかった機能が次第に明確になることと、時間と共に要求が変化して行くことがある。もちろん、計画自体がずさんであったと言う事もあるが、計画時点では、完璧型であった場合を考えよう。
計画が完璧でも、事務処理のソフトウェア開発プロジェクトでは、しばしば、こういうことがおきる。極端に言うと、事務処理システムでは、機能がすべて見えた時は、開発を完了したときだと言うことさえできる。それでも、その瞬間に、要求は変化し続けている可能性が高い。
つまり、事務処理向けシステム開発プロジェクトは、最初から「駄目型」、「奥行型」「間口型」のいずれかであると考えなければいけない。
そうすると、計画段階で、駄目型を承知で突っ走らざるを得ない場合がある。２つの軸（方向）の漏れ、変化、あるいは拡大を、いかに早く見つけるか、見つかった時いかに早く手が打てる様にしておくかが計画の良さである。
(3)もともと、いい加減で良い仕事
例えば、開発過程で問題が多発しているとしよう。しかし、今まで、検査が上手くいっているので、水際で不良品が出て行かなかったとする。不良プログラムを後で手直しするのは金がかかるから、早めに見つけたい。そこで、開発過程での品質向上をするとする。さて、調べてみたら、問題も対策も沢山出てきた。どれからやろうか。ＡＢＣ分析もしてみた。
このような時、「完璧型」を目指すと、多分永久に出来ない。一つでも出来れば、事態は改善される。従って、「奥行型」で取り組むべきだ。
(2) は、きちんと決まるまで待てば良いではないかと言う意見があるかもしれない。そうすると、永久に待っていなければならない。実世界での要求は、コンピュータと関係なく変化し続けている。いったん、あるレベルで止めて、要求を定義し作る。その後で、変化分を手直しするしかない。従って、いい加減を承知した上で、完全を目指している。きちんとしている人は、どのレベルであきらめるかが中々できない。ずるずると新たな要求に引っ張られて、遅れてしまうことが多いようだ。
プロジェクト管理をする人は、その場その場で、きちんとしたり、蛮勇をふるえる人であることが望ましい。なかなか、そういう不思議な人はいないので、しばしば、意思決定を間違えてしまう。
4. 超概算（いい加減の進め その２） （2002年7月28日）
いい加減のすすめの第二弾です。ＳＥでもプログラマーでもよいのですが、きちんとした仕事しか出来ない人が多い。きちんとした仕事ができることは、すばらしいことですが、加えて、超概算に、見当をつけることができるとス-パ-SEの第一歩ですかね。つまり、大雑把と精密な仕事を使い分けることができる人である。大抵の場合、どちらかしかできないから、どちらかは、他人の知恵を借りることになる。
システム設計の初期に、どの方式をとるべきか、そのような時、判断基準は２つある。
(1) 機能を実現するのに、どちらが簡単かと言う点
これは、開発費用に効いてくる。簡単な方が開発規模は少ない、したがって、開発、試験、維持いずれも少なくて済むはずだ。
開発済の方式があればそれが最も単純で早いかもしれない。
(2) その方法をとると、性能の天井にぶつからないかと言う点
性能が悪い方式だと、ハ-ド資源を喰う。しかし、上位機種があれば、そう問題はない。ハ-ド価格は、安くなってきているからだ。
最上位機種を使っていると、次の大きい機種はない。したがって、見通しを得ておく必要がある。
ある時、某SE氏に、「方式比較をするので、処理能力モデルをつくって」とお願いした。そうしたら、その氏は、「トラヒックがわからない」「集中率がわからない」等々と言い出した。
「このモデルで、約束したとか違反したなどと言うつもりはない。方式比較の一つだ」と言って、やって貰えることになった。方式設計時の性能計算は、超概算で良いのだ。桁のレベルの精度で比較は可能。方式は決めなければならないし、詳細情報は、分からない。当然、超概算になる。
2002年6月号「Computer」(IEEE)に、JAVAを実行するハ-ドの記事がありました。62.8%のJAVAインストラクションを直接実行できるようにするものだそうです。だとすると、一体どのくらい早いのかなと言うのを想像してみます。
ちょっと考えてみてください。
･ 大体、ハ-ドを作ると言うことはどういうことか。
･ 62.8%は、javaの持つ命令の内と言う意味であろう。
･ さて、どうしよう?
多くの読者は、ここまでで、この先すすめるには、既知の知識ではすすめられないのではないだろうか。
おそらく、既知の情報でもっとすすめられる。私は、とっさに次の様に考えた。
･まず、静的なカバ-比率62.8%は、動的に命令の実行される割合にすると、95%はカバ-されるのではないだろうか。
パレ-トの理論が使えるはずだが、良く覚えていないのが±20%ではあたっているだろう。
･古典的なインタ-プリッタ-なら、一つのインストラクションに、20実行ステップくらいはかかるだろう。
議事コ-ドに落とす等の工夫をしているから、5倍程度になるかな。
最近のインタ-プリッタ-は、もっと早いかもしれないので、「エイヤ」と2～5倍にしてみよう。
→ 今までよりも、5倍早くなるとすると、0.05×1＋0.95×0.2＝0.24だから、5倍程度早くなることになる。
まあ、こんな感じである。あたらずとも遠からずであろう。本格的には、各々調べてみる必要がある。その場合でも、命令の使用頻度は違うし、実行速度も違う。従って、最後は確率的になってしまう。いずれにしろ、方式の選択、機能（サービス）の実現可能性の検討では、これで十分な場合も多い。
もう一つの問題は、95%や5倍がどうして出てきたか。パレ-トの理論は、品質管理でグラフを書くことだけではなく、原因の20%が、現象の80%をしめることを証明していることだ。これを知っていれば、命令数の20%が、実際に実行される命令の80%を占めるはずだから、62.8%だと相当な割合になるはずだと想像がつく。たいていの人は、パレート図がなんであるか、また、パレートの理論を知っているだろう。インタープリッタがどういう動作をするかを知っているであろう。
5. 事実－推論－結論のスパイラル（2002年9 月7日）
プロジェクトを管理する際、様々な意思決定をする場面に遭遇する。その意思決定に至る推論の原理は、「事実－推論－結論」である。つまり、図の如く、弁証法風スパイラルに考えていくことである。
(1)[事実］事実を、そのまま認識し、
(2)[推論]その事実を整理して仮説を立て
(3)[結論]仮説と事実の間に矛盾がないか確認する。
この過程を繰り返す。つまり、「結論」を得た後、「新たな事実」を見つけ、上と同じ過程を繰り返す。
図-１ 事実・推論・結論
5.1 事実 （2002年9月7日）
事実を認識することは、中々難しい。ただ、物理・数学に関する事実は、比較的共通的に認識しやすい。政治の世界における事実は、価値観を除くことが難しい場合があるので、事実を事実と認識することが難しい場合がある。例えば、裁判を考えれば、事実の認識の難しさが分かると思う。
事実を認識するには、すべて、自分の目で見て事実を確認することが望ましいが、それでは、1000人のプロジェクトメンバーのすべてをチェックしなければならない。実行上そのようなことは、出来ない。せいぜい5～7人までである。
そこで、人に聞くことになるが、聞いたことは一般に歪んでいる。人は、都合の良い事を聞きたいと言う心理が働く。また、都合の良いことを過大に言い勝ちである。また、気がつかない事は当然言えない。また、聞く方も、耳に心地よい情報しか聞かない。この様な人の特性を踏まえて、事実を誤認しない様にすることが、まず、第一の課題である。質問し、判断する事が必要だ。
また、情報源に近いほど、事実に近くなる。例えば、統計値を見るよりも、その原始データを見るとより事実に近くなる。
今、生産性の統計値について考えてみよう。目の前にある生産性は、事実であろうか。
生産性は、ファンクションポイントやＬＯＣなど規模を人月で割ったものとしよう。規模は、どこからとれるだろうか。過去の実績のはずだ。過去の実績は、どうすれば、とれるだろうか。いくつかあるが、もっとも簡単なのは、契約、あるいは、納入時点の数値であろう。そうだとすると、その数字は、契約、あるいは、納入用の数字であり、事実ではないかもしれない。人月も同様である可能性が高い。
もっとも、目的によっては、これで良い場合もある。たとえば、次の契約をするときに、前回比、X%向上と言う様な使い方では使える。一方、本当に時間も人も不足で、ギリギリの生産性で物が出来るかどうかを推定するときには、本当の数字を知らなければならない。
事実を知りたければ、当時の受注者に、目的を明らかにした上で問い直さなければならない。あるいは、自分の経験値を適用することになる。
このたぐいの話は、いくらでもあるので、原理・原則的に言うと、目的に沿った数字を、できるだけ原始データに近いところでつかまえることである。
人は知らないことは言えない。例えば、ソートの処理が遅いので、データを採ったとしよう。少量データでは、すべてのデータがキャッシュ上に乗ってしまっているかもしれない。そうだとすると、実体よりも早い処理時間の推定をしてしまうことがある。実験計画をする時に、コンピュータの仕組みを知って、より、実体に近い環境で測定する必要がある。勿論、実際の環境と同じであることが理想であり、それが出来るなら、そう知恵はいらない。仕組みさえ抑えておけば、異なる環境での実験を計画でき、その結果から実態を推定できる。
人は、都合の悪いことは言いたくない。出来れば、言わずに済めば楽だ。いわれたことが信用出来なければ、事実を自分で調べることになる。これは、不可能なので、なるべく言いやすい雰囲気を作り出すことが必要だ。例えば、あるエラーが出た時、担当は、今までのやり方を少し変えた。担当は善かれと思ってやった事なのだが、このエラーと関係があるかもしれないと思った時、言いたくなくなる。もし、言って、ぼろくそに怒られれば、二度と言わないと心に決めてしまう。「こうしようとしたのだろう。しかし、結果が悪かった」「良く言ってくれた」等々言い方はある。何度も繰り返すなら、別の手を考えるしかない。少なくとも、その場は、言いやすい雰囲気を作ることである。
勿論、人を見ることも重要だ。間違えが無い事が分かっていれば、そのまま事実として認めることになる。初対面だと、この信用度が分からないので、何回かは、結果をフォローしたり、原始データに近づけて判断することになる。
第三に、事実と推論と結論を分けてとらえる事が出来る人は、そう多くない。特に、プログラムあるいは、仕様に強い人ほど、周りのことを一緒に考えてしまう。現在、自分の前にある問題との関係によって、これをすぐに拾うか、それとも、棚上げにするかを決める。たいていの人は、この区別ができずに、徒然なるままに考えがながれてしまう。
問題を解決する、あるいは、計画を作る時は、まず、事実だけを使う必要がある。「事実だけ言え、憶測をいうな」と、何度も繰り返さなければならなくなる。忘れない様に事実を黒板に書き出し、その上で推論を組み立てる。
5.2 推論 （2002年10月13日）
以上の過程で事実がはっきりしたら推論に入る。まずは、整理である。整理しながら、問題･リスクを見つけ、原因を発見する。
(1) 時系列に整理すること
これは簡単だ。事実を並べて書けば良い。並べて書くと、順序の間違えなど気がつくことがある。計画であれば、必要項目があるか、故障の調査であれば、手順の間違えは、これで分かる。
(2) 現在の現象をクロスセクションに整理すること
現在の状態の相互矛盾を見つけることである。
(3) 異常値(事実)に注目する。
異常値は、推論根拠の宝庫だ。
(4) 他の似た事例はないか。
他の事例との比較検討である。
推論を組み立てる際、事実が不十分だが、結論を出さなければならない場合がある。また、推論自体が出来ない場合、複数の推論が出来て、解が求まらない場合がある。しかし、答えを出さなければならない。
例えば、計画時に生産性がでるかどうか分からないが、計画は立てなければならい。さらに、人・物・金・資源を準備しなくてはならない。揃えるためには、時間がかかる。したがって、より不確実なときに決断しなければならない。また、仕様変更や設計変更がどの程度出るかも分からない。不確実だらけである。
生産性を考えてみよう。生産性を決める要因は、沢山あって、かつ、そのプロジェクト独特の要素があるので、やってみなければ分からない要素を持っている。やってみなければ分からない事は、いくら考えても分からない。
事実を数多くとっても、分布は広く、どこにあたるか分からない。また、個別事情があり、母集団に無い特性が隠れているかもしれない。さらに、仮説に合うデータがとれている可能性は薄い。なぜなら、仮説を持って仕事をするSEは極めて少ないからである。どのようなやり方でやるかによっても、生産性は変わる。
そのような状況下で決断を迫られるわけである。そのとき、対処出来そうな範囲のリスク最小の点で、決断するしかない。例えば、2割程度なら、後での調整が効きそうであれば、計画の7～8割あるいは、100％で、実行に移す。後は、補正しながら進めていくしかないのである。
生産性や規模ならば、実際に試験プラント(パイロットプロジェクト)をやってみて、事実そうな値に補正しながら計画と実績をトレースしていく。その際、人の習熟による生産性の伸はび、直線ではないの。例えば、プロジェクトの進捗が遅れてきたとき、増員か、現状維持で、生産性の向上効果を期待するだけで追いつくのか、機能を減らす、納期を遅らせる交渉が可能かなど、判断が難しい。
生産性を例にとると、試験プラント（パイロット）の実施時の実験計画でその読みは大きく違う。パイロットの実施には、こつがある。
(1) 必ず、その日に、改善ポイントを報告し、最低限リストアップしておくこと。
一晩寝ると、たいていのことを忘れてしまう。したがって、その日の内に、問題や改善点をリストアップしておくことが必要だ。
(2)生産性等の数字は、必ず3点測定すること(3点測定は別途書く)
一点だと、先が読めない。そのプロジェクトでの経験不足で、標準や言葉に馴れていないので生産性が低いかもしれない。そうだとすると、生産性はいずれ上がるが、1点では、推定が難しい。3種、未経験、普通、ベテランの3人とる、さらに、一人を3回測定すると成長のカーブが見える。もちろん、正確では無いが、曲がる傾向が見えるので、予測鮮度が上がる。
これらのこつは、仮説から成り立っている。
(1)については、人は、翌日には(寝ると)、忘れてしまう動物である。項目を羅列するだけでも、その日にするのが良い。
(2)「当プロジェクトの環境に慣れるまでに時間がかかる」という仮説からこれが導かれる。(塀著「スーパーSE」)。従って、ベテランはベテランなりに、初心者は初心者なりに、当プロジェクトでの経験を踏むに連れ、生産性が向上していく。
脳は、極めて早いアクセス時間をもった記憶装置を持っている。当初、標準化ドキュメントを見ながらでは、生産性は上がらない。知っている人に聞けば、出来るやつの生産性まで落としてしまう。
判断のクライテリアは、影響とコストと時間である。決して、100点を採る必要は無い。上で述べた様に70～80点の推論が出来れば、結論をだす。そして、試して見れば良い。後の20～30点は、やりながら修正していく。
以上、主に生産性を例にとって述べたが、他も同様である。品質の確保、性能の確保、等々・・・。例えば、性能の確保には、3点測定が必須だ。
横軸に対象物、縦軸に発生頻度をとってグラフにすると、たいていのものは、上位20％の対象物が80％量（30－70だったかもしれないが、ここでは、この違いは、大した問題ではない）を決めるというのが、確か経済学者パレート先生の発見だ。その図を、パレート図という。また、この分析を、ＡＢＣ分析とも言う。このパレート図は、品質管理の道具として有名だが、もともとは、パレート先生の理論である。
例えば、応答時間が遅いものは、遅いもの上位20%に手を打てば、ほぼ解決する。実用上には、トランザクションの多い取引の上位80%が問題なければ、実用上ほとんど問題ないということになる。
開発工程のおくれも、同様だ。おくれているサブシステムの一つか二つに手を打てば、たいていの場合ほぼ解決である。組織論、管理スパンでいえば、「一人の管理幅は、7つが最大(スーパーSE)」だから、二つに手を打てば良い。いや、2つしか問題起きないと言う方が正しいかもしれない。
問題が出た時の修復、あるいは、計画をたてる時、計画を修正する時、あらゆるフェーズで、ＡＢＣ分析をする。勿論、正確に、頻度や危険度、迷惑度を測ろうとすると、それだけで、大量の情報が必要になり、調べるだけの時間も工数も足りなくなる。数字になるものは、できるだけ数字にするが、難しいものは、超大雑把に、エイヤっと山勘で多そうなものを取り上げる。山勘を働かすには、日頃から、物の本質を見抜く思考を訓練していなければならない。例えば、日記や随筆を時々まとめてみるのが良いだろう。気がついたことなどをメモしておき、週に一度、あるいは、月に一度そのなかから興味のあるものを選択して書いてみる。考えがまとまるものだ。
6. 日本の方法論と輸入方法論
- プロジェクト成功のための意思決定 -
プロジェクト管理は、意思決定の連続、その意思決定の正さが成否を決めるキーである。プロジェクトの実施、管理、意思決定は、図の構造を持っている。
プロジェクトが実際に行われている場、要求定義をしたり、プログラムを書いたりする場である。その場を測定し、得た情報を、評価し必要な手を打つのが2番目の情報流の場である。この場で意思決定がなされる。この意思決定の正しさをを支えているのが、能力の部分である。
能力の部分が最も重要で、これが無いと測定値は、ただの数字にしかならない。一方、プロジェクトの測定、評価方法は、形式化可能な範囲であり、それなりに出来てきている。
プロジェクト自体のやり方、組織、命令システムなどは、多分に文化の影響を受けている(事例1,5)。プロジェクトの進め方も、判断、情報のとりかたも違う。実世界が違うので、当然、情報流、能力共に違うものが求められる。
にもかかわらず、欧米流の方法論がはびこっている。良く見てみると、日本の観察から、米国版にしてものも多そうだ。つまり、日本が得意で欧米が下手なところを強調している(事例1)。欧米の方法論に一喜一憂せず、日本の方法論をきちんと持つべきであり、これが競争力の源泉である(事例2,3,4)。
以上の観察から、日本でやってきた事をきちんと書きだすことが、今重要である。それは、現場にあるはずだ(事例5)、また、各社のエッセンスであるべきだ。
以上のことを、踏まえて、現場の知恵を掘り出して、マップし、解説する。
(以下参考)
事例1
デマルコの本「SOFTWARE STATE-OF-THE-ART Selected Papers」に、日本のコンピュータソフトウェア産業事情「The computer software industry in Japan」という論文が載っている。
その解説に、「It was so huge and so fast and so functional. it was in fact, the very online teller system that our largest banks still trying and failing to build almost a full decade later」とある。現場で実はやってしまっていた。
その先に、次の様に書いてある。
「There is almost nothing published in English about Japanese software methodol‐ogy. Tajima and Matsubara(論文著者) have come along with this fascinating peek into a truly different world」。発表も同時にしなくてはならない。
事例2
上と同じ本に載っている「A Model for Estimating Program Size and Its Evaluation
」、個別技術の事例を挙げる。見積をプログラムの構造を解析することで見積精度を向上させた発表である。これも、あるプロジェクトで考えて編み出し、やってみた結果を書いたにすぎないが、高い評価を得ている。
「Itakura and Takayanagi(論文著者) have come up with a charming way to give you the benefits of function metrics without all the hullabaloo」
事例3
今までのはやや古い事例なので、最近の事例を挙げる。論文名は、「The Functional Feature Network Diagram」である。米国のIASTED(The International Association of Science and Technology for Development)のSEA(Software Engineering and Applica‐tions)に、現場での工夫を論文にまとめたが、結果として、顧客情報を外すため、伏せ字だらけの論文になってしまった。当然、REJECTと予想していたが、意に反して、次の評価を受け、採択された。
「The paper deals with an important issue in the software engineering, namely how to bring the two worlds - software engineers and domain experts together so that they can understand each other」
事例4
ケント・ベック氏が、米国のＸＰの実習を日本で行った時の話。今まで、米国でやったことのない大人数でやったが、日本人は皆同じようなジェスチャーをしながら、米国人ならなかなかまとまらない相談を素早く終えてしまったということに驚いていました。
事例5
欧米型は、契約社会である。ボスと部下は、この仕事が出来るので契約している。従って、出来なければ、契約解除、つまり首。一方、日本では、出来ないのを縦横に助け合って何とかしようとする。米国の某社で、隣と助け合う事が出来るとボスがランチ券をあげて協力する風土作りをするのは、この違いから来ている。
一般的には上下の個人と個人の契約に対し、日本は、水平の個人と個人の協力が組織体の 基本原理として動いている。これが日本におけるプロジェクト管理の特徴を醸しだし、欧米と異なり現場が強い、現場に暗黙知が溜まる構造を作っている。
（欧米型) （日本型) （日本型)
○ ○ ○
／ ＼ ・ ・ ・↓・
○－×－○ ○←－→○ ○←－→○
事例6 The Cost and Benefits of Pair Programming
コードに要する時間は、1.1～1.5程度に伸びるが、ペアプログラミングにより品質が上がり、コードが短くなることを証した論文である。
考えてみると、コードレビューじゃないのかな。レビュー文化が無いから、こういいだした様な気がする。
＜未完の目次＞
7. 仕様とプログラムの一致
8.
7. 試験しやすいプログラム
8. 読みやすさ
9. 大プロジェクトと小プロジェクトのリーダ
10. 要求の変化と開発との間の時間の不整合
11.
12. ＡＢＣ分析
13. 餅屋は餅屋
14. 美しさ
15. ベクトル合わせ
16. リスクは低める手があれば進める
17. スピード感、本質、その根っこに価値観、哲学、腹、