こんにちは、岡田です。
GVA TECH の「AI契約モジュール」にて、フロントエンド・エンジニアチームのリーダーポジションをしています。
今回は、私がリーダーポジションとしてどんなことを大事にしているかをご紹介します。
チーム運営の一例を知りたい方、また、GVA TECH の中にはどんな考えを持つ人がいるのか知りたい方に参考になれば嬉しいです。
前提
- 「AI契約モジュール」のコードは、5年以上の歴史があります。
- そして、現在携わっているメンバーは、私も含めてほぼ初期構築に携わったメンバーではありません。
- 日々の機能追加や改修は、既存コードを意識しながらおこなっています。
- メインフレームワークには、Vue.js を採用しています。
- 筆者は「責めるべき対象は人ではなく、仕組みのほうだ」という考えをもっています。
- 今回紹介する考えは筆者個人のものであって、必ずしも会社全体で画一的なものとは限りません。
ある日、気づいたリーダーの役割
私が本格的にリーダーポジションになったのは2022年ごろでした。
リーダーになってみて気づいたのが、メンバーは高頻度で迷ってしまっている、ということでした。
当然ですが、迷ってしまうと手は止まってしまいます。
私は、その迷いを聞いて、都度「じゃあその問題は、こうやって対応しよう！」と意思決定をしていきました。
時には、私自身はコードを書かずに、メンバーの迷いを聞いて意思決定をする、ということを繰り返すのみの期間もありました。
エンジニアとしてコードを書かないことは、悪いことかもしれないとも思いました。
しかし同時に、私が意思決定をすることで、メンバーはストレスを感じずに気持ちよくタスクを前に進められていることにも気づきました。
私１人がいることで、複数人の仕事が進むのであれば、むしろ組織としては良いことです。
この時、「私の役割って、メンバーの迷いをいち早く消して、事業を前に進めることなんだ。チームには、こういう役割が必要なんだ」と自覚するようになりました。
この考えを前提として、いくつかの迷いとその対応例を挙げたいと思います。
あと、なんか最後にポエムが出てきます。
どこまでやるかの迷い：間違うかもしれんけど、前に進める勇気
既存コードの改修において、迷いは多く発生します。
理想と、今目の前にあるコードという現実とに、ギャップがあるからです。
.oO(ここのコードが複雑なので、リファクタしたほうがよい。けど、リリース目安が決まっているなかで、どこまでやっていいんだろう...)
既存コードを改修する上では、こうした迷いが生まれます。
しかし、事業として機能のデリバリーを確実に進めることも大事です。
無限に「理想の姿」を追求・議論する時間は、残念ながらありません。
たとえば、こうした悩みには、私は下記のような意思決定をすることが多かったです。
半日という時間を区切って、トライしよう。
想像以上に難易度が高くて時間切れしたら、理想の姿をソースコメントとして残しておき、
今は最小限の対応をして進めよう。
一言で言えば、積極的に諦めていく、という姿勢です。
とはいえ、せめてソースコメントで理想実現の課題は未来に託す、ということは心掛けました。
しかし、結果として私の意思決定が間違っていることもあります。
これは技術負債を残したままにしていることでもあるからです。
実際に、残した負債で後々苦しむこともまれにあります。
それでも私が決めることによって、メンバーの手は確実に進みます💪
「諦めよう！」と勇気を出して言う役。それもリーダーの一つの役割なのかなと思っています。
解釈の迷い：迷いは悪。迷いをへらす仕組みをつくる
チームではかつて、コンポーネントのディレクトリ構成として Atomic Design を採用していました。
一見、スマートな整理方法のようにみえる Atomic Design ですが、大きなデメリットがあります。
それは人によって、解釈がわかれてしまうことです。
.oO(これは Molecules ? これは Organisms ？ どっちにすべき？)
迷う時間は、我々の手を止めて時間を奪います。
そして、なんだかんだここには誰も絶対的正解を持っていません。Web 上の記事を見ても、なんだかんだで十人十色です。
チーム内に Atomic Design スペシャリストみたいな人を１人置いて、日々生まれていくコードを判断するのも非現実的です。
この迷いに対する私の答えは、Atomic Design をやめることでした。
迷いを生み、人の手を止める仕組みは、冷静に考えてやはり良いものではありません😢
解釈の分かれる整理・命名の方法は廃止し、「十人いたら、なるべく十人の解釈が一致する仕組み」を目指すことにしました。
具体的には、命名やディレクトリ構成を Vue.js の公式スタイルガイドに準拠するように方針を決めました。
Atomic Design では、「これは⚫︎⚫︎レイヤーなんじゃないかな...」「いや、自分の解釈だと▲▲レイヤーだ！」という議論は、いつまで続くかわかりません。
しかし、「根拠は、Vue.js の公式ガイドにこう書いてあるからです！」と説明できるルールの下ならば、議論は1秒で終わり、誰も迷わなくてすみます。
公式ガイドはルールが多くて細かいですが、迷いを消すならば、オピニオンの強いものほど助かります。
さらに、公式ガイドでカバーできなかった部分は、チーム内で話し合い、合意した方針をドキュメントにしていきました。
こうして、以前より迷いは少なくなっていきました。
過去のコードを踏襲し続けるかの迷い：「つらさ」に正直になる勇気
.oO(既存コードの構成を真似て書くと、複雑で記述量も多くてつらいな。けど、きっとなにか意図があるのかも。踏襲し続けたほうがいいのかな...)
既存コードを改修していると、こうした悩みも多いです。
冷静にコードを読み解くと、記述量が多い一方で実はやりたいのは１つのシンプルなことで、コードが過剰になっている場合もあります。
しかし、他箇所の既存コードとの整合性も考えると、つらさがあっても受け入れるか迷ってしまいます。
また、どうしてそういった構成になっているか？の意図に関しては、初期メンバーがほぼいないので、完璧にはわかりません。
答えが出ない問いなのに、つい考えて手を止めてしまいます。
過去のコードへのリスペクトはすべきという気持ちはわかりつつも、重要なのは、今の我々が恩恵を受けられているかだと思いました。
ある日私は、「コーディングルールは、"つらくないファースト"に変えていこう！」と方針を掲げました。
前セクションとも通じますが、今居る我々がスピードを落としてしまったり、手をとめてしまうなら、やはりそれは積極的に変えていくべきだと思ったからです。
以降その方針のもと、既存改修でつらさを感じた度に、チームで今居る我々が「つらくない」と思える構成を考えていくことにしました。
そして、新規実装の部分は新しい構成で書いていく、また、既存部分はボーイスカウト・ルールでできる限り新しい構成に移行していくことを心掛けました。
すべてのコードにとは言えませんが、比較的以前よりも、迷いや手が止まる瞬間が減っていったと思います。
ポエム 〜コードの変化って、自然なことなのかもしれない〜
「守破離」という言葉があります。ざっくりこんな感じです。
- 守：まず、師の教えや型を守る
- 破：自分に合うやり方を見つけていき、だんだん型を破っていく
- 離：型から離れ、まったく新しい型を生み出す
我々のチームとそのコードに起きているのは、まさに守破離のプロセスなんだと思っています。
プロダクトの姿は、事業フェーズ・市場からの外部要因に伴って変化していきます。
時にはチームのメンバーも変化していきます。
ならば、コンウェイの法則チックに、コードのほうも変化をしていくのは自然ではないかと思っています。
もちろん、私が主導して決めていったコーディングルールも絶対ではなく、未来の誰かからしたら間違った選択に見えるかもしれません。なので、いつか誰かが変化させていってよいと思っています。
我々が扱っているのは、「ソフト」ウェアですから、柔軟に変わっていくものだと思います。
変化は悪ではなく、むしろ「変われるという選択肢が与えられている」と私はポジティブに考えています。
勇気をもって、これからも良い方向へと変わっていこうと思います。
以上、突然のポエムでした🫰
さいごに
私が意識してきたことを、「迷い」といったキーワードと共に紹介してみました。
個人の意見ですが、リーダーというのは単純に役割であって、べつに偉い人というわけではないと思っています。
立場に驕らずに、これからも迷いが生まれるポイントに目を光らせ、迷いが生まれる仕組みと戦っていきたいと思います。
どなたかの参考になれば嬉しいです。
それではまた！
Discussion