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

伝えられるリーダはなにを「伝えよう」と組み立てているか

on

「この新規の案件、関係者に共有しようと思うのですが誰に伝えればいいですか」
「どの件だっけ、あーそれね。関係者は営業と開発責任者だよ。そうだなぁ(そのまま共有されるて誤解を生んでもキミのためにならないな)ちょっと、まとめたら一度見せてもらっていい」
「あ、はい」
 :
「できました。私のPCで確認しますか」
「ごめん、これの後に見るからメールで送って」 

 ひと段落ついたのでどれどれ、と。

各位
新規テーマの情報を共有します。
テーマ NW統合。テーマをマネージできるプロマネ。ネットワークのスキルが必要。
期間 次の四半期から
ここは現行保守をしているSIerがいますが、新システムのNWになるので積極的に取りに行きたい。ただ、現行SIerになるだろうと顧客の担当者も思っていると思われる。
詳細
 :
補足
これまでの仕様検討会の場で顧客プロジェクトオーナは既存SIerに拘らないと発言がありました。また、顧客PMはプロジェクトオーナの意向を汲む傾向があり、同様の発言をしています。

うーん、惜しい。これではもらった営業は悩むな。開発責任者もネガティブに取るな、あのキャラなら。さて、どうソフトに書き換えるように伝えるか…。

「さっきの件、ありがとうね。内容を確認したよ。全体はオーケー。だけど、関係者はこちらの仔細な状況まで知らないよね。これは大前提ね。それで、今回何を伝えたらいいと思う」
「新規案件の情報共有ですが」
「そうすると、だ。正しい情報を伝える必要があるよね」
「はい」
「そうするとさ、

テーマ NW統合。テーマをマネージできるプロマネ。ネットワークのスキルが必要。
期間 次の四半期から
ここは現行保守をしているSIerがいますが、新システムのNWになるので積極的に取りに行きたい。ただ、現行SIerになるだろうと顧客の担当者も思っていると思われる。

「この赤字の前までは事実で伝えないといけないところなので、○。でも、赤字にしたところは、 推測だよね、キミの。どう」
「そうです」
「確認した事実と推測、つまり私見は分けないといけないんだよ。今回の目的は」
「案件を関係者に伝えることです」
「だよね。だから、赤字前までは目的を達成できそうだ。でもね、赤字の文章は私見で、且つ、ネガティブな意見だよね。これを読んで営業が降りてしまったらどう思う」
「それは拙いです。提案することが目的なのに」
「だったら、ここは必要なのかな」
「…」
「事実かどうかで判断したらいいよ。次ね」

これまでの仕様検討会の場で顧客プロジェクトオーナは既存SIerに拘らないと発言がありました。また、顧客PMはプロジェクトオーナの意向を汲む傾向があり、同様の発言をしています。

 

「これは事実だよね。会議の場での発言でしょ」
「そうです。はっきりと言ってくださいました」
「じゃあさ、これお引越ししよう」
「どういうことですか」

テーマ NW統合。テーマをマネージできるプロマネ。ネットワークのスキルが必要。
期間 次の四半期から
顧客プロジェクトオーナは既存SIerに拘らないと発言があり。
顧客PMも同様の発言あり。

「最初の2項目と発言の行を足すんだよ。ほら」
「あ、なるほど…」
「これ全部、どう、正しい事実かな」
「そうです」
「でさ、ここであともう一つ足すんだよ(キミがネガティブに取られないようにね)」

テーマ NW統合。テーマをマネージできるプロマネ。ネットワークのスキルが必要。
期間 次の四半期から
顧客プロジェクトオーナは既存SIerに拘らないと発言があり。
顧客PMも同様の発言あり。

NWは現行保守をしているSIerがいますが、新システムのNWになるので積極的に取りに行きたい。

 

「どう」
「あー…そういうことですか。なるほど…わかりました。事実の後にどうしたいかを書けばいいんですね」
「でも、詳細も残しておきたいです」
「それはあってもなくてもどっちでもいい。折角書いてもらったけど、今回の目的の補助情報にしかならないから。おいおい必要かもしれないけど」

伝えられる人は伝える目的を理解している

もう、これに尽きます。だから、それが最短で到達できる道を見つけます。

メンバを指導する場合は

一人でやるのであれば、好きに話の構成を建てつけて、パパッと片付ければいいです。でも、メンバが主体でやっている場合は、伝える目的でくくり直してあげればいいですし、足らない情報があればいそれのヒントを出せばいいです。

このケースでは、目的を確認して、伝えようとしている内容を目的でくくり直しているだけです。もし、情報が足らなければ、ヒントを出して情報収集するように仕向ければいいのです。

 

 

 

