エンジニアとしての伝え方

某所でトラブルプロジェクトの事例を話すことになったので、そろそろスライドを作らねばと思い、印象が強い立て直しプロジェクトを思い出しながらそのうちの１つのプロジェクトのあらましをノートに書き出してみた。

なんでもそうなのだが、いきなりスライドを作り始めてはいけない。いや、頭の中で

「何を伝えたかったのか」

引用　SHIROBAKO

が決まっていて、そこに落とし込めるなら構わない。

でも、人がスライドを作るとき、思いついたことから書き出してしまうし、伝えたいことよりは書けてしまうことを仔細に書いてしまい、ある程度書いてしまった後に全体を見回して、大変な思いをして整えていくことになる。

偉そうなことを言っているが、毎回似たようなことをしているのだが。

SOLOなふりかえり

その１つのプロジェクトのあらまし、特徴、体制、関わり方、出来事、対処などを書き出すと今でもプロジェクトで関わったアクティビティのいくつかを鮮明に思い出すことができる。

多くのことは忘れてしまったが、多分にストレスを感じていたか、アドレナリンが出ていたかはわからないが、パッといくつかのシーンを思い出すことができる。

１ページにざざっと書き出した後、見返してみると、割とすごいことをしていたな、と思う。トラブってからの立て直しの対策のことだ。

多分、今なら、トラブルの直接原因は防止できないだろうが、トラブルを部分的には極小化はできるかもしれない。

なぜ、トラブルの直接原因を防止できないかと言うと、原因がプロジェクトチームの外にあるからだ。外部依存というやつだ。ただ、それを識別することと行動を取るタイミングは、ループする世界線に紛れ込んだとしてもそのくらいはできるだろう。

ひとり、平日の夜にソファーに寝そべって、プロジェクトの振り返りをしているのは稀有な感じもしないではないが、なかなか発見があるものだ。

何を伝えるか

あらましをページに書くと8割方が、半ばプロジェクト説明のようなものになっている。8割のうち、その半分はトラブルの説明と対処だ。 

 トラブル事例に興味を持つエンジニアは少なくない。だから、それに時間を割けばそこそこ楽しめる（内容に若干、勧善懲悪的な世界観の要素も含まれている）ので、その場的には好評かもしれない。

でも、主旨が違うのだ。2つのポイントで切り口を作らねばならない。

• チームをどう立て直したか
• 第三者の立場でどこを見るか

を書かなければならない。

そうすると、ページ書いたことは2ページ程度のスライドに圧縮し、伝えたいことと直接関連しないことは削ってしまう方がいいだろう。

ページの2割しかないところから数ページのスライドを切り口で見せ方を変え、伝えたいことを伝えなければならない。

聞き手の満足ではなく

 場の聞き手には3種の立場の方がいる。エンジニア、マネージャ、第三者の立場。この方たちに費やしてもらった時間の価値に満足を与えることまでは考えていない。

必要なことは主旨を捉え、伝えたいことを伝えきることだ。

こうしたことを夜に考えるためにも平日も定時近くで変えることが必要だと思った。

SHIROBAKO Blu-ray プレミアムBOX vol.1(初回仕様版)

SHIROBAKO Blu-ray プレミアムBOX vol.2(初回仕様版)

部下を無能ということに躊躇わないマネージャは無能である

情報収集と言うソーシャルを徘徊といってもはてブかtwitterかfacebook程度をチラチラと眺めているだけで、そんなことに時間を使うなら本の１冊でも読んだほうがいいのはわかっているけれど、ちょっと本を読むまでの気力がないというか。これも立派な言い訳なのだが。

ソーシャルを眺めているのは何か気づきが得られるというかインスピレーションが湧くキーワードを探しているのだ。それはわかっている。だったら積ん読の山を崩したほうがいい。それもわかっている。ただ、本を読むのは電車の中でが一番好きだ。これもまた立派な言い訳である。

無能を.する意味

昨日だったか、目についた記事は無能へペナルティを課しても組織から一掃されない的な話で、流しながら読めば、目新しいことは何一つない。パレートの法則やらドラッカーが引用されている。

blog.tinect.jp

記事の中では無能をクビにすることが極論として出ていたが、海外では一定の割合をクビにする。例えば評価の下位10％を決めて、入れ替える。そう、入れ替える。気づく人は気付くだろうけど、このシステムは循環する。下の評価層を評価ごとに作り出すシステムなのだ。

よくできている点は、貢献しない＝事業にフィットしない技術を持っている社員は自然と他社に流動する機会を作るということだ。フィットしない技術で、低評価でいれば社員にも会社にもいいことは何一つないのだから。

悪い点は、事業を観察していないと自分がいつその下位層になるか安心して働けないということくらいか。

