こんにちは、アダコテックでソフトウェアエンジニアをしている小嶋です。
アダコテックでは例年、開発チームで合宿を行っており、昨年10月末にも熱海で1泊2日の開発合宿を実施しておりました。
毎年、今期の振り返りや来期の目標についてチームで議論することに加えてイベントを実施するのですが、今回は私がイベント企画を担当しました。結果、イベント自体は皆の満足感も高かったようで、個人的にもこの合宿企画から開発にも通じる示唆を得られたので綴ってみます。
料理
主要メンバーの異動もあり、改めてチーム間の関係性を強めたいという合宿の方向性を開発部長とエンジニアリングマネージャーから伺ったうえで、今回は「料理」をテーマにした企画を実施しました。
開発チームの合宿と聞くと、時間刻みのアジェンダでハッカソンや技術系イベントがぎっしり詰まっているものを想像する方は多いと思います。
実際、過去のアダコテックでもかなり綿密な準備のもと、スクラム開発研修のようなものが行われていたようで、数十ページにわたる資料を使った講義のあと、マインクラフトで実践するという、かなり本格的な内容がありました。今見てもボリュームがあり、内容的にも難易度の高いものです。また、コーディング系イベント３連ちゃんといった回もありました。
ただ、1泊2日といった限られた時間でいろんなことを詰め込むことには限界があるとも感じており、もう少し軽く、コミュニケーション重視の企画のほうがよいのではないかと考え、超シンプルな料理にすることにしました。
料理において、何も特別なルールや仕様は設けません。開発チームは8人なので、4人ずつの2チームに分かれ、それぞれのチームが8人分の料理を作る。ただし、料理の内容が被らないように、
- 片方のチーム：主菜担当
- もう片方のチーム：副菜担当
というルールだけ設けました。それ以外は完全にほぼ丸投げの自由なイベントです。
なぜ料理だったのか
私自身もめちゃめちゃ適当に考えたわけではなく、狙いはありました。
1. 料理は「総合的なモノづくり」
料理は、実は開発とかなり似ているのではないかと考えていました。
- どういう方向性にするか話し合う
- 方針をもとに何を作るかチームで決める
- 何が必要かを洗い出す
- 買い出しに行く
- 役割分担して作る
- 完成したものを評価する
企画から実行、振り返りまで、一連のプロセスが自然に含まれています。実際、主菜チームは、もつ鍋を煮込み方に関して音声ChatGPTとひたすら議論するメンバーがいたり、私がいた副菜チームは、そもそもどんな副菜メニューがあるか調べるところからの始まりでした。
2. 制約がちょうどいい
今回の環境が良い制約となりました。
- 予算が限られている
- 熱海という立地で、近くにスーパーが全然なく材料の選択肢が限られる
例えば自分たちのチームでは、ある調味料を買いに行ったものの見つからず、「じゃあ香味ペーストで代用しよう」と判断したり、別の店でじゃがいもが安かったので買う材料を微調整したりと、その場その場で柔軟に意思決定することがありました。
まさにアジャイル的な進め方で、臨機応変に対応できました。
3. 歩くことで会話が生まれる
もう一つ意識していたのが「歩くこと」です。買い出しに向かう道中、横並びで歩きながら自然に会話が生まれます。座って向き合うよりも、リラックスして話せるのが不思議なところです。オフィスのある神保町の雑踏から離れ、熱海の落ち着いた雰囲気のもとで普段あまり関わりのないメンバーと、
- 会社のこれまでの歴史
- 開発体制の変遷
- 過去のプロジェクトの話
といった、普段の業務ではなかなか出てこない話題を自然に話すことができました。
完成した料理
最終的に、
- 主菜チーム：もつ鍋
- 副菜チーム：野菜炒め＋じゃがバター
という構成になりました。普段包丁をあまり持たないような男だけで作ることになるので、カオスな料理に溢れることになると思っていたのですが、想像以上にどちらのチームも完成度が高く、お互いの料理を褒め合いながら最後においしくいただきました。
親睦を深めるという目的の合宿で、「好き勝手に動いてご飯作ってください！」という実に練られていない、企画者としてはだめだめなイベントだったとは思いますが、体験してくれたメンバーに感想を伺うと皆結構満足した様でこちらとしては嬉しいものでした。
シンプルでいいのではないか？
今回改めて感じたのは、考え抜かれた“大人なスタンス”でなくもっと素直でシンプルな発想でもいいのでは、ということです。
過去であれば、スクラム開発のお作法が詰めに詰め込まれた座学&ワークショップや開発イベント盛りだくさんでかえって疲れてしまったり、少し掴みどころがないと感じたメンバーもいたようでした。実際、私自身が講義資料を見て圧倒された部分もありました。目的によっては、今回のように最初からがちがちに練りすぎない設計しすぎない、というのもありなんじゃないかと感じました。
何かを構想する上で、自分の経験や知識をすべてを詰めこもうとしてしまうことはあると思います。しかし、さまざまな技術や手法を取り込むこと自体が目的化してしまい、気づけば必要以上に複雑な設計になってしまうということもあると思います。開発現場で例えると、
- 将来のスケールも不明なのに、過剰に分割されたマイクロサービスを採用する
- 抽象化しすぎて、実装者にしか理解できない汎用コードが生まれる
- フロントエンドで、規模感を考慮せずデフォルト感覚でReduxなどのグローバル状態管理ライブラリを導入する
などです。場合によっては、
- モノリポ＋シンプルなMVC設計
- 抽象化よりもコピペベースの素直な実装
- ライブラリは導入せず、Contextベースの状態管理
といった、シンプル設計の方が結果的に良い開発体験につながることもあるでしょう。
特にアダコテックのような
- 各製品せいぜい2,3名体制で開発
- 製品の将来性は未知
- 機能やデザインの更新頻度が高い
- 走りながら仕様も考える
- ユーザー検証前
みたいな段階では、"最初から完璧を目指しすぎず、必要以上に技術や開発手法を詰め込んで複雑な仕組みを持ち込まない"といった姿勢のほうが、チーム全体にとって良い結果につながることが多いのではないかと感じています。
もちろん、すべてを単純化すればよいわけではありませんし、新しい技術や他社の事例を学んでいくことは欠かせません。しかし、学んだことを自分の現場に導入することがチームメンバーにとって本当に満足か、そもそも他の先進事例をただ猿真似しているだけではないか、会社やチームの状況を顧みて「それ必要？もっと簡単でいいんじゃない？削減はできない？」と考えてみる価値はあるでしょう。今回の合宿企画では、そんな原点を思い出させてくれる良い機会になりました。
これからの開発でも、特に初期段階では必要以上に構えすぎず、小学二年生のように、素直でシンプルな気持ちで臨む姿勢を大切にしていきます。
