はじめましての方ははじめまして。
ご存知の方はお久しぶりです。

Classiプロダクト部の徳光史考(@toku345)です。

ある日社内を歩いていたら、バッタリ出会った人事の三戸さんに素敵な笑顔で 強要 お願いされちゃったので、今回は私が部長をやっている「整地部」という社内活動を通じて私が学んだことについて書かせていただきます。

tl;dr

書き出したら長くなってしまったので "Classi整地部" で学んだこと3行まとめ

• Classiには残念ながらイケてないところも所々あるが、自分から動き出せば少しずつでも改善を続けていけることを実感
• モブプロ ＆ TDD ＆ ふりかえりのコンボ、すっごくいいよ
• 学びの形を進化させるプラットフォームを提供している我々も、日々学び、より良くカイゼンしていくことができる

そもそも整地部とは？

整地部とはClassiの社内部活動です。
プロダクト部の有志が週一のペースで 業務時間中に 集まり、モブプログラミング（以下、モブプロ）で以下のようなことをやっています。

• コード上の落とし穴を塞ぐ
• 意図が分かりづらいコードを意図が伝わるコードに置き換える
• コードの凸凹をキレイに舗装する
• サポートツールの作成

【コラム】なぜ整地が必要なコードが存在するのか？

プログラムというものは一度書いたら終わりではなく、機能の追加や使っているソフトウェアのバージョンアップなどで十中八九あとから手を入れることになります。

そのため保守性が高い（＝あとから手を入れやすい）コードを書く必要があるのですが、最初からそういったコードを書くのはなかなかに難しいです。

その理由として

• 開発を続けていくうちに大きく要件が変わってしまう
• 納期が迫ってきて「やっつけ仕事」をやらないとリリースできない状況に陥ることが多々ある
• エンジニアのスキル・モラル不足
• 書いた本人は（その瞬間は）保守しやすいと思っていた（あとから見るとアレレ...?）

といったことが挙げられます。

※ それぞれの理由について話し始めると、それぞれが１記事になってしまうほど奥が深いので、詳細はここでは割愛します。
（詳しく知りたい方は是非、Classiまで遊びに来て聞いてください！）

どうして整地部を始めようと思ったのか？

コードをキレイにしたかったが一人では限界があった

私は2018年2月にClassiに入社したのですが、その時担当となったコードは、

• 先任のエンジニアがClassiを離れたばかり
• その他の詳しいエンジニアは他プロジェクトのほうが優先となっていた

ということで、ほぼ一人で面倒を見ることになりました。4月に大きなリリースが控えており、8割ほど完成していたコードを引き継いでなんとかリリースまでこぎつけました。

ただ、おそよそ2ヶ月触った感触では「お世辞にも保守性が高いとは言えない品質」で、このままでは次に大きな機能改修がやってきたら...💀💀💀💀💀

そこで意を決して一人黙々とカイゼンを開始したのですが、

• リリース後に見つかったバグ修正
• リリース後に必要だったことに気づいた機能の追加
• 他機能も任されることになったのでその引き継ぎ

などに追われ全然時間が取れず、理想と現実とのギャップに次第に心が消耗していきました💔

モブプロを試してみたかった

4月に体制が変更され、haazimeさんと同じチームになってから風向きが変わりました。
haazimeさんは前職で本物のScrumチームを経験され、アジャイル・ペアプロ・モブプロに対する造詣がとてつもなく深い方でした。
新しいチームではhaazimeさんと常時ペアプログラミング（ペアプロ）で進めることになりました。
（最初はちょっと抵抗があったのですが、すぐにペアプロの魅力に取りつかれ、今ではすっかりペアプロ無しでは生きられない体になってしまいました😅）

一緒にペアプロをやっている中で「モブプロも良いよ」という話になり、いつかモブプロもやってみたいな...とひそかにチャンスを伺っていました。

詳しい人が少ない

Classiはエンジニアの数に対してリポジトリ（≒大きな機能）の数が多く、あまり注目されないリポジトリには管理者がいない、もしくは他と兼任して必要な時だけと面倒を見るという状況が続いていました。
また、書いた人たちは既にClassiにいない方が多く、気になることがあっても気軽に聞けないという状況でした。

整地部のはじまり

上記のようなことを、部長のささたつさんとの1on1で話したところ「とりあえずモブプロやってみたら？」というありがたいお言葉を頂戴したので、ではとりあえずやてみるかーという軽い気持ちで、何人かに声をかけ、場所を押さえて試験的にモブプロを実施してみました。

やってみると予想以上にいい感じで、その日の日報でも「モブプロ良かった」旨を書いたところ、これまた予想以上の反響が！

