自分戦略研究所 | 自分戦略研究室 | キャリア実現研究室 | スキル創造研究室 | コミュニティ活動支援室 | エンジニアライフ | ITトレメ | 転職サーチ | 派遣Plus |

第56回　エンジニアはデンジャラス。危機管理術を装備せよ

Tech総研
2008/1/29

エンジニアの仕事には多くのリスクが潜んでいる。危機管理のスナイパーが、その心得を指南する。（Tech総研／リクルートの記事を再編集して掲載）

危機管理は重要って分かるけど……

Techスナイパー・井元康一郎 鹿児島県出身、年齢不詳。経済誌や自動車誌などで、自動車、宇宙、航空……などを中心に活躍する技術＆マニア系ジャーナリスト。技術をこよなく愛するがゆえTechスナイパーに。心優しき音楽家という別の顔も持つ。

　「ロールアウト直前に設計ミスが見つかって対処できない！」「自分が身に付けてきたスキルがオールド化して役に立たなくなった！」「開発に追われているうちに彼女にフラれた！」。――世の中のありとあらゆることには、さまざまなリスクが存在する。何も企業経営や政治・外交戦略といったマクロ的なものだけではない。エンジニアの日常においても、身の回りはリスクだらけといっていい。リスクを想定し、それに対する備えをしておかないと、危機に見舞われたときに泣きながら右往左往するハメに……。果たしてエンジニアはどのようなリスクマネジメントを実行しているのか。これまでの人生において無数のトラブルに見舞われ、リスクコントロール、リスクマネジメントの必要性をイヤというほど痛感させられてきたTechスナイパーが、エンジニアのリスクマネジメントの実態にロックオン！

危機管理をして、楽しく明るい2008年にしよう

　仕事、プライベートともにさまざまなリスクに囲まれているエンジニア。当然いらぬ苦労や身の破滅を招きたくはないとあって、多くがそれなりにリスクコントロールを行っている。「プログラムなど常に見ていないと忘れたりするので、スキルを保つために、家でもスキルアップを図る」「常にメモを取って、コピー、pdfファイルなどで証拠を残す」「社内キーマンと考えられる人とは日常から情報交換をし、アクシデントに見舞われたときに助けを得られる体制を取っている」「常に周りに情報を発信し、間違った方向に進んでいないことを確認しながら仕事を進める」……。

　が、それでもリスクのもたらす厄災に見舞われてしまうのが人生というもの。果たしてリスクの影響を最小限にとどめ、いいエンジニアライフを送るためにはどうしたらいいのだろうか。リスクコントロールの極意を、リスクコンサルタントの草分けといわれる牛場靖彦氏に聞いた。

■知識ではなく知恵、教養でリスクに立ち向かうべし

どんな道にもリスクはある

　何となく平和に日常を過ごしている私たちだが、一寸先は闇。いつどのようなリスクに見舞われるか、分かったものではない。果たして、どのようにリスクマネジメントを行えばより良い人生が手に入るのだろうか。

　リスクコンサルタントの草分け的存在として知られる牛場氏は、意外なことに、リスクを恐れるべきではないと語る。

牛場靖彦氏 1960年慶應義塾大学卒業後、三菱商事に入社。1988年独立し、牛島事務所を設立して現在に至る。ヘルスケアアドバイザー、ノンフィクション作家、エッセイスト、モデル、大相撲解説者、映画・ミュージカルプレイ・モダンジャズ解説者など多数の肩書を持つ。本業であるリスクマネジメントについては、レオナルド・ダ・ヴィンチ風に「少々たしなむ程度」という。

　「ビジネスパーソンの人生にはおおむね3つの道があります。第1はいまいる会社に定年まで居続け、そこで功績を挙げて出世するという道、第2は自分にとってより良い道を探すため、転職や社内でのジョブチェンジを模索する道、第3は独立して一国一城の主となる道です。そのいずれにもリスクはある。安全な道などないんですよ」（牛場氏）

　安定志向で、いまいる会社に定年まで勤めようとしても、途中で業績が悪くなったり倒産したりするかもしれない。転職したらしたで、新しい職場が肌に合わなかったりイジメに遭ったりする可能性がある。独立して成功すれば利益はすべて自分のものだが、失敗すれば借金の山だ。

　「それらのリスクをどう最小化するかですが、その判断の決め手となるのは教養、知恵なんです。これはとても重要なことですが、知識と知恵は違います。いまはインターネットが発達していることもあって、知識なんか誰でもいくらでも手に入る。でも、そんなものは本当の意味では役に立たない。自分でいろいろと試して失敗して痛い目に遭って、そこからはい上がって初めて知識が知恵になる。知識を実際の生活やビジネスに応用できる知恵を持ち、その知恵の蓄積である教養を持つこと。これがリスクマネジメントには大切なんです」（牛場氏）

ゾンビになるな。アライブになれ！

