こんにちは うるるのエンジニアのましもです
これは株式会社うるるのアドベントカレンダー25日目の記事です
「技術力さえあれば」と思っていた自分と、今の自分を比較してみると、かなり考え方が変わっていました。
リプレイスの失敗、研修での学び、他部署との連携、チームマネジメント？？いくつかの経験を経て、技術だけじゃなく事業やチームのことを考えるようになった話です。
誰かの参考になれば幸いです
エンジニア＝技術力を上げることだけを考えてた
当時の自分を振り返ると、以下の3つを重要視していました。
- 自分の技術力の向上
- プロダクトの技術的な負債を解決すること
- 自分の市場価値を上げること
技術的負債が多くあるプロダクトは確かに開発しづらいです。ただ当時は、「モダンな技術を触りたい」「自分の経験を積みたい」という気持ちが先行していて、ユーザーの利益や事業の成長を深く考えられていませんでした。
少人数のチームでもあったため、技術が好きで貪欲に取り組む姿勢があれば目の前の仕事はずっとありますし、多くの未経験の領域のタスクを自ら手を挙げたりと、多くのことを経験できました。
モダンな技術スタックにするリプレイス
今を考えてもこれは失敗したなというリプレイスプロジェクトがあります
それは、技術選定も込みだと１年ほどかけて取り組んだリプレイスプロジェクトです。
3年目の頃、自分の部署のプロダクトのフロントエンドはNuxt2で構成されていて、サーバーサイドがTypeScriptにも関わらずフロントエンドはJavaScriptで書かれていました。古いスタックで作られた画面は、メンテナンスが比較的大変でした。
（比較的であり、緊急性を要するものではなかったなと今は感じています）
ただ当時は、「この負債を返さなければ」と思い、まずは管理画面を最新のスタックにリプレイスしようと、上司に相談し、自分で技術選定を実施しました。3ヶ月ほどかけて技術選定を行い、React + React Router + Mantine UI + TypeScriptのスタックに移行しようと決めました。
この移行の際、今後の運用を考えて設計にかなりこだわってしまいました。ソースコード自体の品質は悪くなかったのですが、リプレイス計画に問題があり、結果的に全てのリプレイスを完了できませんでした。
最終的に、そのソースコードは使われないまま、つい今月に削除しました。理由としてはAIのコンテキストとしてノイズになってしまっていたからです。
問題解決フレームワークの再学習
この失敗も経験しつつ、会社で研修を受ける機会があり、そこで問題解決のフレームワーク(What、Where、Why、How)や、人のマネジメントの基礎を学ぶことができました。
新卒研修時にも問題解決フレームワークについては少し学習していましたが、今回の研修で改めて学習してみて、問題解決フレームワークを以下の3つの目線で適用することで、事業としての課題とその根本原因を常に考えられるようになってきたかなと思います
- 1個人の目線
- 開発チームとしての目線
- 事業部としての目線
また、問題を分解して構造的に考えることで、解決策の工数と課題解決のインパクトを改めて考えられるようになりました。
他部署との連携
研修を通して、プロダクトをより成長させるには他チームとの連携強化が必要と思いました。
そこで、他チームの定例会議に参加し、彼らの課題を現状を解像度高く把握するようにしました。その結果、社内ユーザー向けの機能開発が活発になり、今ではチームメンバー全員が他部署との連携を重視する文化ができています。
他部署との連携強化の成果として例を挙げるなら、管理画面のダッシュボードの刷新です。
fondeskでは、オペレーターが電話対応を行い、オペレーターを管理するチームがあります。
このプロジェクトの時にダッシュボードのベストプラクティスなども参考にしましたが、リプレイスの失敗も踏まえて、オペレーションチームが
- ダッシュボード画面のどの情報をどう参考にして、アクションを取っているのか
- アクションのトリガーとなるものは何か
について、実際にオペレーションチームの席の横で業務を観察しながら、聞き取りを行いました。
例えば、オペレーターのステータスが複数回変化したとき、管理者が目視で確認して声をかけていた運用がありました。これをSlack通知で自動化することで、管理者の負担を減らせました。
シフト終了後に画面をつけっぱなしで離席しているオペレーターへの電話割り当てを防ぎ、受電率の低下を防ぐためです。
現場を見て課題を抽出し、それを解決する機能を実装できたことが成功につながったと思います。このダッシュボードは今も継続的に使われています。
また、この経験をきっかけに、チームメンバーの誰もが必要に応じて、他チームの定例に出たりするようになりました。私だけでなく、チーム全体が他部署との連携を重視する文化が生まれてきたのは、大きな変化だと感じています。
チームメンバーとの1on1
もう一つ今年になって変わったのが、チームメンバーとの定期的な1on1です。毎週または隔週で、メンバー一人ひとりと話す時間を設けるようにしました。(メンバーは2人しかいませんが...)
去年11月に新メンバーが入り、その育成担当になったことがきっかけです。1on1を通じて、メンバーの考えや困っていることを深く聞けると感じたため、全メンバーと実施することにしました。
最初はフォーマットなしで始めたため、ただの雑談で終わることが多かったですが、モバイルファクトリーさんの記事と研修での学びを参考に、フォーマットを設けました
Google Document内での雛形に、事前に記入してもらいます。基本的には、うまくいったこと、いかなかったこと、こうすればよかったこと、次はどうしたいか、という流れで話します。文章化することで、メンバー自身を責めるような構図にするのではなく、コトを反省できるように意識してます
この1on1を通じて、メンバーの体調や仕事の状況、困っていることを把握できるようにな理、チーム全体のパフォーマンスを上がった、もしくは働きやすさが上がっていると嬉しいなと思います。一人ひとりと対話することの大切さを学ばせてもらってます
また、自分の考えを共有しておくことで、チーム内での意思決定もスムーズになっていると感じています。
これから
上記のようなことを語ってはいるものの、完璧とは程遠いです。
工数が大きくかかるプロジェクトを円滑にリリースする。新しい市場を狙うときの既存設計との折り合い。など課題は山積みです。
事業の成長スピードと技術的な完璧さの両立は、とても難しいです。
それでも、次のステップとしては、大きなプロジェクトもマネジメントしながら、デリバリー後も責任を持って運用し、きちんと成果を出したいと考えています。リリースして終わりではなく、それが本当に事業やユーザーに価値を届けられているかまで見届けることが大切だと思っています。
同時に、小さな工数で大きなインパクトをプロダクトに与えられるアイデアを考え続けたいとも思っています。
大きな工数＝事業インパクトという式を持ってしまわないように、常に事業の本質的な課題を深掘りし続けて、どうにか、発想の転換で成果を出せるようになりたい。そう思います。
そして何より、fondeskをどうしていきたいのか、プロダクトとしての理想の姿は何かを考え続け、それに向けて何が必要なのかを考えて行動していきたいです。5年後の事業がこのような姿でいてほしいから、今自分にできることは何か、プロダクトとしてできることは何か。そういった視点を持ち続けたいです。
まとめ
技術力を高めることは、エンジニアとして当然大切なことです。でも、それだけでは足りないということを、失敗を通じて、、、学べたかなと。
チーム全体のことを考える、事業全体を見る、プロダクトの理想の姿を描く。そして、他部署の人たちとコミュニケーションを取り、彼らの課題を理解する。こういった視点を持つことで、結果的に自分自身の成長にもつながったかなと思います
もし同じような立場の人がいたら、視点を変える？広げてみる？ことでまた異なる仕事の向き合い方ができるかもしれません。
私もまだまだ道半ばですが、これからも、fondeskという事業に対してどう貢献できるか、プロダクトをどう成長させられるか、チームをどう支えられるかを考えながら、前に進んでいきたいと思います。
最後まで読んでくれて、本当にありがとうございます。