チームの成長はロールの成長を優先しなければならない理由

某所で「マネージャのミッションが売り上げからチームの成長にシフトすればチームメンバの成長にフォーカスしたアクティビティに変わるのでは」という問いかけがあって、「(うーん、それ10年前からやってたよ)」と内心思ったけれどそれいうと話がクローズしちゃうんで言いませんでした。はい。

ところで、マネージャのミッションに売り上げがあるということは、その組織では製販一体(営業機能と開発機能が同一の組織体)の組織であるという前提が暗黙にあるんだな、とまずそこから確認したいところです。組織によっては、製販分離している体制を構築しているところもあるでしょうし。

体制はともかく、マネージャのミッションが売り上げの呪縛から逃れ、チームの成長にシフトすることはどの様な意味を持つのでしょうか。

チームの成長とは何か

チームの成長とは何でしょうか。思いついたことを書き出してみましょう。

どうでしょうか。チームメンバのスキルが向上すること、とか書きましたか。他にはありませんか。広くカバーする表現としてはそれでいいと思います。ただ、誰がとか、どの領域でとかもう少し明確にした方が良いと思いますのでそれを少し。

スキルの向上

 チームメンバの一人ひとりが持っているスキルレベルの向上が1つ目です。プログラミングの技術レベルをあげるとか、新しい適用技術を習得し実践で使える様になる、などです。

ロール

 多分、多くの方はエンジニアの技術レベルを思い浮かべてスキルアップを想像したことと思います。

別の観点では、ロール、つまり役割をステップアップすることもチームメンバの成長なのです。担当エンジニアからサブリーダに、サブリーダからリーダに、リーダからプロジェクトマネージャに、と役割をステップアップすることも成長なのです。

スキルアップとロールのどちらを重要か

基本的にはスキルレベルの成長とロールの成長は両輪です。片方だけ成長しても行き詰まります。

例えば、同じチームメンバがそれぞれの領域でスキルアップをしたり、技術領域を広げたとしても全体のスキルレベルは向上し、成長していますが、それは技術の中だけの話です。技術レベルが上がって成長しているので提供できる技術的な価値は向上していますが、その技術を提供できるパイプラインは増えません。

別の例えをするなら、継続的イノベーションで機能追加している様なものです。なので、技術スキルばかり成長を促してもそのうち行き詰まるのです。何が行き詰まるかといえば、いくらスキルレベルを成長してもチームの役割はチーム最適を優先するとローエうが固定化されるのでスキルの成長以外は停滞するのです。

そこに変化を与えるのはロールなのです。

ロールを成長させる

 チームのロールを成長させるとは、メンバの役割をステップアップさせることだと前述しました。

ロールをステップアップさせる、成長させるということは、必然的に配置転換をチーム内で起こすという意味を持つのです。メンバのエンジニアを安泰とさせない、刺激を与え、期待、つまり、マネジメントは新しいロールへ挑戦して技術以外のスキルを成長させて欲しいというメッセージを伝えることができるのです。

リーダが変わるとその人に属した性質が行動様式として表現されるのでチームの多様化が生まれます。こうした変化を自ら起こしていくことがロールを成長させることで可能となるのです。

 

 

マネージャ的には、ロールの成長は価値提供のパイプラインを増設することと同じ意味合いを持ちます。つまり、ビジネスの幅を受けられるパイをつくれるということで、結果的には数字を支えるリソースを持てる様になるということなのですけれど。

 

 

 

 

 

 

 

 

disらない、同意する、選ばせる、描いて見せる

プロマネやマネージャの仕事をしていて困るというかなんとかして欲しいのは、納期ギリギリになって初めて見せられる資料ですね。いやー、ほら、いつも言っているじゃない。今朝も聞いたじゃん。見せてよって。どうしてもっと早く見せてもらえないの、と言いたくなることなんどもあるわけです。

ほらー、ここのこれ、前提どうしてこうなっているの、えぇ、それ違うからさぁ、みたいなことになりかねないのですよ、ほんと。

こうした納期ギリギリエンジニアをもっとカジュアルに早めにアウトプットを見せてもらえる様にするためにはどうしたらいいのでしょうか。

