読者です 読者をやめる 読者になる 読者になる

エンジニアには会議に出席するのではなくコミュニケーションスキルを発揮することを期待されている

on

PMBOKの第6版は、もうそろそろ出るはずではなどと思いつつ、久しぶりにPMBOKを開いてざっと眺めていたらプロジェクト・コミュニケーション・マネジメントの章でこんなこと書いてあったんだ、と今更ながら驚いてみたりするのです。

PMBOKPMPを取るバージョンはしっかり読むけれど、取ってしまった後はそれほど見ようとは思わないから。
#まあ、今回はたまたまパラパラとPDFでページ送りしたわけですが

プロジェクト・コミュニケーション・マネジメントの章立てで目に留まったのはこの部分です。

端的に言えば、プロジェクトの中でコミュニケーションをマネジメントするには、以下の11のスキルが必要であると要求しているのです。11のスキルを活用しないとプロジェクトの内外とのコミュニケーションが上手くいかない、ということです。

・積極的かつ効果的に傾聴すること
・確実に理解するためにアイデアや状況を質問し、正しく調べること
・チームがさらに効果的に活動できるように、チームの知識を増やすための教育を行うこと
・情報を特定し、または確定するために実態を調査すること
・期待を設定し、マネジメントすること
・行動を起こすように個人または組織を説得すること
・励まし、安心させるために動機づけること
・パフォーマンスを改善し、求める結果を達成するためにコーチングすること
・当事者が相互に受入れできる合意に達するように交渉すること
・深刻な影響が生じないように、コンフリクトを解消すること
・要件をまとめ、整理し直し、次の手順を特定すること
 ※プロジェクト・コミュニケーション・マネジメントの概観図は略
引用 PMBOK 5th

11のスキルを眺めると、プロジェクトチームのマネジメント、つまり、プロジェクトマネージャが発揮するスキル群(黒色)とプロジェクトメンバがアクティビティを実行する際に発揮しなければならないスキル(水色)と分けられます。

期待を設定し、マネジメントすること」についてはマネジメントとキーワードが入っていますが、メンバ自身のアクティビティで得たい成果があり、他者に働きかける場合

はメンバ自身が期待する結果を得られるようにコントロールしなければなりません。

 

実際にコミュニケーションを行う場合、総合に意思伝達をすることが目的ですから、双方の間で交換されるのは情報です。

その情報を中心にコミュニケーションを駆動するために識別する必要がある事項が次の7項目なのだな、と理解することができます。

・誰が、どの情報を必要としているか、また、その情報へのアクセス権限が与えられているのは誰か
・いつ情報が必要となるか
・どこに情報を保存すべきか
・どの形式で情報を保存すべきか
・どのように情報を検索するか
タイムゾーン、言語の障壁、および文化の相違に配慮する必要があるかどうか
引用 PMBOK 5th

最終的には、会議体としてプロジェクト・コミュニケーション・マネジメントとして整理されるのですが。

この会議体に行き着くまでにも次のことを考慮しなければならないのです。

・内部(プロジェクト内)と外部(顧客、供給業者、その他のプロジェクト、組織、一般の人々)
・公式(報告書、議事録、概要説明)と非公式(電子メール、メモ、その場限りの話し合い)
・縦方向(組織内の上下関係)と横関係(オフレコのコミュニケーション)
・公認(ニュースレター、年次報告書)と非公認(オフレコのコミュニケーション)
・書面や口頭、および言語と非言語(ボデーランゲージ)
引用 PMBOK 5th

奥が深いですねぇ。プロジェクトマネジメントの計画書のテンプレートがある組織であっても、こうした背景の説明はされずにいきなり会議体の設定になりますからね。

ましてや、プロジェクトマネジメントの計画書がない場合は、過去の経験知だけでしかも思い出せたものだけでしかセッティングされませんから。

会議体だけで眺めてしまうとプロジェクトのメンバは、ただ参加すればいいとか、ある会議で資料を作らないといけないと自分で分担する作業ばかりを考えてしまうけれど、本来は、そうした分担を成功裏に導くために自らのスキルを発揮することが必要であるとプロジェクトマネージャは働きかけなければならないのです。

 

アウトカムで目標を設定するという新しい考え方

on

通常、目標管理制度などでは年度の目標を立て、設定した納期を目指し、活動の成果をアウトプットすることで、期初の目標と期末のアウトプットを比較することで業績評価を行います。

