率いる側になるまでの動き方
べるどす。
の2日目の記事です。
前回の記事で反響があったので、それに関連した話をかきかきしていきます。
信頼ポイントをいつまで貯め続ければいいんですか、もういい加減にしてくださいって思ってる人向けにお願いします。
1. 指示されたことが十分できること、改善案の提案と実行ができることを示して、信頼ポイントを貯めます
の次のステップっていうのが正しいかも。チュートリアルの次の2歩目とおんなじイメージ
前提
今回は話を簡単にするためにまあweb系のエンジニアの会社というか組織についての話だとします。
信頼ポイントについて一応認識を合わせておきます。
重要なのは、周りからどれだけ信頼してもらえるか。その「信頼ポイント」が高くなるほど発言力が強まって、周りを巻き込めるようになります。
周りからどれだけ信頼しているか、を示す自分や周り独自のバロメータのことですね。目には見えません。
指示されたことが十分できること、改善案の提案と実行ができることを示して、信頼ポイントを貯めます
これがメンバーとしての最低要件と思われてるっぽいです。
まあ機能要件的には間違いではないのですが、自分は組織で働く人間として以下の前提、考えを付記したいと思います。
仕事は助け合いでできている
仕事では、誰かが開けた穴(例えば突発的な体調不良、計画的な育休、その他様々な休暇など)は必ず誰かが埋めてくれています。これは自分が自覚的/無自覚的に穴を開けたことがあるかどうかに関わりません。そういう仕組みで回っているということです。
後に詳しい対処法を述べますが、「自分だけが頑張ってる、なんか空回りしてる」みたいな気持ちになるときは大体1日〜1週間くらいズル休み、サボりをした方がいいです。(：特に体調不良とかやむを得ない事情ではなく休みを取ること)
人への興味、リスペクトを持つ
大袈裟に言えばその人の行動原理ですね。
その人が何を思って(目的として)、どうしたのか/しなかったのかに関するデータを蓄積していくことが大事です。大体は前者が見えないからモヤモヤするわけですが。それこそ前提というか住んでる世界が違う(cf. 「お仕事」としてプログラミングをされている人)場合もあるので、そういうときは魚類だったと割り切るしかないです。でもそれは割と最終手段というか、例えば自分の精神や身を守るなどのより優先度の高い課題ができた時だけにした方がいいと思います。そうやって曇ってしまったメガネをクリアにするのは簡単なことではないので。
本題
とりあえずエンジニアとして働くメンバーとしての機能要件がクリアできたところで、チームを率いる側になっていくまでに自分だったらやる動きとその考えを書いていきます。例によって書きながら考えています。
これはやろうと思えばできる構造化をある程度サボって速さを優先することを指しています
まず結論としては、近道はないです。
強いて言えば、
- マネージャーのポジションが人事的に空いた時
- 新卒教育とかOJTとか特定の時期でチャンスが発生する時
だけですね。それでもその時までに一定の信頼ポイントが貯まっていなければいけないのは事実だと思います。
組織に対する不確実性を減らす
不確実性を減らす≒情報量を増やすことです。
目的は自分が動きやすく+周りを動かしやすくなるためです。
ヒト・モノ・カネ・データ......
情報になるものはなんでもプラスであるという考えを持ちましょう。
ヒトの具体例としては先ほど書いたこれです。
その人が何を思って(目的として)、どうしたのか/しなかったのかに関するデータを蓄積していくこと
プロダクトに関しても同様です。
サブクエストを優先的にこなす
目的は一つ上と同様です。(自分が動きやすく+周りを動かしやすくなるため)
まず、周りの人が困っていること、解決したいと思っていることを把握します。ヒアリングでも、普段の言動や行動でも、いろいろ観察していきます。
「あったら便利」はこれに当てはまらないことがあるので注意が必要ですが、まあ一旦含めちゃっていいと思います。
次に、自分ができそうなところからアプローチしていきます。
- 自分で解決できそうであれば、手を動かしてつくったり整備したりする動きをします。
- 誰かを巻き込んだ方がよければ、声をかけたりインタビューしていきます。
- これがサクッとできるようになるために、普段から社内の人を把握しておく必要があるわけです。
- ex.
- インフラに詳しい人「デプロイならお任せあれー！」
- 社内仕様のこの辺に詳しい人「このシステムなら隅から隅まで知ってるよ」
- 人に詳しい人「自分に聞けば知ってる人と繋げてあげるよー」
- 逆に頼られる側になる必要があるときは、この辺のブランディングが効いてくるのではないでしょうか。僕はまだ道半ばですが。
- 実はこれも多分率いていく側になるための別アプローチというか別解ではある気がします
あと、これには目的がもう一つあって、これは直に信頼ポイントを稼ぐことに繋がります。
人は何かをしてもらった人しか基本的に信頼するようになっていきません。というかそもそも認知しません。
そもそも(×2)、信頼とはなんでしょうか？
信じて頼ると書きますね。完全に信じてたら「信じる」という言葉は使われません。
この人なら任せてもいいなって思ってもらうには人の心が密接に関わっているので、こういう行動が必要なわけです。情けは人の為ならずっていいますよね。
注意としてはメインクエスト(リリーストレインとかマイルストーンで敷かれているチームの最優先課題)が疎かにならない程度にしましょう。といっても、そっちがヒマなら今はサブクエストをやりまくるくらいの気持ちでいいと思います。ちいさなメダルくらいのいいアイテムは手に入るかもしれませんよ。
上司から仕事を巻き取る
「周りの人」とあえて分けたのは、周りは横のつながり、上司は上下のつながりだからです。
世の中の仕事の増やし方は2種類しかないと僕は思っています。
一つは仕事を生み出すこと、そしてもう一つは仕事を巻き取ることです。
生み出す方は、課題発見・定義に加えて優先度や温度感を周りに合わせるというハードルがあります。一方、巻き取る方はすでにある程度の優先度や温度の合意が取れていて、やるだけだがpendingでボールが止まっていたりすることが多いです。
これらによって、実際にその職能になる前にその仕事にチャレンジすることができます。実際に組織から期待されてからやるよりは、プレッシャーが少ないですね。これは興味ないやつとか半分事務手続きみたいなやつも含みます。
上の決定と自分の意見を比べて学びを得る
目的は意思決定のトレーニングです。
よくメンバーのうちから自分の意見は持っておきましょうみたいなことを言われると思うんですが、それをもっと本格的にやってみる感じですね。ここには情報の非対称性が必ず存在します。
技術的なこと、組織的なこと、なんでも学びになって情報量が増えます。本題の一つ目に書いた組織に対する不確実性を減らすにつながるわけです。
これを興味が薄かったりないことについてもやっていくことが大事です。それは将来の仕事の幅を広げることに繋がります。世の中の人間と「わかりあえない」なかでもわかりあえる幅が広がることに繋がります。無知の知。
興味のない話してもなんとなく興味持って話聞いてれば一つくらい面白いところがあるはずです。
「立場」を得る
新卒研修なり、OJTなり、特定の時期で一時的に「率いていく」側のチャンスが回ってくる時があります。また、それ以外でもたまたまチーム編成の中で自分がフロントに一番詳しいとか、そういう状況はあると思います。そういった状況は積極的に利用していきましょう。
ここで学んでほしいことは、自分で進められるから自分一人でやるのが「最適」とは限らないということです。
大体そういう状況の時、期間とかリソース的には最適かもしれません。もしくはその他のボトルネックがない場合。しかしそれはプロジェクトを進めるという視点から見た時だけではないでしょうか？例えば、複数人を巻き込んでやれば知見の共有の手間が省けるかもしれません(実際に手を動かしてるので)。一人でガッと進めた基盤整備が放置される原因は大体これと逆の現象ですね。啓蒙は地道にやっていく必要があるので(そもそもそれが継続的にできる体制を作る必要がありますが。)
その先：動きやすさを得たいのであれば、そういうトレードオフを飲んだ方がいい場合があります。組織にとって自分や自分の行動がプラスであるということのアピールが自然にできる状態が理想です。
また、最適化しすぎないということも重要です。チームの中に足並みをそろえたい人がいる場合、説得してもダメな場合は早めに失敗させて学ばせるなど別の手段をとる必要があります。説得コストと失敗してからのリカバリコスト(もしくはその他の手段に払うコスト)を天秤にかけて、より良い方向に状態を進めていきましょう。
僕は大学の時、「べるは最適化されすぎてるね」と言われたことがあります。これは「それって正論だね」並にいまだにムカつく言葉のひとつなのですが、こと組織運営においてはそういう場合があるということです。
その時の現象としては、自分は「メンバーの声は聞きすぎてはいけない」ということが分かっていたしそう行動していたものの、他の人(組織運営の経験が浅い人)から見た時にはそれが不自然もしくは冷たく映ったのでメンバーの声を聴く側に意思決定としては倒したという形でした。その結果こっちの仕事が増えてつぶれたり不満が噴出したりしたんですけどね。僕の反省としては説得コストをちゃんと払うか、リカバリできるよう手を回しておくべきでした。その人(たち)は「運営って結局サークルの奴隷じゃん」みたいなことを言ってましたが、その行動は自分からサークルの奴隷になりに行ってるだけであって、そうなる必要性はどこにもないです。もちろん、奴隷になるという状態を一時的に経由してでも何かメリットがあるのならキャパの限り全然やりますが。
2人チームで相手が職能2つ上とかの時はあきらめて上の上に言いましょう。そもそも盤面の駒が少なすぎてひっくり返すことが不可能なので外力に頼るしかないです。
実績を作る、棚卸しておく
何を目的として、何をして、結果どうなったのか。何をしたことになるのか。査定の時に書くやつですね。
特に最後をちゃんとやっておくのが大事です。チームの週次の振り返りとかとは別に。タイムライン法みたいに、思い出すフェーズを設けてからGood/Badを書いていくのがおすすめです。自分の仕事人生の棚卸に近いですね。
もしわからなかったら【振り返り タイムライン法】とかで検索してみてください
プラスマン、マイナスマンに対する解像度を上げていく
プラスマン、マイナスマンについて
> 高い成果を出したり、より広い範囲により良い影響を与えること
マイナスマン、プラスマンってのもここに対してどう作用するかっていう意味です
マイナスマン、プラスマンを考える場合は、彼らがすでに他者であることに気をつけます。「周囲」はチーム外が理想だけど、未来の自分たち自身も含みます
まあ要は、シンプルに成果を出したり広範囲に影響を与えていくうえでプラスになるかマイナスになるかということですかね。
大前提として、組織とか世の中の問題はいろんな立場の人によるいろんな問題が複雑に絡み合っています。技術的な問題に関しては、解決策としてベストプラクティス(こうしたらいい)、もしくはアンチパターン(これは避けた方がいい)というものがはっきりしていることもしばしばですが、組織的な問題に関してはそれより複雑度が上がる印象があります。いろんな問題が絡み合っていて、しかもいろんな力が働いているので。
これの考え方としては、「自分が今どの帽子をかぶっているのか？」というのを意識することが大事です。
- 個人(自分自身)
- チームのメンバー
- チームのリーダー
- さらにその上
- 外野
- その他
ざっとこんなところかなと思います。他にもあるとは思いますが。
その上で、「誰が」「どこから見た時に」「どうプラス/マイナスなのか」というのと言語化して、データとしてためていきます。そういうロールやモデルを増やしていくイメージです。
同様に、「どうプラス/マイナスなのか」を分析していくために、問題のとらえ方、外枠も増やしていきます。教科書的な話だとプロジェクト運営、プロダクト開発、組織設計......ほかにも視点、視野、視座の話とかありますね。
先ほど組織とか世の中の問題はめっちゃ複雑みたいな話を描きましたが、問題の分類やとらえ方についても同様にいろいろ考えられます。多分、プロダクト開発の問題なのか、組織設計の問題なのか、その他かきっぱり分けられる問題の方が世の中は少ないです。そのうえで、どっから見るか、どう解くか？というのが大事なんだと思います。
さらに言えば、問題を解くことが大事なのではなく、問題をきちんと定義した上で3ヶ月後に今より良い状態にいることが大切です。
概して、個人の課題はチームの課題、ひいては組織の課題につながっているものです。
期を待つ
多分これが一番大事です。
いくら自分のコンディションが良くても、今日が試合の日じゃなかったらそれを発揮できる場はありません。同様に、ちゃんと打席に立ち続けても、いい球が来ないときは来ないものです。
「その時」が来たときにちゃんと打ち返せるように、自分の知識を経験を磨いておきましょう。技術、ビジネス、ピープルマネジメント、プロダクトマネジメント、プロジェクトマネジメント......教科書的なところだけでも、学んでおくべきものはたくさんあります。
もう一つたとえを書いておくと、人間にも一日の中で気分の波があるように組織にも「波」があります。波が来てないときに頑張らないのが大事です。50点の日は50点出せればok。
まとめ
自分の持てる限りを書いてみました。基本方針は組織に対する不確実性を減らすというところに尽きます。そのうえで、自分が動きやすく、周りも動きやすく(≒動かしやすく)なる方向に進める行動をとり続けていれば、そういう行動を継続できる人間は少ないので自然にそういう立場が降ってくる感じです。