マネージャは有能なのか

その記事とは別にこんな記事があった。

www.businessinsider.jp

これを見て思ったのは、新しい価値を産む産まないは誰が評価しているのかということだ。

マネージャに決まっているじゃないか、と。そうなんだ。マネージャが評価している。キミは50歳にもなって新しい価値を産まないな、というわけだ。

ところで、マネージャの役割は何だろう。あれこれとマイクロマネジメントをすることか。それとも、マネージャが思うように仕事をしない部下を叱咤することか。

そんなマネージャをマネージャとはドラッカーは呼ばないだろう。

部下の特性を知り、何をしたいかを知り、組織として割り当てられたリソースを組織へ貢献させるために最大限活躍できる場を作り、仕事にアサイメントすることがマネージャだ。

マイクロマネジメントをしたがるマネージャに新しい価値を見極められるだろうか。それはありえない。なぜなら、そのマネージャが持っている古い価値観で行動様式を決めつけ、強制してくるからだ。

先の記事にもあるように無能を産むのは組織であるという言い分は確かにそのとおりだ。なぜなら、そのマネージャをアサイメントしているのは組織の意思決定なのだから。

なので、部下を無能ということに躊躇わないマネージャがいる組織は社員に貢献させるという点において無能なのだ。

有能なマネージャは、社員が最大限に貢献することを考えている。それだけである。

エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング

エンジニアにコーチやメンターが必要な理由

エンジニアがお仕事をする上でどのように様々な技術を身につけるかを自分自身のことで思い出してみよう。

新卒のエンジニア候補生を集めた集合教育でスライドやテキストを横に置いて、開発環境の整え方や実際にコードを書いて評価されるような形式が多いのではないだろうか。

現場では即戦力が欲しいから、当然、研修を行う担当（または業者）には実務（＝コードを書く）ができるエンジニアを促成するために道具の使い方を教えるように要請される。

まあ、そうだよね。それにどこか問題があるのかどうか。

研修を受けているエンジニア候補生が現場に配置されれば、現場に起きている業務課題を解決することが求められる。それはそうだ。だって、ITを使い課題を解決するために採用されたのだから。

でも、研修で教えられるのは道具の使い方だけである。開発ツールという道具、言語という道具の使い方を教えられただけである。これは、研修で教えられることは教科書的な教え方しかできない、ということだ。

ところが、現場で起きている業務課題は現場ごとに違う。これも当然だ。業務自体が組織により違うからだ。

研修で出来ることと現場で必要な教育の内容は最初からズレているのであれば、現場の研修に対する期待自体が無理筋なのではないのかということになる。

では研修の担当者ができることは何か。

それは、開発環境や言語は道具でしかなく、置き換わるものだという考え方と開発環境や言語を置き換えたときにどうやって新しい技術を身につけるかという技術の捕まえ方なのではないかということだ。

言い換えれば、業務課題を解決するために知っている、身につけている技術を適用するのではなく、解決に適切な技術をどう選ぶかということだ。

ただ、研修では道具の使い方しか教えられない状況なのであれば、配属されたエンジニアに対してそういったことを教える役割が必要となってくる。

それをコーチやメンターが担う。

現場の特性に合わせて必要となる技術を示したり、参考となる書籍を読み合わせたりとエンジニアの側にいて、技術の習得を促す。

エンジニアの技術力云々の記事を見かける事が多いが、何もしなければ技術力相応の価値がないのだから、だったら、コーチやメンターにコストを支払って組織的な技術力のレベル上げに使ったほうが良いし、コーチやメンターを内製化するならそれを担うエンジニアが自分自身へ再教育を行うキッカケとなるのでその点でも良い策である。

Scratchコーディングカード

技術的負債はプロジェクトの成功に含まれるか

某所でのつぶやきに対して、もにゃった人から意見を求められた。

「プロジェクトの成功って何ですか」

その質問の背景をこちらから尋ねる前に説明してくれた。コンテキスト的には冒頭の某所のつぶやきをみてその発言された方がいうプロジェクトの成功は誰の立場で言っているか、発言された方の影響力があるにも関わらず自覚のないような発言を見ているとよからぬ波紋がひろがのではないかと言ったいくつかの気持ちを織り交ぜてもにゃっているように感じられた。

結論から言えば、発言された方やその周辺の関係者を入れて話す機会を作ることで議論をしたい方の欲求は一旦、受け付けらることになった。召喚する相手がsnsで繋がっていると即座にグループを作れ、その場（＝意見を求められたそのタイミングで）でグループに招待するだけで忘れずに約束を果たせるのは素晴らしいと思う。

プロジェクトの成功とは何か