端的に言えば、活動から生み出すアウトプットを評価しているわけです。こうした考え方は、業績に対する評価制度としては適当かなと思うのですが、キャリアプランにおいて同じように活動をとおしたスキルの伸長ではスキルが有形でない分、救えきれないなぁと思っていて、有形でないからこそ運用で対処するしか手段がないかと思っていたのでした。

アウトプットでの評価

ejje.weblio.jp

設定する目標に対し、活動を経てアウトプットで評価をすることは従来の目標管理制度の基本ですし、アウトプットで言い表わせる有形の生産物を評価すること自体はとてもわかりやすく、評価が合意しやすいです。

アウトプットで言い表わせるということは定量的であると表現できます。数量、時期、諸元など誰が見て比較しても同じ尺度で生産物を評価できる特性を持っているのです。

ところで、以前のエントリで目標管理制度では定量的な目標に少しだけ定性的な目標を入れておく方が評価者にとっても評価の幅を持たせられるので好ましいと述べていました。

この定性的な目標を新たな基準として持つことでより適切に運用できるようになります。

アウトカムでの評価

ejje.weblio.jp

ここでのアウトカムは

「活動によってもたらされる効果」

として捉えます。

効果とは「働きかけによってもたらされる望ましい結果」の意がありますから、目標設定により取り組む業務活動によって望ましい結果を得られていれば成果として評価できることになります。

dictionary.goo.ne.jp

望ましい結果がある以上、現場は望ましくない状況であり、望ましい結果とのギャップを捉えることができることになります。つまり、活動による効果測定ができるようになるということです。

こうしたアウトカムによる目標設定は、活動による効果を望ましい結果として捉える必要があり、定量的な目標よりは活動により影響を与える対象と影響を与える事象の仮説検証をする必要があり、よりレベルの高い目標と位置付けることができます。

ロジカルシンキングなどの仮説検証型のスキルの育成機会を設けたい、自ら創出したい場合は、アウトカムでの評価を前提とした目標設定をすると良いでしょう。

 

 

 

 

追求されない進捗報告

on

進捗報告の場で突っ込まれたり追求される原因はほとんどが報告するエンジニア側にあるのです。別にプロジェクトマネージャやマネージャの立場だからってそちら側の目線で、というわけではありませんよ。

こんな状況を見た経験はありませんか。進捗報告の場で報告するエンジニアがしどろもどろになっていたり、プロジェクトマネージャと空中戦をしている場面を。

そんなつまらないことに時間をかけてしまうのは嫌ですよね。

先が見えているなら突っ込まれない

進捗報告の目的は、プロジェクトの進捗上の障害の有無をプロジェクトマネージャが知り、必要な対策を打つ判断をすることです。

進捗する作業はメンバが担っているので進捗状況はメンバが行います。

ここまではよろしい?

PMはプロジェクト全体の進捗の先行きのあたりをつけたいと思っています。なぜなら、先に述べたとおりプロジェクトの進捗上の障害があれば回避するのか除去するのか策を打つ判断をするのがPMの仕事だからです。

ですから、進捗報告をする際に先まで見通しが立っているなら正直、PMとしては

「予定どおりやっってて」

とお任せして、他に進捗上の障害がないかを探したいのです。

進捗で何を伝えるか

では、進捗を報告する担当としては何を伝えれば良いのでしょうか。

今使っている進捗報告のフォーマットやチケット管理システムのビューを思い出して見ましょう。どんなプロジェクトでも、計画に対し実績で差異が生じる可能性があるから進捗報告で進捗上の障害を見つけようとしていることを忘れないでください。

進捗報告で伝えなければならないことを3つあげてください。さてさっと言えましたか。

・実績
・予定
・課題

至極当然で「それで」という感じですが、これがベテランでもきっちりと押さえて報告している人は多くないのです。

進捗をどう伝えるか

実績、予定、課題を伝える、報告するのは、まあそうだとしてどう伝えれば突っ込まれないか。忙しい最中だし、変に突っ込まれて宿題なんてもらいたくないですし。

立場を変えて、PMならどんな進捗報告だったら、スルーするかを考えてみましょう。

・予定した作業は予定どおりに着手したかな
・いつ終わるか見通しは立っているのか
・差異があるなら原因は何か
・誰かのサポートが必要なのか
・予定している作業は予定どおり着手できるのか
・予定と違うことがわかったりしていないかな

と、こんなことを考えているものです。そうだとすれば、これを満足する情報を流せばいいわけです。

上記のことをカバーするのが、

・開始数/開始予定数
・完了数/完了予定数

