「サービスを創るエンジニア」誕生秘話：顧客体験最大化に向けたエンジニア組織改革
こんにちは！ナレッジプラットフォーム「Qast」を運営するany株式会社 CTO波多野(@hatamasa1988)です。
本noteでは社内で何の説明もなしに突然爆誕したが、あまりにも馴染んでいるanyエンジニアのキャッチコピーである"サービスを創るエンジニア"について語りたいと思います。
以下に少しでも該当する人は読んでいただくと良いのではないかと思います！
シリーズAスタートアップでのエンジニア組織の実態を知りたい！
求めるエンジニア像をわかりやすく表現したい！
理由は様々だがとりあえずanyのこと少し気になっている！
anyのエンジニア組織に入りたい！
以前のエンジニア組織に感じていた課題
2年程前に遡りますがコード品質を向上させることに力を入れていましたが、いくつかの課題は解消できずに、チームに漠然としたどこまでやるんだろう感が漂っているのを感じていました。
ちょうどnoteにも残していたこの頃です
どこまでやるんだろう感については"生きたサービスのコード品質"という正解もない、100点もないが、より良いものを目指し続けることのドツボにハマっていたように思えます。
言葉を選ばず表現すると「高品質の良いコードを書くこと」を目的とさせてしまっていた自分のミスでした。
結果、諸々の問題が発生していました。
PRのコード品質に散らばりが出る
レビュー指摘で大きな設計の手戻りが起きる
レビュアーに偏りが出て一部のメンバーの負担が増加
レビュー指摘で水掛け論的なコミュニケーションが発生する
指摘=指示になり学習機会が損失される
これらは開発の遅延やメンバーのデモチに繋がるので早急に解消をしたいところです・・・ちなみに以前はこんな状態でした
コードレビューのグランドルールや規約の言語化などあまりない
発信するだけで現場を見ない（緊急事態の開発をするだけでチーム開発には参加していなかった
あまり良くないことはすぐにわかると思います・・・。
共通認識がないことで品質の基準がメンバーごとにばらつく。現場を見ないことでガバナンスが効かない。状態になっていました。
エンジニアチームで掲げたvisionも今見ると手段の目的化でした
Vision
高拡張性、高保守性、高品質を持つシステムを構築できる
設計技術が高いエンジニアを増やす
2022年10月"サービスを創るエンジニア"爆誕
前章の課題を持っていましたが、anyDAYという全社会でプロダクトフィロソフィー（考え方や目指している価値観のようなものの言語化）をディスカッションする中でメンバーから出た名言すぎる名言がこちらです。
anyのエンジニアは単にコードを書くプログラマーじゃなくって、
プロダクトを創るエンジニアなんだなと思いました。
あまりの名言に全社から拍手喝采！
CTOの胸にも刺さりました。
ちょうど2022年10月から全社で"顧客体験の最大化"を掲げました。
顧客の成功を自社の成功と捉えるSaaSの王道的な考え方をしっかりやっていこうという思いや、プロダクトだけではなくanyとお付き合いする一連を気持ちよく体験してもらえるようにと、anyらしい方針となっています。
また、前章で感じているような課題感からサービス提供しているからにはサービスの価値とコード品質の順序を誤ることなく意識させるような方針を立てたかったタイミングがちょうど一致していた時でした。
この2つとの合致度も半端なく高く、すぐにエンジニアチームのキャッチコピーとして使わせてもらいました笑
これが今でも使い続けている"サービスを創るエンジニア"です。
anyにとってのエンジニアとは？
プログラムを書くプログラマーではなく、
サービスを創るエンジニア。
会社のバリューを一番に体現し、
会社とサービスを一歩も二歩も前に進める存在。
すでにこのキャッチコピーに惹かれてカジュ面にいらしてくれた方、入社を決めてくれた方が続々と出てきています。既存メンバー含めてカルチャーとして根付いてきている感覚があります。
その後のエンジニア組織
すぐに"サービスを創るエンジニア"を採用のカルチャーデックにも添え、その後"顧客体験最大化"を目指し、チームに複数方針を打ち出しました。
全社の"顧客体験最大化"をよりエンジニアチームに置き換えて言語化できた"サービスを創るエンジニア"のおかげでグッとメンバーの当事者意識が高まったのを感じます。
品質の考え方
PR運用ルール整備
エンジニア独自の評価制度
簡単にですがそれぞれ紹介したいと思います。
品質の考え方
品質の考え方については、まず品質とは？を整理し「内部品質は最終的にサービス品質（顧客価値）に紐づくもの」という考え方を徹底して説いています。
サービスを提供している上でこの順序はとても大切だと思っていて、
まずサービスとしての体験（外部品質）があり、その次に内部品質（コード品質）を重要にしようというリソースが限られたスタートアップの選択の話なのかなと思います。
ただここでミスリードしたくないのは、内部品質は必ず顧客価値に紐づくので蔑ろにしてはいけないとして徹底し続けたいと思います。
国際規格SQuaRE（ISO/IEC 25000、JIS X 25000）に定義されているソフトウェア品質の図をベースに置き換えて起こしたものでチームに説明しています。
PR運用ルール整備
大きく「運用ルール」と「心得」を設置してあります。
ただPR運用ルールがあるのではなく、大上段に前述した品質の考え方があることでレビューの位置付けが明確になります。
「運用ルール」の目的はPRプロセスの時間短縮と効率化、チームパフォーマンスの向上として、PRの作成方法、コメントラベル運用、レビュー依頼~修正~マージ方法などをまとめました。
その中で特に重視しているのは、レビューの迅速化とPRの適切な分割、および明確なコミュニケーション戦略を記載しています。
「心得」の目的はチーム全体のコード品質の向上とプロジェクトの効率化として、チーム開発におけるマナーや根底にあるべき行動指針を示しています。
良いコードレビューの重要性と、レビュワーがレビューしやすいように心がけること、適切なコミットの管理、セルフレビューの実施、レビューコメントの品質維持、さまざまな観点からのレビュー実施、効果的なレビュー修正方法などを記載してます。
エンジニア独自の評価制度
"サービスを創るエンジニアとして"フルサイクル/フルスタックな開発をチームでベースとしました。
anyは全社で評価制度を作成しています。
作成するにはかなり早いフェーズかとは思いますが「個の幸福と組織の実利が両立する世界をつくる」というPurposeを掲げているanyにとっては必須のものであると考えています。
Purposeについては先日代表吉田から発表されたnoteもご覧いただきたい！
anyにかけた熱い想いを読むことができます。
エンジニア評価制度については、全社共通の評価制度を継承してエンジニア用に翻訳して作成しています。
現状エンジニアチームはエンジニア一人でより多くの範囲をカバーすべくフルサイクル/フルスタックな開発を行っています。
それについてはLayerX松本さんがわかりやすく考えを展開してくれているのでここでは割愛します！（先日Newspicksで記事になっていました）
フルサイクル/フルスタックな開発を評価しつつ、その中でも自身がバリューを発揮できる部分をより評価して伸ばせるような設計をして現在β版として運用中です。
さいごに
その後のエンジニア組織については詳細を語ると長くなりすぎるのでざっくり説明になりましたが、より深く聞きたい人はカジュアル面接にお越しください笑
anyでは職種は関係なくプロダクトと徹底的に向き合う時間があります！
今後一緒にプロダクトを成長させていきたいという、我こそは"サービスを創るエンジニア"だ！という方は転職意欲関係なくカジュ面しましょう！またランチとかもいきましょう！（DMお待ちしております！@hatamasa1988）
そして、つい今月ですがアセンドCTO丹羽さんからプロダクトエンジニアとは何者かという素晴らしいnoteも出ていてこれに近いものを感じたので、今後参考にさせていただこうと思ってたりしています。
今年は諸々の事情であまり発信に割く時間が取れずにいましたが、来年は頻繁に発信していけたらと思っています！
それではまた！
いいなと思ったら応援しよう！
