開発組織を改善していくための技術

OPENLOGI Advent Calendar 2022 5日目の記事です。

おはこんばんちは!!
尾藤 a.k.a. BTOです。

今年の8月にオープンロジという物流テックの会社に入社しました。入社してから4ヶ月経ち、無事に試用期間が終了したということでほっとしております。

今までウノウ、UUUM、Reproという会社でCTOを歴任してきました。立場や経験上、開発組織の立ち上げや改善に携わることが多いです。今まで自分がやってきて、開発組織を改善するために気をつけていることを書いていきます。

既存のシステムをリスペクトする

あなたがこの瞬間のシステムを切り取って見た時に、仕組みがぐちゃぐちゃだったり、意味不明な処理をしていたり、不合理な仕組みになっていることは大いにあると思います。しかしながらこれまでの会社を支えて売上を作ってきたのは、紛れもない今のシステムなのです。過去の経緯もいろいろあるでしょう。今の状況を嘆いたり、過去を批判したところで何も良くなりません。前向きにどうやったら状況を改善することができるかを考えることが大事です。

課題解決の黄金フレームワーク「調査→計画→実行」

開発組織を改善していくためには、課題をどんどん解決していかないといけません。そのために私が使っているフレームワークが「調査→計画→実行」です。このフレームワークは非常にシンプルですが強力かつ効果的です。よくある失敗は「調査」をしないで「計画→実行」をすることでしょう。あてずっぽでやってもあまり効果が出ないで工数を無駄に使うことは少なくありません。課題解決は「調査」することから始めるのが鉄則です。

意思決定する

「調査」するところまでは自らの手を動かせば良いので、ここまではほとんどの方ができるでしょう。しかし「計画→実行」には意思決定が必要となります。意思決定をするのは言うのは簡単ですが、実際に実行するのはなかなか難しいです。過去にリーダーの意思決定力が弱いことが原因で改善が進まない事象を何度も見てきました。人それぞれ考え方や価値観は違うのですから全員の合意や納得感を得るのは難しいです。大きく反発されることもあるでしょう。時には強い気持ちをもって意思決定することも必要になります。

戦術ではなく戦略を意識する

システムを改善していくためにはいろんなことを実行しないといけません。「コード整形」「テストコード」「リファクタリング」「テーブル構造の変更」などなどいっぱいあります。これらの施策は全て正しいですが、うまくいかないケースが非常に多いです。うまくいかない典型的な例は、1チームが試験的に始めるが全体に普及せずに頓挫するパターンです。私はこのようなケースを「局地戦」と呼んだりするのですが、うまくいかない理由は全体戦略がない状態で戦術として実行しているからです。戦術レベルの施策をうまく実行するためには、必ず全体戦略の施策の一つして戦術レベルの施策が実行される状態を作るのが大事です。

計画を立てる

全体戦略を決めるためにも計画を立てなければ物事は進みません。一つ一つの施策が点として存在しているだけでは、「何を解決してどういう成果が出るのか」「どういう順番で実行していくのか」「なぜその優先順位になっているのか」などなど不明瞭なことが多くなり、周りの合意を得るのが難しくなります。人を巻き込んで物事を進めようと思ったら、ある程度計画を立てることは必要です。

仕組みで解決する

課題を解決するときは必ず仕組みで解決するようにしましょう。気をつけましょうとか頑張りましょうという考え方は、人が入れ替わった時に同じ問題が発生しますしスケールしません。私が嫌いな言葉の一つに「ダブルチェック」があるのですが、これはただの現場猫案件なので何の課題解決にもなっていません。課題解決をするときは必ず仕組み化されているかを意識するようにしましょう。

実行の優先度は「自分 > 自チーム > 他チーム」

課題を解決するためには実行しないと何も結果を得られません。実行する時の優先順位は自分 > 自チーム > 他チームです。いきなり他チームに依頼をして物事がうまく進まない人を見かけますが、他チームには他チームの事情や考え方があります。そもそも成果が見えてないところにいきなり貴重な工数を割いてもらうのは都合の良い考え方でしょう。まずは自分たちで始めてみて、実績や成果を上げてから、他チームに働きかける姿勢が大事です。

説得には「論理的腹落ち」と「感情的腹落ち」が必要

自分一人で実行できることには限界があり、大きく物事を動かすためには人に動いてもらう必要があります。人に動いてもらうためには説得する必要があります。人を説得するためには論理的腹落ちと感情的腹落ちの両方が必要です。論理的腹落ちだけを求めるは正論です。逆に感情的腹落ちだけを求めるのは感情論になります。両方ともたいていの場合うまく人を説得することができません。論理的に物事を構成しつつ、相手の感情に配慮してコミュニケーションをとることが大事になります。

