退職への向き合い方

本記事はEngineering Manager Advent Calendar 2018の19日目です。

エンジニアリングマネージャーをやっているとメンバーの退職というイベントが発生することがあるかと思います。
この退職というイベントはエンジニアリングマネージャーにとってはとても悩ましくどう対処すべきなのかが難しいイベントでもあるにも関わらずテーマがテーマだけにあまり知見が共有されない話題のように思います。

そこで今回は退職についてどう向き合うべきなのかを私の観点から書きたいと思います。

退職云々の前に普段から考えておくべきこと

メンバーがいなくなるとどうなるかを考えて組織戦略を考える

退職に関わらず、怪我・病気や、ライフイベントなどでチームからしばらく離れることがあると思います。

そういった場合にチームのアウトプットにどのような影響があるか、その影響は事業の持続性、システムの持続性にどのような影響を与えるのか。 影響がある場合取れる選択肢はなんなのかを普段から考えて組織戦略を考えておくべきです。

事業の持続性、システムの持続性に関する影響例

• システムの運用が止まるもしくは遅くなるか
  • 他のメンバーで回せる業務か
  • 縮退運転が可能か、その許容期間はどれくらいか
• 収益への影響がどれくらいの期間でどれくらいの金額になるか
• 監査への影響がどれくらいあるか
• ...

このような事業の持続性、システムの持続性に関して判断するためには、メンバー、そしてチームのスキルセットを正しく把握しておく必要があります。

チームでスキルマップを作ってみるなどのワークをチームビルディングの過程などで一度はやっておくとよいでしょう。

我々はなぜここにいるのか

これは根源的なテーマです。 多様な働き方を選択できる世の中になった今あえてその組織において働く理由はなんなのでしょうか？
人によってその目的は様々だと思いますが、マネジメントとしては全メンバーのWillを把握しておくべきです。

そこから組織に期待されていること、組織として提供できる価値そしてその優先順位を明らかにすることができます。

またその目的がどれくらいのタイムスパンで達成されるものなのかも考える必要があります。

達成した先に新たな目的を考えるべきなのか、その組織を離れて次のチャレンジに移行するのか、組織の提供価値と期待がずれてきていないかを判断する基準になるからです。

できればこの組織に期待されていること、組織として提供できる価値は経営陣とも認識をすり合わせておけると理想です。退職に関しての捉え方がずれていると経営陣からのマネジメントに関する評価においても不幸な結果につながる可能性があります。

メンバーとの信頼関係

これがもっとも重要です。
上で述べたようにメンバーがその組織にいる目的や将来のビジョン、マイルストーンについて普段から腹を割って話せる関係であることが非常に大事です。

フラットな関係で双方向のフィードバックをできなければ組織の持続性において重要なインサイトを見逃すことになります。

退職したいと言われたら

以上のような前提の上で、退職の相談をされたらまずは理由を聞きましょう。
仕事を変えるというのは人生において大きな決断です。
その決断をしたということはそこに大きな理由があるはずです。

• やりたいことをやり尽くした
• 起業する
• 引っ越す
• 人と合わない
• 方針・価値観が合わない
• 報酬が合わない
• やりたいことができない
• ...

それがポジティブ、ネガティブ関わらず、考えていた組織戦略の中で想定できていたものなのかが重要です。

想定できていた理由だった場合

想定できていた理由であれば素直に送り出しましょう。

ただし、上で述べたようにメンバーがその組織にいる目的が達成されたかどうかがポイントになります。
目的が達成されていないようであれば、メンバーが抱えている問題に対して退職という解決策が適切でない可能性もあります。
そのようなケースの場合は引き止めにならないように気をつけながら率直なフィードバックを試してみましょう。

メンバー自身の課題の可能性がある場合、

• この課題についてはどう思っている？
• 何が問題だと思う？
• 誰が解決すべき問題だと思う？
• 自分の力では解決できないと判断したのはなぜ？
• それは誰かに相談した？

などです。
場合によってはまだ残ってチャレンジするという決断に変わるかもしれません。

想定できていない理由だった場合

想定できていない理由だった場合、その決断のきっかけとなった課題をなるべく聞き出しましょう。

課題をヒアリングしたらマネジメントメンバーでその課題を分析し組織としてのアクションを考えます。場合によっては経営陣を巻き込んで課題解決に向かう動きをしていきましょう。

課題をそのままにせず、必ず解決に向かっていくことを本人、そしてその他のメンバーにも伝えていきましょう。逆に課題を放置してしまうとさらに人が離れていってしまう原因に繋がってしまいます。

引き止めをすべきか