disらない

 持って行く度にdisられちゃうと早く持っていけば持って行くほどdisられる回数が増えちゃうだけじゃん、と思っても仕方がありません。

disられたくないと心理的に行動へ働きかけますから、そりゃ納期ギリギリに持っていけば締め切りの都合を優先するなら1回だけ見てもらって、1回だけdisられてあとは逃げ切ろと対策をするわけです。

早く見たいならdisってはいけません。

同じ様な考え方に同意する

 disらないルールを資料を見る側に課すとするとあとは何ができるかというと褒めることです。でもですねぇ、褒める資料レベルのエンジニアが作るなら早く見たいと思わないんですよ。だって、出来栄えが想定できているから。

早く見たいというのは出来栄えに心配事があるからです。であれば、褒めるところを探すのは難しいんです。

だから褒めることはしないでいいです。その代わり、同意できるところを同意する、です。

これ、いいね。褒めるのではなく、同じ様に考えていたよとかこのストーリーの持って行き方はいいんじゃないかな、とか。

助ける方法を選んでもらう

 納期ギリギリで持ってきたとしても出来栄えにダメ出しをするにしても退路を塞いでは手も思考も縮み上がってしまい、終えられることも終わらなくなってしまいます。

本人がどうしたいか意思を確認して、助け方を選ばせましょう。

この後も仕事は続くのですから、主体性を持たせて腹を括らせる時には括らせないといけないし、こっちが腹を括るかと覚悟しないといけないときには括らないといけないので。

まあ、情報さえ揃っていればそんな場面に出くわすことはないはずですが。

描いて見せる

最後は指示するしかないんですけれど。ただ、一方的に指示しても覚えてくれないというかdisられてダメ出し食らってしか残らないので、そうならない様にどうしてそう指示しているのか思考の中身を解説します。

それもホワイトボードなどに図表やフローを描いてビジュアライズするのです。で、それを写真に撮らせて、ファイルサーバでもどこでも置いてもらうんですよ。見えるところに保存しておく。少なくとも資料ができるまでに1回は見てくれると思いますので。

運が良ければ、似た仕事の時にもう1回くらいは見てくれるかも。 してくれたらいいなーくらいですけどね。

 

 

LEAN IN(リーン・イン) 女性、仕事、リーダーへの意欲
 
SOFT SKILLS ソフトウェア開発者の人生マニュアル

SOFT SKILLS ソフトウェア開発者の人生マニュアル

 

 

顧客とエンジニアの未熟なコミュニケーションでは忖度してはいけない

なんというか、いくら歳を取っても知らない言葉が次から次と出てくるというか、一部の方はよくご存知ですよね。一部の方だけしか知らないからメディアは物珍しくて取り上げているのでしょうけれど。

ええ、忖度の話です。辞書を引いてみると忖も度もどちらもはかる意味だとあるので重言のような感じもしなくはないのですけれど、強調したくなるくらい「察しろ」ってことでしょうか。

とても日本的なハイコンテキストなコミュニケーションだなぁ。

 

そん たく [1] [0] 【忖▼度】
( 名 ) スル
〔「忖」も「度」もはかる意〕
他人の気持ちをおしはかること。推察。 「相手の心中を-する」

引用 www.weblio.jp

 

局面分割は伝言ゲーム

ウォーターフォール型のシステム開発が典型ですが、局面分割や繰り返し型のシステム開発は先行する局面やn-1の開発時のリポジトリがあり(あるはず)、それをインプットに次工程や次開発をする前提としてます。

1回きりの作業ではないので前工程の活動の結果としてのアウトプットの意味合いは、次工程にとっては全然違うものです。どんな出来合いであろうが、前工程のアウトプットはある意味神様みたいなものです。そこにそう書いてあるから、という指示が出てくるくらいな絶対的な御神体にダメプロジェクトでは進化する場合もあります。

ダメプロジェクトではなくても基本構造的に作業をつなぎ合わせる形態を取るので伝言ゲームをしているわけです。

まあ、昨日の自分が言っていることなんて、他人が言っていることとそれほど差はありませんから、システム開発だって同じようなものです。ええ。