iOSアプリ「精選版 日本国語大辞典」2017年1月31日まで発売記念セール中なのでポチる

off iPhone

舟を編む」を見て辞書編纂に興味を持ったけれど、こんな辞書があるのは知らなかったなぁ。

ということでポチる。

 

マネージャが知っておくべき10の評価観点の要求事項a.k.aエンジニアの虎の巻

on

目標管理精度を導入している組織は多いと思いますが、じゃあどうやるのというとhowtoまでは誰もマネージャに手ほどきをしません。

そんな環境下で何が起きるかと言えば、評価者の感覚による評価です。これは評価者であるマネージャが

成果に対する客観性及び厳格性を確保するための信頼できる評価手法を持っていない

ということです。

現実はこんな感じです。もし、これを読んで「ひどいな」と思ったら、自分がマネージャになって信頼できる評価手法を作ることです。

評価の観点を持つ

評価手法とは評価の「観点を持つ」ということです。観点、軸を持たずに評価をするから評価者の感覚でしか評価できず、評価も被評価者に対する感情や思い込みで評価することで被評価者からの不平不満が募るのです。

評価の観点

評価をするためには目標あることが前提事項です。つまり、目標設定から評価が始まっているということです。それなくして評価の観点だけを作ってもインプット自体に整合性がないため不整合が起きるのは当然です。

評価には次の評価観点の要求事項を明確にしておく必要があります。

・目標は何か
・目標は合意しているか
・誰が実務者か
・誰が評価基準があるか
絶対評価相対評価が明確か
・評価項目は定量的、定性的で定義されているか
・評価情報は何か
モニタリングの実施手段が確立しているか
・フィードバックはいつ行うか
・客観性を持たせるためのインプットの手段は確保できているか

 評価観点の要求事項

名称自体、たった今名付けたのでアレな感じは歪めないですが、まあ、便宜上必要かなと思ったので。

で、これを担当している事業の特性を具体的に書き出せばいいわけです。

大事なことは、文字に起こすこと。それを持って、目標設定し、評価することです。

評価観点は教えてはいけない

もちろん、評価観点の要求事項の具体的な内容を被評価者には教えてはいけないですし、教える必要は1ミリもないです。

ただ、評価方法があって、客観性及び厳格性を持った評価の上、総合評価をしていると説明することは構いません。

Q:緻密な時間管理は生産性と指導力の鍵である。○か×か

on

タスクの見積もりを時間単位で行うのはプロジェクトのスケジュールを緻密な時間管理をするためにしている。

これは「×」ですね。

作業の見積もりを時間単位でできるような粒度にタスクを分解しているのは確実に成果を出すためです。

時間単位の作業に分解しているから、問題が起きれば共有も早いし、対策も早くできるわけです。

この考え方、つまり、綿密な時間管理が生産性の鍵であるかどうかは、アジャイルでもウォーターフォールでも当てはまりません。

綿密な時間管理は、単位時間当たりの作業の集約度を得ることを目的におこなうものです。

生産性を現状より向上させたいなら、生産する方式を取り替えなければ単なる作業の集約度を高めているだけですぐに限界に到達するし、人が介在している場合は作業の集約度が優先されるために作業品質がおざなりなるために歩留まりが悪くなるだけです。

緻密な時間管理のために時間を割くことは指導力にとって必要なことである。

これも「×」ですね。

作業をするメンバに対して多くの関与をすることはチームの自律を阻害する要因です。人は、自ら考え、判断し、行動することで初めて当事者になれます。

他者から自分の作業に対し、仔細な関与が働ければ、考え、判断する裁量が剥奪されます。それでは指示を出すリーダの作業を代行しているに過ぎません。

その状態は、プロジェクトの作業量が増えるに従っていつかはリーダのキャパシティを超え、破綻することが目に見えています。

見積もり時間に対する成果をモニタリングする。

これは「○」です。

チームのやることは、投下したリソースに対して期待する成果を得られるかをモニタリングすることです。

時間を管理することで成果は得られないし、指導力が高まることもありませんから。

 

コミュニケーションは感情を押さえないと目的が達成できない

on

進捗は歩いてこない、だぁから歩いて聞くんだよ
1日目に10%、3日目で80%
80%まで進んで滞る

 早朝から365歩のマーチの出だしが降臨してきてこんなセリフを当てることを思いつくなんて馬鹿なのかアホなのか…。

コミュニケーションの幻想

これだけチームで働くにはコミュニケーションスキルが重要だとか、必須のスキルだとか、コミュニケーションを促進するためにはツールを導入すべきだとか、ツールはこれがいいとか賑わしていますが、