なのですよね。それで差分があるのが課題で共有されるのです。

・完了予定と実績に関する差異の原因の掌握状況
・予定している対処
・プロジェクトに対するリクエスト
・後続作業への影響
・想定していた前提との差異 

 この予定している対処の裏付けである、差分の状況把握は割と重きを置きます。現状把握ができていないということは対処までどれだけ時間がかかるか見積もりもできないという事態ですから。

差分が生じたら、この状況把握を一人でどこまでやるつもりかを意思表示し、合意していくのが良いです。さらに悪化するようだったら、その前に割り込みをしてでも情報を。共有することで信頼感を得られますし。

 

 ということで、

・開始数/開始予定数
・完了数/完了予定数

 で報告するとして、課題があればPMが知りたい要点を押さえて報告しましょう。これが進捗報告で突っ込まれないエコシステムを作る基本です。

 

シン・ゴジラで学ぶ一言でワンチームに変える方法

先週シン・ゴジラの円盤がリリースされましたね。うちにも、在宅時間指定をしたクロネコさんによって配達された円盤が無事届いていました。

早速その夜に家族に「観る?」と誘ってみたら子どもさんも観たいと特等席を陣取って早速視聴です。

まー、ワタシは近所の映画館や極爆で何度も観ているのですけどね。

巨災対はどのような組織か 

そもそもシン・ゴジラが蒲田くんとして上陸したり、品川くんとして上陸してきたりすること自体を考えたりしませんから、リスクマネジメントの範疇外なのですよね。

だから、想定外というか、予測不可能な事象な訳で。

ということから、巨災対は通常のオペレーションの組織ではありませんから、プロジェクトとして捉えることが適切となります。

ずっと東京に居座られても困りますし。

プロジェクトの目的

通常、プロジェクトではプロジェクトの目的を設定するものですが、ゴジラに対する対処方法が未確認の状況ですから目的自体もプロジェクトの中で設定することになります。

駆除や捕獲など出ていましたが、蒲田くんでさえ相当大きいにそんな定置網ある訳ないじゃんとかどんな大きさの船なら網で巻き上げられるんだよ、なんて思いながら観てましたけど。

外野のいうことに耳を貸してはならないという典型的な例ですね。

プロジェクトメンバのアサイメント

プロジェクトの目的も定まっていないプロジェクトのコアメンバにオペレータは不要です。必要なのは少ない情報から分析するスキルとソリューションを組み立てる想像力です。

「了解した。首を斜めに振らない連中を集めて渡すよ」
泉修一保守第一党政調副会長

とはいえ、頑固者でも自分の識別する情報だけで得られる結論にしがみつくので迷惑千万です。

間違っていたとしても論拠から仮説を立てられる思考を持ったメンバが必要です。

さらに、素直であることも必要です。

「ごめんなさい」
安田 文科省研究振興局基礎研究振興課長

なぜなら、論拠を元に立てた仮説が間違っていたり、直感による判断が間違っていたら別の仮説から対策を立てるために素早くピボットできないからです。

心理的安全とワンチーム

そうした資質を持つメンバをアサイメントできたとしても、こうしたプロジェクトでは責任に対するプレッシャーがメンバに重くのし掛かってくるものです。

斜めに首を振らない変わり者であったとしても、メンバの発想を責任という安定していた中でのオペレーションでの思考のままで枠を嵌められては発想が心理的に不自由になってしまうのです。

そうした見えない枠を取り外すためには、責任者若しくはそれに代わる者がそうした心理的な縛りを解き放つ必要があります。

ま、便宜上私が仕切るが、そもそも出世に無縁な霞ヶ関のはぐれ者、一匹狼、変わり者、オタク、問題児、鼻つまみ者、厄介者、学会の異端児、そういった人間の集まりだ。気にせず好きにやってくれ。
厚労省医政局研究開発振興課長

 これでしがらみを最初からないことにして自由な発想ができるように心理的な安全を確保したのです。

さらに出身がバラバラでお互いに素性のしれない者同士を一つのチームに変えてもいるのです。

 

 

 

エンジニアとして持つ必要のある危機感

on

多分、30年前くらいのエンジニアなら、ワタシのようなオジサンエンジニアは業務上必要となったことを必要となった時点で、それも業務時間の中でキャッチアップしていればよかったのではないかなぁ、と思うのです。観測範囲で言えば、入社時に周りにいた30代の先輩方のうち技術書を読んでいると識別できた方は10%くらいでしたから。そのた90%の先輩方からそういった自己研鑽的な話を伺ったことはないので。