引き止めによって残る決断をし結果的に組織としてはよかった、というケースもあるかもしれません。

しかし、私は基本的に引き止めには前向きではありません。
なぜなら、引き止めは普段から期待値と提供価値がずれてしまってきていたことを見逃した挙句言われてやるというマネジメントとしてはまったくバリューを出せていない行為だからです。

想定していなかった理由で退職の相談をされた時点で手遅れという見方をしたほうがよいでしょう。

普段から先手を打てるようにインサイトの収集に時間を使いましょう。

メンバーへの伝え方

伝えるべきメンバーの数が少ない場合はメンバーを集めて伝えるのもよいです。
チームメンバーなど関わりが深い人たちへ先に本人から伝える場を設けるのもよいでしょう。

伝えるべきメンバーが多い場合は、事実の周知と今後の方針について先にチャットなどで伝えた上で1on1等の心理的安全な場で感情面も含めたケアをしていくのがよいでしょう。

ここでの重要なことはマネジメントとして退職についてそもそもどういう考えを持っているかを伝えること、課題があればそれに向き合っていくということをきちんと伝えることかと思います。

長く一緒に働いてきたメンバーが離れるのは寂しいですが、感情面だけでなく事業・システム・組織の持続性の観点から論理的に捉えることも重要です。

1点気をつけたいのは伝えるべき人に本当にきちんと伝えられているかということです。個別に伝える方針をとった場合、情報の非対称性が起きるリスクが高くなります。人づてに聞いて「知らなかった・・」となるのは最悪です。

組織の持続性について

チームそして組織はなるべく固定化して長く同じメンバーで試行錯誤し続けることでナレッジが溜まりパフォーマンスの向上につながります。

一方で、同じメンバーで同じ仕事をする期間が長くなりすぎるとダブルループ学習がしづらくなるという問題もあります。

チームは短期的な観点では固定化したほうがよい反面、長期的な観点では小さな流動性を持たせたほうがよいと考えています。

取り組むミッションを変えたり、チームを異動したり、退職したり、こういった変化は短期で大きな変化を起こすことはアンチパターンですが、長期で小さな変化を起こしていくことはむしろ組織の持続性の観点で重要です。

ということで、何を伝えたいかというと退職というとネガティブなイメージを持たれることが多いと思いますが、ちょうどいいタイミングというのも存在すると私は思っていまして、エンジニアリングマネージャーとしては真剣にやるが深刻になりすぎないようにするのが心理的な負担を考えてもよいのではないかなということです。

最後に

エンジニアリングマネージャーをやっていると組織のいろいろな課題に向き合わなければならず、ときに辛いときもあるかもしれませんが、退職のような難しいテーマについても正しく捉えることできっとうまく付き合っていけると思っています。

退職したあとも副業で手伝ってくれたり知見を交換しあったりそんな良い関係を作れたときはうれしいですよね。既存の概念に縛られずどう人とのつながりを作っていくかがエンジニアリングマネージャーの仕事の醍醐味とも言えると思います。

RSGTのスポンサーになるにあたっての思いとか

この記事は「Regional Scrum Gathering Tokyo Advent Calendar 2018」の15日目の記事です。

今回私が所属している株式会社クラウドワークスからスポンサーをさせていただくことになったのですが、そこに至るまでのお話を書きたいと思います。

(※会社のブログに書こうかなと思ってたのですが間に合わなかったため個人の見解として書きます。)

スクラム風の何かとの出会い

私がスクラムの片鱗に初めて触れたのは3年前にクラウドワークスに転職してからでした。当時は組織の拡大期で新しい人がどんどん入ってきてチーム開発に少しずつトライしていっていた時期でした。

当時スクラムの経験者は少なく、スクラムという言葉もあえて使わずにプランニング・朝会・ふりかえりのみを各チームでやるというルールのみがありました。 これは最初から「スクラムやるぞ」と型通りに推進することでの拒否反応を避ける意図もあったのかなと今では思っています。

各チームいろいろなプロセス改善を積み重ねていき、チーム開発としては次第にワークするようになっていきましたが、それはスクラム風の何かでした。

なんちゃってスクラム問題

その後自分たちが直面したのがなんちゃってスクラム問題です。 チーム開発が回り始めて、それぞれいろんなプラクティスを試してカイゼンがどんどん進んでいったのはよかったのですが、教科書通りにやったことがないため各イベントがワークしているように見えて全然本質的なところに向き合えてないという問題が起きていました。

当時は自分はチームリーダーをやっていて、メンバーとスプレッドシートでバックログを作ったり、ふりかえりもスプレッドシートで効率的にやったりなど、自分のチームはいい感じに回っている！と思っていました。