それでコミュニケーションは期待するように取れるようになったのかね

と問いたい。

結局、コミュニケーションを取りたい側=プロジェクトマネージャやマネージャなどの必要としている情報を吸い上げるための仕組みだから、必要とする側から駆動して取りに行く必要があることは何一つ改善されないのではないか、と。

#記憶が確かなら、半二重通信みたいなものなのでは。

1通のメール

とある日、1通のメールが。開くと、

あなたの活動でこちらの部門の作業が想定外に忙しい。一体、この先どうなるのか。次のことを知りたい。打ち合わせが必要なら言ってくれ。

意味がわからないのですが。そちらの部門はサービス提供部門なのだからサービスリクエストを受け付けて、仕様上のリードタイムで応答すれば良いのでは。

まあ、情報共有は別に構わないけれど、そちらの欲しい情報をこちらが判断して出せる情報かどうかの判別がつかないんだよなぁ。

こちらの計画の資料を渡して理解できるのかしら。資料渡して、さらに説明が必要なくらいなら最初から打ち合わせをしたいと言えばいいのに。

わからないのは、打ち合わせが必要かどうかはそちらが決めることでこちらはレスポンスする立場なんだけれど。

そちらの活動に対応すべく、今後の計画を共有いただきたい。次のことを知りたいが対面でインタビューしたいので次の候補日時ではいかが

ワタシなら上記のように打診の上、直接コミュニケーションの「場」を一席設けてお伺いするけれど。この打診では場を設けることが目的であることがはっきりしている(と思うけど)。

目的が達成されれば、何をしようとしているのか、今後の計画の見通しはどうかが直接聞けるのに。それにサービスリクエストを大量に出しているということは今後も関係があるだろうから面が割れている方が相手しやすいと思うのだけれど。

ワタシがそちら側ならそう思う。

コミュニケーションでは感情を押さえないと

1通のメールの書きっぷりは大分簡略化しているけれど、原文のメールには行間や文字間に滲む感情が窺えるのですよ。

言葉の選択は感情を表すので。

むかーしにも書きましたが、コミュニケーションツールの選択により伝えたいことの伝達力が大分減衰するんです。

対面|超えられない壁|電話>メール

なぜなら、書き手の意図を書き手の知識と情報から語彙から選び、感覚で選び(ろくに推敲もせず)、全体の構成も見直しせずに投げてしまうから。

さらに、受け手は書き手の意図とは無関係に、一切、制約を受けずに受け手が持っている知識と情報を背景に解釈している語彙の意味でのみ受け取り、理解(表面だけか裏まで読むかは別として)するから。

そうしたことを知っていると、メールなんてビジネスライク(死語?)な丁寧に用件を伝えるのが合理的なソリューションになるですよ。

で、ご丁寧な大人語のメールが飛び交うと。でもね、それコミュニケーションを効率的に取るための手段なのね。

指示待ちシステムエンジニアは組織の文化かもしれない

on

チームを編成すると指示待ちのメンバがある程度いるものです。これ、不思議なんですが組織の特性かと思えば、他社と組んだ場合でも不思議と一定の割合があるんですよね。

よくよく観察していると、指示待ち系のシステムエンジニアもどうやら2つのタイプに分けられる。本当の真性の指示待ちシステムエンジニア。もう一つのタイプが「仕事だから言われたことはやります。(ごにょごにょ)」と自分の意思を持っているタイプ。

真性の指示待ちシステムエンジニアはもう「真性」だけあってブレません。システムエンジニアという専門家として扱うのを躊躇うほどの指示待ち。

さて、2つ目の「仕事だから言われたことはやります(ごにょごにょ)」タイプは、真性ではない指示待ちです。でもよく話を聞いてみるとご自分の意見を持っていることがわかる。じゃあ、自分のやりたいようにすればいいのにと思ってしまうけれど、何かそうしない原因があるのかなぁ、と。

指示されているのは誰か

指示されているのは誰かとは、指示されることを待っている指示待ち系のシステムエンジニアの他にも指示待ちの役者、ロールがあるのではないか、と一歩引いて周りをみてみよう、ということです。

さて、組織構造的に誰が見えてくるかと言えば、

開発責任者
 |
プロジェクトマネージャ
 |
メンバ

 と大雑把に言えばこれだけ見えてくるわけで。メンバの中に指示待ちシステムエンジニアが混ざっているなら、その周りにもいるのではないか、と。

プロジェクトマネージャの全員が全員、自主的に活動をする特性を持っているかと言えば、そんなことはないと思い当たることもあるのではないでしょうか。

