エンジニアtype - エンジニアのシゴト人生を考えるWebマガジン

[連載:高橋信也③] 原発問題で重要度UPのリスク対応には、「技術の分かる副官」が欠かせない

公開

 
PMOの達人・高橋信也のプロジェクト最前線
先読み(6)高橋氏_100px.jpg

株式会社マネジメントソリューションズ  代表取締役/CEO
高橋信也

外資系コンサルティングファーム2社を経て、大手メーカー系システム会社へ転職。PMとしてグローバル案件などを手掛けた後、2005年に各種プロジェクトマネジメント支援を行うマネジメントソリューションズを設立。著書に『PMO導入フレームワーク』(生産性出版/税込2310円)がある

今回の震災以降、さかんに議論されるようになったリスクマネジメント。とりわけ、原子力発電所の事故を巡っては、「想定外」という言葉が頻繁に話題に上っています。

高橋氏画像(5).jpg

From midorisyu

震災後に起こった福島第一原発問題で、リスクマネジメントに対する世間の関心は一気に増した

ただ、この問題を開発者目線でとらえるなら、本当はあらゆるリスクを事前に想定できていたはずだとわたしは見ています。

門外漢であるわたしは今回の事故を深く言及する立場にありませんが、原発問題の本質は「リスクは想定できていたものの、対応策を万全には取っていなかった点」にあった。そう思っています。

その理由はなぜか。まず考えられるのは、どの分野のエンジニアリングにもありがちな落とし穴です。とかく開発者というのは、優秀で腕に自信がある人ほど、「自分が作ったものは安心だ」、「何か問題が起きても自分が解決できる」となりがちだからです。重要度や規模は異なるものの、あらゆるシステム開発プロジェクトでも、これと同じリスクは常に存在しています。

もう一つはコストパフォーマンスの問題。世の中、リスクが100%なくなることはあり得ないという観点で考えれば、開発を発注する側は「すべてのリスクに万全な備えをしていたらコストがかさみ過ぎる」と考えるのが当然です。原発のように人命にかかわるものと、企業システムとを同等に扱うべきでないのは重々理解していますが、リスク対応を突き詰めていくと、結局はどれもコストパフォーマンスとの兼ね合いに突き当たります。

そこで大切になるのが、作る側、発注する側共に、リスクの発生確率を論理的に分析する知識や、どれだけの危険をはらんでいるのかを察する感度を持ち合わせること。例えば企業が自社サーバの運用を考えるとき、100万のアクセスが集中したときにトラブルが発生する確率と、1000万アクセスのときの確率とは当然違います。同時に、100万アクセスに耐えれば良いシステムと、1000万アクセスに耐え得るシステムとでは、かけるべき開発コストも異なってきます。

後者のシステムを採用したのに、結局アクセス数は常に100万以下だったということになれば、過剰な投資をしたことになりますし、前者のシステムを採用した後、大幅なアクセス増でサーバが止まってしまえば、リスクを軽視した判断ミスを責められる。意志決定者はこれらの想定を基に、多方面の専門家に意見を聞き、かつコストパフォーマンスを意識しながら、対応しておくべきリスクを決めるのです。

言い換えれば、「これ以上のリスクマネジメントは不要」という線をどこで引くかが非常に重要、ということ。この線引きには、開発に携わるエンジニアも十分コミットしなければなりません。

多くのプロジェクトが、非論理的な理由で対応をおろそかに

わたしも新卒のころ、システム開発の最前線でプログラミングをしていたときは、「今回のこのリスクには対応をしておくべきなのでは……」と思うことがままありました。似たような経験は、エンジニアなら誰でも持っているはずです。

では、こういったシチュエーションで、現場のエンジニアはどんなコミュニケーションをとっていくのが理想なのか。プロジェクトマネジャー(以下、PM)が慎重派タイプなら、すぐ対応しようと話がまとまるかもしれません。ただし、プロジェクトの納期や予算は決まっており、PMには「今から対応したら納期に間に合わないかもしれない」という不安もつきまといます。

高橋氏画像(6).jpg

リスク対策の敵はチームの雰囲気。守りの仕事が続くとメンバーのモチベーションも下がってしまう

それに、もしもの場合に備えた守りの作業は、メンバーのモチベーションを下げてしまう危険性もあります。エンジニアという人種は、前向きでクリエーティブな仕事を好む生き物ですからね。そんな中で決断を下すのは、なかなか難しいものです。

一方で、とにかく納期に向かってムチを入れるようなPMだった場合はどうか。開発自体は滞りなく進むかもしれませんが、各現場で不安視されるリスクはどんどん黙殺され、「このリスクには備えておいた方が……」と提案しても「後ろ向きなことばかり言うな」と一喝されてしまうかもしれません。

そんなこんなでリスク対応が玉虫色のまま進んでいくプロジェクトが、実のところ非常に多いのです。しかも、PMの性格やチーム内の和といった非論理的な部分が重視されて。これでは、いざ何かが起きたとき、ユーザーに問題発生の理由や善後策をきちんと説明できるはずがありません。

PMに近い立場にいる上級SEやプロジェクトリーダーは、このバランスの取り方に細心の注意を払わなければなりません。ならどうすればいいか。わたしの考える解決策は、開発現場とPM、開発側とユーザーのちょうど中間にいるSEが、率先して「和」を乱すコミュニケーターになっていくことです。

「もう一つのリーダーシップ」を、自ら志願して身に付けよ

具体的に何をすべきかを説明すると、現場で想定されるリスクがあったら、その都度アラームを鳴らすように動きつつ、「なぜアラームを鳴らしているのか」を周囲にも理解してもらえるよう論理的に説明し続けます。

こうして、プロジェクト内部に理解者を増やしながら、どんなリスクがあるのかを皆に承知徹底していくのです。これをマネジメントの専門用語では、「サーバント・リーダーシップ=下手に出るリーダーシップ」と呼びます。

リスク感度の共有が進んでいるチームというのは、チーム力そのものが強くなります。何かあったとき、逐一PMやリーダーに相談をしなくても、皆が自律的に動けるからです。このリスク感度と目的の共有を一人で実現できてしまう、素晴らしいリーダーも中にはいますが、そんなスーパーな人は希有ですから、間に入って動くコミュニケーターの存在が必要不可欠なのです。

プロジェクトを任されているPMは、目的、つまりビジョンを示して一気に突き進むようなポジティブなリーダーシップを発揮する。その傍らには、常に皆に注意を喚起するような発言をする副官的人物が存在する。このグッドバランスを生み出す副官こそ、SEが目指すべきコミュニケーターといえるでしょう。

副官は、時に嫌われ役を買って出なければならないこともありますから、損な役回りのように思うでしょう。が、いわばクラスの学級委員のように、「クラス一の人気者ではないけど彼がいると場が締まる」存在がいてこそ、リスクは未然に回避されるのです。

それに、誰もやりたがらない役回りだからこそ、キャリア面でも自分を成長させるチャンスが容易に手に入る。時流を考えれば、リスクマネジメントのスキルは今後いっそう重要性を増していくでしょうから、皆を前に向かってけん引するリーダーシップとは少し色合いの違う「もう一つのリーダーシップ」を身に付ける、格好の機会と思ってチャレンジしてみてはどうでしょうか。

撮影/外川 孝(人物のみ)