しかしながらマネージャーと一緒にふりかえりをした時に、

「スクラム全然知らない」「XP全然知らない」

といったProblemを出されてはっとしたのを覚えています。

プロダクトオーナーの役割も曖昧だし、付箋など物理のアイテムを使わずにツールに頼っていたことで表面上の議論で終わってしまい、本来の目的を達成できていなかったり。。 いいかんじで回していると思っていたけど、自己流でやっていたスクラムではない何かだと気づいたときとてもショックを受けた記憶があります。

正しい知識を学ぶ

その後は書籍やいろいろなWeb上のコンテンツから一回きちんとやるとどうなるのかを手当たり次第にインプットしていきました。

チームでSCRUM BOOT CAMP読書会をやってやれていないことをチームで試したり、外部の勉強会に参加したり、インプットと実践を繰り返していきました。 当時社内でスクラムマスターって名乗っている人はいなかったのですが勇気を持ってスクラムマスターをやっていると宣言しました。 これは結構怖かったwえ、スクラムマスターってなに？コードかけよって言われそうでw 実際は兼務でコードも書いてたのであれなのですが、最近はチーム組成の際にはスクラムマスターは誰がやるか？みたいな議論も出てくるようになったのでチャレンジしてよかったなと思っています。

そして大きな転換となったのがRSGT2018です。 自分が思っているよりもスクラムやその周辺にある概念が広く深いもので、自分が見ているものが本当に狭い範囲でしかなかったのだなと衝撃を受けました。

当時の記事 RSGT2018初参加してきた - yo-log

上記でも触れていますが、ネットワーキングパーティの際に川口さんとお話する機会があり、認定スクラムマスター研修について受けるとどういう意味があるの？という質問をしました。 答えは「火を付けられるんだよ！（意訳）」とのことでして、この言葉がきっかけで2018年3月にJim Coplien氏の認定スクラムマスター研修を受けさせてもらいました。 研修では初めて体系的に人に教えてもらうという体験でしたので、ようやくこれまでやってきたことと正しい知識が自分の中で繋がっていき言語化ができるようになっていきました。で、やっぱり火を付けられた。RSGT2018の時点でも付いてたんだけどなんかさらに薪をくべられた感じ。

ちなみにこの回の研修では8日目担当の森さんと一緒でしたw ほんといつも刺激をもらっています。ありがとうございます。

広めていく

火が付いてしまったのでそのあとはどんどん実践の範囲を広げていきました。 社内でまずきちんと本質に向き合って開発できるようにする、そして社外にもいい感じの現場を増やしていきたい、そんな思いでやっています。

詳しい話はこちら 2018年マネジメント振り返り - クラウドワークス エンジニアブログ

社内ではここまでで結構いろんな人に新たな火をつけることができたように思ってますw

スポンサーになるにあたっての思い

これまでなんちゃってでやっていたところから、自分の中でこのままじゃだめだ、もっと知りたい、もっとうまくやれるようになりたい、そう決意させてくれたのはRSGTでした。

今では社内でももっと学びたいという人も増えてきています。

私の思いとしては、そんなきっかけを作ってくれたRSGTへの貢献と、スクラムやアジャイルをはじめとしたプロセスのことを大事にしている会社だよという表明の意図を込めて今回スポンサーに参加させていただいています。

今後も引き続き社内での実践のチャレンジとコミュニティへの貢献を両立していきたい次第です。

明日はTakahiro Kaiharaさんの「ぼくがどんだけRSGTが好きか書きます」です！ 思いの丈が楽しみですね！

夫婦のチームビルディング

本記事は子育てエンジニア Advent Calendar 2018の1日目です。

開発においてはまずは何事もチームビルディングからスタートだ、ということで1日目は夫婦のチームビルディングについて考えてみます。

そもそも夫婦とは？

そもそも夫婦とは何なのでしょうか？

日本の民法では第752条にて「夫婦は同居し、互いに協力し扶助しなければならない。」と記されています。
なるほど、たしかに。子育てにおいてもこれは重要な要素であるように見えます。

しかし、どうやったら同居している中で、お互いに協力し扶助しあえるでしょうか？

結婚する前に知り尽くした相手だからそんなことは当然できている？

... 本当に本音で話し合えていますか？
こんなこと言っても通じないだろうから我慢する・・みたいになっていませんか？
価値感の違いは諦めている・・なんてことはないですか？

うちの場合はできている！...と言いたいところですがまだまだできていないことも多いと感じています。