PMBOKの最初の方のページでプロジェクトの定義を読めばいいのだが、端的に言えば有期限性を持つ業務活動の目的を達成すれば良いのだ。目的は定性的な概念が多いため、目標を定量的に設定することが必要だ。このときの目標にKPIを設定することになるだろう。

このKPIにQCDSなどが設定される。

プロジェクトの成功とは誰のものか

 冒頭の意見を求められたところで、起因となったつぶやきの成功とは誰の立場で発言しているかと言うところが議論の最初に行われる確認ポイントととなる。

なぜ誰の立場でが確認ポイントになると言う理由は、下図の行にあたる組織が誰に相当し、その立場でプロジェクトの定義が変わるからだ。

内製化する場合は、ベンダやサブコンは組織内の主管部署に置き換えればよく、その場合はサブコンやサブサブコンは存在しない。

何れにしても、プロジェクトに関わる立場が変わればプロジェクトのスコープが変わると言うことだし、図から最大のスコープを持っているのはオーナ自身であることが明らかだ。

それを踏まれば、プロジェクトはオーナのものだと考えるのが妥当であるが、世の中的にはPMBOKを含め、ベンダの立場で語られることが多いし、前に取り上げた日経の記事は記事内で行われるアンケートの回答者の偏りで変わってしまっている。

技術的負債をどう取り扱うか

 冒頭の質問者のもにゃった疑問は、よくよく聞くとプロダクトライフサイクルの最初のプロジェクトで制約事項から本来は考慮される技術的負債を抱えたままリリースしてしまい、それは2つ目のプロジェクトにマイナスの遺産相続されてしまうのでそこが耐えられないと言う。

プロジェクトマネジメントが適正に適用されるのであれば、技術的負債を作り込まないように作業標準化がなされているはずである。

なされているはずのものがなされていないのは、本来は適用される作業標準化をネグらなければならない制約条件若しくは前提事項が優先されたと言うことだ。

これはプロジェクトをデリバリする役割からオーナに伝え、プロジェクトとして意思決定される議案である。これを踏まえていなければ、技術的負債はデリバリするチームが勝手に行ったことであり、オーナサイドから見れば、デリバリするチーム側の負担で解消しなければならない。

逆に、技術的負債を織り込む可能性があるとオーナと議論し、オーナ同意で制約条件や前提条件を飲むとしたら、それはそれで構わない。オーナが決めたのだから。

あるあるなケースでは、技術的負債を抱えることもNGだし、制約条件も織りこめと言われる場合は、それを実現する方法に置き換えるか、スコープを分割し、プロジェクトをさらに細分化し、細分化したスコープをプロジェクトとして執行することが望ましいし、現実的である。要は、技術的負債を防止するための作業量を織り込んだ工数を見積もりし、予算が合わないなら予算の合わせたスコープにせよと言うことだ。

目標はこれで行けると納得できるまで摺り合わせしなければ、マネージャが期末に都合よく解釈することを忘れてはいけない

仕事をしていれば色々な仕事があり、仕事それぞれに目標があるのです。よろしいか、仕事それぞれに達成しなければならない目標があるのだよ。

目標管理はゲームだ

世の中には目標管理制度というものがある。個人的には、ゲーミングぽくなるので、希望の有無を問われることのないままにプロジェクトにアサインされ、なんだかよくわからない評価基準で1年の活動の成果をなかったことにされるより断然いい制度だ、と思っている。

ただし、その組織の目標管理のルールをわかっているエンジニアだけに良い制度なのだが。

 つまり、ルールをわかっていないエンジニア、ルールをわかろうとしないエンジニアに取っては、逆に目標を設定しなければならないし、面談を受けなければならないし、目標達成のトレースをされることもあるだろうから、ただただ煩わしいだけの制度に写るだろう。

目標管理という仕事

 今年も部下の目標をすり合わせる時期である。過去のエントリに書いてきたように目標管理はゲームなのでルールを覚えろ、ゲームを提供する側が何を考えているかを読め、と繰り返し伝えるのもお仕事だ。

先にチートを教える。

なぜなら、部下が評価される仕事を作り、それを評価される目標を設定させ、実績を作らせるのが仕事だからだ。

その結果がビジネスの数字になる。彼彼女らの成果がビジネスになる。つまり、儲けは部下に依存しているのだ。彼彼女らの成功なくしてビジネスの拡大はないのだ。

目標を摺り合わせよ

限られた時間のリソースをこの時期、かなり部下との目標設定のために時間を使う。なぜなら、彼彼女らの目標とマネージャの期待が一致しなければ部下の1年を棒に振ってしまうからだ。

だから、目標を擦り合わせるためにこれでいいだろうと思うところまで時間を取る。

この目標設定を１回程度でマネージャの期待とすり合わせられるエンジニアは少ない。10％もいない。