伝えられないこと、聞き取れないこと

 システム開発で要件を提示するのは顧客です。その顧客は解決したい業務課題を要件として持っています。その要件はシステム化の要件定義局面で何をしたいかを伝えたいと考えています。

  • 本来実現したいことに対する思い
  • 事実として伝えられること

エンジニアとシステム化要件定義の中で何が起きるかといえば、

  • 本来実現したいことに対する思い
  • 事実として伝えられること
  • 思いを言語化する際に表現できなかったこと
  • 伝えられない事実

 と思考から言語化する際に語り部としての顧客とインタビューする聞き手としてのエンジニアの双方の未熟なコミュニケーションから、伝えれない、聞き取れないという二重の不幸が関係してグレーゾーンが生じます。

同じように事実として存在するけれど存在していることを忘却したり、テーブルに上がらないことでうやむやになってしまったりするケースもあります。

これらが上流工程も最上位の工程で起きると何が起きるか。わかりますよね。

伝えたつもりと独自解釈による補完

 顧客はグレーゾーンな領域でコミュニケーションをしているので話したつもりになるんですね。

人の基本的な行動として不都合な事実は視界から外れるのであれはそういう意味だとか、それも含んでいる、とか言い始めるわけです。

一方、エンジニアは過去の事案で慣らされているので行間を過去のパターンから埋めようとする行動を始めるわけです。エンジニア独自のエンジニアに都合が良いような解釈をして。これも、人の基本的な行動としての都合の良い情報だけを集めて回るという行動に起因するのですが。

 

やっぱり、この2つも行く末は遠くない将来に綻ぶんですよ。だから、システム開発においては忖度してはいけないんです。あ、ほら、昨日のアレ、ちゃんと顧客に確認したほうがいいですよ。

 

システムを「外注」するときに読む本

システムを「外注」するときに読む本

 
なぜ、システム開発は必ずモメるのか?

なぜ、システム開発は必ずモメるのか?

 
「なぜ」で始める要件定義(日経BP Next ICT選書)

「なぜ」で始める要件定義(日経BP Next ICT選書)

 

 

 

 

悪意を持った○×△の使い方

普段、お仕事で資料を作るときに物事を評価することはよくあると思います。評価する対象を列挙して、評価項目を設定し、評価対象の評価項目毎に評価をします。

実際に表にすると以下のようになります。

 

|評価対象|評価項目1|評価項目2|
|評価対象A|○   |×    |
|評価対象B|△   |○    |
|評価対象 C|○   |○    |

 

普通に、普段から使用している所謂評価表というものです。このなんとなく使っている評価表をよく理解しないで使用すると誤った判断をしてしまうことがあるのです。それはどうして起きるのでしょうか。

 

それでは先の表をもう一度見てみましょう。 この表の中で一番評価が良いものを選ぶとしたら評価対象のどれを選びますか。間違いなく全員が評価対象Cを選ぶはずです。なぜなら、評価項目1と2のそれぞれ両方が「○」の評価となっているからです。

 

|評価対象|評価項目1|評価項目2|
|評価対象A|○   |×    |
|評価対象B|△   |○    |
|評価対象 C|○   |○    |←これを選ぶ

 

暗黙の評価基準

 どうして評価たいしょうCを選ぶか、その理由は評価項目が「○」となっているからです。○という記号に暗黙で評価基準を脳内で設定しているからです。

 そのような評価基準は、表の欄外に凡例として記号と基準を明記することで評価基準を明示化して評価表の結果を意図したとおりに伝える必要があります。

 

凡例 ○=良 △=可 ×=不良 ←凡例で評価基準を明示する 

|評価対象|評価項目1|評価項目2|
|評価対象A|○   |×    |
|評価対象B|△   |○    |
|評価対象 C|○   |○    | 

 

明示しない評価基準のもう一つの罠

評価表に評価基準を記載しないことにより、評価表の読み手に対して誤った判断をさせることができます。

これは評価基準を記載せずに評価表を提示することで読み手が無意識に評価基準を補完して読むことを利用して読み手に対して誤謬を与えるのです。 

下表は先と同じ評価表です。この表をみて良い結果の評価対象を選ばせれば、全員が評価対象Cを選ぶと予測できます。

 