「お互いに協力し扶助しあう」これ自体は良い定義だと思うのですが、どうやってその状態に至るか、いわゆるチームビルディングについては、夫婦では実はあまりちゃんと考えたことがない、という方が多いのではないかと思います。

夫婦のチームビルディングの必要性

家事育児をアジャイルに考えてみる

夫婦のチームビルディングと聞いてまずどんな印象を受けるでしょうか？

yo-iida.hatenablog.com

以前、上記のような話をしたことがあります。
当時私は家事育児についてもアジャイルな考え方がフィットするのではないかと考えていました。家事育児は夫婦お互いに同じだけの責任があり、限られた時間の中で効率よく進める必要があります。また、計画など決めていたこともなかなか思い通りにはならないという不確実性もあります。それに対処し持続的な関係を作るには前提となるチームビルディングが不可欠なのではないかという考えです。

とくに、子供が生まれてからはチームとして動かなければならない時が多くなると思っています。それまでは気楽なもので二人の関係性だけだったものが、急に様変わりして子供に対して夫婦で価値を届けていく構図に変わるからです。

どうやるかは色々なアプローチがあると思いますが、注意するポイントとして「仕事っぽくしない」ということを重要なポイントとしてとらえていました。
言葉で伝えるのは難しく、不要な対立を生む可能性もあるからです。拒絶されてしまうと元も子もないので自然にやっていくのがよいと考えていました。

偉そうな話をしていても喧嘩は起こる

先々月結婚記念日というイベントがあったのですが喧嘩をしてしまいました。

その時のきっかけはこうです。

家の窓が壊れており、先日の台風の際に雨水が吹き込んでくる事態が発生しました。その修理に関する業者とのやりとりを自分が担当しており、週末など手の空いた時間で進めていたのですが、妻はそうではありませんでした。次台風がきた時にまた同じことが起こり浸水などの被害が出たらどうするのか、優先順位を上げて進めるべきではないのかと指摘されました。
正直その当時は仕事が期末で忙しく自分の優先順位としては下がっている状態でした。そんなに言うのであればあなたがやったら？というニュアンスのことを言ってしまいました。妻は呆れて落胆し、自分もなぜわかってくれないのかとイライラしてしまいました。子供にも本当に申し訳なくて最悪の気分でした。

このとき何が起きたかというと、「自分はここまでやればいいと思っている、が、相手は違う基準で違うレベルのことをゴールだと思っている」という期待値のずれが起きていました。

仕事でもありがちな話ですよね。
実際、仕事では組織の課題解決などの話をよくしているのにプライベートでなぜこんな初歩的なことができていないのか。タイミングが最悪で理由はしょうもなくて情けなくなりました。

しかもこれまで何度か似たようなきっかけで喧嘩をしたことがあります。 何度も繰り返しているのになぜ全く改善しないのか、考えた結果ある仮説に至りました。

何かを変えなければいけない。「仕事っぽくしない」は実は間違った解釈なのではないか？仕事っぽくてもいいからちゃんと対話しないとだめなのではないか？

仕事でやっているやり方を家でやってみる

そもそも「仕事っぽい」とは何か。非常にあいまいで解釈的な言い回しです。
仕事でやっているやり方が一番うまくいくやり方ならプライベートでもそうやればいいわけです。

なぜそれをプライベートに持ち込みたくなかったか。
うちの場合は元々妻からプライベートと仕事は違うから一緒にしないでほしいという希望があったからでした。
家族との時間を仕事に使うのはもちろん違います。
しかし、何かの課題解決のためのよりよいやり方があればそれは仕事とプライベートを区別する必要はないのではないかということです。

それから、仕事のやり方がプライベートで適用しづらい理由はもう一つあります。
真面目にやるのが結構小っ恥ずかしい。
これは割と大きな壁です。友達に対してワークショップとかしないです。それは妻に対しても同様です。
でも、それを乗り越えてでもやる価値があるのではないか、妻と子供のためならうまくやらなければならない、そう思いました。

チームビルディングのワークとしては、インセプションデッキやドラッガー風エクササイズなどを思い浮かべる人が多いのではないでしょうか。

その視点で考えてみると、
妻が自分に何を期待しているのか
自分が妻に何を期待しているのか
自分たちはどうなりたいと思っているのか
あまり腹を割って話したことはないな、ということに気づきました。

そこで、そこからまずは話をしてみようとなったわけです。

どうやったか

喧嘩している途中だったのでワークをやる空気ではなかったのですが、何かを変えて考えていく必要性があると伝え以下のワークを二人でやりました。

