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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

土曜日、リーダークラスが集まるセミナーで、話をさせていただきました。

このときに「バグが出たときにどうすればよいか」といった質問が出て、そうだ、そのことを書いてないなあと、思い出したので、今週のネタが決まりました。

毎週、テーマに困っているので、本当に助かりました。

さて、プログラマでもSEでも、開発会社の技術者であれば、納品後のシステムで「バグ」が発見されたという経験はお持ちのはずです。

お客様から「困った声」で連絡があるときもあれば、いきなり、営業を通じて叱責の連絡が来ることもあったでしょう。

事態は様々ですので、一概には言えませんが、それでも、バグが発覚した場合の発言、行動から、お客様は、あなたという人間の誠実さを見るのです。

若く未熟なプログラマは、時に言ってはいけない言葉を発してしまいます。

「ちょっとしたミスです」、「すぐ直せます」

まず、当たり前のことですが、プログラマにとって、例え、「ちょっとしたミス」だとしても、「ちょっとした」とか「些細な」といった形容詞は、明らかにお客様に失礼な発言です。

一番最初にしなければいけないことは、「大変、申し訳ありません」と、お詫びすることなのです。

次に、「すぐ直せます」という言葉。
これは、相手が「どのくらいで直せるの？」と問われたことに対する回答であれば、問題はありません。

しかし、相手が聞いてもいないのに、最初にこういう言葉を発すると、「悪いと思っていない。直せばいいと思っているんだ」といった誤解を受けることもあるでしょう。

お客様が、システムに何か問題を見つけたときに考えることは、「すぐに直す」ことではないのです。

それは、このバグによって「何が問題になるか？」、「業務のどこに支障をきたすか？」、「システム全体に、どんな問題が潜んでいることが分かったか？」といったことなのです。

優先順位としては、
【1．お客様の取引先に迷惑が掛からない】
【2．お客様自身の業務に支障をきたさない】
【3. 問題が起こった原因を探る】
【4．問題をつぶす】
といった順になるはずです。

ところが、この優先順位の1、2を全く無視して、（お客様の視点で、物事を考えたことがないからだと思うのですが）問題の原因を探りたい、プログラムを直したい、という気持ちだけが先走るのが、技術者の悪習なのです。

原因を追究することよりも先に、これ以上の被害を出さないためには、どう運用を変えるのか？とか、最悪、システムを止めることさえも、技術者が、自ら提案すべきことなのです。

技術者は、何があっても、「システムを止めてください」と言わない、言えない人が多過ぎます。

バグが潜んでいるシステムを使い続けることは、お客様にとって、多大なストレスになります。

そういった意味でも、システム稼動後のバグ発見は辛い話です。
できれば、"バグゼロ"にしてシステム納品を行いたいものです。

しかし、人間が作っている以上、バグがあることは明らかであり、「予測できる失敗」なのです。
予測できることなのであれば、対処を考えておく必要があります。

対処を考える場合の優先順序こそ、お客様の視点で考えることが必要なのです。

何か問題があったときまず、お詫びする。

そして、お客様の視点で、「どうすべきか。どう動くべきか。どうアドバイスするか」を考えるのです。

若手エンジニアと、仕事のポイントについて話す機会がよくあるのですが、「顧客が言ったものを、そのまま作ってはいけない」とアドバイスすることが何度もあります。

若手エンジニアの特徴として、何でも顧客に聞いてしまうということが挙げられるでしょう。
一つ一つ聞いて、一つ一つの答えを貰ったら、その通りに作ればよい、と考えてしまう人が多いのです。

設計をチェックしていて、まずい部分をみつけ、「どうしてこう作ったの？」と質問すると、「お客様がそう言われました」と頑として退かない技術者もいます。

つまり、自分の頭で考えた結果ではない、プロとしてそれが良い設計なのか悪い設計なのか、必要なのか不必要なのか、といったことを考えないで、顧客が言った通りに設計した、というわけなのです。

ここには非常に大きな問題が潜んでいます。

それは、「顧客がどんなシステムが欲しいのかを、本当に分かっているか？」ということです。

技術者の質問に対して、顧客が答えるといったやり方では、本来の顧客の日常の全貌を、技術者が理解しないで作ることもあるのです。

また、一つ一つの答えを結びつけてつくったシステムでは、組み合わせに問題があることに気づかずに、運用がうまくいかないこともあるのです。

顧客が考えているのは、「相手は、なんといってもプロだ。分かってくれて、うまく作ってくれるだろう」
ということなのです。

ここを開発側がどれだけ分かっているかが、ポイントとなるのです。

顧客にOKを貰っていようとも、ドキュメントを確認して印を貰っていようとも、実は、本当のところ、どんなシステムが出来上がるのかは、顧客が分かっていないことが多いというのも、事実なのです。

顧客が望むシステムをイメージできていないとしたら、プロである貴方はどうでしょうか？

