■「太陽」を直接見てはいけない
先日の皆既日蝕は、関西地方では曇っていて良く分からなかったと思います。
日本で見られるのは４６年ぶりだそうで、結構な騒ぎになっていました。実際は、
皆既日蝕自体は１～２年に１回くらいは起きています。来年は南太平洋で見るこ
とができるそうです。日蝕ハンターといわれる、日蝕を追いかけることを楽しみ
にしている人たちも居ます。
「世界天文年2009日本委員会」によると、「太陽を肉眼で直接見つめることは、
たとえわずかな時間（１秒足らず）でも目に重大なダメージを及ぼす危険性があ
る」そうです。
■「サン」がいっぱい
リゾートの「３Ｓ」と言うのがあるそうです。「Ｓｅａ・Ｓｕｎ・Ｓａｎｄ」
だそうです。私もはるか昔に、溜まりに溜まった代休を消化するために、南の島
に行った事があります。南の島・プール・デッキチェア・ビール・水着の女の子
（当時二十歳以上です。念のため）・・・「これこそ人生だ！」と思いました。
今になって考えると、私の人生では、あの１０日間しか無かったような気もしま
すが・・・（笑）これはまた別の話です。
工学上の三大事故というのもあります。「タコマ吊橋の落橋、デハビラント・
コメット機の金属疲労による墜落・リバティ級貨物船の低温脆性による沈没」で
す。（「失敗学のすすめ」から）これらの事故は、原因が究明されて、その後の
教訓として生かされた（同じ失敗を繰り返さなかった）例として語られています。
ソフトウェアの開発は、昔から「きつい、暗い、帰れない」とか「きつい、帰
れない、給料が安い」の「３Ｋ」と呼ばれていました。（いずれにしても、「き
つい」は変わらないですね）2007年に情報処理推進機構（ＩＰＡ）が実施した
「ＩＰＡフォーラム2007」では「きつい、帰れない、給料が安い」の３Ｋに加え
て「規則が厳しい、休暇がとれない、化粧がのらない、結婚できない」の７Ｋだ
という学生からの指摘もあったそうです。確かに私も結婚できていませんが
・・・これもまた別の話ですね。
私は、ソフトウェア開発の見積りも「３Ｋ」だとよく言います。「経験・勘・
気合」の「３Ｋ」ですが、７月２０日の本メルマガで、池内さんが「ＫＫＤは否
定されるべきものなのか？」というコラムを書いておられました。池内さんの
「ＫＫＤ」は「経験・勘・度胸」ですが、ほぼ同じと思います。
経験者ならお分かりでしょうが、ソフトウェアの開発の工数は、倍・半分が当
たり前の世界です。今でこそ、自分で作ったファンクション・ポイントをベース
にした簡易見積りツールで、自らの見積りの検証をしたり、サード・オピニオン
として全く別の人間の見積りと相互チェックを行いますが、それでも自分の未経
験の分野では精度が大きく落ちます。
最近では、日本情報システム・ユーザー協会（ＪＵＡＳ）などから標準的な開
発生産性の数字が公表されていますが、生産性に影響を与える要因が多くあり、
またその影響度も大きいので、簡単ではありません。見積りに失敗すると、その
プロジェクトはほぼ確実に失敗します。しかし安全率を高くとって見積りを出す
と、仕事は取れません。結局は、ぎりぎりの所で「気合」か「度胸」で勝負する
ことになったりします。ここにもプロジェクトの危険が潜んでいます。
■「危険」がいっぱい
プロジェクトは「一回性」の物です。同じ様に見えても、リスクは違うところ
に潜んでいます。例えば、キーになる人間が突然入院してしまうかも知れません。
実は、私もこの前、初めて入院しました。四捨五入すると百歳になるような歳
なので、壊れない程度にメンテナンスしながら仕事をしてきたつもりなのですが、
ある日突然、救急車で運ばれてそのままＩＣＵに入れられてしまいました。直近
の仕事は、周囲がカバーしてくれましたので、社長報告を１つすっぽかしたくら
い（笑）で、幸い大きな問題にならずに済みましたが、リスク管理の１つとして、
仕事の状態を自分以外にも分かるようにしておく重要性を改めて感じました。
ソフトウェア開発のプロジェクトをやっていると、若手（といっても３０台後
半～４０歳前半くらい）で、妙に自信を持っている人に出会うことがあります。
おそらく基本的に優秀で、失敗経験が無い人なのだと思います。周りが失敗ば
かりする（ソフトウェア開発のプロジェクトは「失敗」ばかりです）のを見てき
たので自信があるのでしょうが、危ういものを感じます。
自信を持つこと自体は、決して悪いことではありませんが、自信と過信は紙一
重です。
私は臆病なので、プロジェクトをやる場合は、いつも「怖い」と思います。
「怖さ」を感じれば「危険」に対して敏感になります。もちろんプロジェクトの
時間は限られていますから、次々に決断を下して行かざるを得ません。自分とチ
ームの「力量」を正確に把握し、信頼することで「危険」に対して決断する（そ
してその結果に責任を取る）勇気が湧いてきます。（それでも怖い事は怖いです
が・・・（笑））
また、「怖さ」を感じれば「これで上手く行かなければこうしよう」と、常に
第２・第３の対策を考えることができます。第２・第３の対策に移るためには、
決断の結果が上手く行っているかどうかを判断する指標とリミットも考えます。
今回の私の入院も、言ってみれば「過信」の結果だと思います。
以前は、４０度近い熱があってもサービスインや重要な会議の時は、必ず客先
に行くことができました。この「成功経験」が、自らの体力や体調への「過信」
を産んだのだと思います。
■「危険」は直接見なければいけない
「危険」が見えなくなるような、過信は禁物です。工学上の三大事故がその後
の教訓として生かされるには、正しい原因の究明と類似の事象が発生する範囲の
特定が必要でした。コメット機の墜落の原因となった金属疲労は徐々に進行しま
すが、ある時、突然空中分解を引き起こすことが大規模な実験の結果わかりまし
た。金属疲労に対処するために、航空機の窓は丸くされ、フェイルセーフ構造が
取り入れられました。
ソフトウェアの開発においても、Ｗｅｂ系のシステムでは、負荷によって突然
性能が低下したりバッファ・オーバーフローが発生することが分かったため、ス
トレステストが普通に行われるようになりました。（このストレステストは、本
来「期待されている性能を満足する」かではなく「どこまで耐えられるか」を確
認するまでやるべきです）
また、セキュリティの面からも、ＳＱＬインジェクションやクロスサイト・ス
クリプティングの手口が分かると、それに対処するコーディング規約が決められ、
テストされる（既存のサイトでは、充分とは言えませんが）ようになりました。
他人の失敗を「他人事」と捕らえて無視するか「他山の石」と捕らえて自分を
磨くかは、大きな差になって来ると思います。
危険を早く察知し対処するためには、その危険を直視する必要があります。
「危険（やその兆候）を直接見つめないことは、たとえわずかな時間でもプロ
ジェクトに重大なダメージを及ぼす危険性がある」ことを理解し実践するために、
プロジェクトの「怖さ」を感じ、危険を見つける目を養っておくにはことが、危
険を縫ってプロジェクトを成功に導く、結果的な近道になると思います。
＜参考＞
・ＫＫＤは否定されるべきものなのか？（池内 正晴）
http://www.itc-kyoto.jp/itc/index0368.html
・世界天文年2009日本委員会
http://www.astronomy2009.jp/ja/webproject/soecl/ng.html
・21世紀(2001～2100年)に起こる皆既日食の一覧（せんだい宇宙館）
http://uchukan.satsumasendai.jp/event/news/2009eclipse/21century-totalecl.html
・「失敗学のすすめ」畑村 洋太郎 著 講談社
・IT業界不人気の理由は？ 現役学生が語るそのネガティブイメージ（@IT）
http://www.atmarkit.co.jp/news/200710/31/ipa.html
・「デ・ハビランド DH.106 コメット」ウィキペディア（Wikipedia）
■執筆者プロフィール
上原 守 harvey.lovell@gmail.com
ITコーディネータ CISA CISM システムアナリスト
京都を中心に仕事をしたいと思いながら、毎週東京へ出張していましたが、今年
からやっと大阪中心で仕事できるようになりました。（と思ったら、入院してし
まいましたが・・・）
上流から下流まで、最適なアドバイスやソリューションを提供できる人材を目指
しています。
コメントをお書きください