• 相手のだめなところ、不満に思っていることを書き出す
• 相手のいいところ、満足していることを書き出す
• 相手への期待を書き出す
• 自分が今後どうなりたいかを書き出す

それぞれ5分ほどで紙に箇条書きにし、そのあと相互に話しながら説明していくというスタイルです。

喧嘩はたいてい期待と相手の行動にギャップが生じたときがきっかけになります。これを埋めて行くためには相手が普段なにを大事にして行動しているのか、を知る必要があります。

このワークの意図は、現状の不満を洗い出すことと、その反面のよいところにも目を向けつつ、未来についてどのような考えを持っているかを明らかにするというものです。そのような状態を作れたら期待とのギャップを相手の目線で考えることができ、前向きな対話になりやすいのではないかと考えました。

結果的に以下のようなアウトプットになりました。

妻から自分への不満の抜粋

• 家のことの優先順位が低いと感じる
• 仕事が忙しいと家にいる時のOffが長くなる
• やってほしいことを伝えても何週間たってもやってくれていない
• やるとなると仕事っぽいやり方↔︎やらないのどちらかで間がない
• やってほしいことを頼むと指示されているようで機嫌が悪くなる

う・・耳が痛い。
言語化すると相当いけてない人のようです。。
でもお互いにきちんと出し合えば受け入れる気になります。

妻から自分へのいいと思っていることの抜粋

• 子供の面倒は見てくれている
• キッチンまわりは協力的
• 前よりも早起きしたり生活リズムを改善しようとしている
• 喧嘩はするけど話を聞き入れてくれる

自分がまあやれているかなと思っていることはそのように受け取っていてもらえたようです。

何が変わったか

お互いの認識

まずお互いに全部出し合うとそれだけでもスッキリします。
これはこの言語化というプロセスがかなり効いていると感じていて、普段だと口頭で言い合って終わりなのですが、落ち着いて書き出すことで認識が整理される効果がありそうです。

その上で相手が何を感じているのかしっかりと聞くことができます。
一方的に言われるのではなく、自分も伝えるからこそ相手の話も聞けるというものです。

小っ恥ずかしい部分はあるのですが、これをきちんとやるとこれまでよしなにやっていた話がすり合って行動しやすくなります。
やる前はこんなのやりたくないと思っていたようですが、やった後はやってよかったと言ってもらえました。

まとめ

お互いの価値観を改めて言語化してみたり、期待のすり合わせの言語化のワークをやってみるとよいですよ。ぜひ喧嘩する前に！ 長い付き合いであればあるほど意外な気づきがあるかもしれません。

ちなみに、妻は後日仕事から帰ってきて「仕事のほうの人間関係的なところも実は夫婦喧嘩の話とそんなに変わらないのかもしれない・・」と言っていました。 ちょっと自分の考え方もわかってくれたのかなと思ってうれしくなりました。

初日から堅苦しいテーマだったかもしれませんが、夫婦のチームワークに悩んだときに参考にしていただけたら幸いです。

明日はmana_catさんです！

なぜマネージャーをやるのか

8月も半ばを過ぎ、夏が終わろうとしてます。
マネージャーになって4ヶ月目。

なんでマネージャー大変なのに頑張んのよ？っていう問いをもらった

ある日の飲み会で聞かれた。
自分でもなんでなのかよくわからなくてその時は浅い回答しか出てこなかったのだけど、ふとしたときに考えているうちにこれかも？というものが見えてきた。

今の自分にとってマネジメントとはチャレンジ

チームリーダーとかはやってきたけどきちんとマネージャーの権限と情報と責任をもったのは4月から。経験のあるものでもなければスキルがあるわけでもない。未知の世界であり、面白いからという知的好奇心の割合が8割くらい。

あとは自分の市場価値を高めるためのチャレンジ要素が2割。ここでやったという経験はきっとこれからも役に立つと思ってる。

そして、これは今の会社にくる前から思っていることだけど、明日会社がなくなってもなんの心配もいらない人間になりたいと思っていて、そういう文脈もある。（今は結構会社目線としても考えるようになったのでどっちかというと会社を持続的にするためにどうするのかという見方もしているが）

マネジメントにおける知的好奇心とは

色々考えた結果、アジャイルな組織とはどんな組織なのか、中でも自己組織化を突き詰めた先に何があるのか、を自分の体感として知りたい、ということが一番大きいと思った。

アジャイルやスクラムの本を読むと必ずこの自己組織化という言葉が出てくるけど、結構都合のいい形でも使えてしまう言葉なので、ちゃんとやったらどうなるんだろうということを自分の目で確かめたいというかんじ。

