「うちのセミナー」略して「うちセミ」は、各社のエンジニア向け社内勉強会をのぞき見することで、開発組織文化やリアルな現場の雰囲気に迫っていく連載企画です。今回は株式会社ニーリーで実施している、アーキテクチャチーム（以下、ARCHチーム）主導の「わいわい会」をのぞいてみました！
プロダクト志向の強いニーリーの開発組織で、技術的な問題をわいわい議論できるオープンな場が、全エンジニアの知的好奇心を刺激し、プロダクトをより良くする着火剤になっているようです。
株式会社ニーリー
設立：2013年
従業員数：260名。プロダクト組織は66名、うち正社員は35名
事業内容：月極駐車場オンライン契約サービス、契約管理サービス「Park Direct」の開発・運営、法人車両用駐車場管理システム「Park Direct for Business」の開発・運営
「バックエンドプラクティスわいわい会」「フロントエンドプラクティスわいわい会」
期間：2025年2月〜現在
頻度：毎週（BE・FEを交互に実施） / 金曜 17:30~18:00
目的：コード品質の向上 / プラクティスの共有
形式：①ARCHチームから事前に資料を共有 ②オンラインで解説 ③質疑応答 / 任意参加
⭐︎ のぞき見メモ
この日のテーマは「Policy Patternのすすめ（Always Valid Entity Principleに添えて）」。Always Valid Domain Model の概念の紹介と、それを組み合わせてポリシーをつくることでアプリケーションの組み合わせを制限し、見通しの良い設計をする方法について、具体的な例を交えて議論されました。
「わいわい会」を主催するプラットフォーム本部 ARCHチーム リードの野呂有我さんにお話を伺います。
オンライン開催の「わいわい会」の様子
テキストでは不十分。必要なのは対話でした
― 「わいわい会」を始めた経緯を教えてください
野呂：ARCHチームが発足したのは2022年。スタートアップでアーキテクチャ専門のチームを発足するには、異例の早さかと思います。ただ実際のところ、当初のARCHチームが担っていたのは、“ソフトウェアアーキテクチャや設計”といった上流工程の責務というより、“新規のフレームワーク導入や置き換えを爆速で進める”とか、“既存のコードベースをリファクタリングする”といった、思い切り手を動かして、腕力でなんとかする泥臭い作業が中心でした。
その後、組織は急拡大し、開発組織の社員数が4名から30名近くに増え、チーム数も3チームから13チームに再編されました。コードベースの規模、機能数、開発速度、何もかもが一気にスケールした結果、“ARCHチームのメンバーが手を動かしてなんとかする”という世界観では追いつかなくなってきて、ARCHチームと組織全体をつなぐ効率的なコミュニケーションの仕組みが必要になってきました。
そこでまず行ったのが、技術に関するTipsをまとめたプラクティス集を作成し、配布する取り組みです。コーディング規約ではなく、あえてTipsとしたのは、いかなる状況でも適用可能な規約はとても限られているので、最終的には開発者自身が最適な方法を選択すべきだと考えているからです。
しかしやってみたものの、資料だけでは意図を伝えきれませんでしたし、受け手の理解度や活用状況もわかりませんでした。そこでテキスト共有だけではなく“対話する場”をつくりたくて、この「わいわい会」を始めました。
「わいわい会」では、ARCHチームが作成したプラクティス共有の資料に沿って、まずARCHチームから説明をしたあと、関係者を中心に多くの参加者から質問や感想をもらうようにしています。双方向に話し合うことで、そのプラクティスに関する理解が深まりますし、組織に必要なことも見えてきます。
― 議題やテーマはどのように決めていますか？
野呂：実際の業務で発生しているアプリケーションの課題を取り上げることが多いです。
例えば今回見てもらった勉強会では、Always ValidなオブジェクトとPolicy Patternについて取り上げましたが、これは「バリデーションをどこで行うべきか？」という開発者の素朴な疑問であり、アプリケーション構成に関する質問がきっかけになっています。
こうした“開発者が今、困っている課題”は、私たちARCHチームにとってはご馳走です。誰かが困っているなら、他にも困っている人がいるはずですから。なので、質問に答える形でARCHチームがプラクティスを作成し、質問をくれた人に共有＆フィードバックをした上で、「わいわい会」でも取り上げています。
また開発者からの質問以外にも、ARCHチームが発見した“良くないコード”の発生原因と対処法について扱うことも多いです。特にその原因が、“先に存在した良くないコードの模倣”だった場合には、同様に模倣され続けてしまう可能性が高いので、優先的に「わいわい会」で取り上げるようにしています。
最近取り上げたテーマ一覧
― 得意分野やバックグラウンドが異なるエンジニア全員が参加されていますが、運営の工夫はありますか？
野呂：まず資料では要点だけでなく、読み手がイメージしやすい具体例を交えて記載するようにしています。この資料を元に「わいわい会」で対話をして、立ち戻りが必要なことがわかれば、次回のテーマにするなど、理解度に合わせた柔軟な対応をしています。
例えば今回見てもらった「わいわい会」では、議論の範囲をコードの表現に絞っていたのですが、話しているうちに、“業務をどう整理するべきか”というコードに落ちる以前が重要だという話に発展していきました。
ただ、それも含めて全部を社内プラクティスに載せようとすると、それはもう書籍になってしまいます（笑）そんな時こそ「名著に頼ろう！」ということで、『ドメイン駆動開発を始めよう』の第１章を題材にした輪読会を行ってはどうか、というアイディアが上がりました。このように「わいわい会」をきっかけに、やりたい社内勉強会がどんどん増えています。
技術に向き合う時間を大切にしたい
― 「わいわい会」で得られた、具体的な成果はありますか？
野呂：「わいわい会」ドリブンで組織の知見が蓄積され、体系的に整理されたことで、エンジニア同士の意思疎通がどんどん円滑になっていっています。
先述の通り当社では、基本的な部分以外ではコーディング規約をなるべく増やさないようにしていますし、アーキテクチャに関しても厳格な取り決めは骨子までにして、なるべく柔軟性を保てるようにしています。
それでも「わいわい会」で対話する中で、「これはもう規約にしていいよね」と開発者の総意が取れる瞬間があります。こうして決まった規約は、自然と浸透しますし、問題になることも少ないんですよね。
― 「わいわい会」がきっかけになった規約で、印象に残っているものはありますか？
最近だと、あるレイヤーにおける共通ロジックの保管場所が決まりました。
これに関しては開発者から質問されたこともないですし、私自身もあえて規約にする必要がないと考えていましたが、対話を通してこの小さな認知負荷がいかに大きいか気づかされました。そして、実はみんなが同じように感じていたということも（笑）
こうした積み重ねが、開発生産性や開発者体験の向上につながるのだと思います。
実施後の振り返りメモ。参加できなかった人のためにも、メモやアーカイブを残している
― 「わいわい会」という形式にして、よかったと感じるのはどんなところですか？
野呂：やはり会話のキャッチボールがあることで意思疎通が取りやすく、実務で活用されやすくなっているようです。別のチームのチャンネルで「わいわい会」で取り上げた話題が語られるシーンをよく目にするようになったので、組織全体のコード品質を高めるという本来の目的を果たしていることを実感しています。
またARCHチームへ寄せられる相談件数も増えました。週1のコミュニケーションを続けたことで、お互いを知れて、「この問題ならこの人に相談したら良さそうだ」という関係性の構築にもつながったと思います。
― 参加者からは「わいわい会」に、どのような意見やコメントがありますか？
野呂：「開発業務を進める上でとても役立っている」とか、「自分も発表したい」という前向きなコメントをもらっています。なにより「技術に関する建設的な会話ができて、おもしろい」と言ってもらえているのが、個人的にはとてもうれしいです。
当社はプロダクト志向が強い組織ですが、その反面、技術だけに関心があるタイプのエンジニアが多くありません。そうした風土もあってか、これまではオープンな場で技術について会話をする機会がなかったので、私としては、チームとして技術的な成長ができていないのではないか、と危惧していました。
だから実は、この「わいわい会」が、そんなチームの技術的成長を促す起爆剤になればと、ある種のカウンター的な狙いがありました。始めてみれば、みんながこの時間を楽しんでくれているし、組織の力も高まっているので、私の願いが通じた気がしています。
過渡期に突入した今、ナレッジ共有と共通意識をつくる
― 改めて、ニーリーの開発組織やARCHチームの役割について教えてください。
ニーリーの開発組織図
野呂：当社の開発組織は大きく、プロダクトを開発する「プロダクト本部」と、それを支える「プラットフォーム本部」に分かれています。
「プロダクト本部」では、エンジニアが事業創造や事業グロースに積極的に関与していくことを推奨しているため、開発部門とビジネス部門が密にコミュニケーションを取り、エンジニアがPlanningやDeliveryに染み出すカルチャーを発揮できる組織構造になっていることが特徴です。
一方「プラットフォーム本部」は、いいモノをより速くデリバリーするための仕組みを整えています。中でもARCHチームは、コードベースのアーキテクチャを最適化することで中長期的な開発生産性の向上を図るほか、新規システム開発では設計のサポートを行っています。
― 今後はどのような組織を目指していきたいですか？
野呂：セオリーやベストプラクティス、トレードオフを知った上で、今の事業にとってオーバーエンジニアリングにならない、最適な選択ができる状態を目指しています。
今、ニーリーは過渡期にあります。創業事業の「Park Direct」は、駐車場オンライン契約サービスに留まらず、EVインフラやモビリティコマースを含めた次世代のモビリティプラットフォームを目指して拡大中です。プロダクト組織で見ても、2025年現在は35名にまで増えましたし、さらに採用を強化しています。
そんな過渡期を迎えた今こそ、社内のナレッジを資料化し、エンジニア同士で共通認識を持ちながら開発ができる体制を整えたいと考えています。プロダクト志向が強い組織なので、技術のナレッジを共有することは、プロダクト品質を飛躍的に向上させることにつながると思います。
この「わいわい会」の最終的な目的は、プロダクトの品質を良くすることと、プロダクトの価値の提供を早めることです。勉強会という営みは、参加者の技術力向上を通じて、事業の本質的な価値を高める効果があると信じています。知った上で選択できる組織にしていくために、当たり前に知識やノウハウが共有される組織を目指していきたいと思っています。
課題山積の過渡期。象を外に出すための、声を上げてほしい
― 採用活動をされていますが、どんな人がフィットすると思いますか？
野呂：事業への染み出しを重視する文化ですから、サービスの成長に強い関心を持ちながら開発を楽しむマインドを持っている人。そして、エンジニア以外のあらゆる職種の方をリスペクトする心を持っている人が、フィットすると思います。
よくある話ですが、例えば新機能を設計するとき、それがどのように使われ、どのような課題を解決するのかを知らなければ、的外れな機能が出来上がってしまいます。ではどのように、その使われ方や現在の課題を知るのかといえば、やはり対話や非同期のコミュニケーションが必要になりますが、相手にリスペクトができないと、どうしても想像が浅く、理解が薄くなってしまいます。
さらに言えば、本質的な理解が浅い状態で作られた設計は、致命的な欠陥を引き起こしかねません。当社では、エンジニアのサービス理解が、それほど重要なことだと考えています。
― 新メンバーには、入社後どのような動きを期待しますか？
野呂：「象がいる！外に出すので手伝ってください！」と声を上げてほしいです。（課題を見つけたら、解決のために周りに協力をあおいでほしい）
当社の場合、開発組織の一番の関心事は、事業です。技術的に明らかにおかしなことがあっても、事業に大きな影響がなければ、優先度を下げてしまう傾向があります。なので既存メンバーが平然としていても、その雰囲気に流されずissueを上げていただきたいです。また同時に、誰もが声を上げ、助け合えるフラットな組織でありたいとも思います。
当事者になると環境に慣れて些細な違和感に気付きにくくなるものですが、あたかも自身が顧客であるかのように、プロダクトに対する敏感さを持ち続け、また同時に、プロダクトをつくる人としてのオーナーシップを両立してほしいと思います。
― 最後に求職者へメッセージをお願いします！
野呂：いまニーリーでは、サービス・プロダクト・組織、3つの側面で急速に拡大している、とてもおもしろいフェーズです！事業を一緒にグロースさせてくれる方、大量の活きの良い課題を用意してお待ちしております。
株式会社ニーリーはエンジニア採用中
以上、ニーリーの社内勉強会をレポートしました。
ニーリーではさまざまなポジションでエンジニアを募集しています。関心のある方は、以下の求人票をチェック＆「いいかも」を押して、関心を伝えてみましょう。