|評価対象|評価項目1|評価項目2|
|評価対象A|○   |×    |
|評価対象B|△   |○    |
|評価対象 C|○   |○    | ←これが良い結果

 

 ところが、良い結果が評価対象Cの他にBも対象となるとしたらどうでしょうか。

 

|評価対象|評価項目1|評価項目2|
|評価対象A|○   |×    |
|評価対象B|△   |○    |←これも良い結果
|評価対象 C|○   |○    | ←これはもちろん良い結果

 

どうしてそうなるのでしょうか。評価表を機能の充足性を評価する評価表として見てみましょう。機能の充足性ですから、表の評価としてはCのみが合格しそうです。

でも、Bも合格だとしたら何が得ている情報として間違っているのでしょうか。

 

|評価対象|評価項目1|評価項目2|
|評価対象A|○   |×    |
|評価対象B|△   |○    |
|評価対象 C|○   |○    | 

 

 それは、評価基準と評価を表す記号がズレにより情報の理解で齟齬が生じしているのです。

評価基準の△を見ると無意識に何かしら一部が劣っていると思いがちです。ところが○が過剰な状態であったとしたらどうでしょうか。つまり、必要以上に満たしているという状態です。

○の評価基準に引きずられて△は充足しているとなっているとしたら、それは評価表の読み手は間違った判断をしてしまいます。

これは、評価基準を先に作らずに、評価結果を軸に評価表を作ってしまうと起きてしまう事象です。

 

読み手に暗黙で記号の評価を保管させないようにするためには、凡例で充足している記号を明示する必要があります。

下表に例を示します。

 

凡例 ◎=過剰 ○=満たしている △=一部不足がある ×=満たしていない
|評価対象|評価項目1|評価項目2|
|評価対象A|○   |×    |
|評価対象B|○   |○    |
|評価対象 C|○   |◎    | 

 

 凡例を記載せずに資料化し、評価を行ったことを報告することは、読み手に誤謬させることを期待できるので評価を恣意的に誘導したい場合に使用することができるのです。

 

ああ怖い。実際にこうした資料を見たとき、会話しなかったら見抜けなかったし。

 

 

 

Graphic Recorder ―議論を可視化するグラフィックレコーディングの教科書

Graphic Recorder ―議論を可視化するグラフィックレコーディングの教科書

 
ビジュアル・ミーティング  予想外のアイデアと成果を生む「チーム会議」術

ビジュアル・ミーティング 予想外のアイデアと成果を生む「チーム会議」術

 

 

 

エンジニアが無能な管理職を回避する方法

日本では部下を持つ役職に付くと管理職と呼ばれるようになります。組織にもよりますが、係長で部下を持つところもあれば課長になって部下を持つところもあるようです。組織というお家の家風で組織構造の違いがあるのでしょう。