いろんな事例を聞いてもやっぱりまだまだ局所最適の事例が多い印象で、組織全体でやりきった事例ってあまりないので（僕が無知なだけかも）自分がやりきったと言えるようになりたいというのがモチベーションな気がする。

しかしながら、自己組織化等を軸に改善し続けている人はきっと「やりきった！」とは絶対に言わない気がするので答えのない問いっぽい。
自分もおそらくどれだけやってもまだまだやりきってはいない、、と思う気がする。

あとは 組織の成熟過程における人の成長 も未だ答えがなくて自分なりの答えを探しているところ。これは組織が安定化すればするほど個人の成長の機会は作り出しにくくなるという話。人は新しいことにチャレンジして変化していくことで成長していくので、組織としては意図的な不安定さを生み出す必要がある。が、そんなことは物理的にも心理的にもそう簡単にはできず、うまくやれるパターンを見つけ出したい。

問いの答えは問いだった

まとめると、なぜやるのかと言えばそこに問いがあるから、ということになりそう。

• アジャイルな組織とは?
• 自己組織化したチーム、個人とは?
• 組織の成長と個人の成長の関係は?

引き続きがんばる。

宣伝

関係ないけど XP祭り2018 登壇します。

http://xpjug.com/wp-content/uploads/2018/08/XP2018_timetable.pdf

チームビルディングとか場の話をします。

非対称性の連鎖（情報→楽しさ→モチベーション）を超えていくために

マネージャーになって2ヶ月ほど経ったが、最近思うことがあったので書いてみる。

情報の非対称性とは

情報の非対称性と調べると市場における情報格差が出てくるが、ここでは組織における情報の非対称性について話す。

情報の非対称性自体は、2者がいるとき一方が知っていて一方は知らないものがある状態のことを指す。

組織における大きな意思決定の情報は、権限のピラミッドにおいて上から下に流れる。簡単のため、経営陣→マネージャー→社員という3ステップで考える。このとき非対称性と呼ばれるのは、「経営陣が知っていてマネージャー、社員が知らない情報」、「経営陣、マネージャーが知っていて社員が知らない情報」がある状態のことを非対称性が発生しているという。

この組織の意思決定における情報の非対称性は単に伝達の途中で間違って伝わったりロストするリスク以外にも様々な問題があるのではないかと思ったことが発端である。

情報の非対称性の例

上司「最近どう？大変そうだけど、この仕事今月中には片付けたいね」

部下「いや、これは来月末までかかりますよ。」

上司「来月はXXの案件が始まるからきついなー、部下にはメインで入って欲しいからはみ出るとしても誰かに任せられるようにしておいてよ」

部下「いや、その案件は初耳です。。」

上司「今期中に小さめので実績積んで、来期でかいの取りに行きたいんだよね。ここで実績作らないと次に繋がらないから先週急遽決まって。言ってなかったっけ？まあそういうことだから。」

部下「そうですか。。どうにかします。。」

（あるあるっぽいやつを想像で書いており事実に基づいた話ではありません。）

ここで起きているのは単に次の案件の開始時期が伝わっておらず業務調整が困難になっているということだけではない。

隠れているであろう事象はたとえば以下のようなことである。

• 上司はこの構想を半年前から考えており、資料ベースでは部下に共有している
• 上司の構想は経営計画から逆算して作った事業戦略である
• 部下は経営計画の内容は知らない
• 部下は上司の構想の資料を読んだことがあるが目の前の仕事とは紐づいていない
• 上司は部下の抱えている具体的な課題を把握していない
• 上司はこの計画がうまく行けば大きな利益貢献ができると見積もっており楽しみにしている
• 部下は仕事が増えることを悪く思っており、仕事を増やすために安い仕事をしたくはないと思っている

これを非対称性という観点で深掘ってみる。

楽しさの非対称性

上司は経営計画から考えて自分の管轄する領域で次の大きな仕事が取れた場合全社的なインパクトも大きいためとても楽しみにしていたとする。 経営計画という 「経営陣、マネージャーが知っていて社員が知らない情報」という非対称性の中で自分が主導権を持って考えているため楽しみにするのは当たり前の話である。またその方針決めにあたって経営陣とも調整しており期待を持たれているため成功に向かうモチベーションは非常に高い。

一方、部下は上司のことを無責任にとにかく仕事を増やす上司だと思っており、なぜその仕事をやるのかは理解していない。楽しさはなく、仕事をこなすだけになっているのでモチベーションも低い。

ここでは、情報が非対称であることで仕事における楽しさも非対称性がおきる可能性がある、ということを言いたい。