　牛場氏は昔から、ビジネスパーソンを2つのタイプに区分けしている。さもしく、活気がなく、いつも利己的に振る舞うことしか考えない「ZOMBIE（ゾンビ）族」と、自分はもちろん世の中にとってもプラスになるような夢を持つ“利他的利己主義”者「ALIVE（アライブ）族」である。

アライブ族であるための姿勢

Active （現実的な）	長期的視野に立って現在を処する 予見性・洞察力に優れ、潜在的リスクに的確に対応すべく努める
Large （度量の広い）	他人の立場を尊敬し、思いやりがある 固定観念や既成観念にとらわれず、自由でのびのびとした発想をする
Intelligent （知的な）	生きていくうえでも仕事のうえでも知恵があり、知識に振り回されない さらに知恵を見識や胆識にまで高めることができる
Vivid （活力ある）	心身そろって健康であり、絶えず考えたことを積極的に実行に移す 現実に正々堂々と直面し、いい訳をしたり、逃げを打ったりしない
Essential （本質的な）	物事の体質をしっかりとらえている 枝葉もできるだけ丁寧に見るが、根幹を把握し「木を見て森をも見る」ことができる

ゾンビ族の特徴

Zany （ごますり）	上にペコペコ下に鬼 言動が八方美人的
Ostentatious （見せびらかし）	タテマエ論のキレイ事をいう 何かをしているフリをする
Monocular （単眼思考）	前例にとらわれる 応用動作が利かない
Blowzy （さもしい）	社内遊泳術に明け暮れる ポストをめぐってヤミ取引
Intriguing （策略を用いる）	がんじがらめの人間関係 利権に狂奔
Emotional （感情的）	メリットを追求しすぎ、デメリットには目をつぶる 他人を色メガネで見る

　「会社にいると、それこそゾンビみたいな上司や同僚がたくさんいる。これは会社や自分がもうかりさえすれば、あとはどうでもいいという人たち。ゾンビにも階級があり、最上位には意図的に利己主義で人をたぶらかすゾンビマスターがいて、その手下に悪知恵をはたらかせるゾンビゼネラル（参謀）がいる。その下で夢を持たずにに『おれの人生はこの程度なんだ』とあきらめてしまうと、その人もゾンビになってしまう。それではダメ。ゾンビに立ち向かう、他人のために良く自分にはさらに良くという“利他的利己主義”で行動できるアライブ族を目指すべきです」（牛場氏）

　人生における最大のリスクは、何のために生きたのか分からないような過ごし方をして、そのことを後悔しながら虚無的に死ぬこと。転職・独立をする、しないにかかわらず、生き生きと人生を過ごすためには、利他的利己主義を実現させ、アライブ族になれと牛場氏はいうのである。

　「みんな、本当は生き生きと生きたいはずです。そうするためには、先にも述べたように、知恵、教養を身に付ける努力をすべきです。腕力では1人かせいぜい数人を相手にすることしかできないが、知恵をもってすれば1000人にだって勝てる。会社や上司は別に神様じゃないんだから、みだりに尊敬をしてはダメ。自分はどう生きるかというスタンスをきちんと決めて、より良く生きることを目指してほしいですね」（牛場氏）

エンジニア、危機管理の実態

　牛場氏が語った社会人としてのリスクに加え、開発業務、上司・部下や同僚との人間関係、キャリアアップなど、エンジニアの身の回りには多様なリスクがひしめいている。エンジニアは実際問題として、どのようなリスクを負い、どのような対処を行っているのだろうか。Tech総研は読者アンケートを実施し、リスクのパターンや対処法の実態を探った。

仕事編1

人間関係の危機管理

仕事上の人間関係の危機に 遭遇したことがありますか？

　職場の人間関係についてのトラブルで圧倒的多数を占めるのは、やはり上司・部下の関係。上司の無理解に憤る若手も多いが、部下のいいかげんな仕事ぶりに悩まされている上司もそれに負けないくらい多い。エンジニア人生において、人間関係のリスクマネジメントは極めて重要だ。

　人間関係をつかさどるのは、基本的に相互理解だ。この手のトラブルの背景をよく調べてみると、若手が大した実績でもないのに自信過剰になっていたり、ベテランがやたらと上司風を吹かせ、若手のやる気をそいだり、不要な摩擦を生んでしまったりしている。

　どんなにイヤミな上司でも、あるいは生意気な部下でも、普段から相手を尊重する姿勢を見せていれば、いざというときにあしざまにいわれることはない。人間関係がちょっとね……と思っている人は、普段から相手とよく話をするようにしてみるのも手だ。人間関係が円滑になれば、職場の雰囲気も180度違って見えることウケアイである。

エンジニアたちが証言！ 「仕事上の人間関係の危機を私はコレで解決しました」