相手が理解するまでが情報伝達

みなさんも自分がちゃんと言ったにも関わらず相手がちゃんと理解してくれないと思ったことはありませんでしょうか。それは本当にそうでしょうか。情報伝達は言葉を発するだけでは不十分で相手に理解してもらうまでやらないといけません。私は資料を作るのは嫌いだし苦手ですが、重要な場面では必ず資料を作ります。それは情報伝達が物事を進めるにあたって重要な要素をしめていると考えているからです。相手にうまく理解してもらえていないときは自分がちゃんと情報を伝えているかどうかを見直してみましょう。

自分の意見はポジショントークであることを常に意識する

自分が見ている世界は意外に狭いものです。特に他チームのことは自分が思っているほど理解ができていないことがほとんどです。自分の考えや意見はポジショントークであることを常に意識しましょう。意識することでより全体を俯瞰的にみて物事を捉えることができるようになります。

信頼貯金を貯めることを優先する

課題を解決するためには人と協力して物事を進めていかないといけません。そもそもあなたが他のメンバーから信頼を得ていなければ協力してもらうことも難しいでしょう。人と協力して物事を進めたいなら、まずは自分自身や自チームで実績や成果を出して信頼貯金を貯めることを優先すべきです。信頼を得られれば協力してくれる仲間を増えて、課題解決がしやすくなります。

得意な事と苦手な事を見極める

得意なことと苦手なことを区別しましょう。意外にこれはできてない人は多いと思います。特に多いのが好きだけど苦手なことを一生懸命やるパターンです。苦手なんだけど好きだから一生懸命やって、ずっと成果が出ない状態が続きます。自分が何が得意で何が苦手なのかはちゃんと言語化しておきましょう。得意なことはやればいいだけですが、大事なのは苦手なことに対してどのように対処するかです。

苦手なことに対しての対処の方法は、①克服する、②誰かに任せる、③やらない、この3パターンしかありません。③は選択肢としてはとれませんが、①か②のどちらかを選ぶ必要があります。①の場合、私は方法論に落とし込むようにしています。感覚でやると必ず間違えるので方法論に落とし込めば一定の成果を出せるようになります。②の場合は誰かにお願いすればいいですが、その時は少なくとも成果が出ているかどうかの判断軸は必ず自分で持つ必要があります。

怒らない

怒ることは百害あって一利なしです。自分の意見が通らずに怒り出す人を見かけますが、怒って物事がうまくいった場面はみたことがありません。アンガーマネジメントをしっかり身につけましょう。

諦めない

何でもかんでも物事がスムーズに進むことはありません。やってみないとわからないことも多いし、失敗もたくさんします。そこでいちいちくじけてたら何も問題解決になりません。諦めたらそこで試合終了ですよ。

敵を作らない

敵を作って得することはほとんどありません。協力者は多ければ多いほど施策の成功率はあがります。人それぞれ考え方や価値観が違うので、意見が対立することはよくあります。そういった時でも落ち着いて揉め事を起こさずに対処することを心がけることが大事です。

成功施策は分析・言語化し再現性をあげる

成功施策は必ず分析・言語化しておきましょう。そうしておけば似たような場面に遭遇した時に再現性をもって課題解決に取り組むことができるようになります。逆に成功施策の分析・言語化をしておかないと、いつまで経っても成長に結びつかないので、毎回同じことをゼロから繰り返すことになってしまいます。

失敗施策を分析・言語化し繰り返しを防ぐ

失敗施策も同じように分析・言語化しておきます。そうしておかないと同じような場面に遭遇した時に再度同じ失敗を繰り返すことになってしまいます。自分がやった施策に関しては、成功しようがしまいが必ず振り返りをしましょう。そうすることで自分の中での知見が溜まっていき、いろんな物事がうまく進むようになってきます。

結論

オープンロジでは一緒に働いてくれるエンジニアを熱烈募集しております!!!!!!

【オープンロジイベント情報】
<12/15(木)19:30〜>
「CTO・VPoEぶっちゃけトーク！　〜失敗から学ぶエンジニア組織論〜」
過去の失敗談をセキララに語りつつ、オープンロジでどんな組織をつくっていくかが語られる予定なので、ご都合合う方は是非ご参加ください！
https://openlogi.connpass.com/event/265230/