これはいわゆる「当事者意識を持て」という無茶振りに繋がりやすい。情報非対称性がある状態で情報の少ない側に「当事者意識を持て」というのは戦場で武器もないのに戦えと言っているようなもので、ほとんどのケースでプラスに働くことはないと考えている。

モチベーションの非対称性

仕事の楽しさに非対称性がある場合は、ほとんどの場合モチベーションにおいても非対称性が存在する。

例えば、上司は成果物に高いクオリティを求めるが部下は最低限のクオリティで切り抜けようとしている、といった具合だ。

モチベーションの非対称性があるチームではほとんどのことがうまくいかなくなる。まずはそういう仕事の質に現れ、コミュニケーションにずれがおき、だんだん人が来なくなるだろう。

人が辞める理由は何通りものパターンがあるが、元をたどるとこのような情報の非対称性が辞めることに繋がるケースも少なくはない気がしている。

インセプションデッキで超えられない壁

アジャイルソフトウェア開発においては、バックグラウンドやスキルセットが異なる人たちでチームを組成した際にチームビルディングのワークとしてインセプションデッキというものを作ることがある。

知らない人は、 5分でわかった気になるインセプションデッキ を読んでわかった気になってほしい。

一番最初のワークは「われわれはなぜここにいるのか？」という質問についてチーム全員で考える。チームの目的や組成された背景などを自分たちで考えて言語化してみるというものだ。

これにより、チームはどこに向かって何をすべきなのかがなんとなく把握できる。

しかし、プロジェクト開始時に方向性が見えていてチームがいい雰囲気で動きはじめていたとしても情報の非対称性は容赦無く忍び寄る。

「お客さんの都合で作るものが全く変わった。これまで作ってきたものは役に立たない。」

「1ヶ月後にはこのチームは解散することが決まった。」

「明日から当社はXXホールディングスの傘下に入る事になった。」

など。

仕方ないと割り切れることであればいいが、そうでないことも多い。そして振り回されるうちに楽しさはなくなりモチベーションもなくなっていく。なぜここにいるのかで考えたものと現実のギャップが大きくなってしまうとインセプションデッキはもはや役に立たない。

メテオフォールという表現もある。

情報の非対称性をどうやって超えるか

いくつかパターンがありそうなので整理してみる。

1. 非対称性を受け入れていく

非対称性はもはやどうにもならんとする考え方。

情報量、権限、責任は比例的に大きくなるように見える。情報がほしければ必要な対価を払うべし、的な考え方で合意していく。「当事者意識もて」とか言わないから上から降ってきたものはやってね、という合意。

旧来の強いリーダシップ型の組織で行われていたマネジメント的なやつ。

2. 非対称性をなくしていく

こちらを頑張っていきたい。

が、その前に自分の知っている情報をどんどん伝えていくことで情報の非対称性は減るはずなのになぜできないか？

• 伝えること自体のコスト
• 伝えた後のフォローのコスト
• 伝えた内容をアップデートするコスト
• 伝えることで法的リスクになるケース

などがありそうだ。

最後のやつはインサイダーとかなので議論してもしょうがないのでいったん無視するとして、他の三つは意思をもってコストを払えばもっとうまくやれる可能性はある。

例えば課題の報告が前向きな気持ちになれないのと同じで、インセプションデッキをひっくりかえすようなお知らせもマネージャーは当然しにくいのである。（そんな素振りを見せないマネージャーがいたらそういう気持ちを押し殺して気丈に振る舞うタイプか、本当にサイコパスかどちらかである。後者なら早く逃げた方がいい。）

伝えるということは自分が説明を求められる。そのためには全体像を理解し、自分の言葉で話せるようにする必要がある。自分の言葉で話すということは自分が批判される覚悟を持つと言うことである。

そして伝え方。内容によって、全員一緒か、1on1か、これもパターンがありすぎて、どれが適切なのか判断するのは非常に難しい。

そしてもうひとつポイントがあって、決定事項として伝えるのか、相談として伝えるのかという二択。決定事項として伝えるのは楽だが、そこに対して伝えられた側が考える余地がないため楽しさは減る。ということで考えてもらうために相談という形をとったほうが望ましいが、これはこれで伝えた内容を時間をかけてアップデートしていく必要がありとてもコストがかかる。特に上から決定事項で降りてきたものを下に相談でやりとりするのが一番コストがかかる話で、内容次第では自分より強い権限を持っている相手に決定を覆す相談をするのでこの領域になると相当なコストを払う必要がある。

しかしながら、正しいことをやっていく強い気持ちがあればこのコストも払えるだろう。

情報を持っている人はどう振る舞うべきか