別な見方をすれば、今の時代というかこの30年、いや、20年でエンジニアの世界では技術改良のスピードが上がり、一つの技術だけではエンジニアとして明日のおまんまも食い上げになってしまったり、コモディティ化により単価が急降下し、やっぱり明日たのおまんまが危ういということに気づけるような環境が揃ったのでしょう。

これはワタシ流の業績評価の考え方ですが、業績評価は年次での昨対でロールのアップグレード若しくは技術領域のエンハンスでどれだけ(プロジェクト)チームに貢献した領域を広げたかをエビデンスで評価します。

まずは、個々に評価基準に従い評価をしますがこれは絶対評価となります。なぜなら、昨対(年次)で目標設定しているからです。この評価を他のチームメンバと比較することは相対評価となり、評価対象の個人のチャレンジングな取り組みを握り潰してしまことになり、成長の芽をマネージャ自身がパーにしてしまうのでやってはいけないことです。

個々の絶対評価の後は、エンジニアのセグメントの中で相対評価をすることで業績を評価する仕組みにします。この相対評価も評価基準を作り、基準によりチームのエンジニアを評価するのです。

なぜ、評価の話を持ち出し方と言えば、絶対評価の中にエンジニアとして持って欲しい危機感を見出すことができるからです。

それは、

業績評価は年次での昨対でロールのアップグレード若しくは技術領域のエンハンスでどれだけ(プロジェクト)チームに貢献した領域を広げたか

という評価基準に現れていますし、エンジニア自身の成長を昨対で比較するという点がポイントとなるのです。

市場では、コモディティ化すれば技術料は低減される力学が働きます。つまり、昨年の値付けで自分自身を売ることができないような環境にエンジニアの都合は構わずに変わっていくということです。

価格優位性のある技術を持っているのであれば、その方程式が成り立っている間はエンジニアとしての改良は不要ですがその中身は、優位性を日々削りながらジリ貧になっていることに気づくことが遅れればやはり近い将来コモディティ化の波に飲み込まれるだけです。

このことから、エンジニアの技術に対する評価は市場で決まると言えると思うのです。
#だから、そういう評価をしているのですが。

これは評価側の理屈ですが、エンジニアはどう捉えれば良いのでしょうか。

自分の技術料を高く売りたいと思うエンジニアは、自信を専門家として看做していると言えます。専門家であるということは実現する手段を持っていない人の実現したいことを代替するビジネスを担えるからです。

一方、エンジニアとして自分を専門家として扱わない=技術のビジネス適用を考えられず、技術利用だけに留まっているエンジニアは、自信を作業者としかみていないのです。指示書に記載の範囲で持っている技術を利用するだけであり、これはオペレータに過ぎません。こうしたオペレータに対する市場価格は代替リソースが低いのです。

エンジニアが持たなければならない危機感は市場価格に左右されない技術を維持するために持つ必要があるのです。

大規模になれば足を引っ張るエンジニアが増えていく

on

「アップルは、600人のエリート社員を動員して2年足らずで『iOS 10』を開発し大成功を収めました。対照的に、マイクロソフトは10,000人もの社員を動員し、5年以上もかけて『Vista』を開発したにもかかわらず、最終的にサポートを終了することになったのです」

wired.jp

マイクロソフトを擁護するつもりはないけれど、これapple to appleの比較になっているのかぁ、と。 作っているのはOSで人員の規模となっているけれど。

なんでもそうだけれど、比較が出てきたら疑ってみることは習慣にしたほうがいいです。

成功の鍵はアサイメント

それで、なぜこの記事を引用しているかというと、プロジェクトチームの要となるロールにはキーパーソンを置けるか置けないかでそのプロジェクトは大体勝負が決まるのです。

 

言い換えれば、鍵はアサイメントです。

「えっ、当たり前じゃん」と思ったら、今いるチームの要となるロールがどの役割で、ロールにふさわしいエンジニアが配置されているかを思い出してみてください。

現実にはスキル又はスキルレベルのいづれかに不足点があることの方が多いいのです。これはプロジェクトの立ち上げタイミングである需要とエンジニアが前のプロジェクトからリリースされて供給されるタイミングがプロジェクトで必要とするロールのスキルとレベルと一致することは滅多にないことを物語っています。

需要と供給がなぜ一致しないか

いつもデスマとまではいかないけれど不安定なチームでプロジェクトを運営しているとするとどうしてそのような事態になっているかを考える必要があります。

