開発がいい感じにいってるってどういうことかについて、社内で勉強会をやってる話

アイキャッチ

こんにちは、ギフティでエンジニアをやっている中屋(@nakaryo79）です!

この記事では社内コミュニティの一つである Engineering Methodology ギルド（以下、EM ギルド）について紹介したいと思います。

はじめに

「開発がうまくいっている」

この言葉を聞いて、みなさんはどんな状況を思い浮かべますか？

開発の成功を測る物差しは、チームやプロジェクトによって千差万別ですよね。多くのチームが KPT などの振り返りを通じて改善を重ねていますが、その貴重な知見や気づきは往々にしてチーム内に留まってしまいがちです。

そこで私たちギフティでは、そんな開発プロセスに関する知見の共有と探求の場として、EM ギルドというコミュニティを作り、定期的に勉強会を開催しています。

ギルドとは

弊社にはギルドと呼ばれる社内エンジニアコミュニティがあります。ギルドは有志による半オフィシャルな組織で、事業部を超えた技術的な情報交換の場として機能しています。

tech.giftee.co.jp

当初、社内にはバックエンド、フロントエンド、AI、アジャイルの4つのギルドが存在していました。このうちアジャイルギルドで扱っていたトピックの範囲を広げ、エンジニアリング手法やプロセス全般について議論する場として "EM（Engineering Methodology）ギルド" が誕生しました。

他のギルドが具体的な技術領域にフォーカスしているのに対し、EM ギルドでは以下のようなトピックを主に扱っています：

開発プロセス
プロジェクトマネジメント
チームビルディング
開発生産性
その他エンジニアリングプラクティス全般

現在、弊社のエンジニア数は50人を超え、各事業部がそれぞれの状況に適した開発プロセスを採用しています。ウォーターフォールからアジャイルまで、様々な手法が実践されている中で、これらのメタ的なトピックについては絶対的な正解がないケースが多く、対話を通じた共通認識の形成が重要です。

しかし、チームの垣根を越えてこうした話題について情報交換する機会は限られていました。そこで、EM ギルドは、これらのトピックについてカジュアルに相談・議論できる場として設立されました。

設立から約1年が経過した今、普段どのようなテーマで議論を行い、どのような知見が共有されているのかをご紹介したいと思います。

どんなことを話しているのか

実際に開催したテーマの中から、差し支えないものを載せてみます。

開発スピードを上げるためにみんなが意識してること＆困っていることディスカッション
開発が上手くいってるってどういうことだろう
チームや個人が良い状態に向かう/維持するために何ができるか
「ADR こんなふうに書いてます！」の事例を眺める会
オンボーディング & ナレッジ共有どうしてますか
各チームでどんなAgileのイベントをやっていて、どうやってるのかをざっくばらんに共有する
長期的な振り返り
開発生産性カンファレンス2024に参加した
各チームのテスト戦略を知ろう
ディレクターとエンジニアの職種の垣根をどう超えるか
各チームの KPI とその設定方法
チームのコミュニケーション方法についてディスカッション
みんなのメンターのやり方、メンティーの体験談を共有する会
ソフトウェア開発における各種テスト、ギフティではでどのように運用するとよい？
エンジニアとディレクターがお互い思っていることを正直に話してみる会
デイリーどうやってますか
pmconf 2024振り返り
zatsu 会
輪読の進め方、どんな方法がいいのか？
仕様、要求の伝え方どうしてる？
チームトポロジー輪読
チームトポロジー実践例を調べてみる会

コミュニケーションや振り返りの仕方といった具体的な how から、「良い開発」とはのようなメタな話まで、幅広いトピックを扱っています。

いくつか詳しく見ていきましょう。

開発が上手くいってるってどういうことだろう

「開発が上手くいってる状態」について、参加者それぞれが考えを共有しました。出てきた意見は大きく以下のようなカテゴリに分類できます。

チームの方向性と目的意識

明確なチーム目標があり、全員がその方向を向いている
何を作るべきか、何を目指すべきかの認識が共有されている
メンバー全員が同じ熱量を持っている

開発のフロー効率

リードタイムが短い（リリースや承認待ちの時間が少ない）
継続的デリバリーが実現できている
自動化・仕組み化が進んでいる

チームの意思決定とコミュニケーション

コミュニケーションに障害がない
意思決定が適切に分散されている
強力な意思決定者の存在と、分散された意思決定のバランスが取れている

持続可能性

属人化を防げている
アウトプットの why が誰でも理解できる
スプリントゴールが安定して達成できている
チームの幸福度が維持できている

成果と楽しさ

プロダクトゴールに向かって着実に進んでいる
アウトカムが生み出せている
開発自体が楽しい（これが最も重要という意見も）

興味深いことに、CI/CDなどの技術的な要素よりも、コミュニケーションや認識の共有といったソフトな要素が多く挙げられました。特に、チームの目的意識と開発のフロー効率に関する意見が目立ちました。

これは、ギフティでは技術的に完結した問題はすぐに改善され、開発環境や開発フローに関してはそこそこモダンな状態が担保されている一方で、人やチームは流動性があり、また他職種との協働も多いため、自然とソフト面へ目が向いているのかもしれません。

また、これらの状態をどう測定するかという議論も行われました。Four Keys のような定量的な指標も挙がりましたが、「うまくいっていると感じること」という定性的な側面も重要だという意見が多くありました。

特に注目すべき点として、開発の速度や生産性だけでなく、「開発の楽しさ」という要素の重要性が挙げられました。これは近年注目を集めている Developer Experience（開発者体験）の観点とも合致しており、今後さらに重要性を増していく可能性があります。

エンジニアとディレクターがお互い思っていることを正直に話してみる会

ギルドは基本的にはエンジニア主体のコミュニティなのですが、EM ギルドは対象にしている領域が開発そのものに閉じないので、ディレクター職種の方の参加もウェルカムという形でやっています（ギフティでいうディレクターは PjM、PdM などの開発ディレクションを担当する職種を指します）。

ディレクターの方も多く参加した会では、普段の業務でエンジニアとディレクターがお互い思っていることを正直に話してみる会をやりました。

ディレクターからは、以下のような意見が多く聞かれました。

エンジニアと率直に意見交換できる関係性が非常に健全
- こういうこと困ってる、を伝えて解決方法を一緒に考えられるのが嬉しすぎる
- お互い同じ目的に向かうことができるので、この関係性は常に維持したい
技術面だけでなく、運用やビジネス要件まで一緒に考えてくれることへの感謝
- ビジネス要件の検討まで入ってくれるのが心強すぎます！
- 運用の要件やビジネスの要件まではみ出して検討してもらえるのがめっっっっっっちゃありがたい
- 運用やビジネス事情やお客さんは何て言ってるの？ってところまで気にして、知ろうとしたり一緒に考えてくれることがありがたい
柔軟な開発プロセスと意思決定の文化
エンジニアの論理的思考から学ぶことが多い
- 基本的にロジカルシンキングだなーと思っている。自分の書いた要件書とエンジニア兼務のPdMが書いたものを比較するとわかりやすさにかなり差があって勉強させてもらっている
プロダクトへの責任感の共有を高く評価
- 作るだけでなく、運用することにディレクターと同じ責任感を感じてくれることはすごいことだと思います
それ必要ある？に答えるの結構むずい
一言でいうと箱推ししています（？）

特に印象的だったのは、「同じ目的に向かうパートナー」としてエンジニアを捉えている点です。単なる実装者としてではなく、プロダクトの成功に向けた重要な協力者として認識されています。

一方、エンジニアからは以下のような意見が出ました。

ギフティのディレクターはめちゃくちゃリスペクトを感じておりめちゃくちゃありがたいです
社会性なくてすみません
- エンジニアはステ振りのときに人間性を全部技術とかに振っています(諸説あります)
エンジニアがなんか渋い顔してるときは結構未来のこと考えてることが多い気がします
- 5年後に改修困りそうだなとか
- 一方でエンジニアからは「いや今やらんかったら5年後会社ないよ」みたいなのが見えてないので、そういう input をもらえると態度が軟化します
自由にやらせてもらっているのはありがたい一方、個人的にはもうちょいバチバチやりたい
- ディレクターとエンジニアは同じ方向を見なければいけない場面と、綱引きをしなければいけない場面どちらもあると思うので
「仕様決めたからこの通りに作って」って感じじゃなく、「一緒にいいプロダクトを作ろう」という感じがすごくあって楽しい（嬉しい）
- 納得感を持って開発進められる
個人的にはどういうことをやってほしいだけではなく、自分の考えていることを都度教えてくれるディレクターの方とはすごく仕事がしやすいなと思っています
- 色々、見ている範囲がエンジニアとは異なり、エンジニアが見えていない視点も大いにあると思うので、そう言った面を隠さずに共有してくれると結局ディレクターとエンジニアが一番納得した回答を最短で見つけやすい気がします
ビジネスの話もっと聞きたいです
- 直近こういうところが狙い目で〜だったり、競合こんなん作ってますよ、みたいな
越境に対する姿勢がすごい

どちらの目線からも、職種の間に壁を置かずに一緒にモノづくりをしている感覚があり、それがとてもありがたい（嬉しい）ということを感じている人が多いようです。

この関係性の基盤となっているのが、ギフティの行動指針「Geek Suit」です。職域を限定せず、相互理解しながら良いものを作ろうというマインドが根付いています。ディレクターは主に why/what の部分に、エンジニアは how の部分に責任を持ちますが、お互いの領域に染み出してプロダクトをよりよくしていける環境があります。

geek_suits

中には、リスペクトが強くて気を遣われている感覚があるのでもっとバチバチやりたい（健全な綱引きをしたい）と感じている人もいて、普段のコミュニケーションにおける押し引きのバランスは難しいなあと思いました。

また、「それ必要ある？に答えるの結構むずい」というディレクター側の意見もありました。エンジニアは要件を伝えられたときに「それって本当に必要なんですか？」と問い返すことがままあると思います。言われたものをただ作るだけではないという思いがあるからこそ出る発言かと思いますが、問い返し方は気をつけないと少し攻撃的に聞こえてしまいますよね。そもそもファクトや仮説からその機能の必要性や普遍性を考えるのはエンジニアの仕事でもあるので、その答えを PdM に丸投げしないように気をつけていきたいですね。

zatsu 会

こにふぁーさんのブログ Konifar's ZATSU は巷で大人気ですが、弊社でも社内 slack にこのブログの RSS チャンネルがあるぐらいには人気で、各々気になった記事をピックアップして感想を言い合う会をやりました。

ここには挙げきれないですが、以下のような記事が刺さっているようでした。

ただ感想を言い合うだけですが、このようなカジュアルな会もやっています。みんなの仕事のスタイルや大事にしていることを窺い知れて、シンプルに楽しいです笑

チームトポロジー輪読会

本の輪読会をやっていたりもします。

直近ではチームトポロジーという本の輪読会を開催しています。この本は、組織設計のパターンやチーム間の相互作用について体系的にまとめられた良書で、多くの組織で参考にされています。

輪読会では、単に本の内容を追うだけでなく、以下のような観点で議論を深めています。

理論と実践のギャップをどう埋めるか
組織の成長フェーズに応じた適用方法
チーム編成や境界の見直しのタイミング
コンウェイの法則を意識した組織・システム設計

特に、ストリームアラインドチームの設計や、チーム間の依存関係の管理など、実務で直面する具体的な課題について、参加者それぞれの経験や現状の課題感を交えながら話し合っています。

「ストリームアラインドにおけるストリームの定義が難しいよね」とか、「チームの認知負荷の限界量ってどう測ったらいいんだろう」とか、一人で読んでいると中々解釈が難しい部分を他の人と議論しながら深めていくことができるのは、ギルドというコミュニティの良いところです。

また、他社の取り組み事例を眺めてみて、具体的なチップスや課題などを深掘りしたりもしています。

tech.timee.co.jp

note.com

弊社も事業が成長していくにつれて、組織設計の課題が出てきています。システムやチームも細分化されており、システムの依存関係やチーム間のコミュニケーションのオーバーヘッドが大きくなってしまっている部分もあり、現在では大規模なリアーキテクチャによる交通整理が行われていたりします。

コンウェイの法則やコラボレーションモードを意識して、より良い組織設計を模索していければと思います。

終わりに

このように、EM ギルドでは、技術的な話題だけでなく、組織やプロセス、コミュニケーションなど、幅広いトピックについて議論しています。

弊社にはプロダクトや開発プロセスにも興味があるエンジニアもたくさんいます。参加者それぞれが「より良いエンジニアリング」について真摯に考え、時には率直に意見をぶつけ合いながらも、建設的な議論ができています。その場で明確な答えが出せなくとも、悩んでいることや考えていることを知ること自体に価値があるのではないかと思います。また、普段の業務では見えづらい他のメンバーの考え方や価値観を知る良い機会となっています。こうした相互理解は、組織全体のエンジニアリング文化の醸成にも繋がっているのではないでしょうか。

弊社のエンジニア組織は年々拡大していますが、人が増えるほど全体の開発プロセスの設計も難易度が上がっていきます。日々、より良いエンジニアリングを目指して活発に議論を続けていければと思います。

それではまた!