2021年、Hameeの開発3部署に起きた変化とその目的について
みなさーーーーーん！！！！
変化の目的！！！
なんでしたっけーーーーー！！！！？？
こんにちは。Hameeでエンジニアリングマネージャーを務めております正訓（まさくに）と申します。肌の乾燥が最近の悩みです。
Hameeのプラットフォーム事業部は、開発部隊として開発1部、2部、3部が組織されています。おそらくは時代柄、多くの企業、開発組織においても同様かと思いますが、Hameeの開発組織においても2020年後半〜2021年はまさに怒涛のような変化が次々と起こりました。
本記事では、僕ら開発3部署に起きた変化を並べるのではなく、「なぜその変化が起きたのか、起こしたかったのか」という観点で並べてみたいと思います。どうぞ皆さんの組織設計の一助となれば幸いです。
また、こちらの記事は、Hameeアドベントカレンダー最終日の記事でもあります。アドベントカレンダーの最後だからということで無理を言いまして、Hameeの公式noteにお邪魔させていただきました。
「御託はいらないから一緒に働きたいよ」というせっかちな方は、どうぞ下記からジョイナス！それでは、よいクリスマスを！
2021年年始の開発3部署の状態
Hameeの期は5月から始まります。5月〜10月を上期、11月〜翌年4月を下期とし、経営計画や評価の区切りとして扱っています。このためHameeの23期下期は2020年11月から始まりました。
Hameeでは、2020年11月に大規模な組織変更があり、下記のように元開発部と元SRE部が合併し、さらに3部署に分かれ、エンジニアリングマネージャー（EM）とテックリード（TL）が各部署に置かれました。
これは組織としての流動性を高め、関わりのある業務であればサイロ化※を防ぎ、マネジメントコストを下げ、変化へのレジリエンスを持つ目的をもっていました。
※システムや業務プロセスなどが、他のアプリケーションや他事業部や部門との連携を持たずに自己完結して孤立してしまう状態のこと
2021年が始まったとき、まだこの体制変更から2カ月しか経っていません。業務変化はできるだけなだらかになるよう設計したつもりですが、部署統廃合、ロールの変更といった激震が同時に走ったため、まだ組織としては人間関係や業務分担の距離感を測っていた時期です。
また開発活動としては、さくらのオンプレミスからクラウド化へのリアーキテクチャのプロジェクトが佳境で、開発3部署ほとんどすべてのエンジニアがそのプロジェクトを陰に陽に支えていました。このため、2021の年始めはプロダクトとしても命運が変わる大切な時期でした。
年始から、それまでの歴史を大切にする、これからの歴史を作るといったことを同時に、そして急ピッチに進める必要があった2021年でしたが、体制変更以外に起きたさまざまな変化を目的別で、下記にピックアップしたいと思います。
・メンバーが組織方針に寄与できるようにしたい
・個人も組織も成長できる環境にしたい
・意味と意義あるコミュニケーションを醸成したい
・保守、開発のフローを高速化したい
文章の構成上、「〇〇したいからこうした」という書き方にしてありますが、すべての変化はメンバーや関係各人が能動的に活躍し、生み出してくれた成果です。僕個人の成果は一つもありません。
「こういうこと／課題を感じたとき、Hameeという会社ではこういうことをしたんだなー」という、エンジニア組織の比較対象として、ご参考になれば大変うれしく思います。
メンバーが組織方針に寄与できるようにしたい
◆開発3部署の基本方針を立てる
この公式noteでも何度か述べられておりますが、去年からHameeでは「クリ魂プロジェクト」という全社としてミッションを再定義し、カルチャーを浸透させようという活動が強まっていきました。
2021年になり、24期を迎え、その一連の「パーパスデザイン」は表層的にも深層的にも影響力を増し、OKRや24期のプラットフォーム事業部の基本戦略もその影響を強く受けています。
このような全社的な活動は組織形態にもよりますが、ルーターの中継機のようにミドルリーダー層の理解と伝播が必要です。
このため、まず開発3部署では、24期のプラットフォーム事業部の基本戦略を受け、開発3部署としての24期上期基本方針をエンジニアリングマネージャー陣で考え、メンバーに説明をしました。ステートメントはざっくり略してありますが、下記のようなものでした。
・非機能部分改善でアプリケーションを強くする。
・継続的な負債解消を定着させ開発速度を向上させる。
・カスタマーサクセスに寄与する。
このとき意識したのは、目標間のつながりです。
基本的に、組織の目標はミッション・ビジョンにしろ、中期経営計画にしろ、経営のレイヤーほど抽象度が高く、実務のレイヤーほど具象度が高い情報になります。
その連結部分につながりがないと相互の立場で「よく分からん」ということになりやすく、さらにメンバー個人の意識にも上位の概念が現れなくなります。
このため、その連結部分として「メンバーが手を動かす理由と、その成果のつながり」を明示することで、組織の目標を意識し、自分の活動理由も意識できるのではと考え、まずは開発3部署の基本方針を立てました。このつながりについては、評価制度の部分でも後述します。
◆「僕らの価値」を示す”北極星”を打ち出す
テックリード主体で「開発3部署の存在価値」について言語化を行いました。こちらは24期の基本方針よりもさらに遠く、自分たちがこの組織にいる価値は何か、自分たちが目指すべき点はどこか、自分たちの「北極星」を自己説明できるようにするような取り組みでした。
その結果、「ずッぱや」が自分たちの価値である、という表現に行き着きました。「ずッぱや」とは「ずっと超早い」を略した造語です。
まず、エンジニアリングマネージャーとテックリードで異論なく合意したのが「僕らにとって”スピード”はどの時点でも必要となり、組織内でも体現していくべき価値だよね」ということでした。
それには「いまの速度（プロダクトのレスポンスや開発速度など）も重要だし、将来的な速度（プロダクトに負債のない状態や組織的な体制やマインド）も重要だよね」という話し合いの末、「ずっと超早い」略して「ずッぱや」が、僕らの価値であり、目指していく北極星だ、という結論になりました。（ちなみに”ッ”はカタカナでなければ怒られます。）
この「ずッぱや」については、キャッチーな言葉を選定したということもあって、24期、最も意識づけができた言葉となったと思います。
Slackに「みんなのずッぱや」というチャンネルがあり、リアクジチャンネラー（「ずッぱや」のリアクションがついたメッセージが転送されるSlackのアプリ）によって、毎日、誰かしらの「ずッぱや」な活動が分かるようになりました。
もちろん内容は見せられないのですが、みんなの「ずッぱや」な仕事が集まるチャンネルです。
これらの目標を定めたというよりは、目標の置き方と伝達方法を考えた結果、メンバーへ「自分たちらしく次にアタックする場所」を説明できるようになり、その基準をもって組織への寄与を考えることができるようになりました。
個人も組織も成長できる環境にしたい
◆勉強会の種類と頻度を増やす
一時期、元開発部ではリモートワークのやりにくさやリソース不足によって、全体的な勉強会が行いづらい時期がありました。
個人の、特にエンジニアの成長のために勉強会はあった方がいいんだろうなぁとは思っていたところ、2020年中盤〜で、有志が全体の勉強会（LT会）を復活させてくれました。
「デブライブ！」と名付けられた（どこかで聞いた名前ですね）その勉強会は現在も1Qに一回ずつほど開催されており、テーマもさまざま有志の活動によって2021年も続けられています。12月もリファクタをテーマに、さらにワークショップ形式で開催されました。
その他にも、2021年はさらに自律的、組織的に開催されるようになり、Hameeとして外部講師の方々をリモートでお招きしたり、2年ほど停止を余儀なくされていた合宿をリモート（！）で実現できたり、テックリード主体で部署での勉強会が開催されたり、有志で読書会が開かれたりするようになりました。
「リモートワークに慣れてきた」ということも大きいとは思うのですが、メンバーの能動的な意識が組織に自学自習をもたらしてくれたのだと思っています。
◆評価制度を目的から再考する
24期に入り、5月から開発3部署は評価制度を刷新しました。元開発部と元SRE部という違った評価制度を用いていたチームが合併したことも大きかったのですが、個人の成長を後押しできるような制度にしたいと思っていたため、基本的に目標管理制度を導入することにしました。
すでに存在した給与を表す「レベル」の考え方にプラスして、「グレード」の考え方を導入し、自身の目標を考える際、開発力と影響力を軸として、「次はこのようなエンジニアになろう」ということを言語化し、共有しました。
前述の理由から、個人目標は開発3部署の基本方針に紐づくべきだと考えていたため、期初にエンジニアリングマネージャーとメンバーが、基本方針に紐づく目標、個人のキャリアプランに紐づく目標を対話しながらかなり綿密に立てるようにしました。
さらに、少なくとも月イチでの1on1で、その目標の進捗度合いを話し合い、合意し、フィードバックをできるだけリアルタイムに行うようにしています。これにより、期末に「全然目標達成してないね」というお互いに不幸な結果にならないようにしました。
もちろん目標を立てる時間、進捗を確認する時間など、お互いに一定のコストはかかるのですが、1on1が目標を中心に語られるようになったことで、少なくとも月イチでは期初の目標に立ち返って方向性を振り返ることができるようになる、自己評価とマネージャーの評価を途中ですり合わせることができるなどの大きなメリットがありました。
10月にこの評価制度での初めての評価が無事に終わり、アンケートを取ってみると、この活動は概ねメンバーにも好評価だったことが分かりました。11月からの下期も同様の評価制度の運用を開始しています。
◆事業部で統一された新卒研修を行う
新卒として入社していただいたエンジニアは、歴史的背景から開発部が考案したOJTを行っていました。それは前年度の新卒がOJTの講師になるというインプット／アウトプット両面で優れた仕組みでしたが、さらに広く、プラットフォーム事業部として新卒を育てる枠組みを作りたいという意識がありました。
このため去年度からHameeとしての研修、プラットフォーム事業部としての研修、開発部としての研修を3本立てで実施していました。今年はその幅をさらに広げ、開発3部署の研修をプラットフォーム事業部の研修として内包し、一貫した研修の仕組みを作ることにしました。
ここ数年、特にプラットフォーム事業部は、カスタマーサクセスを標榜しているため、エンジニアとして入社しても新卒研修で顧客対応を体験して視野を広げる、逆に総合職として入社しても開発を体験して効率化などを学ぶ、といったことができるようになりました。
ただ、デメリット（というまでにはなっていないと思います）が、エンジニアとして入社したけれどOJTでコードを書く時間が減るなどの現実があり、これは実務に入ってからサポートする必要がありました。これもメンバーの献身的な助力により、いまや新卒メンバーも全員戦力として開発に携わっていただいています。
意味と意義あるコミュニケーションを醸成したい
◆情報をできる限りオープンに取り扱えるようにする
大きなところで言うと、24期でプラットフォーム事業部のコミュニケーションツールがSlackに変更されました。
それまでは他部署の活動が特にリモートワーク下で全く見えないなどの状況にありましたが、Slackになり、どのチャンネルも基本的にパブリックで作られることで、状況は大きく改善したと考えています。
チャンネルが作られると #general で通知されるようになっており、いまでは一つのプロジェクトにエンジニア以外のメンバーでも能動的に参加して、コメントをいただける機会は日常となりました。その逆もしかりで、「共創」に大きく近づいている実感があります。
また、多くのMTGがZoomで開催されるようになったため、全社的にラジオ参加ができるMTGや、録画で後に共有されるMTGが増えました。これにより移動することなく、どのような話し合いがもたれ、どのような文脈で決定がされているか、どのような考えがあるかを把握しやすくなりました。
自分はリモートワーク以前のHameeは知らないのですが、リモートワーク初期と比べて、質も量も確実にオープンにされ、コミュニケーションが取りやすくなったと感じます。
◆会議体の意義と内容を見直す
2021年の体制変更時には、特に実務を維持しなければならない部分があったため、会議体の多くが前期を踏襲されました。それが半年経ち、部署の形が見えてきたころ、会議体の内容を変更した方がいいのではないかということがテックリードやプロジェクトリーダーを中心に考えられ始めました。
内容が更新されたり、追加されたりしたのは全体が関わるところで言うと3つです。
・開発ミートアップ
旧体制では締め会と呼ばれ、しばらく内容も踏襲していました。それをここ数カ月で内容を更新し、よりワクワクするようなイベントに生まれ変わりました。具体的には他部署のメンバーを招き、事業部の数字周りの共有を強化したり、前述のずッぱやであったメンバーを称えたり、テックリードやエンジニアリングマネージャーのコーナーを強化したりして、伝達力を高め、将来性を感じるイベントになりました。
・Team Management Revolution
僕らがなんと略しているかは明言しませんが、旧体制ではリーダー会、あるいはプロジェクト進捗会と呼ばれていました。そもそもプロジェクトのリーダーが増えたということもありますが、プロジェクトの進捗を共有する場から、プロジェクトリーダーが課題や考えをグループに分かれて相談、協議する場に生まれ変わりました。
・開発3部署キックオフ
もともとHameeには期の始めにHamee全社、事業部のキックオフが用意されていました。エンジニアリングマネージャーの提案によって、これにプラスして、24期下期から開発3部署のキックオフを追加で実施しました。
前述のとおり、組織の枠で目標の抽象度が変わってきます。Hameeのキックオフは会社の大方針、OKRを語り、事業部のキックオフでは事業部の戦略、数字の目標があり、開発3部署のキックオフでは、基本方針の共有と、メンバーの手元に目標が降りてくるようにしました。
上期では実施していなかったので、この段階的なキックオフの実施で下期の全員の認識を統一化することができ、個人個人の目標の立案がやりやすくなりました。
保守、開発のフローを高速化したい
◆障害対応のワークフローを変える
テックリードの先導により、それまでの障害対応を見直し、障害発生から障害の振り返りまで一連のワークフローを定めました。「障害かな」とSlackでつぶやくと、障害対応のフローの記載された記事が返ってくるのは本当に冴えた方法だと思います。
このKibela（Wiki）の記事の中に記載されているのですが、障害対応フローとして下記のような流れが決められました。
1．Slackで「trouble_*」チャンネルを作り関係者を招待する。（そのうちこのチャンネル作成もbotで作ってくれるようになりました）
2．障害の規模、インパクトを定めて、優先度、対応者、対応人数、報告先を決める。
3．真摯に障害に対応し、解決する。
4．対応者は全員任意参加で、障害の概要や暫定対応の共有、恒久対応を検討するMTGを開く。（ポストモーテム）
今では、このフローが浸透し、障害情報の事業部への共有や状況判断、振り返りまでがスピーディに行われるようになりました。Slackになったことにより、1．の段階でエンジニアだけでなく、事業部としてキャッチし、ビジネスサイドとも連携できるようになったことも大きかったと思います。
◆リリースまでの開発フローを変える
一つのリリースをどれだけ早く顧客へ提供できるかが「ずッぱや」の命題の一つであり、恐らく改善に終わりはありません。「ずっと超早く」プロダクトを改善していくためには、リリース速度を早くすることは避けては通れない課題です。
この課題をさまざまな角度から考えてきましたが、今年大きく進捗できたところは、監査、統制の枠組みを変え、ツールを変えることで、リリースフローを変更できたところだと思います。
Hameeは上場企業であるという前提もありますが、顧客へ安心や信頼を継続的に提供できるよう、監査、統制の面から開発フローも明示的に定められています。
誰が開発のチケットを起票し、誰が承認し、誰が開発し、誰がリリース承認を行い、どうやってリリースするのかということから、誰がどのような権限を持っているのか、その更新時期はいつかということまでです。
前期までは定められた開発フローに従うと、この監査、統制に従うことができるという絶妙なバランスを保っていました。
しかし、技術的な情勢やプロダクトのクラウド化が進んだこともあり、多くの面で品質を確保しながら自動化できること、セキュリティを保てること、個人、組織成長をさらに後押しできることなど、品質と開発速度が担保できることであろうことから、関係各所にご協力いただき、この監査、統制を更改しました。
その周辺の変更点として、開発3部署はコード管理をBitbucketからGitHubへ、チケット管理をRedmineからAsanaへの変更を行い、リリースフローに適用し、将来的な開発の柔軟性、速度を上げようと今も試みています。
改善の変化は改善の変化を呼ぶ
語りきれていませんが、他にも多くのことが2021年では変化しました。
顧客からの調査問い合わせのフローを変えたり、戦略に呼応してプロジェクトの数や目的や手法を変えたり、プロダクトのロードマップを引いたり、個人のリソース管理方法を変えたりしました。
正直、SlackとGitHubとAsanaを事業部、開発3部署に導入しただけでもすごいなぁ、ありがたいなぁという感覚ではあります。そのうえ、ここで語るのは避けましたが、冒頭で少し記載したとおり、プロダクトをオンプレミスからクラウド化へ移設するというHamee史上最大級の開発を並行的に行っています。
そのような多くのことを振り返ってみて羅列すると、それぞれの変化は核融合のように他の変化のきっかけ、あるいは前提条件になっていることが多いということを実感しました。
例えば、監査、統制を変えなければ、新しいツールを導入することができませんでした。基本方針を立てなければ、組織に寄与できる目標の軸がありませんでした。”北極星”がなければ、フローの改善理由も漠然としていたでしょう。
僕は変化することが偉いとか、生き残れる、とかはあまり思っていません。そこには行間があると思っていて、「目的に対して変化を自省的に選択できることが大切なのだ」と考えています。このため、変化は目的のために、目的は成果のためにを、忘れないようにしたいと思います。
多くの変化が道半ばですが、変化を促すための変化として、障害対応のところでも語りましたが、「振り返り」の数が開発3部署では激増しました。これからはそういった自浄作用の定着化もあいまって、もっと「ずッぱや」に強くなっていくでしょう。
最後に繰り返しになりますが、起きた変化のほぼすべてが他メンバーの勇気ある活動のおかげです。2021年、破綻なく進めることができたのは、多くのメンバー、そして関連部署の献身的なサポートがあればこそでした。僕自身がご迷惑をおかけすることが多かったと思いますが、この一年、本当にありがとうございました。
2022年も、よろしくお願いします。
追伸、そんな強くなっていく僕らの仲間を募集しています！
カスタマーサクセスに興味がある、主体的に物事を変えてったるぞ、クリエイティブな魂を持ってるぞ、ずッぱやな開発精神を持っているぞ、ECに詳しいぞ、というあなた！
2022年はHameeでいかがですか！
◆この記事を書いた人
PROFILE：伊藤 正訓（いとう・まさくに）
Hameeのプラットフォーム事業部Webエンジニア、エンジニアリングマネージャー。
何にせよ、感動、誠実、遊び心が大切だと思っている。
最近ベースとロードバイクをはじめ、今年も宣伝会議賞を逃した。
多様性、柔軟性、成長性のある楽しいプロダクトとチームを作っていきたい。