リスク1●報告の遅れには気を付けるべし	リスク2●部下にウソをつかれた
★こんな危機 ちゃんと報告しているのに、ちょっとした手違いで1点報告が少し遅れただけで、課長は激怒。顧客と合意ずみのプロジェクトの進行を妨げられた。 ★コレで解決 話の分かるさらに上の役職の上司に相談して、課長の顔を立てながら、うまく事を収めてもらった。 （回路・システム設計、36歳） Sniper's eye すべてを仕切りたがる上司は意外に多いもの。性格を読んで普段から十分ケアしておくべし。	★こんな危機 開発についてウソの進ちょく報告を部下から受け、それを信じた結果スケジュールに狂いが生じ、クレームも発生した。 ★コレで解決 回避策として、その後は必ず自分の目で結果（記録）を確認するようにした。 （Web開発、41歳） Sniper's eye 同種の回答はほかにもいくつも見られた。部下が報告しやすいような人間関係をつくるのも上司の務めかも。
リスク3●愚痴をこぼす上司に悩まされた	リスク4●神経質な上司の命令に要注意
★こんな危機 毎日のようにどうでもいいことでネチネチと愚痴る上司。そのせいで時間は止まり、リカバリする時間もなく、毎回、開発が遅れる。 ★コレで解決 あまりに度が過ぎていたので、社内のポータルサイトに自分の名前とその人物の名前を書いて糾弾した。 （社内システム開発、32歳） Sniper's eye 糾弾で一応愚痴は止まったようだが、後のことを考えるとなるべく穏便な手段で対処しよう。	★こんな危機 同じ部署の女性の先輩は日々あれこれとやたら命令する。初めは我慢していたが、4カ月もたつと精神的に参り、軽いうつ病のようになってしまった。 ★コレで解決 さらに年上の上司に相談し、その女性と一緒に仕事をしないですむように、自分の仕事のテーマを変えてもらった。 （素材、29歳） Sniper's eye 異性の上司・部下とは思わぬところであつれきが生じることも。周囲への速やかな相談が幸運の鍵。

仕事編2	プロジェクトの危機管理

プロジェクトにおいて回避できないような危機に遭遇したことがありますか？

　開発プロジェクトにおいて、最初に想定したモノが何のトラブルもなくロールアウトされるというのは理想だが、現実は仕様や開発スケジュールなど、多くの点について変更に次ぐ変更のオンパレードだったりする。変更は開発者にとって、まさしくリスクの火種だ。アンケートを見ても、ソフトウェア、ハードウェアともに、仕様変更がもとでプロジェクト全体に影響が及んだというケースが目立つ。

　リスクマネジメントの観点からは、開発前にあらかじめどういう事態が想定されるかというシミュレーションを行うとともに、途中での仕様変更をどれだけ受け入れやすくするかという、柔軟性のある開発体制を工夫することが求められよう。また、ニーズと合わない開発になっていることが自覚されながらなかなか修正できないケースも案外目立つ。これについても対策が求められよう。

エンジニアたちが証言！ 「プロジェクトにおける危機を私はコレで解決しました」

リスク1●慣れは危険！ “思い込み”が死を招く	リスク2●商品トレンドの読み違いがトラブルに
★こんな危機 製品と同じような機能だと思い込み、要求も仕様書も確認せず製品を開発した。できた製品はまったくうまく動かなかった。 ★コレで解決 最初の仕様打ち合わせからやり直して納品。すでに納品していたものはすべて回収して、自分で営業して販売した。 （サービスエンジニア、40歳） Sniper's eye 現場視察はモノづくりの基本だが、慣れだけでは相手のニーズをくみ取れない。担当者との直接対話を。	★こんな危機 開発段階では旧型仕様のユーザーが多く、旧型で開発を進めていたが、市場での新型仕様の浸透が想像以上に速く、ニーズに合わなくなった。 ★コレで解決 開発途中で方向性を迅速に変えることができず、結局開発が完了した後に、急きょ仕様を変更した。 （機械・機構設計、41歳） Sniper's eye 市場ニーズと製品開発の乖離（かいり）は珍しくない。臨機応変な開発のための方法論を持っているかどうかが分かれ目に。
リスク3●仕様変更もほどほどにと顧客を説得	リスク4●派遣社員のスキル不足に注意すべし
★こんな危機 クライアントからの矢継ぎ早の仕様変更で、内部設計と表面の設計に齟齬（そご）が発生。どんどん性能が落ちていった。 ★コレで解決 ニーズの把握や仕様の変更について、営業任せにしていたのがよくなかった。最後は上級SEが客先に直接出向いて説明し、相手も納得して解決した。 （Web・オープン系システム開発、35歳） Sniper's eye システム開発では仕様変更は日常茶飯事だが、技術的に限度があるという認識を顧客に共有してもらおう。	★こんな危機 外部から派遣されてきた開発スタッフが、経歴詐称とまではいえないもののスキル不足で予定していた開発が大幅に遅れた。 ★コレで解決 あらかじめ状況ヒアリングの回数を増やすなどして、管理を注意深く行った。それでもまかないきれない部分は、開発期間を延期してカバーした。 （オープン系システム開発、35歳） Sniper's eye スケジュールを左右する協力会社の情報収集は大事。日ごろから社内で共有する仕組みをつくるなどしよう。

現場のプロジェクトに集中していたら、いつの間にか会社が倒産！