8人の個人開発から、“チームで作る開発”へ。勉強会から始まった、コードレビュー文化の醸成とチーム開発への転換
8人の個人開発から、“チームで作る開発”へ。勉強会から始まった、コードレビュー文化の醸成とチーム開発への転換
目次
目次を読み込み中...
勉強会から始まった、コードレビュー文化の醸成とチーム開発への転換
「システムAは○○さん、システムBは△△さん」。担当者しかそのシステムを知らない。誰かが休めば、別の誰かがゼロからコードを読み解くことになる。8名という少数精鋭のチームで、全員が自分の業務を黙々とこなす中、気づけば開発は「8つの個人作業」になっていた。
転機となったのが、チームの課題に合わせてカスタマイズされた全5回の開発勉強会だ。アジャイル開発の基礎からレビュー文化、ドキュメント設計、会議運営まで。勉強会を終えた今、メンバー同士が自発的に集まってウォークスルー（コードの内容をメンバーで一緒に読み合わせる作業）を行うなど、現場の空気は確実に変わりつつある。
なぜ、勉強会という手段を選んだのか。現場では何が変わったのか。CCMシステムの開発・保守を担う大日精化工業の間瀬さんと高橋さんに、チーム開発への文化転換の背景と、その具体的な変化についてお聞きしました。
プロフィール
間瀬友浩さん 大日精化工業 CCM開発チーム 課長
CCM開発一筋でキャリアを歩み、現在は課長としてチームのマネジメントと開発企画・進捗管理を担う。
高橋直也さん 大日精化工業 CCM開発チーム
新卒入社5年目。CCMシステムのデスクトップアプリケーション開発・マイグレーションを担当。
チームのミッションと規模感
── まず、チームのミッションと規模感を教えてください。
間瀬： 私たちのチームは、CCM（コンピューターカラーマッチング）システムの開発・保守を担っています。CCMとは、コンピューターを使って色の配合を計算するシステムです。たとえば塗料や絵の具で特定の色を作りたいとき、従来は職人が経験と勘で配合を調整していました。CCMを使うと、その計算をコンピューターが行ってくれるので、目的の色を効率よく、精度高く再現できます。大日精化工業は化学メーカーとして色材を扱っており、私たちはそのビジネスを支えるシステムを内製で開発しています。
チームは管理職含めて8名。70年代から一貫して内製でやってきた組織です。今のメインミッションは、長年使い続けてきた古いシステムを新しい環境へ引っ越すことと、パソコン専用アプリをインターネット上で動く仕組みに変えることを最優先で進めています。あわせて、最新のAI技術を顧客対応の仕組みに活かすための実験的な開発にも取り組んでいます。
8人の組織で、8人の個人開発。誰も疑わなかった「1人1システム」の文化
── チームの課題感について教えてください。
間瀬： 一番大きかったのは、「1人が1つのシステムを担当する」という開発スタイルが、長年の文化として根付いてしまっていたことです。システムAは○○さん、システムBは△△さん、という形で、その人が1人で作り上げる。当然、そのシステムのことはその人しか分からない。誰かが休んでトラブルが起きたとき、初めて別の人がコードを読み解こうとするんですが、独自実装だらけで手が出せない。そういう状態がずっと続いていました。
お互いのコードを見る文化もなかったので、コーディング規約もない。表面上はまとまったソフトウェアを作っているように見えても、中を開けると全員がバラバラのやり方でやっている。問題だとは分かっていても、それが当たり前になっていたんです。
── 現場で、どんなやりづらさを感じていましたか？
高橋： 長年使ってきたシステムを新しい環境へ引き継ぐ際にですが、昔の説明書が何も残っていませんでした。そのため、プログラムを自分で読み解いて仕組みを調べるしかなく、それが当たり前になっています。「なぜこう作ったのか」と思っても、当時の人がいないため、「どういう意図で作られたんだろう」と思っても、聞ける人がいないケースもあって。
間瀬： そういった声が若手から上がってきたことが、変化のきっかけになりました。ある時、若手メンバーを集めて意見を出し合う場を設けたんです。そこで全員から「チームで開発したい」という声が出てきた。世の中を見ても、ソフトウェア開発はもう1人でやるものじゃない。それならうちも変わっていこう、という流れになりました。
個人からチーム開発へ。伴走にFindy Team+を選んだ理由
── チーム開発への転換を決めてから、最初に何をされましたか？
間瀬： 変えなきゃいけないとは思っていたのですが、正直、何から手をつければいいのかまったく分からない状態でした。我流でずっとやってきたので、体系的に学んだことがない。メンバーも同じで、チーム開発をやりたいという気持ちはあっても、具体的にどう進めればいいかのイメージが全員にとって曖昧なままでした。社内だけで変えようとするには限界があると感じて、まずプロから教わろうと決めました。
── Findyとの出会いのきっかけを教えてください。
間瀬： 展示会でたまたまお声がけいただいたのがきっかけです。最初は開発生産性向上のプロダクト提案をいただいたのですが、話を聞く中で「今の開発体制のままでは、どんなシステムを入れても意味がない」と気づいて。まずチームで開発できる体制を作ることが先だと。そのことを正直に相談したら、開発ノウハウを体系的に学べる勉強会も提供していますよ、と紹介していただきました。内容を確認したところ、若手メンバーからも「受けたい」という声が大きかったので、実施することにしました。
── カリキュラムはどのように決めたのですか？
間瀬： 私たちの課題をそのままファインディさんに伝えて、それに合わせてカスタマイズしてもらいました。何をどの順番で学べばいいかも分からない状態でしたから、そこから一緒に考えてもらえたのは非常に助かりましたね。自分たちだけではどこから手をつければいいかも分からなかったので、伴走してもらえる形は私たちのチームには合っていました。
── 勉強会は全5回、どのような内容でしたか？
間瀬： アジャイル開発の基礎、レビューの推奨手法、ドキュメント設計、要件管理、会議運営という5つのテーマで進めました。座学だけでなく、実際にワークをやりながら学ぶ形式だったので、メンバーも受け身にならずに取り組めました。自分たちの現場を題材にしたワークも多くて、「これ、うちの話だ」と感じながら進められたのがよかったと思います。
「レビューは人格否定ではない」——言葉が変えたチームの空気
── まず、アジャイル開発の基礎から教えてください。
間瀬：アジャイル開発※1の成り立ちからウォータフォール開発※2の違いなど基礎から学ぶことができました。 個人開発からチーム開発への転換がテーマだったんですが、この回を境に、メンバー間で相談し合う空気が少しずつ生まれてきました。それまでは管理職と担当者の間のやり取りはあっても、開発メンバー同士が相談するという場面がほとんどなかったので、そこは大きな変化でした。
※1：短期間を一つのサイクルとして、必要な機能ごとに開発を進め、実際にリリースすることを繰り返す開発手法
※2：工程を段階的に区切り、前の工程に戻らないことを前提に上から順に進行させる開発手法手法
高橋： ちょうど同時期にGoogle Workspaceが導入されたこともあって、分からないことがあればすぐチャットで質問できる環境が整ってきました。テキストで解決しきれない部分は、開発者同士が集まってウォークスルーを実施して、一緒に考えながら進めるようになっています。
── レビュー文化（書いたコードをメンバー同士で確認し合う習慣）についてはいかがでしたか？
間瀬： 「レビューは人格否定ではない」という言葉が、メンバー全員に刺さったようです。後日メンバーと話したとき、みんなが口を揃えてこの言葉を挙げていました。それまではバグが出たとき、どうしてもネガティブな雰囲気になりがちだった。でもこの講義を経て、レビューはあくまでプロダクトに向き合うものであって、その人自身を責めるものじゃないという共通認識が生まれた。よく考えれば分かることですが、自分たちだけでやっていると、なかなか気づけないんですよね。
高橋： 「レビューを行うことでリリースまでのスピードが上がる」という話も、印象に残っています。工程が1つ増えるのに、リリースが早くなるというのは直感に反するじゃないですか。でもその効果を知ってから、レビューに対する見方が変わりました。それまでは正直、評価されているような感覚があって、どこか構えてしまっていたので。
「当たり前」を染み込ませる——ドキュメントと会議が変えた開発の流れ
── ドキュメント設計（どんな文書を・いつ・どう書くかを設計すること）のセッションでは、どんな変化がありましたか？
高橋： 私自身が一番実感したのはここでした。既存システムを新しい環境へ移行する現場では、ドキュメントがないことの弊害を身をもって経験してきたので、「ドキュメントを書く意味」を体系的に整理してもらえたのはすごく腑に落ちました。詳細設計書や仕様書など、ドキュメントにもいろいろな種類があって、それぞれの使い分けまで学べたのも大きかったです。
間瀬： テーマが決まったらいきなりコードを書き始めるのが当たり前になっていたのですが、まず仕様書を書いて、画面設計をして、ドキュメントを作ってから開発に入るという流れへの意識が、メンバー全員に芽生えてきました。当たり前のことに聞こえるかもしれませんが、その当たり前が染み付いていなかったんです。
── 会議運営については、どんな気づきがありましたか？
間瀬： 会議を4つに分類するという考え方が、個人的にすごく使えています。打ち合わせを設定するとき、これはディスカッションの場なのか、ブレストなのか、情報共有なのか、を事前に決めてから設計するようになりました。目的が曖昧なまま何となく集まって終わる、という会議が減ってきたと感じています。
高橋： 私は、打ち合わせの前に解決できることはあらかじめ解決しておくという習慣がつきました。いきなり集まってその場で議論するのではなく、事前に論点を整理してから臨む。小さな変化ですが、会議の密度が変わってきています。
勉強会が変えた、「この実装、どうしてますか？」が自然に生まれる現場へ
── 勉強会を経て、現場で一番変わったことは何ですか？
間瀬： チーム開発を進めるための話し合いが、自然と増えてきたことですね。以前は1人で完結することしか考えていなかったので、自分の知識だけ磨けばいいという発想でした。今は自分が持っている情報をなるべく周りに波及させようという意識が、チーム全体に出てきています。
高橋： 若手の開発者同士で、同じソフトについて話し合う機会が生まれたのが大きいです。以前は1人が1本のソフトを担当していたので、隣の人が何をやっているか話し合うこと自体がなかった。今はチャットや会議の中で「この実装、どうしてますか？」という会話が自然に生まれています。上の方たちが気軽に勉強会を開いてくれることも増えて、ナレッジが共有されやすくなってきました。
── 品質面での変化はありましたか？
間瀬： 問題が見つかるタイミングが、だんだん上流にシフトしてきています。仕様書の段階でみんなで話し合う中で間違いを見つけたり、開発の初期段階で手戻りを減らせるようになってきた。いわゆる「シフトレフト」（問題を後工程ではなく、より早い段階で発見するという考え方）ですが、それが少しずつ実現できてきていると感じています。
高橋： レビューを通じて、情報量が圧倒的に増えました。以前は自分の担当範囲しか見えていなかったのが、他の人のコードや設計に触れることで、チーム全体の動きが見えるようになってきた。視野が広がった感覚があります。
完成形より、今の一歩。PDCAで育てる開発文化
── 習慣化していく上で、今感じている懸念点はありますか？
間瀬： まだ走り始めたばかりで、手探りの部分は正直あります。ルールは一旦作って仮運用している段階なので、メンバーそれぞれがやっていく中でストレスを感じている部分もあるかもしれない。そういったところに私がちゃんと気づいて、フォローできるかどうかが今の一番の課題です。PDCAを回しながらより良くしていく、その繰り返しだと思っています。
高橋： コードレビューの運用については、1回のレビューで見るコード量の目安なども勉強会で学んだんですが、実際の運用ルールやテンプレートはまだ整備中です。そこが固まってくれば、もう少しスムーズに回っていくはずなので、今はそこを整えていくフェーズだと捉えています。
── それでも、確実に変化は起きていると。
間瀬： そうですね。半年前と比べると、チームの空気は明らかに変わっています。メンバーが自分の担当範囲を超えて動こうとする場面が増えてきた。完成形にはまだ遠いですが、向かっている方向は間違っていないという手応えはあります。
── ファインディの支援を通じて、特に良かった点を教えてください。
高橋： 一方的に教えてもらうというより、私たちの現場の話を引き出しながら進めてもらえたのがよかったです。自分たちの課題と学んでいる内容がつながっている感覚があって、「これ、うちの話だ」と思いながら受けられました。講義の内容も、ノウハウを押し付けるというより、組織としてより良くしていくにはどうすればいいかという視点で設計されていて、エンジニアとしての姿勢や考え方まで学べた気がしています。
間瀬： 何から始めればいいか分からない状態から、一緒に考えてもらえたのが大きかったです。カリキュラムを押し付けられるのではなく、私たちの課題を起点に設計してもらえたので、メンバーの納得感も高かった。満足度が100%という結果にも、それが表れていると思います。
──同じように開発文化の変革に悩んでいるチームへアドバイスをお願いします。
間瀬： まずコミュニケーションを取ることだと思います。隣の人がやっている仕事に興味を持って、話しかけてみる。それだけでいい。1人でやっていると気づけないことが、誰かと話すことで見えてくる。その小さな一歩が、チームが変わるきっかけになると思っています。
高橋： コミュニケーションに加えて、記録を残すことです。過去に起きた問題の記録がなければ、同じことが繰り返されたときに対処しづらい。ドキュメントを残す習慣が、じわじわとチームを変えていくと身をもって感じています。
ITと化学、両方の世界に足を踏み入れたい人へ
── 最後に、どんなエンジニアと一緒に働きたいですか？
間瀬： いろんなことに興味を持てる人ですね。私たちはIT企業ではなく化学メーカーなので、システムを作るだけでなく、材料や色のことも知っていないとやっていけない場面があります。ITだけでなく、そういった領域にも面白がって飛び込んでこられる人は、きっと大日精化工業でしかできない仕事ができると思います。
高橋： 私自身、入社して実際に業務をやっていく中で、色や素材の奥深さに改めて引き込まれていきました。。ソフトウェアを通じて実際のものづくりの品質を上げていく、という体験は大日精化工業ならではだと感じています。ITと化学、両方の世界に足を踏み入れてみたいという方には、面白い環境だと思います。
伴走型支援サービス by Findy Team+のサービス詳細は、以下よりご覧いただけます
https://jp.findy-team.io/consulting/service/
経営と開発現場をつなぐAI時代の開発資本プラットフォーム「Findy Team+」はこちらから
勉強会から始まった、コードレビュー文化の醸成とチーム開発への転換
「システムAは○○さん、システムBは△△さん」。担当者しかそのシステムを知らない。誰かが休めば、別の誰かがゼロからコードを読み解くことになる。8名という少数精鋭のチームで、全員が自分の業務を黙々とこなす中、気づけば開発は「8つの個人作業」になっていた。
転機となったのが、チームの課題に合わせてカスタマイズされた全5回の開発勉強会だ。アジャイル開発の基礎からレビュー文化、ドキュメント設計、会議運営まで。勉強会を終えた今、メンバー同士が自発的に集まってウォークスルー（コードの内容をメンバーで一緒に読み合わせる作業）を行うなど、現場の空気は確実に変わりつつある。
なぜ、勉強会という手段を選んだのか。現場では何が変わったのか。CCMシステムの開発・保守を担う大日精化工業の間瀬さんと高橋さんに、チーム開発への文化転換の背景と、その具体的な変化についてお聞きしました。
プロフィール
間瀬友浩さん 大日精化工業 CCM開発チーム 課長
CCM開発一筋でキャリアを歩み、現在は課長としてチームのマネジメントと開発企画・進捗管理を担う。
高橋直也さん 大日精化工業 CCM開発チーム
新卒入社5年目。CCMシステムのデスクトップアプリケーション開発・マイグレーションを担当。
チームのミッションと規模感
── まず、チームのミッションと規模感を教えてください。
間瀬： 私たちのチームは、CCM（コンピューターカラーマッチング）システムの開発・保守を担っています。CCMとは、コンピューターを使って色の配合を計算するシステムです。たとえば塗料や絵の具で特定の色を作りたいとき、従来は職人が経験と勘で配合を調整していました。CCMを使うと、その計算をコンピューターが行ってくれるので、目的の色を効率よく、精度高く再現できます。大日精化工業は化学メーカーとして色材を扱っており、私たちはそのビジネスを支えるシステムを内製で開発しています。
チームは管理職含めて8名。70年代から一貫して内製でやってきた組織です。今のメインミッションは、長年使い続けてきた古いシステムを新しい環境へ引っ越すことと、パソコン専用アプリをインターネット上で動く仕組みに変えることを最優先で進めています。あわせて、最新のAI技術を顧客対応の仕組みに活かすための実験的な開発にも取り組んでいます。
8人の組織で、8人の個人開発。誰も疑わなかった「1人1システム」の文化
── チームの課題感について教えてください。
間瀬： 一番大きかったのは、「1人が1つのシステムを担当する」という開発スタイルが、長年の文化として根付いてしまっていたことです。システムAは○○さん、システムBは△△さん、という形で、その人が1人で作り上げる。当然、そのシステムのことはその人しか分からない。誰かが休んでトラブルが起きたとき、初めて別の人がコードを読み解こうとするんですが、独自実装だらけで手が出せない。そういう状態がずっと続いていました。
お互いのコードを見る文化もなかったので、コーディング規約もない。表面上はまとまったソフトウェアを作っているように見えても、中を開けると全員がバラバラのやり方でやっている。問題だとは分かっていても、それが当たり前になっていたんです。
── 現場で、どんなやりづらさを感じていましたか？
高橋： 長年使ってきたシステムを新しい環境へ引き継ぐ際にですが、昔の説明書が何も残っていませんでした。そのため、プログラムを自分で読み解いて仕組みを調べるしかなく、それが当たり前になっています。「なぜこう作ったのか」と思っても、当時の人がいないため、「どういう意図で作られたんだろう」と思っても、聞ける人がいないケースもあって。
間瀬： そういった声が若手から上がってきたことが、変化のきっかけになりました。ある時、若手メンバーを集めて意見を出し合う場を設けたんです。そこで全員から「チームで開発したい」という声が出てきた。世の中を見ても、ソフトウェア開発はもう1人でやるものじゃない。それならうちも変わっていこう、という流れになりました。
個人からチーム開発へ。伴走にFindy Team+を選んだ理由
── チーム開発への転換を決めてから、最初に何をされましたか？
間瀬： 変えなきゃいけないとは思っていたのですが、正直、何から手をつければいいのかまったく分からない状態でした。我流でずっとやってきたので、体系的に学んだことがない。メンバーも同じで、チーム開発をやりたいという気持ちはあっても、具体的にどう進めればいいかのイメージが全員にとって曖昧なままでした。社内だけで変えようとするには限界があると感じて、まずプロから教わろうと決めました。
── Findyとの出会いのきっかけを教えてください。
間瀬： 展示会でたまたまお声がけいただいたのがきっかけです。最初は開発生産性向上のプロダクト提案をいただいたのですが、話を聞く中で「今の開発体制のままでは、どんなシステムを入れても意味がない」と気づいて。まずチームで開発できる体制を作ることが先だと。そのことを正直に相談したら、開発ノウハウを体系的に学べる勉強会も提供していますよ、と紹介していただきました。内容を確認したところ、若手メンバーからも「受けたい」という声が大きかったので、実施することにしました。
── カリキュラムはどのように決めたのですか？
間瀬： 私たちの課題をそのままファインディさんに伝えて、それに合わせてカスタマイズしてもらいました。何をどの順番で学べばいいかも分からない状態でしたから、そこから一緒に考えてもらえたのは非常に助かりましたね。自分たちだけではどこから手をつければいいかも分からなかったので、伴走してもらえる形は私たちのチームには合っていました。
── 勉強会は全5回、どのような内容でしたか？
間瀬： アジャイル開発の基礎、レビューの推奨手法、ドキュメント設計、要件管理、会議運営という5つのテーマで進めました。座学だけでなく、実際にワークをやりながら学ぶ形式だったので、メンバーも受け身にならずに取り組めました。自分たちの現場を題材にしたワークも多くて、「これ、うちの話だ」と感じながら進められたのがよかったと思います。
「レビューは人格否定ではない」——言葉が変えたチームの空気
── まず、アジャイル開発の基礎から教えてください。
間瀬：アジャイル開発※1の成り立ちからウォータフォール開発※2の違いなど基礎から学ぶことができました。 個人開発からチーム開発への転換がテーマだったんですが、この回を境に、メンバー間で相談し合う空気が少しずつ生まれてきました。それまでは管理職と担当者の間のやり取りはあっても、開発メンバー同士が相談するという場面がほとんどなかったので、そこは大きな変化でした。
※1：短期間を一つのサイクルとして、必要な機能ごとに開発を進め、実際にリリースすることを繰り返す開発手法
※2：工程を段階的に区切り、前の工程に戻らないことを前提に上から順に進行させる開発手法手法
高橋： ちょうど同時期にGoogle Workspaceが導入されたこともあって、分からないことがあればすぐチャットで質問できる環境が整ってきました。テキストで解決しきれない部分は、開発者同士が集まってウォークスルーを実施して、一緒に考えながら進めるようになっています。
── レビュー文化（書いたコードをメンバー同士で確認し合う習慣）についてはいかがでしたか？
間瀬： 「レビューは人格否定ではない」という言葉が、メンバー全員に刺さったようです。後日メンバーと話したとき、みんなが口を揃えてこの言葉を挙げていました。それまではバグが出たとき、どうしてもネガティブな雰囲気になりがちだった。でもこの講義を経て、レビューはあくまでプロダクトに向き合うものであって、その人自身を責めるものじゃないという共通認識が生まれた。よく考えれば分かることですが、自分たちだけでやっていると、なかなか気づけないんですよね。
高橋： 「レビューを行うことでリリースまでのスピードが上がる」という話も、印象に残っています。工程が1つ増えるのに、リリースが早くなるというのは直感に反するじゃないですか。でもその効果を知ってから、レビューに対する見方が変わりました。それまでは正直、評価されているような感覚があって、どこか構えてしまっていたので。
「当たり前」を染み込ませる——ドキュメントと会議が変えた開発の流れ
── ドキュメント設計（どんな文書を・いつ・どう書くかを設計すること）のセッションでは、どんな変化がありましたか？
高橋： 私自身が一番実感したのはここでした。既存システムを新しい環境へ移行する現場では、ドキュメントがないことの弊害を身をもって経験してきたので、「ドキュメントを書く意味」を体系的に整理してもらえたのはすごく腑に落ちました。詳細設計書や仕様書など、ドキュメントにもいろいろな種類があって、それぞれの使い分けまで学べたのも大きかったです。
間瀬： テーマが決まったらいきなりコードを書き始めるのが当たり前になっていたのですが、まず仕様書を書いて、画面設計をして、ドキュメントを作ってから開発に入るという流れへの意識が、メンバー全員に芽生えてきました。当たり前のことに聞こえるかもしれませんが、その当たり前が染み付いていなかったんです。
── 会議運営については、どんな気づきがありましたか？
間瀬： 会議を4つに分類するという考え方が、個人的にすごく使えています。打ち合わせを設定するとき、これはディスカッションの場なのか、ブレストなのか、情報共有なのか、を事前に決めてから設計するようになりました。目的が曖昧なまま何となく集まって終わる、という会議が減ってきたと感じています。
高橋： 私は、打ち合わせの前に解決できることはあらかじめ解決しておくという習慣がつきました。いきなり集まってその場で議論するのではなく、事前に論点を整理してから臨む。小さな変化ですが、会議の密度が変わってきています。
勉強会が変えた、「この実装、どうしてますか？」が自然に生まれる現場へ
── 勉強会を経て、現場で一番変わったことは何ですか？
間瀬： チーム開発を進めるための話し合いが、自然と増えてきたことですね。以前は1人で完結することしか考えていなかったので、自分の知識だけ磨けばいいという発想でした。今は自分が持っている情報をなるべく周りに波及させようという意識が、チーム全体に出てきています。
高橋： 若手の開発者同士で、同じソフトについて話し合う機会が生まれたのが大きいです。以前は1人が1本のソフトを担当していたので、隣の人が何をやっているか話し合うこと自体がなかった。今はチャットや会議の中で「この実装、どうしてますか？」という会話が自然に生まれています。上の方たちが気軽に勉強会を開いてくれることも増えて、ナレッジが共有されやすくなってきました。
── 品質面での変化はありましたか？
間瀬： 問題が見つかるタイミングが、だんだん上流にシフトしてきています。仕様書の段階でみんなで話し合う中で間違いを見つけたり、開発の初期段階で手戻りを減らせるようになってきた。いわゆる「シフトレフト」（問題を後工程ではなく、より早い段階で発見するという考え方）ですが、それが少しずつ実現できてきていると感じています。
高橋： レビューを通じて、情報量が圧倒的に増えました。以前は自分の担当範囲しか見えていなかったのが、他の人のコードや設計に触れることで、チーム全体の動きが見えるようになってきた。視野が広がった感覚があります。
完成形より、今の一歩。PDCAで育てる開発文化
── 習慣化していく上で、今感じている懸念点はありますか？
間瀬： まだ走り始めたばかりで、手探りの部分は正直あります。ルールは一旦作って仮運用している段階なので、メンバーそれぞれがやっていく中でストレスを感じている部分もあるかもしれない。そういったところに私がちゃんと気づいて、フォローできるかどうかが今の一番の課題です。PDCAを回しながらより良くしていく、その繰り返しだと思っています。
高橋： コードレビューの運用については、1回のレビューで見るコード量の目安なども勉強会で学んだんですが、実際の運用ルールやテンプレートはまだ整備中です。そこが固まってくれば、もう少しスムーズに回っていくはずなので、今はそこを整えていくフェーズだと捉えています。
── それでも、確実に変化は起きていると。
間瀬： そうですね。半年前と比べると、チームの空気は明らかに変わっています。メンバーが自分の担当範囲を超えて動こうとする場面が増えてきた。完成形にはまだ遠いですが、向かっている方向は間違っていないという手応えはあります。
── ファインディの支援を通じて、特に良かった点を教えてください。
高橋： 一方的に教えてもらうというより、私たちの現場の話を引き出しながら進めてもらえたのがよかったです。自分たちの課題と学んでいる内容がつながっている感覚があって、「これ、うちの話だ」と思いながら受けられました。講義の内容も、ノウハウを押し付けるというより、組織としてより良くしていくにはどうすればいいかという視点で設計されていて、エンジニアとしての姿勢や考え方まで学べた気がしています。
間瀬： 何から始めればいいか分からない状態から、一緒に考えてもらえたのが大きかったです。カリキュラムを押し付けられるのではなく、私たちの課題を起点に設計してもらえたので、メンバーの納得感も高かった。満足度が100%という結果にも、それが表れていると思います。
──同じように開発文化の変革に悩んでいるチームへアドバイスをお願いします。
間瀬： まずコミュニケーションを取ることだと思います。隣の人がやっている仕事に興味を持って、話しかけてみる。それだけでいい。1人でやっていると気づけないことが、誰かと話すことで見えてくる。その小さな一歩が、チームが変わるきっかけになると思っています。
高橋： コミュニケーションに加えて、記録を残すことです。過去に起きた問題の記録がなければ、同じことが繰り返されたときに対処しづらい。ドキュメントを残す習慣が、じわじわとチームを変えていくと身をもって感じています。
ITと化学、両方の世界に足を踏み入れたい人へ
── 最後に、どんなエンジニアと一緒に働きたいですか？
間瀬： いろんなことに興味を持てる人ですね。私たちはIT企業ではなく化学メーカーなので、システムを作るだけでなく、材料や色のことも知っていないとやっていけない場面があります。ITだけでなく、そういった領域にも面白がって飛び込んでこられる人は、きっと大日精化工業でしかできない仕事ができると思います。
高橋： 私自身、入社して実際に業務をやっていく中で、色や素材の奥深さに改めて引き込まれていきました。。ソフトウェアを通じて実際のものづくりの品質を上げていく、という体験は大日精化工業ならではだと感じています。ITと化学、両方の世界に足を踏み入れてみたいという方には、面白い環境だと思います。
伴走型支援サービス by Findy Team+のサービス詳細は、以下よりご覧いただけます
https://jp.findy-team.io/consulting/service/
経営と開発現場をつなぐAI時代の開発資本プラットフォーム「Findy Team+」はこちらから
8人の個人開発から、“チームで作る開発”へ。勉強会から始まった、コードレビュー文化の醸成とチーム開発への転換
勉強会から始まった、コードレビュー文化の醸成とチーム開発への転換
「システムAは○○さん、システムBは△△さん」。担当者しかそのシステムを知らない。誰かが休めば、別の誰かがゼロからコードを読み解くことになる。8名という少数精鋭のチームで、全員が自分の業務を黙々とこなす中、気づけば開発は「8つの個人作業」になっていた。
転機となったのが、チームの課題に合わせてカスタマイズされた全5回の開発勉強会だ。アジャイル開発の基礎からレビュー文化、ドキュメント設計、会議運営まで。勉強会を終えた今、メンバー同士が自発的に集まってウォークスルー（コードの内容をメンバーで一緒に読み合わせる作業）を行うなど、現場の空気は確実に変わりつつある。
なぜ、勉強会という手段を選んだのか。現場では何が変わったのか。CCMシステムの開発・保守を担う大日精化工業の間瀬さんと高橋さんに、チーム開発への文化転換の背景と、その具体的な変化についてお聞きしました。
プロフィール
間瀬友浩さん 大日精化工業 CCM開発チーム 課長
CCM開発一筋でキャリアを歩み、現在は課長としてチームのマネジメントと開発企画・進捗管理を担う。
高橋直也さん 大日精化工業 CCM開発チーム
新卒入社5年目。CCMシステムのデスクトップアプリケーション開発・マイグレーションを担当。
チームのミッションと規模感
── まず、チームのミッションと規模感を教えてください。
間瀬： 私たちのチームは、CCM（コンピューターカラーマッチング）システムの開発・保守を担っています。CCMとは、コンピューターを使って色の配合を計算するシステムです。たとえば塗料や絵の具で特定の色を作りたいとき、従来は職人が経験と勘で配合を調整していました。CCMを使うと、その計算をコンピューターが行ってくれるので、目的の色を効率よく、精度高く再現できます。大日精化工業は化学メーカーとして色材を扱っており、私たちはそのビジネスを支えるシステムを内製で開発しています。
チームは管理職含めて8名。70年代から一貫して内製でやってきた組織です。今のメインミッションは、長年使い続けてきた古いシステムを新しい環境へ引っ越すことと、パソコン専用アプリをインターネット上で動く仕組みに変えることを最優先で進めています。あわせて、最新のAI技術を顧客対応の仕組みに活かすための実験的な開発にも取り組んでいます。
8人の組織で、8人の個人開発。誰も疑わなかった「1人1システム」の文化
── チームの課題感について教えてください。
間瀬： 一番大きかったのは、「1人が1つのシステムを担当する」という開発スタイルが、長年の文化として根付いてしまっていたことです。システムAは○○さん、システムBは△△さん、という形で、その人が1人で作り上げる。当然、そのシステムのことはその人しか分からない。誰かが休んでトラブルが起きたとき、初めて別の人がコードを読み解こうとするんですが、独自実装だらけで手が出せない。そういう状態がずっと続いていました。
お互いのコードを見る文化もなかったので、コーディング規約もない。表面上はまとまったソフトウェアを作っているように見えても、中を開けると全員がバラバラのやり方でやっている。問題だとは分かっていても、それが当たり前になっていたんです。
── 現場で、どんなやりづらさを感じていましたか？
高橋： 長年使ってきたシステムを新しい環境へ引き継ぐ際にですが、昔の説明書が何も残っていませんでした。そのため、プログラムを自分で読み解いて仕組みを調べるしかなく、それが当たり前になっています。「なぜこう作ったのか」と思っても、当時の人がいないため、「どういう意図で作られたんだろう」と思っても、聞ける人がいないケースもあって。
間瀬： そういった声が若手から上がってきたことが、変化のきっかけになりました。ある時、若手メンバーを集めて意見を出し合う場を設けたんです。そこで全員から「チームで開発したい」という声が出てきた。世の中を見ても、ソフトウェア開発はもう1人でやるものじゃない。それならうちも変わっていこう、という流れになりました。
個人からチーム開発へ。伴走にFindy Team+を選んだ理由
── チーム開発への転換を決めてから、最初に何をされましたか？
間瀬： 変えなきゃいけないとは思っていたのですが、正直、何から手をつければいいのかまったく分からない状態でした。我流でずっとやってきたので、体系的に学んだことがない。メンバーも同じで、チーム開発をやりたいという気持ちはあっても、具体的にどう進めればいいかのイメージが全員にとって曖昧なままでした。社内だけで変えようとするには限界があると感じて、まずプロから教わろうと決めました。
── Findyとの出会いのきっかけを教えてください。
間瀬： 展示会でたまたまお声がけいただいたのがきっかけです。最初は開発生産性向上のプロダクト提案をいただいたのですが、話を聞く中で「今の開発体制のままでは、どんなシステムを入れても意味がない」と気づいて。まずチームで開発できる体制を作ることが先だと。そのことを正直に相談したら、開発ノウハウを体系的に学べる勉強会も提供していますよ、と紹介していただきました。内容を確認したところ、若手メンバーからも「受けたい」という声が大きかったので、実施することにしました。
── カリキュラムはどのように決めたのですか？
間瀬： 私たちの課題をそのままファインディさんに伝えて、それに合わせてカスタマイズしてもらいました。何をどの順番で学べばいいかも分からない状態でしたから、そこから一緒に考えてもらえたのは非常に助かりましたね。自分たちだけではどこから手をつければいいかも分からなかったので、伴走してもらえる形は私たちのチームには合っていました。
── 勉強会は全5回、どのような内容でしたか？
間瀬： アジャイル開発の基礎、レビューの推奨手法、ドキュメント設計、要件管理、会議運営という5つのテーマで進めました。座学だけでなく、実際にワークをやりながら学ぶ形式だったので、メンバーも受け身にならずに取り組めました。自分たちの現場を題材にしたワークも多くて、「これ、うちの話だ」と感じながら進められたのがよかったと思います。
「レビューは人格否定ではない」——言葉が変えたチームの空気
── まず、アジャイル開発の基礎から教えてください。
間瀬：アジャイル開発※1の成り立ちからウォータフォール開発※2の違いなど基礎から学ぶことができました。 個人開発からチーム開発への転換がテーマだったんですが、この回を境に、メンバー間で相談し合う空気が少しずつ生まれてきました。それまでは管理職と担当者の間のやり取りはあっても、開発メンバー同士が相談するという場面がほとんどなかったので、そこは大きな変化でした。
※1：短期間を一つのサイクルとして、必要な機能ごとに開発を進め、実際にリリースすることを繰り返す開発手法
※2：工程を段階的に区切り、前の工程に戻らないことを前提に上から順に進行させる開発手法手法
高橋： ちょうど同時期にGoogle Workspaceが導入されたこともあって、分からないことがあればすぐチャットで質問できる環境が整ってきました。テキストで解決しきれない部分は、開発者同士が集まってウォークスルーを実施して、一緒に考えながら進めるようになっています。
── レビュー文化（書いたコードをメンバー同士で確認し合う習慣）についてはいかがでしたか？
間瀬： 「レビューは人格否定ではない」という言葉が、メンバー全員に刺さったようです。後日メンバーと話したとき、みんなが口を揃えてこの言葉を挙げていました。それまではバグが出たとき、どうしてもネガティブな雰囲気になりがちだった。でもこの講義を経て、レビューはあくまでプロダクトに向き合うものであって、その人自身を責めるものじゃないという共通認識が生まれた。よく考えれば分かることですが、自分たちだけでやっていると、なかなか気づけないんですよね。
高橋： 「レビューを行うことでリリースまでのスピードが上がる」という話も、印象に残っています。工程が1つ増えるのに、リリースが早くなるというのは直感に反するじゃないですか。でもその効果を知ってから、レビューに対する見方が変わりました。それまでは正直、評価されているような感覚があって、どこか構えてしまっていたので。
「当たり前」を染み込ませる——ドキュメントと会議が変えた開発の流れ
── ドキュメント設計（どんな文書を・いつ・どう書くかを設計すること）のセッションでは、どんな変化がありましたか？
高橋： 私自身が一番実感したのはここでした。既存システムを新しい環境へ移行する現場では、ドキュメントがないことの弊害を身をもって経験してきたので、「ドキュメントを書く意味」を体系的に整理してもらえたのはすごく腑に落ちました。詳細設計書や仕様書など、ドキュメントにもいろいろな種類があって、それぞれの使い分けまで学べたのも大きかったです。
間瀬： テーマが決まったらいきなりコードを書き始めるのが当たり前になっていたのですが、まず仕様書を書いて、画面設計をして、ドキュメントを作ってから開発に入るという流れへの意識が、メンバー全員に芽生えてきました。当たり前のことに聞こえるかもしれませんが、その当たり前が染み付いていなかったんです。
── 会議運営については、どんな気づきがありましたか？
間瀬： 会議を4つに分類するという考え方が、個人的にすごく使えています。打ち合わせを設定するとき、これはディスカッションの場なのか、ブレストなのか、情報共有なのか、を事前に決めてから設計するようになりました。目的が曖昧なまま何となく集まって終わる、という会議が減ってきたと感じています。
高橋： 私は、打ち合わせの前に解決できることはあらかじめ解決しておくという習慣がつきました。いきなり集まってその場で議論するのではなく、事前に論点を整理してから臨む。小さな変化ですが、会議の密度が変わってきています。
勉強会が変えた、「この実装、どうしてますか？」が自然に生まれる現場へ
── 勉強会を経て、現場で一番変わったことは何ですか？
間瀬： チーム開発を進めるための話し合いが、自然と増えてきたことですね。以前は1人で完結することしか考えていなかったので、自分の知識だけ磨けばいいという発想でした。今は自分が持っている情報をなるべく周りに波及させようという意識が、チーム全体に出てきています。
高橋： 若手の開発者同士で、同じソフトについて話し合う機会が生まれたのが大きいです。以前は1人が1本のソフトを担当していたので、隣の人が何をやっているか話し合うこと自体がなかった。今はチャットや会議の中で「この実装、どうしてますか？」という会話が自然に生まれています。上の方たちが気軽に勉強会を開いてくれることも増えて、ナレッジが共有されやすくなってきました。
── 品質面での変化はありましたか？
間瀬： 問題が見つかるタイミングが、だんだん上流にシフトしてきています。仕様書の段階でみんなで話し合う中で間違いを見つけたり、開発の初期段階で手戻りを減らせるようになってきた。いわゆる「シフトレフト」（問題を後工程ではなく、より早い段階で発見するという考え方）ですが、それが少しずつ実現できてきていると感じています。
高橋： レビューを通じて、情報量が圧倒的に増えました。以前は自分の担当範囲しか見えていなかったのが、他の人のコードや設計に触れることで、チーム全体の動きが見えるようになってきた。視野が広がった感覚があります。
完成形より、今の一歩。PDCAで育てる開発文化
── 習慣化していく上で、今感じている懸念点はありますか？
間瀬： まだ走り始めたばかりで、手探りの部分は正直あります。ルールは一旦作って仮運用している段階なので、メンバーそれぞれがやっていく中でストレスを感じている部分もあるかもしれない。そういったところに私がちゃんと気づいて、フォローできるかどうかが今の一番の課題です。PDCAを回しながらより良くしていく、その繰り返しだと思っています。
高橋： コードレビューの運用については、1回のレビューで見るコード量の目安なども勉強会で学んだんですが、実際の運用ルールやテンプレートはまだ整備中です。そこが固まってくれば、もう少しスムーズに回っていくはずなので、今はそこを整えていくフェーズだと捉えています。
── それでも、確実に変化は起きていると。
間瀬： そうですね。半年前と比べると、チームの空気は明らかに変わっています。メンバーが自分の担当範囲を超えて動こうとする場面が増えてきた。完成形にはまだ遠いですが、向かっている方向は間違っていないという手応えはあります。
── ファインディの支援を通じて、特に良かった点を教えてください。
高橋： 一方的に教えてもらうというより、私たちの現場の話を引き出しながら進めてもらえたのがよかったです。自分たちの課題と学んでいる内容がつながっている感覚があって、「これ、うちの話だ」と思いながら受けられました。講義の内容も、ノウハウを押し付けるというより、組織としてより良くしていくにはどうすればいいかという視点で設計されていて、エンジニアとしての姿勢や考え方まで学べた気がしています。
間瀬： 何から始めればいいか分からない状態から、一緒に考えてもらえたのが大きかったです。カリキュラムを押し付けられるのではなく、私たちの課題を起点に設計してもらえたので、メンバーの納得感も高かった。満足度が100%という結果にも、それが表れていると思います。
──同じように開発文化の変革に悩んでいるチームへアドバイスをお願いします。
間瀬： まずコミュニケーションを取ることだと思います。隣の人がやっている仕事に興味を持って、話しかけてみる。それだけでいい。1人でやっていると気づけないことが、誰かと話すことで見えてくる。その小さな一歩が、チームが変わるきっかけになると思っています。
高橋： コミュニケーションに加えて、記録を残すことです。過去に起きた問題の記録がなければ、同じことが繰り返されたときに対処しづらい。ドキュメントを残す習慣が、じわじわとチームを変えていくと身をもって感じています。
ITと化学、両方の世界に足を踏み入れたい人へ
── 最後に、どんなエンジニアと一緒に働きたいですか？
間瀬： いろんなことに興味を持てる人ですね。私たちはIT企業ではなく化学メーカーなので、システムを作るだけでなく、材料や色のことも知っていないとやっていけない場面があります。ITだけでなく、そういった領域にも面白がって飛び込んでこられる人は、きっと大日精化工業でしかできない仕事ができると思います。
高橋： 私自身、入社して実際に業務をやっていく中で、色や素材の奥深さに改めて引き込まれていきました。。ソフトウェアを通じて実際のものづくりの品質を上げていく、という体験は大日精化工業ならではだと感じています。ITと化学、両方の世界に足を踏み入れてみたいという方には、面白い環境だと思います。
伴走型支援サービス by Findy Team+のサービス詳細は、以下よりご覧いただけます
https://jp.findy-team.io/consulting/service/
経営と開発現場をつなぐAI時代の開発資本プラットフォーム「Findy Team+」はこちらから