実は、貴方は顧客よりも、もっと、実現したシステムのイメージが無いのではないでしょうか？

だから、一つ一つ細かなことを全部顧客から聞かなければ、設計できなかったのではないでしょうか。

では、プロとして、SEとして、何を聞き出したらシステムをイメージできるのでしょうか？

何だと思いますか？

それは、顧客の業務内容、日常の顧客の行動パターンや思考パターン、課題・問題を含めた、日常の些細なこと全てです。

それらについて知っていなければ、システムをイメージできないでしょう。

システムを作るということだけを目的に、一つ一つを顧客に質問し、顧客に選択してもらって設計するという作業が、どんなに怖い作業かおわかりでしょうか？

貴方は、顧客の何を知っているのか？

システム設計者に求められる最終的な責任は、そこだと思うのです。

当社も2009年度の新卒採用のページを公開しました。
2007年11月なのに、再来年の4月の入社を考えなくてはいけないのですから、システム開発の長さどころではありません。

学生さんには、プログラマと言っても、システムエンジニアと言っても、職種名ではピンとこない人が多いものです。
これは、特に当社が理系、文系問わずに募集しているせいかもしれませんが。

プログラマを2、3年やった後、システムエンジニアになる。

私が二十数年前に、この業界に就職してから、ずっと続いている育成方法です。

実際のところ、プログラマの「ものの考え方」、つまり、「視点の域」、「とことん細かく例外を考えること」
といった感性を理解できることが、SEとしては、かなり重要だと思っています。
プログラミング技術ではなくて、プログラマの感性を理解してほしいと思っています。

さて、これから数回に掛けて、システムエンジニアを目指しているプログラマ、そして、SEの若手に向けて、基本中の基本の考え方について紹介したいと思います。

今回は、その1「日時」についてです。

最近のシステム開発は、分析系システムであったり、ECサイト系の開発が多いのでしょうから、日時というのは、常に、リアルタイムの年月日、時刻を意味することが多いのでしょう。

そんなシステムばかり組んでしまうと、会計システムや販売管理システムといった、基幹業務の年月日についての感性が、育たなくなってしまうことが少し心配です。

そこで、知識だけでも、「日時」について考えてみたいと思います。
本当に初心者向けの当たり前のことばかりですので、キャリアが3、4年以上ある方は、読み飛ばしてください。

●日時には、今、そのとき、その瞬間という意味と、過去のある日時を意味する場合がある。

例えば、Aイベントホールの座席表を考えてみましょう。
予約受付システムを請け負った貴方が考える予約済の座席数、これは、お客様や担当者が画面照会したその瞬間、つまり、今現在です。

1秒後には数が違う可能性があります。

一方、あるイベントは、11月15日受付分までを
先行予約分として、チケット料を10パーセント値引きすると宣言していた場合はどうでしょうか。

この場合、予約済数が分かるだけでなく、値引き販売数もシステムで把握する必要があります。
例えば、11月26日昼13時現在の予約済数が623名で、11月15日までの受付分は、324名であるという、過去のある時点までの集計値をとっておく必要があるわけです。

もちろん、ハードやデータベースの性能が十分にある場合は、集計値をデータベースに項目として持つ必要はなく、クエリで、日付範囲指定で集計すれば大丈夫ということもあるでしょう。

しかし、次の場合はどうでしょうか。

B社では経営会議が毎月開かれています。
営業の月間成績表は、翌月3日には集計され、その表を基に5日に経営会議が行われます。

項目として、月間受注金額、（半期）累計受注金額、受注残金額が載っています。

Cさんの10月の営業成績は、【月間受注金額1,600万円】・【（半期）累計受注金額1,600万円(10月は半期の初めの月です）】・【受注残金額 4,300万円】であったとします。

11月は、【11月30日までの新規受注金額700万円】・【受注から売上になった金額2,300万円】ありました。

ところが、10月に受注した案件でトラブルがあり【400万円が受注取り消し】となってしまいました。

しかし、【12月2日付け新規受注金額3,200万円】取ることができました。

さてCさんの12月3日に出した営業成績表はどうなるでしょうか。

答え→【月間受注金額300万円 (700-400)】・【（半期）累計受注金額1,900万円】・【受注残金額2,300万円】

ここで注意すべき点は2つ。

11月の帳票でも、10月の訂正分は、マイナスされるということ。
受注残金額といった、一瞬の残を表示するようなものも固定月報に印刷する場合は、11月末日を締として、翌月分の日付の伝票は集計しないということです。

特に、経営会議で検討するような表には、リアルタイム性よりも、月間、月間で積み上げた場合に
正しい合計となるものが求められます。

もちろん、ここで集計のキーとなる日付は、入力年月日ではなくて、伝票年月日（受注伝票であれば、受注年月日）です。

こういった、「伝票」としての業務の集計方法を覚えておきましょう。

そして、これらの数値は、何ヶ月後に見ても、常に同じ値が表示、集計されることが、
ほとんどの場合必要となるのです。