結局情報を持っている人は何をすべきかという話で考えると、それを誰かに伝えて、フィードバックを得て、その情報をよりよいものにするということが理想的な状態のように思える。

だから経営陣やマネージャーのような情報と権限を持っている人は自分で手を動かしたりしていてはいけない、というのはこういう話からくるのではないかと思う。コストをかけるべきは意思決定を継続的によりよくする活動である、ということ。

日々の細かい仕事に忙殺されているようではいかん。（自戒をこめて）

家事と育児とアジャイルについて話してきた

先日「子育てエンジニア Hack共有会」というイベントでLTしてきた。

visasq.connpass.com

スライドは以下。

アジェンダ的にはガジェットネタが多かったため、プロセスとか考え方の話をしてもうけないかもと思っていたが、思ったよりうけたのでよかった。

その日は参加者の人と懇親会で喋り、「エンジニアリング組織論への招待ネタっぽい」みたいな感想をもらったりしていた。

その後speaker deckに資料をあげておいたら思ったよりはてブが伸びて驚いた。 みんな似たようなことを考えてるのかなーと思った。

ちょっとだけ補足

LT時に口頭で話したこともあったのでちょっとだけ補足。

家族がそのまま受け取れる価値とは

動くソフトウェアを家庭に落とし込んだら何になるかなーと思って出てきたのがこれ。

わかりやすい定義ではないけど、たとえば、料理と片付けどっちがやる？みたいな議論に時間を使うんじゃなくてやれるほうがやって子どもと過ごせる時間増やそうとか。

あとは、週末飲みに行くかわりに平日1日早く帰るとか、見合っているかはさておき行動や提案を素早くやっていくことが価値なんじゃないかなと思う。

見える化について

ツールやガジェット使いたくなるのはわかるけどまずは物理からやってみよう、はスクラムと一緒。

目につくところに置いてみてコミュニケーションが生まれるかがポイントとなる。

そこからツールつかったりガジェットで効率化したりは全然あり。

懇親会でも「まず物理カレンダーやってみようと思いました」という感想をもらったが意外とやってない人も多いのかも？

機能横断的夫婦について

子どもが生まれてから「家事を手伝う」と言ったことがあったのだけど、これがとても妻の怒りを買ってしまった。

「"手伝う"って何？なんで私がやる前提で話してるの？」

当事者意識がめちゃくちゃ低い発言だったということだった。まったくもって機能横断的ではない。

これはスクラムでチームが機能横断的でパフォーマンスを出している状態とはどういうことかを考える中でめっちゃ反省した。家ではゆっくりしたいっていう意識ってどうしても出てしまうと思うんだけど自分も相手も一緒なので意識して行動する必要がある。

仕事っぽくしないが一番大事

家事育児は仕事よりももっとウェットでソフトスキルの世界なので、目的に感情が絡むことも多々ある。

プロジェクト管理みたいなワードを持ち込むとたいていうまくいかない。

アジャイルソフトウェア宣言を夫婦に落とし込んだとかいっても引かれてしまうというオチだろう。ただ、考えてみることは大事だと思ってて、それに沿って実践できているかを自問自答するくらいから始めるといいと思う。お互いに成熟してきてそれが当たり前だという状態になったらネタばらししてもいいかもしれない。

一般的にも妻のほうはこういうことを日常的に考えていて自然に実践しているので夫の方がどう考え方を変えるかなんだと思っている。わざわざ小難しい言葉で表現する必要はない。不言実行でやっていきましょう。

現場からは以上です。

またどこかでこういうネタで話してみたいとおもいます。

アジャイルとスクラムについて社内勉強会で話してきた

今年に入ってからRSGT2018にいったりCSMをとったりしてスクラムをちゃんとやるためのインプットを多めにやってきた。

色々感じたことを一言でまとめると、根本から知ることでもっとうまくやれるようになるのではないか、ということだった。

個人的にはこれまで形から入ってうまくいったりうまくいかなかったり・・みたいな部分部分での経験値が全体観としてみれるようになった気がする。

ということで、プラクティス以前の考え方の部分を改めて伝えてみることでさらにプロセス改善に興味を持ってもらえるかなと思い社内勉強会で話してみた。

途中付箋などで色々意見を書いてもらったがポジネガどちらのフィードバックも出たのでよかった。

目的は常にプロセス改善し続けることで、スクラムをやることではないんだけど、こういった知識をインプットすることも大事だと思っていてどうやって押し付けがましくならないようにするかは難しい。。

引き続きどうやって組織全体の開発プロセスの向上をやっていくか考えて行きたい。