Edited at

【要約】日経SYSTEMS 2019/7号


1. はじめに

以下雑誌の要約。


  • 題名:日経SYSTEMS 2019/7号


2. ITエンジニア再考 ~「フルスタック」は非現実的 得意スキルをもう1つ加える~


2-1. フルスタックエンジニアとは


  • 数年前からネット企業を中心にフルスタックエンジニアが必要と言われてきた。

  • フルスタックエンジニアの定義は厳密には決まっていない。「ハードウェアからアプリケーションまでの知識を持っている」「サーバーサイドからフロントエンドまで手掛けられる」「サービスの企画から実装までを1人でやってのける」など様々。
    幅広い知識とスキルを備えているエンジニアを指す。


2-2. 価値を高めやすいのは複数スキル


  • スペシャリストの道を極めるか、フルスタックエンジニアを目指すかはその人次第。しかし、現状では新しい技術をいち早く取得し、柔軟に組み合わせられるエンジニアの価値が高まってきている

  • 海外人材を含め、単一のスキルが優秀なエンジニアは多くいる。ただし、1つの領域で評価されるようになるのは、かなりハードルが高い。複数の得意スキルを掛け合わせたほうが価値を高めやすい

  • 「今の職場では役割が限られている」「忙しくて新たなスキルを身に付けられない」と嘆くエンジニアもいる。「フルスタック」と言うと、習得すべき技術領域が広すぎるので、目指すのは簡単ではない。とはいえ、1つのスキルだけで価値を発揮できる時代は終わりつつある。

  • まずは今の環境に照らし合わせ、自分の価値を高められるスキルは何かを特定し、現状のスキルにもう1つの得意スキルを加えることから始めよう。


3. 炎上するプロジェクト そのときどうする? ~ユーザーとの対話に問題~


3-1. ストーリー

◆登場人物

・プロジェクトリーダー → 出木杉
・エンジニア → 野比
・顧客 → 骨川

骨川「仕様としては、〇〇の場合はどうなるんですかね?」
野比「・・・」
出木杉「(またフリーズだ。野比さん、見当違いでもいいから、何か言って。黙り込むのだけはやめて。)」
骨川「現在の仕様がどうなっているのか、確認したいだけなんですよ。仕様を変更したいという話ではありません。」
野比「・・・」
出木杉「(チッ) 〇〇の場合、××できます。その前に△△が必要です。野比さん、合ってるよね?」
野比「えーと、あー、多分そうです。」
出木杉「念のために仕様を確認しておいてね。一方、□□の場合は、☆☆になります。そうだよね?」
野比「(コクリ)」
骨川「出木杉さんに会議に出ていただけると本当に助かります。次回も出席いただけるんですよね?」

野比は開発に関することは詳しかったが、業務の観点からシステムをどう使うのかというイメージが
うまくつかめないらしい。だから、簡単な質問にも立ち往生することになってしまった。
分からなければ分からないと答えるなり、詳細な説明を求めるなり、いくらでも応じようがあると
出木杉には思えるのだが、生真面目な野比には、それも難しいらしい。圧力をかわせずにフリーズしてしまうのだ。


3-2. トラブルの要因


  • システム開発の上流工程では、技術力や業務知識以上に、混沌の中で議論をリードし、合意を形成していくコミュニケーション力が必要である。そのためには、相手の用語を使って、相手の立場に合わせて説明する必要もあるし、時には対立をさばいて結論に落とし込む交渉力も発揮しなければならない。

  • プロジェクトチームのメンバーは多種多様で、合意形成に向けたコミュニケーションが得意なメンバーだけではない。そもそもコミュニケーションスキルは、技術力や業務経験に比べると定義が難しい。

  • 特に協力会社のメンバーの場合、アサインは受託者の権限である。そのため、要件定義などが始まってから、役割やスキルのミスマッチが見つかることは少なくない。


3-3. 鎮火法


3-3-1. スキルを見極める


  • 冷静にメンバーのスキルを見極める。何が足りないのか、それは補完できるものなのかどうかを評価する。本人と面談したり、他のメンバーの意見も聞く。仮に知識不足が阻害要因なら補うことができる。

  • 会議で合意を形成するという目的や使命感のようなものが不足しているのだとしたら、短期に補うことは難しい。使命感はあっても、結論を出せるように対話を組み立てる能力が不足している場合、特に評価が難しくなる。


3-3-2. 補完策を検討する


  • スキルを評価できたら、補完策を検討する。最も分かりやすい対策は、メンバー交代である。

  • 協力会社の場合、メンバーの配置は受託会社の専管事項のため、直接交代を求めたり、交代メンバーを指名したりすることはできない。しかし、スキル未達であることを先方が納得すれば、メンバー交代も含めて対策を検討してもらえるはずである。

  • メンバーの交代には至らなくても、当面の間は支援メンバーに入ってもらうなど、他のプロジェクトメンバーが一部の役割を代替するなどの暫定対策も考えられる。場合によっては、骨川さんが求めているように、ファシリテーターとして当面PLが会議に出るというのも考えられる


3-3-3. 対策を顧客と共有する


  • 対策を顧客と共有することも有効である。メンバーのスキルの問題については、「受託側の責任で解決することであって、お客様を煩わせるべきではない」という考え方があって、それはそれで筋が通っている。しかし、現に問題や支障が発生していて、顧客もそれを知っているなら、むしろオープンに話すべきと考えられる。

  • 顧客が「これで大丈夫だろうか」と不安に思っているとしたら、対策を伏せるのは得策ではない。「現在こういう対策を考えているがどうだろうか」とか「業務知識習得に努めさせているので、効果が出るまでお待ち願いたい」といった相談や連絡があった方が安心してもらえる。何か問題があったときは、顧客の側からも相談しやすくなる。


3-3-4. 結果をトレースする


  • 対策を講じたら、有効に機能したかどうかを必ずトレースする。顧客の担当者など当事者の感触をヒアリングするのもよい。場の雰囲気が進行や成果を左右することがあるので、出席者の感触は重要である。


3-4. 発生防止策


3-4-1. 役割分担を定義する


  • 会議を計画するときに、その場での役割分担を定義して、出席者相互で確認しておく。メインの説明を誰がするのか、ユーザーからの質問に応じて誰が答えるのか、記録は誰が取るのか、異論や不満が出たら誰がさばくのか、いったん持ち帰ることにするのか、のように、発生しそうな事態を想定して切り回し方を検討しておくことがポイント。


3-4-2. シミュレーションなどで事前評価しておく


  • 会議に先立って、シミュレーションを実施して、評価・改善のサイクルを回すことも有効。第三者の目を入れると、進め方の問題点や説明の仕方の癖など、自分では気づかない点についてアドバイスをもらえることがある。


3-5. マインドマップ