ユーザベースにおけるアジャイルリーダーシップの実践 - UB Tech vol.5に参加してきた

uzabase-tech.connpass.com

こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。

会の概要

以下、Connpassのイベントページから引用です。

ユーザベースはテクノロジー・カンパニーとして「エンジニアリングの力で、誰もがビジネスを楽しめる世界をつくる」を目指しています。この世界の実現に向け、エンジニアの成長はとても大切なテーマ。 これまでも、一人ひとりが持っている個性と可能性を最大限に引き出すため、試行錯誤を重ねてきました。このシリーズはそんな私たちの日々の学びを共有することで、明日のエンジニアリングを少しだけより良いものにしていくための勉強会です。

今回は、ユーザベースが翻訳し、先日出版された『アジャイルリーダーシップ』をテーマに、ユーザベースでの取り組みを紹介した後、みなさんからの質問にお答えする形でのパネルトークをお届けします。

会の様子

事例講演1 1 on 1から始まるアジャイル組織の第一歩」〜 岩見恭孝さん〜

1on1を通してコーチングのスキルを伸ばし、アジャイルな組織づくりの第一歩を踏み出した事例の講演をしてくれました。

1on1においては「コーチ」と「クライアント」のパートナー関係を築くことが重要だと考えているというお話で、ユーザベースではこの「コーチ」を立候補制で募り、1on1のふりかえりを「コーチ」と「クライアント」でお互いにしながら「コーチ」のコーチングスキルを高めていくことを目指しているということでした。

事例講演2 自分たちで仲間を集め、育てあうエンジニア組織で起きていること〜木村直人さん〜

アジャイルな組織を作るために、共同経営者となる仲間を集めるためにやっていることや仲間を育て合うために起きていることを話してくれました。

仲間を集めるためには、思考が柔軟でいろいろなことを熱心に学んでくれることが期待される新卒採用を中心に採用を行えるのが理想ということで、その準備としてエンジニアが率先して採用活動に取り組んだり、インターン制度など新卒採用を行うための窓口を作っているという話をしてくれました。

また、仲間を育て合うための取り組みとしては、

• 頻繁なふりかえりを行う
• フィードバックを常に与えられるように必ずペアプロをする
• あらゆる透明性を実現するために、給与をフルオープンしている。給与は360度フィードバックで行い、フィードバックの評価基準もすべてエンジニアが決めている

を実践しているそうで、これらの結果、自分たちが考えざるを得ない環境やオーナーシップを持たざるを得ない環境が実現できているということです。

事例講演3 Zuziさん、私、リーダーにあんまり向いてないと思うんです〜二木拓也さん〜

二木さんがリーダーに向いていないと思うという理由と、Zuziさんの本を読んだ後に起きた変化を話してくれました。

二木さんはリーダーを務める頻度はそこそこ多いそうですが、自分だけが問題解決に向かってしまって周りが全然ついてこなかったり、メンバーに指示をするようにお願いされて守った結果自分がボトルネックになってしまったりといった失敗経験があるそうで、これが原因でリーダーには向いていないんじゃないか？と思ったそうです。

しかしZuziさんの本を読んで、信頼、忍耐、安全の重要性やリードをあまりしたくない(あまりしない)リーダーがいてもいいという話を聞いたり、自分が指示をする場面/しない場面の使い分けなどが学べたそうで、非常に勇気をもらえたということでした。

パネルディスカッション

以下、パネルディスカッションで出ていたお題に関して、お題と内容を常体&箇条書きで記載していきます。

リーダーとはどういう人だと皆さんは表現するか？

• 「指示を出してくれる人」「タスクを振ってくれる人」のようなイメージも間違いではないと思うが、「周りを支援してチームメンバーがビジョンや目的に向かっていけるような人」がリーダーだと思う*1
• 解決すべき課題があったときにオーナーシップを持って何かしらの発言をしたり行動を起こす人がリーダーだと思う
• 周りを強くする人がリーダーだと思う

1on1で自分より明らかにスキルが高いメンバーをコーチングするときにどういうことを意識するのか？

• 相手のほうがスキルが高くても、相手が課題を持っていないことはない。相手の話をよく聞いて相手の問題を探れば、相手の役に立つことはできると思う
• コーチングスキルは独立したスキルなので、決してプログラミングのスキルが劣っていても問題ないとは思っている

アジャイルに価値を見いだせていない組織がまず取り組むことは？

• 1on1をはじめたり、アジャイルに共感する人を増やすのが重要だと思う
• ふりかえりなどで仲間づくりをしていく

お互いを評価し合うことで問題はなかったのか？そのときどう対応したのか？

• チーム横断で評価を確認することでフェアネスを確認するようにしている。
• 不平不満を言いやすい環境を作り上げる

忍耐ってどれくらい待つのか？

• 個人的な話で言えば、「忍耐する」ことにふっている

リードしないと評価はされにくい気がするのだが、リードしないリーダーはどういう評価になるのか？

• リードできないと給与が上がりにくいというのはそう
• ただし、疑問を素直に投げたりチームがぐちゃぐちゃになっているときに状況を整えるということも評価されるので、リードできないと評価されないわけではない

オンボーディングのコストをどう判断しているのか？どうコストを払おうとしてるのか？

• オンボーディングのコストを引き受けられるだけの仲間を集める

自分がやらないとどうにもならない状況をどう打開していくのか？

• 自分がやっちゃうのはやっちゃうではいい。そのときに思考のプロセスを開示したり、解決した後にフォローアップをするような時間を作る

自分から採用や評価制度を変えるのは難しいと思うのだが一歩目として何をやるといいのか？

• 採用面接をやっている人と一緒に面接をやる。同席してみる

会全体を通した感想

採用制度や評価制度をすべてエンジニアたちがマネジメントし、実態としても継続的に変え続けているというのは、素晴らしいなあと思って聞いていました。

最近出版されたアジャイルリーダーシップとリンクする部分も多くあり、面白いイベントでした。

*1:結果的ん指示を出してくれる人、という風に具体化されることもあるはず