エンジニアの需要はプロジェクトが立ち上がるからです。プロジェクトの目的を達成するために必要なプロジェクトのチームとしてのスキルセットとスキルのレベルが需要全てです。

そうした需要に本来であればチームとしてスキルセットとレベルをチームとして共有しなければなりません。

規模が需給の不一致を増大する

この要求されるチームの規模が大きくなればなるほど、需要側に応えるための難易度は難しくなるのは想像できるでしょうか。

冒頭のアップルの600人でさえiOSのエンジニアを集めるのは容易ではありません。ただ、アップルの社内であるからこそできることです。では、マイクロソフトの10000人の規模ならどうでしょう。優秀なエンジニアを自社で10000人も集めることはマイクロソフトでさえ難しいことは想像できます。

大規模になれば足を引っ張るエンジニアが増えていく

でも、600人だとしたらどうでしょう。10000人の17分の1です。17分の1であれば精鋭だけのチームとなった可能性は高いのです。アップルもマイクロソフトもどちらのエンジニアも優秀だと思うのです。それでもその中で選りすぐりのエンジニアでなければプロジェクトのアウトプットは目指すものとは違うものができてしまうのです。

これはチームとしてのスキルセットとレベルには程遠いエンジニアが混ざり込み、プロダクトのすべての過程においてレベルの低い方で物事の判断が引っ張られてしまっているのです。

この人数で開発できる規模だったらVISTAはどんなOSになっていたでしょうか。それはまた別の話ですね。

 

 

Q新しいツールを業務に導入するにあたり、予め検討しておくべき課題をあげよ

on

Q 現行業務で使用している情報共有ツールがある。1世代前の技術で実装されているため使い勝手がよくない。ツールの入れ替えを提案したところ、採用され新しいツールに置き換えることになった。そのツールは使用したことがないが類似のツールはプライベートでし利用経験がある。

 新しい情報共有ツールを業務に導入するにあたり、予め検討しておくべき課題をあげよ。

「 情報共有ツール」は身近なものに置き換えていただいても結構です。例えば、開発ブレームワークがEOLになったときどうするか、と考えてもらってもいいです。

ゴールを確認しよう

 新しい情報共有ツールを業務に導入するにあたり、予め検討しておくべき課題をあげよ。

とあるので導入前に片付けておく必要のある事項を列挙すればいいことになります。「導入前に」がどのような状態か、それを想定できるかが鍵ですね。

キーワードを挙げよう

 

現実にはパッと目次構成を作ってしまってそれそれの目次ごとのデザインを順次ディテールをある程度まで詳細化するように進めているのでこのステップを飛ばしているのですが、こうしたタスクを振られたときは、と考えると1ステップとして踏んだ方がいいでしょう。

キーワード

現行業務 情報共有ツール 使い勝手が悪い 新しいツール 使用したことがない 類似ツール 利用経験はある

作業の範囲

 新しい情報共有ツールを業務に導入するにあたり、予め検討しておくべき課題をあげよ。

 

とあるので、この検討後には導入とあるので運用が可能な状態にすると仮説を立てて良さそうです。導入するとあることで、運用が考慮されていないとすると

Q 現行業務で使用している情報共有ツールがある。1世代前の技術で実装されているため使い勝手がよくない。ツールの入れ替えを提案したところ、採用され新しいツールに置き換えることになった。

 情報共通ツールの置き換えが実現できないからです。

業務とツール

ツールは、業務の一部を機械化するものです。つまり、業務を行うリソースの置き換えです。

業務の機能をツールで代替していたのですから、新しいツールに置き換えるのであれば、現行業務の機能を新しいツールでも担えなければなりません。ですから、機能の継続が可能かを確認しておく必要があります。

置き換える理由

置き換えるということは、置き換えなければならない課題があったわけです。それが解消されるかどうかを予め確認する必要があります。

業務フローの見直し

現行業務でツールを使うにしても、業務の関係者と担当作業を業務フローとして整理しているものです。新しいツールに入れ替えたときの新業務フローに現行業務フローを見直す必要があります。

新しいツールを使うことにより、これまでの事前準備の作業や導入後の業務上の操作に関わる役割分担が変わる可能性があります。そのために業務フローを確認しておく必要があるのです。

前提条件・制約条件の整理

上記の各項目を整理する中で新しいツールを使うために考慮しておかなければならない前提条件や制約条件が判明するものです。こうしたことも予め検討する項目に入れておく必要があります。