その管理職の方の名刺の裏面を見ると組織によっては英語表記の役職が記載されていてだいたい「manager」と記載されています。manager、つまりマネジメントがお仕事ですよ、と英語ではそういっているわけです。マネジメントをしているんだ、自分の上司は(棒

自分の上司はどんな管理職か

別に意味の違いを書き残したいわけではありませんけれど、語感からそれを使う人によって言葉で表そうとしている=これから管理職を任せる人に対する期待がこうも違ってしまうということがあるんじゃないかという仮説を立てたので、そうであるかを検証しましょう。

まずは、管理職の「管理」です。

かん‐り〔クワン‐〕【管理】の意味
[名](スル)
1 ある規準などから外れないよう、全体を統制すること。「品質を管理する」「健康管理」「管理教育」
2 事が円滑に運ぶよう、事務を処理し、設備などを保存維持していくこと。「管理の行き届いたマンション」「生産管理」
3 法律上、財産や施設などの現状を維持し、また、その目的にそった範囲内で利用・改良などをはかること。

引用 dictionary.goo.ne.jp

管理という言葉の意味合いからは、決められたルールや基準の中に収まるように統制をかけていくための処理をしていく、という意味であることがわかります。

ここ、とても大事です。そして多くの組織が管理職という言葉を使用している限り、組織の人事をデザインしている経営層は、管理職はオペレータであると宣言しているのと同じことです。

管理には変化を起こすことは期待されていないのです。年度始めに決めた計画を達成するための活動を期待されているのです。

 

では、管理職の英語表記のmanagementにはどのような意味があるのでしょうか。

マネージメント【management】の意味
1 経営などの管理をすること。
2 経営者。管理者。「トップマネージメント」

引用 dictionary.goo.ne.jp

統制、処理、維持といった言葉は一切出てきません。それらは手段としてサブセットにしていて、主な意味は経営となっているところに注目しましょう。

つまり、日本での管理職に求められている統制、処理、維持などのための活動は経営のためのツールだよ、ということです。日本の管理職には、経営は求められていないのです。

よくよく考えればわかることですが、日本の組織は経営職と管理職の2層構造になっています。

それでは、エンジニアが仕事のやり方を変えたいとか新しい技術に取り組みたいとか思って上司に言っても上司の管理職では経営のための手段しか裁量がないのでネガティブなレスポンスしか返ってこないわけです。

 

マネジメントの英語の辞書ではどう言った意味合いなのでしょう。そのまんまですね。2番目の意味の方がわかりやすいかも。ビジネスを担う。

 

management

noun
1.the act of managing something
 he was given overall management of the program is the direction of the economy a function of government?
2.those in charge of running a business 

引用 english.cheerup.jp

 

日本の管理職にはビジネスを担うという意味合いがないとは言いませんが希薄なのではないでしょうか。

無能な管理職を探せ

 管理職により濃淡があるとするならば、それがエンジニアに個人的に合う合わないは別にして、ビジネスに寄与するエンジニアの行動であれば、援助してくれる可能性はたかそうです。だって、経営に対する意識が希薄なただの管理職では、経営に寄与する判断も変えていくこともせず、現状のルールに収めながら進めるのですから。

ではどうやって見分ければいいのでしょうか。

それは、管理職の分掌に付いての計画を自力で作っているかどうか、です。

経営をしていない希薄な管理職は、経営企画など上から落ちてくる年度計画を元に詳細化、具体化した計画どおりに進捗するように数字をにらめっこしています。だから計画を組織の上の方から落ちてくるものがあったとしても、現場に展開する計画が管理職の分掌に対する経営的なポリシーがあって担当する事業が儲かるための活動をしているかを見ればいいのです。

だから、無能な管理職を探すならそうしていない管理職かどうかを探せばいいのです。そういう経営的なポリシーを持っているかどうかは管理職と少し話すだけで、経営的に対して受け身か自分の我が道を行くビジネス的な言葉を使うかで簡単に判別できます。

それをしたいなら、見極めたいなら、管理職とサシで飲むことです。それで見極められなかったらそれは勉強代を払ったと思ってください。

 

 

 

マネジメント[エッセンシャル版]

マネジメント[エッセンシャル版]

 

 

エンジニアの生産性も稼働率もマネジメントの指標にはならないことをマネージャ自身が気づかないのはなぜか

プロジェクトマネージャはプロジェクトの目的を達成するためにプロジェクト遂行に必要なリソースを確保して、プロジェクトの目的の一つである納期に契約に記載されたアウトプットをプロジェクトに求められる要求品質を満たして納めるための活動にフォーカスして行動基準を定め、判断するものです。

なぜならそれがプロジェクトマネージャのロールだから。

プロジェクト最適化というフロー効率という考え方

プロジェクト最適化とはプロジェクトの活動の中でプロジェクトに寄与することを最優先とする行動規範です。冒頭に記載のように判断しなければならないときに、そのくだす判断がプロジェクトにとって最大の利益に結びつく結果を選択します。

プロジェクト最適化をプロジェクトマネージャが行うとき何を考えているかというと、解決したい課題が最速で、リスクのエクスボージャが最小となるような手段を選択するということです。厄介ごとは手早く片付けたいという心理が働くということです。

ここで注目したいのは手早くエクスボージャを最小でとしているので投下するリソースは最小でかたづけたいということです。これは効率よく課題を解決したいのでリソースのフローを効率的に使いたいという心理が働きます。

なぜなら、本来のWBSは並行して動いており、課題解決をするためには本来のWBSに投下をしているリソースから剥がして持ってくるか、予算措置的に確保しているコンテンジェンシプランの予算から切り出して充てがうからです。

この課題解決の対策を斬新的且つ中途半端に対処すると課題可決のめどが立たず課題がプロジェクトのトラブルにクラスチェンジするので悪手であるのですがそれはまた別のテーマで。

稼働率というリソース効率という考え方

ところで、プロジェクトマネージャが管理職になってマネージャになるとそれまでリソース効率を行動の判断基準としていたプロマネが同じ人なのにエンジニアのコストを外部からの収入で利益化することの効率性を行動基準に宗教替えしてしまうマネージャがいます。

プロジェクトマネージャのときは少数のリソース投下で最大限の効果を得ることを判断基準としてきたのに、マネージャになるとどんな仕事をしているかどうかはどうでもよくエンジニアの月当たりの稼働時間のうちどのくらいの割合を使用しているかという、リソースの源泉は同じエンジニアなのにエンジニアの成果で判断しなくなるということが起きます。

これに類似しているのが、プログラムの生産性です。ほら、もう、エンジニアの稼働率もプログラミングもそういった数値は計測可能だし簡便に得られるけれど勘弁に手に入れられるからこそ、そこから導き出される率には数字に何か意味があるか、エンジニアの稼働率であれば価値あるアウトプットを生産したかやプログラムの量が機能数と相関関係があるかと問えばそれはノーです。

 

ではどうしで宗教替えをしてしまうマネージャが出てくるのでしょうか。それは、マネージャ自身がマネージャの仕事をオペレーションと捉えているからです。

ビジネスを拡大すること、つまり利益を生むことがマネージャの仕事だとしたら、デリバリーして利用される機能が期待する成果を産んだかを測ることが必要なのです。 

 

 

スモール・リーダーシップ チームを育てながらゴールに導く「協調型」リーダー

スモール・リーダーシップ チームを育てながらゴールに導く「協調型」リーダー

 

 

エンジニアはどうしてやることがなくなると心配になるんだろう

 「開発チームのやることがなくなってしまったらどうしよう」と心配していたらそれはしなくてもいい心配ですよ、とお話ししてもやはりエンジニアは何かをしていないと割り込みでタスクを突っ込まれてしまうから…とアサインされたタスクの期間を目一杯使うのはエンジニア自身にとっても回避したい判断なのです。

どうしてやることがなくなることが心配なのか

まず、エンジニアはどうしてやることがなくなると心配になるんでしょうね。タスクがない、作業がないと仕事から外された気がするのでしょうか。

それとも普段からみっちりとタスクを詰め込まれていて残業もするのが当たり前になっているくらい慣らされてしまっていりするんでしょうか。

習慣は怖いもので生活のリズムになってしまうので常習的に働き詰めになっていると、うっかりとタスクの谷間に陥ると何していいかわからなくなるんですよね。

だからタスクで埋めてしまうんでしょうか。

いやいや違うよ

そうじゃないよ、違うよというエンジニアもいると思います。ええ、プロジェクトマネジメントが回っていないプロジェクトなら。

計画があっても実態を表していない、WBSの作業項目がずさんで後から後から増えていく、品質がコントロールできていなくてモグラ叩きのようにモグラが出てきてから対処療法なのでスケジュールの後半になる方が無茶振りされて忙しくなる…。

困るのは想定していないから

 作業はいつか終わらせないといけません。納期があるのですから。でも納期前に終わっても困ることはありません。困るのは空いている時間に想定していない仕事を差し込まれることです。で、どうして差し込まれると困るかというと想定していないから。心の準備ができていればいいのです。

考える時間を確保するには

でも、仕事ばかりだと考える時間が取れなくなってしまいます。確かにタスクの成果物を作るために考えているけれど、それは処理しているんです。作業です。考える時間とは新しい手法や技術、改善したい課題の解決手段を思考する時間です。

その時間、どこで取りましょう。そうなんですよね、タスクを少し前に終わらせるしかないのです。

あなたがリーダだったら、メンバにはもし完了予定日より前に終わったら、改善や技術向上に使っていいよと言ってあげてください。もちろん、佳境ならそれはチームとしてやっつけなければいけませんがそれ以外は考える時間を確保してあげてください。

あなたがメンバでトラブルプロジェクトで差し込まれることが日常的であれば、少し前に完了していたら闇で技術向上に使っておくしかないです。早く抜けましょう。