-国産機での銀行システムのオンラインは、1968年頃の全国地方銀行協会であろう。それから、約35年経って、システム開発の難しさを理解している人々が居なくなってしまったのでは無かろうか。私は、1967年にSEになったので、日本のオンライン化の歴史と同じに歩いた。M銀行も担当していないが、いくつかの巨大銀行システムのプロジェクトリーダから設計者までを、様々な立場で担当してきた。状況を知らないので、直接この問題には立ち入れないが、単に銀行の問題と言うよりは、これが、日本の現状(実力)になってしまったのでは無かろうかと感じている。日本に、巨大プロジェクトをやれるリーダは、ほとんど、いなくなってしまった。普通コンピュータシステムは、買ってきて、インストールすれば動くが、・・・・。ビジネスルールを新規にシステム化するプロジェクトは、あまりないので、経験不足は否めない。コンピュータ技術、専門(コンピュータ化対象)分野、人間の3つの分野に通じているSEが本当は必要なのだが・・・。プロジェクトリーダの能力を評価出来る人も組織もなくなってしまった。某社が、大規模プロジェクトのリーダが出来るSEを、常務待遇にすると言う記事があった。日本的議論下手(誰かに従う文化と言葉の使い方)が、問題を先送りにしている。近い将来、ミッションクリティカルなシステムが、経済的に、あるいは物理的に限界を迎えるはずだ。その時、システムは、数十年におよぶ機能追加により、多くの機能を満載している。これを、切り換えることになる。小さな独立した小単位に分割する技術など、技術開発に加えて、プロジェクト管理にも、スパイラルな進化が起きるようにしておくべきだ。プロジェクト管理を理論にまで高めて、教えられるようにしておくべきである。プロジェクト管理は、「スーパーSE」に書いたので、それも読んで下さい。(2002年5月3日)管理という言葉から、仕事の後追い、前例を重視する、仕事の邪魔をする「必要悪」というイメージがわいてきます。プロジェクト管理と言う言葉はあまり使いたくない。コントロールとかマネージメントなど英語もどきがあるが、カタカナ英語は意味を不明確にする。結局、適当な言葉が無いので、仕方なく「管理」を使う事にします。会社の管理もプロジェクト管理も、人、金、時間、もの、情報などを制御して、目標を達成することなので、目的は同じである。規模や分野にもよるが、プロジェクト管理の方が、会社の管理よりは易しそうだ。一般に、プロジェクト管理は、会社の管理に比べて、目的が単純で規模が小さいので、容易なはず。プロセス、やり方、外交、品質などなどである。この制御可能な変数を変えることで、プロジェクトを制御して、プロジェクトの目標を達成することが、プロジェクト管理である。プロジェクトが、うまくいかないから誰かの応援を頼んだのも、チームが機能していないので、組織を変えるのも、制御可能な変数を制御したことだ。この場合、人事と組織が制御可能な変数になっている。この、変えたことが管理である。人によって、制御可能な変数の種類は異なる。チームや個人のモラールを制御可能な人もいれば、出来ない人もいる。あることが、それが得意な人も出来ない人もいる。場合、人はそれぞれ良さを持っている。何かが出来て、何かが出来ない。従って、様々な人材に、適材適所適時に働いてもらい、その力を相乗的に出して、プロジェクトを進めることが管理である。以上の如く、プロジェクト管理における管理は、後追いだけでは無い。事実を事実として認識し、そこから演繹あるいは、帰納して、あり得る可能性を予測する。場合、あるべき姿とかけ離れているので、制御可能な変数を通じてそれを、あるべき姿に近づけ、あるいは、ゴールを実現可能な線に導くことである。Action)を回すことである。プロジェクト管理は、もっと理論になると考えている。理論化できそうなテーマが転がっている。目標を持って、プロジェクトをやってみよう。プロジェクトリーダだけではない。将来プロジェクトリーダになる人も、日々の高い目標とその実現に知恵を絞ることが自分を育て、理論を育てる。いい加減のすすめ(2002年6月30日)時々思うのですが、人は、何でもきちんとやらなければ済まない人と、いい加減な人がいます。同様に、仕事も、きちんとしていなければいけないだけではなく、いい加減さが必要な場合があります。一般に、きちんと好きの人は、いい加減が出来ない、逆も同様です。そのあたりが問題です。いい加減さには、いくつか種類があります。プロジェクトを想定して、例を考えてみます。10本のプログラムを開発する必要があったとしましょう。10本あることに気がつかず、8本だと思い込んだ場合、2本は、後工程で見つかる。対象物の量を、間違えた事になる。そこで、この個数の軸の事を、「間口」と言うことにする。一つの軸、10本の個々の定義の厳密さを、「奥行き」と言う事にする。10本のプログラムのどれかに、エラー処理の仕様が書かれていなかった場合は、間口が不正確であるということになる。「間口」と「奥行き」の両方に、いい加減さが潜んでいる。その組み合わせは、次の4つである。奥行き、間口共にきちんとしている「完璧型」と言うことにする。奥行きはきちんとしているが、間口に漏れがある。「奥行型」と言う事にする。間口には漏れが無いが、奥行きの詰めが甘い。「間口型」と言うことにする。「駄目型」と言う事にする。仕事の面から、いい加減さを分類してみよう。原子力発電所の施工・運転・管理がいい加減だと沢山の人が死ぬ事もあり得る。すべてのシステムは、基本的にこれに属する。ソフトウェアの開発プロジェクトでは、計画と実績で、200%狂った等と言うことがおきる。このようになる大抵の場合は、計画段階では、明確に見えていなかった機能が次第に明確になることと、時間と共に要求が変化して行くことがある。計画自体がずさんであったと言う事もあるが、計画時点では、完璧型であった場合を考えよう。計画が完璧でも、事務処理のソフトウェア開発プロジェクトでは、しばしば、こういうことがおきる。極端に言うと、事務処理システムでは、機能がすべて見えた時は、開発を完了したときだと言うことさえできる。それでも、その瞬間に、要求は変化し続けている可能性が高い。いずれかであると考えなければいけない。すると、計画段階で、駄目型を承知で突っ走らざるを得ない場合がある。2つの軸(方向)の漏れ、変化、あるいは拡大を、いかに早く見つけるか、見つかった時いかに早く手が打てる様にしておくかが計画の良さである。開発過程で問題が多発しているとしよう。今まで、検査が上手くいっているので、水際で不良品が出て行かなかったとする。不良プログラムを後で手直しするのは金がかかるから、早めに見つけたい。そこで、開発過程での品質向上をするとする。調べてみたら、問題も対策も沢山出てきた。ABC分析もしてみた。このような時、「完璧型」を目指すと、多分永久に出来ない。一つでも出来れば、事態は改善される。従って、「奥行型」で取り組むべきだ。決まるまで待てば良いではないかと言う意見があるかもしれない。すると、永久に待っていなければならない。実世界での要求は、コンピュータと関係なく変化し続けている。あるレベルで止めて、要求を定義し作る。その後で、変化分を手直しするしかない。従って、いい加減を承知した上で、完全を目指している。している人は、どのレベルであきらめるかが中々できない。新たな要求に引っ張られて、遅れてしまうことが多いようだ。プロジェクト管理をする人は、その場その場で、きちんとしたり、蛮勇をふるえる人であることが望ましい。いう不思議な人はいないので、しばしば、意思決定を間違えてしまう。(2002年7月28日)いい加減のすすめの第二弾です。SEでもプログラマーでもよいのですが、きちんとした仕事しか出来ない人が多い。した仕事ができることは、すばらしいことですが、加えて、超概算に、見当をつけることができるとス-パ-SEの第一歩ですかね。大雑把と精密な仕事を使い分けることができる人である。場合、どちらかしかできないから、どちらかは、他人の知恵を借りることになる。システム設計の初期に、どの方式をとるべきか、そのような時、判断基準は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%だと相当な割合になるはずだと想像がつく。人は、パレート図がなんであるか、また、パレートの理論を知っているだろう。インタープリッタがどういう動作をするかを知っているであろう。月7日)プロジェクトを管理する際、様々な意思決定をする場面に遭遇する。その意思決定に至る推論の原理は、「事実-推論-結論」である。図の如く、弁証法風スパイラルに考えていくことである。(1)[事実]事実を、そのまま認識し、(2)[推論]その事実を整理して仮説を立て(3)[結論]仮説と事実の間に矛盾がないか確認する。「結論」を得た後、「新たな事実」を見つけ、上と同じ過程を繰り返す。(2002年9月7日)事実を認識することは、中々難しい。物理・数学に関する事実は、比較的共通的に認識しやすい。政治の世界における事実は、価値観を除くことが難しい場合があるので、事実を事実と認識することが難しい場合がある。裁判を考えれば、事実の認識の難しさが分かると思う。事実を認識するには、すべて、自分の目で見て事実を確認することが望ましいが、それでは、1000人のプロジェクトメンバーのすべてをチェックしなければならない。実行上そのようなことは、出来ない。そこで、人に聞くことになるが、聞いたことは一般に歪んでいる。人は、都合の良い事を聞きたいと言う心理が働く。都合の良いことを過大に言い勝ちである。気がつかない事は当然言えない。聞く方も、耳に心地よい情報しか聞かない。この様な人の特性を踏まえて、事実を誤認しない様にすることが、まず、第一の課題である。質問し、判断する事が必要だ。情報源に近いほど、事実に近くなる。統計値を見るよりも、その原始データを見るとより事実に近くなる。今、生産性の統計値について考えてみよう。目の前にある生産性は、事実であろうか。生産性は、ファンクションポイントやLOCなど規模を人月で割ったものとしよう。規模は、どこからとれるだろうか。過去の実績は、どうすれば、とれるだろうか。いくつかあるが、もっとも簡単なのは、契約、あるいは、納入時点の数値であろう。すると、その数字は、契約、あるいは、納入用の数字であり、事実ではないかもしれない。人月も同様である可能性が高い。目的によっては、これで良い場合もある。次の契約をするときに、前回比、X%向上と言う様な使い方では使える。本当に時間も人も不足で、ギリギリの生産性で物が出来るかどうかを推定するときには、本当の数字を知らなければならない。事実を知りたければ、当時の受注者に、目的を明らかにした上で問い直さなければならない。自分の経験値を適用することになる。このたぐいの話は、いくらでもあるので、原理・原則的に言うと、目的に沿った数字を、できるだけ原始データに近いところでつかまえることである。人は知らないことは言えない。ソートの処理が遅いので、データを採ったとしよう。少量データでは、すべてのデータがキャッシュ上に乗ってしまっているかもしれない。すると、実体よりも早い処理時間の推定をしてしまうことがある。実験計画をする時に、コンピュータの仕組みを知って、より、実体に近い環境で測定する必要がある。実際の環境と同じであることが理想であり、それが出来るなら、そう知恵はいらない。仕組みさえ抑えておけば、異なる環境での実験を計画でき、その結果から実態を推定できる。人は、都合の悪いことは言いたくない。出来れば、言わずに済めば楽だ。いわれたことが信用出来なければ、事実を自分で調べることになる。これは、不可能なので、なるべく言いやすい雰囲気を作り出すことが必要だ。あるエラーが出た時、担当は、今までのやり方を少し変えた。担当は善かれと思ってやった事なのだが、このエラーと関係があるかもしれないと思った時、言いたくなくなる。言って、ぼろくそに怒られれば、二度と言わないと心に決めてしまう。「こうしようとしたのだろう。結果が悪かった」「良く言ってくれた」等々言い方はある。何度も繰り返すなら、別の手を考えるしかない。少なくとも、その場は、言いやすい雰囲気を作ることである。人を見ることも重要だ。間違えが無い事が分かっていれば、そのまま事実として認めることになる。初対面だと、この信用度が分からないので、何回かは、結果をフォローしたり、原始データに近づけて判断することになる。第三に、事実と推論と結論を分けてとらえる事が出来る人は、そう多くない。プログラムあるいは、仕様に強い人ほど、周りのことを一緒に考えてしまう。現在、自分の前にある問題との関係によって、これをすぐに拾うか、それとも、棚上げにするかを決める。人は、この区別ができずに、徒然なるままに考えがながれてしまう。問題を解決する、あるいは、計画を作る時は、まず、事実だけを使う必要がある。「事実だけ言え、憶測をいうな」と、何度も繰り返さなければならなくなる。忘れない様に事実を黒板に書き出し、その上で推論を組み立てる。(2002年10月13日)以上の過程で事実がはっきりしたら推論に入る。整理しながら、問題・リスクを見つけ、原因を発見する。時系列に整理することこれは簡単だ。事実を並べて書けば良い。並べて書くと、順序の間違えなど気がつくことがある。計画であれば、必要項目があるか、故障の調査であれば、手順の間違えは、これで分かる。現在の現象をクロスセクションに整理すること現在の状態の相互矛盾を見つけることである。異常値(事実)に注目する。異常値は、推論根拠の宝庫だ。他の似た事例はないか。他の事例との比較検討である。推論を組み立てる際、事実が不十分だが、結論を出さなければならない場合がある。推論自体が出来ない場合、複数の推論が出来て、解が求まらない場合がある。答えを出さなければならない。計画時に生産性がでるかどうか分からないが、計画は立てなければならい。準備しなくてはならない。揃えるためには、時間がかかる。したがって、より不確実なときに決断しなければならない。仕様変更や設計変更がどの程度出るかも分からない。生産性を考えてみよう。生産性を決める要因は、沢山あって、かつ、そのプロジェクト独特の要素があるので、やってみなければ分からない要素を持っている。やってみなければ分からない事は、いくら考えても分からない。事実を数多くとっても、分布は広く、どこにあたるか分からない。個別事情があり、母集団に無い特性が隠れているかもしれない。仮説に合うデータがとれている可能性は薄い。仮説を持って仕事をするSEは極めて少ないからである。どのようなやり方でやるかによっても、生産性は変わる。そのような状況下で決断を迫られるわけである。そのとき、対処出来そうな範囲のリスク最小の点で、決断するしかない。2割程度なら、後での調整が効きそうであれば、計画の7~8割あるいは、100%で、実行に移す。後は、補正しながら進めていくしかないのである。生産性や規模ならば、実際に試験プラント(パイロットプロジェクト)をやってみて、事実そうな値に補正しながら計画と実績をトレースしていく。その際、人の習熟による生産性の伸はび、直線ではないの。プロジェクトの進捗が遅れてきたとき、増員か、現状維持で、生産性の向上効果を期待するだけで追いつくのか、機能を減らす、納期を遅らせる交渉が可能かなど、判断が難しい。生産性を例にとると、試験プラント(パイロット)の実施時の実験計画でその読みは大きく違う。パイロットの実施には、こつがある。その日に、改善ポイントを報告し、最低限リストアップしておくこと。一晩寝ると、たいていのことを忘れてしまう。したがって、その日の内に、問題や改善点をリストアップしておくことが必要だ。(2)生産性等の数字は、必ず3点測定すること(3点測定は別途書く)一点だと、先が読めない。そのプロジェクトでの経験不足で、標準や言葉に馴れていないので生産性が低いかもしれない。すると、生産性はいずれ上がるが、1点では、推定が難しい。ベテランの3人とる、さらに、一人を3回測定すると成長のカーブが見える。正確では無いが、曲がる傾向が見えるので、予測鮮度が上がる。これらのこつは、仮説から成り立っている。(1)については、人は、翌日には(寝ると)、忘れてしまう動物である。項目を羅列するだけでも、その日にするのが良い。(2)「当プロジェクトの環境に慣れるまでに時間がかかる」という仮説からこれが導かれる。(塀著「スーパーSE」)。従って、ベテランはベテランなりに、初心者は初心者なりに、当プロジェクトでの経験を踏むに連れ、生産性が向上していく。脳は、極めて早いアクセス時間をもった記憶装置を持っている。当初、標準化ドキュメントを見ながらでは、生産性は上がらない。知っている人に聞けば、出来るやつの生産性まで落としてしまう。判断のクライテリアは、影響とコストと時間である。100点を採る必要は無い。上で述べた様に70~80点の推論が出来れば、結論をだす。後の20~30点は、やりながら修正していく。以上、主に生産性を例にとって述べたが、他も同様である。えば、性能の確保には、3点測定が必須だ。横軸に対象物、縦軸に発生頻度をとってグラフにすると、たいていのものは、上位20%の対象物が80%量(30-70だったかもしれないが、ここでは、この違いは、大した問題ではない)を決めるというのが、確か経済学者パレート先生の発見だ。その図を、パレート図という。この分析を、ABC分析とも言う。このパレート図は、品質管理の道具として有名だが、もともとは、パレート先生の理論である。応答時間が遅いものは、遅いもの上位20%に手を打てば、ほぼ解決する。実用上には、トランザクションの多い取引の上位80%が問題なければ、実用上ほとんど問題ないということになる。開発工程のおくれも、同様だ。おくれているサブシステムの一つか二つに手を打てば、たいていの場合ほぼ解決である。組織論、管理スパンでいえば、「一人の管理幅は、7つが最大(スーパーSE)」だから、二つに手を打てば良い。いや、2つしか問題起きないと言う方が正しいかもしれない。問題が出た時の修復、あるいは、計画をたてる時、計画を修正する時、あらゆるフェーズで、ABC分析をする。正確に、頻度や危険度、迷惑度を測ろうとすると、それだけで、大量の情報が必要になり、調べるだけの時間も工数も足りなくなる。数字になるものは、できるだけ数字にするが、難しいものは、超大雑把に、エイヤっと山勘で多そうなものを取り上げる。山勘を働かすには、日頃から、物の本質を見抜く思考を訓練していなければならない。日記や随筆を時々まとめてみるのが良いだろう。気がついたことなどをメモしておき、週に一度、あるいは、月に一度そのなかから興味のあるものを選択して書いてみる。考えがまとまるものだ。-プロジェクト管理は、意思決定の連続、その意思決定の正さが成否を決めるキーである。図の構造を持っている。プロジェクトが実際に行われている場、要求定義をしたり、プログラムを書いたりする場である。その場を測定し、得た情報を、評価し必要な手を打つのが2番目の情報流の場である。この場で意思決定がなされる。この意思決定の正しさをを支えているのが、能力の部分である。能力の部分が最も重要で、これが無いと測定値は、ただの数字にしかならない。プロジェクトの測定、評価方法は、形式化可能な範囲であり、それなりに出来てきている。プロジェクト自体のやり方、組織、命令システムなどは、多分に文化の影響を受けている(事例1,5)。プロジェクトの進め方も、判断、情報のとりかたも違う。違うものが求められる。かかわらず、欧米流の方法論がはびこっている。良く見てみると、日本の観察から、米国版にしてものも多そうだ。日本が得意で欧米が下手なところを強調している(事例1)。欧米の方法論に一喜一憂せず、日本の方法論をきちんと持つべきであり、これが競争力の源泉である(事例2,3,4)。以上の観察から、日本でやってきた事をきちんと書きだすことが、今重要である。それは、現場にあるはずだ(事例5)、また、各社のエッセンスであるべきだ。以上のことを、踏まえて、現場の知恵を掘り出して、マップし、解説する。Japan」という論文が載っている。現場で実はやってしまっていた。その先に、次の様に書いてある。発表も同時にしなくてはならない。Evaluation」、個別技術の事例を挙げる。見積をプログラムの構造を解析することで見積精度を向上させた発表である。これも、あるプロジェクトで考えて編み出し、やってみた結果を書いたにすぎないが、高い評価を得ている。今までのはやや古い事例なので、最近の事例を挙げる。Diagram」である。Applica‐tions)に、現場での工夫を論文にまとめたが、結果として、顧客情報を外すため、伏せ字だらけの論文になってしまった。REJECTと予想していたが、意に反して、次の評価を受け、採択された。事例4ケント・ベック氏が、米国のXPの実習を日本で行った時の話。今まで、米国でやったことのない大人数でやったが、日本人は皆同じようなジェスチャーをしながら、米国人ならなかなかまとまらない相談を素早く終えてしまったということに驚いていました。事例5欧米型は、契約社会である。ボスと部下は、この仕事が出来るので契約している。従って、出来なければ、契約解除、つまり首。日本では、出来ないのを縦横に助け合って何とかしようとする。米国の某社で、隣と助け合う事が出来るとボスがランチ券をあげて協力する風土作りをするのは、この違いから来ている。基本原理として動いている。これが日本におけるプロジェクト管理の特徴を醸しだし、欧米と異なり現場が強い、現場に暗黙知が溜まる構造を作っている。Programmingコードに要する時間は、1.1~1.5程度に伸びるが、ペアプログラミングにより品質が上がり、コードが短くなることを証した論文である。考えてみると、コードレビューじゃないのかな。レビュー文化が無いから、こういいだした様な気がする。編集Jimdoあなたもジンドゥーで無料ホームページを。