そう、メンバに指示待ちがいるならその上に立つプロジェクトマネージャだって指示待ちの特性を持っているPMは存在するのですよ。

ただ、あれやれこれやれは言うけれど、上からの指示をトレースしているに過ぎないプロジェクトマネージャだっているのです。

だからね、指示しているように見えてもその指示がぶれるなぁと感じることがあるじゃないですか。それです、それ。

こうした構造は、各人が自分の頭で考えることを放棄しているんですよ。ああしよう、こうしようとプロジェクトを成功させよう、目的を達成しようと考えているのではなく、指示されたことを指示されたとおりにやることがプロジェクトの判断基準になっているんです。

この判断基準が間違っているのは指示を命じることがプロジェクトマネージャの仕事になっていることです。それを解消しないと指示待ちシステムエンジニアは一層できないです。

指示待ちシステムエンジニアだけど自分の意見を持っている人は、実は、こうした指示されるより、自分のやり方を認めて欲しいと思っています。

これって、プロジェクトマネージャが指示をすることがマネージャの仕事であると思っていることをやめるとごにょごにょが解消するんですね。だって、指示されるのではなくて、意見を聞いてもらって、その上で行動が決まるようになるのですから。

まあ、指示系のプロジェクトマネージメントなんて随分前に転換期を迎えたはずなのにまだあるのは組織の文化になって上の方に残っているからなんですけれど。

SEに必要な生存戦略としての習慣

機会があることに、いや、ネタを思い付く度に学びの習慣をしようと書いているのですが。

まあ、その意図はわかる人にはわかっている(=伝わっている)と思うのだけれど、今の状況を変えていくために、システムエンジニアなら技術者としての生存戦略としての技術習得を習慣化することが必要だよね、と言う思いを書き留めているのです。

SEと生存戦略

今の仕事(=プロジェクト)は長期だからとか維持管理だからとかプロジェクトの特性を背景に技術的な学びを先延ばしすることをしていると、近い将来、退路のない崖っぷちの状況に自らを追い込んでしまうことを覚悟しなければならいです。

何故、そうなってしまうか。それは自分で選べる選択肢を自分で狭めてしまうから。更に言えば、自分でコントロールできないプロジェクトの特性に将来の自分の選択肢の幅を丸投げしてしまっているからです。

自分がそのプロジェクトに参画し続けられるかは、自分の上司か顧客の予算に依存していることを理解し、それは自分の希望とは別の意思で判断される、つまり、コントロールできないところで決められていると言うことを改めて認識しなければなりません。

ですから、システムエンジニアとしての生存戦略が必要で、それが学びの習慣であるのです。

習慣の落とし穴 

じゃあと、気になる技術を学べばそれで良いかと言えば、そんなことはない。そこに落とし穴があります。どんな落とし穴かと言えば、習慣を一つ作るだけではシステムエンジニア生存戦略にはならないからです。

システムエンジニアに限らず、人は怠け者ですから、重い腰を上げてきになる技術を学ぶ習慣を作ったとしても、それっきりになる方が多いのです。

それっきりになる、そうしてしまう理由づけを自らが行うことがそれっきりを助長しているのですが。

やっている、やり続けている人はわかると思うのですが、人は何かと

「やらない理由」

を作りたがるのです。それはワタシ自身もそうです。今日は忙しいから、遅いから、疲れているからとやらない理由づくりはとても簡単だし、自分を自分自身で窮屈に指定てる環境から解放します。

別の観点ではやらない、続けない理由も作ります。これをやってみたけど

「今の仕事に使えない」

と言うように。こうしたことは表面だけ理解したつもりになって続けることを否定するための理由づくりとして行なっているのです。

習慣の習慣こそ生存戦略

一つを学ぶことを習慣とすることが習慣の狙いではありません。必要なのは、継続して技術を習得することが狙いです。

言い換えると、学ぶ習慣を身につけること、学ぶ対象を見つけ出し続けることが習慣の狙いですし、それこそがシステムエンジニアとしての生存戦略です。

別の見方をすれば、すでに習慣として身につけた技術をそのままでいいのかと疑う、更新することを考えることも必要ということです。

いつまでも過去に身につけた技術を使い続けることが良いことだとは限りません。特に、適用技術、技法や言語、利用技術については更新が早いです。それが更新の対象であるかどうかを見極めることができるのは基礎スキルです。

技術習得の習慣を習慣にするためには基礎スキルが必要で、そちらをおざなりにすれば技術の習得は継続的に身につけることは難しい、つまり続かないのです。

学びを習慣とするためには、技術スキルばかりでは続かなくて、基礎スキルも鍛えないと続かないし、生存戦略にもならないということです。