つまりほとんどのエンジニアは１回では目標設定をできない。あるエンジニアになるとなんども摺り合わせのミーティングを繰り返す。

そして、切れてしまう。

誰の目標かを考えなさい

 あるエンジニアは「もうどう書けばいいか言ってください」という。これは実際にあった話だ。

そこでこう返した。「これはあなたが実現する目標だ。それを他人に任せていいのか」と。

自分の言葉で目標を書き、マネージャと摺り合わせできないエンジニアにプロジェクトで顧客と要件や仕様、プロジェクトのトラブルの決着をできるだろうか。できるわけがない。できていると言うのは嘘で顧客の要望を受け入れているだけだ。それはすり合わせじゃない。御用聞きだ。

だから、エンジニアは納得するまで、自分が少し背伸びをして達成できそうな目標を複数せってしなければならない。納得が必要なのは、自分の目標とするためだ。背伸びは、背伸びした分が昨対と比較したビジネス貢献の寄与分になるからだ。複数設定するのは達成できなかった場合のリスク分散をするために別のアタックルートを確保するためだ。

曖昧な目標はマネージャが期末に都合よく解釈することを忘れないこと。

SANDISK USB3.0フラッシュ 64GB SDCZ43-064G (ULTRA Fit)

エンジニアとのコミュニケーションの取り方

仕事をする上で、コミュニケーションの最低ラインはリーダーと実務を担ってくれるメンバの間では、作業の期待する結果が得られるために行われればそれで十分です。

すごーくビジネスライクに聞こえますけれど、現実にはこれのためにコミュニケーションをしているし、それが出来ていない＝期待する結果を得るために十分なコミュニケーションが取れていないからあちらこちらのプロジェクトがトラブっているのですよねぇ。

コミュニケーションの原則 

 コミュニケーションは、二人以上の間で何かを成し遂げたい一人が他者に対して期待する振る舞いをするように表現手法を用いて働きかけることです。

ですから、仕事の上で、仕様を確認したい、実績を確認したい、困っていることを解決したいというような、「○○したい」で実現するために自発的に作用しなければなりません。

プロマネとメンバとの関わり方

 振り返ると、プロマネをするときには必要以上＝仕事上に関係することだけでコミュニケーションを取ることが多いです。

こちらから、あまり雑談はしないし、飲みニケーションと呼ぶような飲み会もキックオフと打ち上げくらいしか模様ししません。もちろん、メンバ同士で何をしようが邪魔はしませんし、それでメンバ同士がお互いを知り、仕事上で相談しやすくなるのなら良いですね、くらいです。

マネージャから部下への関わり方

マネージャの場合、部下がパフォーマンスを最大限に発揮できるように環境を作ることを考えて施策をします。

プロマネと違うところは、労務管理も仕事の内なところです。つまり、環境、物理もありますし、制度的なところなど組織として整えることもありますけれど、部下の身の回りのことについてもある程度把握しておく必要が出てきます。

部下自身の健康、冠婚葬祭、キャリアなどをあまりパーソナルな情報に踏み込み過ぎない程度で部下の動向を把握しておく必要があるのです。

部下への関心を持たない弊害

 個人的には部下のパーソナルな情報には関心がありません。知ったからといって中するわけでもないなら、はなから聞かない方が情報管理をしなくて良いのですから。

ただ、全く関心を持たないとこれはこれで、前述した部下の動向が把握できませんし、部下が関心を持っていることを知ることができません。

関心を持たな過ぎると突然辞めたいと言われて困るのがマネージャですし、上からどうして気づかなかったんだと言われるかもしれません。

流石に関心がないからとは言えませんし。

マネージャからコミュニケーションをとる場合

 最近の関心事をアイスブレーク的に聞くのが良いのではないかと思います。部下が関心を持っていることは部下がリソースを使ってでもやりたいことです。

「へーそうなんだ」

「それで」

「すごいね」 

部下が話し始めたら、聞き役に回ることです。批評したりdistたりすることが目的ではないので。

時間まで、話させます。

とは言え、話がぶちぶちと途切れてしまう部下もいます。ただ聞くのではなく、キーワードを拾いましょう。

「なるほどー」

「その○○ってどんな感じなの」

 部下が話している言葉を使って、関心があるよと「教えてモード」を発揮します。

こんな感じでコミュニケーションを取るとまーまーな感じには会話が成立するし、話してもらって満足感を持ち帰ってもらえます。

こうでもしないと話さないエンジニアが多いので。

あなたの話はなぜ「通じない」のか (ちくま文庫)

調達 1st LIVE「My LIVE」at Zepp DiverCity 2017.08.20

ぬーさん 

1st LIVE「My LIVE」at Zepp DiverCity 2017.08.20 [Blu-ray]

彩 -color- (DVD付初回限定盤)