という感じで、来週も続けてみよう → 再来週も → 再々来週も...と続けているうちにモブプロ会が「整地部」となっていったのです。
（ちなみに整地部という名前をつけたは私です( ･`ー･´) ﾄﾞﾔｯ!）

整地部の進め方

現在、整地部Ruby支部では↓のようなタイムテーブルで進めることが多くなりました。

# タイムテーブル（一例）

14:00 ~ 14:15 前回のふりかえり確認/今日のゴールを決める
14:15 ~ 14:45 モブ作業１（前半）
14:45 ~ 15:00 休憩
15:00 ~ 15:45 モブ作業２（後半）
15:40 ~ 15:55 ふりかえり＆次回やること検討

毎回ふりかえり

整地部の終わりにはKTPという手法でその回の「ふりかえり」を実施し、次の回の初めに前回の Keep と Try を確認して、

• 前回の良かった点は続けられるように (Keep)
• 悪かった点はカイゼン (Try)

できるよう挑戦しています。

TDDでやってるよ

プロダクトコードを書く際は基本的にTDDで進めています。
ドライバーは前半・後半で交代し一人に負荷が集中しないように注意しています。

整地部やってよかったこと

成果が出せている

この半年でこのようなことができました。

• 気になるけど当分触らない箇所のリファクタリング
• 複雑なSQLリーディング ＆ 動作確認用のテスト作成
• 静的解析ツールをCI環境で実行するようにして、いつでも解析結果を見れるようにした
• DB取込みツール作成、などなど

整地部がなかったらできなかった or やったとしてもだいぶ先になってしまったことができました。

社内の他チームの優秀なエンジニアと一緒にコードに向き合うことができる

現在、整地部ではドライバーは各自のPCで作業しています。

そのため、エディタの種類・設定はもちろんのこと、ターミナルの設定も十人十色で、エディタの使い方、ターミナルの使い方、各種コマンドの使い方など見て学べることが多いです。

また、TDDのコツや、効率の良いデバッグのやり方も デキるエンジニアといっしょに体験できる ので、本やWebで読んだ情報より深く理解できることに気が付きました。

暗黙知が減る

ドキュメントにもコミットやGitのログにも理由が書かれていない難解な処理でも、

• 詳しい人がいる → 整地部にお呼びしてその部分について説明してもらう → あっという間に疑問が解消
• 詳しい人がいない → 皆で解読 → 一人で読んだときよりも深く理解できる＆暗黙知が共有できる

ということを実感しました。

自分では気が付かないことに気づける

これは複数人で同じコード・同じ問題に向き合っているからこその利点でしょうか。
メンバーごとに視点が違うので、一人では気づけないことも誰かが気づいて指摘をしてくれることで、すぐに問題解決への糸筋が見えたり、遠回りを防ぐのに役立っています。

整地部のカイゼン

毎回KPTでふりかえりをし、次の回の冒頭に Keep / Try を確認することにより、なんとなく整地部を続けている状態を減らせています。

ふりかえりで変わったこと（一例）

• 会の時間（1H → 2.5H → 2H）
• 開催場所変更（広い会議室 → 6人入ったらちょうど良いサイズの会議室へ）
• タイムキーパー役を設置 → 廃止 → また設置
• ドライバー以外は極力自分のPCを見ないようにする
• 整地部の開始時に到達できそうなゴールを設定する
• 後半開始時にゴールを再確認する
• ホワイトボードにゴールを書き出す
• 整地部の開催前にドライバーを募集する（事前に開発環境を用意してもらうため）
• 6人以上参加した場合は、チームを2つに分ける

初参加の方に新しい風を吹き入れてもらうの大事

こんな整地部でも時々、停滞気味になることもありました。
そんなときは中途入社してばかりの方やインターン生の方など初めての方に参加してもらい、その方に説明する中で整地部の原点を見直すことができました

また、新しい風を吹き込んでもらって新たな方向に進化することもできました。

整地部長が不在でもちゃんと整地部が開催できた

気がついたら整地部長に任命されていた私ですが、整地部長として以下のようなことをやってきました。

• esa (社内向け情報共有サービス)にその日のアジェンダを作る
• 当日の朝チャットで、ドライバー募集する
• 開催場所の手配、参加者のスケジュール調整
• （必要なら）整地部ファシリテート
• 参加したことが無いエンジニアに声をかける

そんなある日、自分の仕事が忙しくて参加できなかった時のこと...
整地部長の私がいなくても整地部が開催されているのを目にして「あ〜、自分がいなくても開催されるくらいにはこなれてきて、定着したのか...」と、とても感慨深く感じました。

自分が率先してやってきた活動がひとりでに動いているところを見るのは嬉しいものですね！
（でも、ちょっとだけ寂しかったですけどね）

PHP支部も誕生

これまた、ささたつさんとの1on1の中で「PHP版整地部もやってみたいですね」というありがたい一言をいただき、試しにやってみたところ評判もそんなに悪くなく、整地部PHP支部として定着しはじめました。

※ 最初は「支部」など作らず、担当領域に関係なくエンジニアならだれでも参加できる形にしたかったのですが、これではうまくいきませんでした...
ただ、PHP支部はRuby支部とはまた違う進化の形を見せていて、おもしろいな〜とも感じているので、もう少し「支部」体制で続けてみようと考えています。

差し入れしてもらえる！

時にはこんなことも！
（理啓さん、ステキ❤️ 差し入れありがとうございました）

まとめ

気がつけば開始して半年以上経過していた整地部。
自分が率先して立ち上げた活動ががこんなに続いたことに驚きですが、私ひとりではここまで続けることができませんでした。
いつも参加してくださっているメンバーの皆様、整地部始めるきっかけをくれた haazime さん、モブプロをやってみることを快く承諾してくださったプロダクト部部長のささたつさん、本当に本当にありがとうございます！！

またこれからも一緒に頑張っていきましょうね！

Classiではメンバーが必要だと感じたら自発的に新しく始めることができる雰囲気があります。
（整地部の他にもいろいろな部署で日々、新たな取組がすすめられているようです）

整地部もまだまだ成長途中なので、ちょっと興味あるなという方は是非、遊びに来ませんか？