やっていけ！既存プロジェクトの改善会
第９章では、新たな中途メンバーが入社してから4ヶ⽉の間に行った、プロジェクトの改善活動について紹介します。内容はAndroidチームについてですが、他のチームの改善にも参考になると思います。
全章を一括して購入されたい方はこちらの記事をご購入ください。https://note.mu/nikkei_staff/n/n44623c9b9ab4
⽇経電⼦版のアプリチームでAndroidアプリを開発しているおがぱん/@ogapantsです。
2018 年5 ⽉に⼊社してからの4 ヶ⽉間、私はAndroid チームの新参者としてさまざまな改善活動を実施してきました。コードの改善、プロダクトの改善、チームの改善と⽅向性は多岐にわたりますが、今回はその⼀部を紹介します。これを読んで皆様のチームでも新たな改善活動を始められるきっかけになれば幸いです。
9.1 改善ポイントを探る
改善を始める上で現状を知らないことには何もできません。どこに課題があり、誰が何を思い、今は何を⾏っているのか把握することから始めました。
9.1.1 アプリチームの現状
弊社のAndroid アプリは⽇経電⼦版と⽇経紙⾯ビューアーの2 本からなり、いずれも2015 年にリニューアルリリースされました。
アプリチームは10 名ほどとなり、Android チームは現在私を含めて3 名です。私以外の2 ⼈はいずれも新卒⼊社して以来ずっとアプリチームで活躍しています。
アプリチーム全体の改善活動はPM が主導しており、1on1 やKPT、週次のミーティングなどを定期的に実施しています。
9.1.2 中途メンバーの役割
Android アプリの内部的なコードは前任者の尽⼒もあって、設計は抽象化したMVP でテストもしっかり書かれており、CI 運⽤もされています。しかしリリースから3 年も経つと技術的負債も溜まり、使⽤しているライブラリも⼀部アップデートされないままになっています。
私はプロジェクトに参⼊してまずは全体的な⾒通しを得るために簡単な改善タスクをこなしていました。その中で次第にコード品質をより向上させることに特化した時間を作る必要性を感じました。
機能やUI に関わる施策タスクはたくさんありましたが、コード品質に関する改善タスクはあまりなかったからです。これから技術的負債にどう⽴ち向かっていくか、⽇々流れてくる新情報をどう共有し取り⼊れていくか、各⾃のコーディング⼒をどう⾼めていくか。新卒⼊社のメンバーに⽐べてこれまでさまざまなプロジェクトを経験してきた私としては、新たな⾵を巻き起こしてプロダクトやチームメンバーの成⻑を促していく責任を感じていました。
プロダクトとしての品質はPM のタスク捌きによって⽇々向上していますが、当然ながらPM はコードの中⾝までは分かりません。内部的品質の低下による危機感はコードを書いてる⼈間にしか分からないので、都度ボトムアップして改善するための時間を確保するようPM と確約しました。
既存メンバーは技術的負債の存在に鈍くなりがちですが、途中参加したメンバーほど気づきやすいものです。中途メンバーにとって、こういった問題点を積極的に指摘していくことは使命といってもいいでしょう。技術的負債は、既存メンバーはタイミングを伺っているだけで、常に技術的負債を返済する契機を⾒計らっていることが多いです。指摘する際は負債に⾄った過去の背景をヒアリングしつつ、これまで⾛り続けてきたメンバーを尊重することが何より肝要です。そして今のコードがどうであれ、ユーザーに価値を届けているプロダクトに敬意を払うことを決して忘れてはいけません。
9.1.3 課題、時間、品質。そして…
プロジェクトの改善をするための社内勉強会を⾏うにはメンバーのモチベーションがとても重要です。もちろんモチベーションがなくても必要なことは⾏うべきですが、必要性の認識が曖昧なものはPM に命じてもらうほうが責任を持って実践できるでしょう。エンジニア⾃らが提案して改善を進める活動を⾏うには、誰かの思いつきで始めるのでなく、課題に対するモチベーションの整理と「みんな丸太は持ったな」という⼀体感が第⼀に求められます。私は既存メンバーから現状の設計思想やそれに⾄る経緯の説明を受けながら、それぞれどんな課題を感じていて、どんなものを⽬指していきたいと思っているのか、どんな分野への関⼼が強いのか、率直な考えをヒアリングして彼らのモチベーションを探りました。その結果、現状に次のような課題があることがわかりました。
• 今の開発の進め⽅しか体験していない
• デザインベースが古く、Android に最適化されていない
• リファクタリングをしたいがタイミングが掴めない
「これはやっていきだ」
誰かが⼝にした。私は多くの課題を感じながらも、⾼鳴る胸を抑えられなかった。
9.2 改善会を開く
これらの課題を元に、次の4 つの社内勉強会を開催しました。
1. Android Studio 最強の使い⽅選⼿権
2. マテリアルデザインガイドライン輪読会
3. Kotlin もくもく会
4. Lint 警告撲滅会
それぞれ⽬的を持って進めていますが、やりながら⼿法を変え、時間を変え、時には会⾃体を終了させたりもします。4 つの会で共通しているのが、エンジニア主導で業務時間内に集まって実施するということです。
業務時間内で⾏えるようにエンジニア側から社内勉強会の⽬的や必要性をPM に説明をして、1 スプリント内の通常のタスク量も調整してもらっています。なおかつ業務が忙しいときはその都度柔軟にリスケしています。
実施する上で重要なのが他者からの⼲渉がない場所で向かい合いながら⾏うことです。勉強会中も思ったことはすぐに声に出して意⾒を交わしながらやることで、互いの不安や疑問を払拭し、考えを共有し、普段の業務中も声を掛けやすくするという利点もあります。
次節からはそれぞれの勉強会ではどんなことをやっているのか紹介していきます。
9.2.1 Android Studio 最強の使い⽅選⼿権
Android Studio のプラグインやショートカットやLive Templates など、⽇々どんなお役⽴ちツールを使っているかを順番にやってみせて⾃慢し合う会です。
きっかけは、既存メンバーのコーディングの様⼦を背後から覗き⾒ているときに、「あぁっ…それもっと⼀瞬でできるのに…」というもどかしさを感じたことでした。⾃分が当たり前のように⽇々使っているものは意外と知られていないと実感し、少ない学習コストで使えるツールやTips は⾚裸々に共有して⽣産性の向上を図ろうと考えました。また、逆に他者は⾃分が知らないようなツールを使っているはずだという確信もあり、選⼿権の形で開催に⾄りました。
極⼒学習コストが低いものに限定することにしましたが、ただ⾃慢し合って終わりではありません。各⼈に⾃主的に試してみるよう投げるのでなく、反響が良かったものは実際にペアプロ形式で設定・実践まで⼀緒にやってみせることが重要です。その場で盛り上がっても後でやろうとすると導⼊で詰まって⾃然と諦めたり、そのまま忘れ去られたりすることが経験上往々にしてあります。興味を強く持ったその瞬間に試すところまでやらないと、本当にただの⾃慢⼤会で終わってしまう可能性が⾼いので、しっかりとフォローアップを⼼掛けました。特に特定の場⾯でだけ⼤いに役⽴つようなものは使⽤⽅法を忘れがちなので、付箋に書いて貼るなどしておいて常時確認できる環境づくりも⼤切です。
また、その場の既存メンバー内で共有だけして終わりでなく、最終的に社内Qiita にドキュメント化するようにしています。これは永続化することで今後⼊社される⽅にも共有しやすくする⽬的があります。また、社内のエンジニア陣にAndroid チームがどんなことを⾏っているのかアピールし、同様の⽣産性向上会を促進するという狙いもあります。この会はこれまで2 度実施しました。第1 回は突発的な開催でしたが、なかなか受けがよく盛り上がりました。第2 回は1 回⽬が終わってから使っているツールや機能を⽇々メモしておくようにし、それに倣った形で⾃慢し合いました。これにより⽇々何気なく使っているものを網羅的に共有することができ、⽣産性向上はもちろんのこと新たな発⾒をすぐ共有しやすい⽂化が根付いてよいコミュニケーションが⽣まれるようになりました。ひとまず2 回だけやってある程度⽬的は達成されたため次回は未定となっています。しかし最近でもちょっとしたペアプロをするときに新たな発⾒があるので、これまでの復習を兼ねて近い内に改めて開きたいです。⽣産性向上の欲望はつきません。本会で取り上げられたTips の⼀部を別章で紹介します。
9.2.2 マテリアルデザインガイドライン輪読会
マテリアルデザインガイドラインをチームで輪読したり、新しいデザインコンポーネントを試しに使ってみたりする会です。輪読会と謳っていますが、他にもデザインに関する書籍やブログを読んだりサンプルアプリを作ってみたりと、デザインに関する知⾒を貯められることなら何でもOK になっています。
現状のアプリはデザインベースが最新でなく、Android に最適なデザインとなっていない課題がありました。それはAndroid エンジニア⾃⾝が感じており、ユーザーから操作感に関する要望も多くあるため重要な課題でした。
2018 年のGoogle I/O でマテリアルデザインガイドラインが⼀新されました。既存のメンバーは皆UI/UX に対する関⼼が強かったため、新しくなったガイドラインをチームで輪読する形で読み進めたいと思いました。なにより弊社にはアプリ専属のデザイナーがいないため、エンジニア⾃⾝がデザインの基礎知識やパターンを把握し、⾃ら提案できるようになる必要がありました。
おおよそのやり⽅は以下です。
1. MTG スペースに移動します（重要）
2. 今⽇読む箇所ややることを宣⾔します
3. 各⾃宣⾔したアクションを開始します
4. 残り15 分となったら終了し、⼀⼈5 分程度メモした内容をベースに話して回します
5. 終わる際には次回はどんなことをやるか簡単にメモしておくようにします
まず、今⽇やることを宣⾔するのは曖昧に始めるのでなく限られた時間内にゴールを意識して実施するためです。次に、作業中はGoogle ドキュメントに各々疑問に思ったところや関⼼を持ったところなどを、なるべく声に出しながらざっくりメモしていきます。これによりただ漫然と読んで終わりという無味乾燥な会にならず、進⾏に抑揚が⽣まれます。最後に、今⽇のまとめを⾏いつつ、その内容に関して聞き⼿は質問や意⾒を投げて知⾒を共有します。そして、⼤体志半ばのまま終わるので、メモを残し次回の開始時に何をやるか思い出す時間を減らします。
この形式はとりあえずで始めて徐々に改善していった結果です。やり始めた当初はガイドラインの完読が主⽬的でしたが、読んでるうちに実装部分を触ってみたくなったり、デザイン関連の別記事を読んでみたくなったりすることが多く、結果的に⼿広くデザインについて触れるようになりました。
また時間についても、最初は集中⼒を考慮して週に2 度、30 分時間をとって⾏いましたが、現在は週に1 度、1 時間にしています。理由としては、ガイドラインには動画も含まれているので集中して読み進めるとあっという間に時間が経ってしまうというのと、最後の感想を述べる時間がまったく⾜りなかったというのがあります。後者について、⼀度制限時間を2 分と決めてやってみたのですが、聞いてる側としても思わず質問をしたり意⾒を投げかけたりしてるうちに延びがちでした。それぞれの興味を強くもつジャンルの新たな発⾒や考察を熱く話し合うことを⽌めるのはもったいないため、⼀⼈5 分取るようになりました。やり⽅は今後も柔軟に変えていきたいと思います。
この輪読会で培った知識は⽇々の開発で⼤いに役⽴っています。実際に過去にAB テストで導⼊したストーリー画⾯（過去記事のリパッケージ画⾯）では、Android エンジニアが画⾯設計とデザインを担当しました（図9.1）。
この会を開始してから2 ヶ⽉以上経っていますが、毎回新たな発⾒があり、今のところ中⽌の予定はありません。まだまだ既存のUI には改善の余地があるので、少しずつ検証しながら⼿を⼊れていきたいです。
9.2.3 Kotlin もくもく会
Kotlin に関する何かしらをもくもくとコーディングする会です。
リファクタリングをしたいがタイミングが掴めない、という課題を解決するには、そもそもどうリファクタリングしたいのかをチーム内で共通認識としてもつ必要がありました。新規クラスはKotlin、既存クラスは余裕があればKotlin 化という漠然とした取り決めがありましたが、弊社アプリのKotlin 率はそこまで⾼くなく、Kotlin でcommit する⼈にも偏りがありました。今後リファクタリングを進めていく上でKotlin の⾔語機能の利便性を活⽤することは満場⼀致で賛成となり、もっとKotlin に触れる時間を増やさなければならないと感じました。普段のタスクの中で学ぶことも考えましたが、全員の習熟度がバラバラだったため、もくもく会として集まってコーディングすることで知識の底上げを図りました。
やり⽅はマテリアルデザインガイドライン輪読会と同様に週に1 度1 時間、それぞれ何をするか宣⾔してから最後に振り返る形式をとっています。内容としては、簡単なアプリをフルKotlin で作ってみたり、本やブログを読んだり、ライブラリを写経したりとさまざまです。⼩さな疑問はググるより聞いたほうが早く、かつ教える側も学びが多いので、
やはり集まって⾏うことで⽇に⽇に全員の知識量が上がっているのを感じます。最近はモブプログラミングで既存クラスの置き換えを試すこともあり、全員でさまざまな書き⽅を試⾏錯誤できてとても盛り上がり、よい雰囲気を醸し出しています。
既存のJava クラスを全てKotlin に置き換えるという⽬標を持っているわけではありません。既存の設計上、引き続きJava で書いたほうがいい箇所もあります。100% のKotlin を⽬指しはしないものの、各⾔語機能と現プロジェクトの親和性を考慮して、徐々にKotlin の⽐率を上げていきたいです。この会のおかげでKotlin の経験がなかった同僚からはじめてKotlin のPR が⾶んできたときは感動で⾜が震えました。⾔語としてもどんどん新しい機能が出ているので引き続きキャッチアップしながら続けていきたい会です。
9.2.4 Lint 警告撲滅会
リファクタリングの⼀環として、Lint 警告をひたすら潰していく会です。プロダクトに影響しない範囲のリファクタリングなら⼀緒にやってもOK ということにしています。この取組はクックパッド社の朝Lint 活動*1の影響を強く受けています。
リファクタリングをしたいがタイミングが掴めない、という課題のアプローチのもう⼀案として、タイミングが掴めないなら無理やりタイミングを作ってしまえという会を始めました。
既存のプロダクトに対するリファクタリングは、たとえテストが書かれていたとしても100% デグレを防ぐことは難しいです。しかしそのリファクタリングしたい箇所も、そもそもLint 警告が多く⼿を付けづらかったり、よく⾒ると実はもう使われていなかったり
します。⼤きなリファクタリングをする前にまず全体のコードのクリーンアップが必要だと感じました。
⼀⼝にクリーンアップと⾔ってもクリーンの定義が⾮常に曖昧です。そこで、Lint 警告を消した状態をきれいな状態と捉えて、Lint 警告撲滅会をスタートすることにしました。
やり⽅としては、Android Studio で出ているLint 警告をひたすらoption+enterで潰していくことです。先述のように実プロダクトに⼿を⼊れる以上、ある程度の秩序のもとでやりすぎを抑える必要があったので、次のように約束事を設けています。
• 修正のサジェストにしたがって修正する
• サジェストの結果がかえって複雑になる場合や、あえてそのままにしたい理由がある場合はSuppress アノテーションを使うことで警告を消す
• Suppress アノテーションを使う場合は最⼩単位で使う
• Suppress アノテーションだけでなくnoinspection コメントも使っていいこととする
• 修正候補が出ない場合は⼿で直す
• Lint ルールはAndroid Studio の標準に従うが、必要に応じて話し合いのもとCustom Lint に登録する
• あえて警告を残している場合は、理由を正直にコメントで書いて、後から⾒た⼈にも納得感を持たせるようにする
• 新たな警告を⽣まないようDanger を使って⾃動でチェックするようにする• デグレが⼼配になるくらいならissue として切り出して後⽇対応とし、PM と相談のもとスプリントに乗せてQA チェックも⼊れて対応する
• できるだけコミットの粒度を細かく分ける
• 不安がある場合はすぐに相談する
また、Lint 警告の撲滅を謳っていますが、次のようにプロダクトに影響しないリファクタリングもどんどんやっていいことにしています。
• テストを書く
• import 整理、format、rearrange をする
• layout-xml にtools 要素を書いてプレビューしやすくする
• Java コードに@NonNull/@Nullableをつける
なお、はじめてLint と向き合う場合は、まず使ってないクラスやメソッドやリソースなどを消すところから始めるといいでしょう。頑張って警告の対応をしても実はもう古くて使われていないクラスだったら徒労に終わります。
unused class 類を削除した後も再帰的に探索して削除し、取りこぼしのないようにしましょう。実は将来的に使うものであったりリフレクションで参照していたりBuildVariants に応じて使うものだったというケースもあるので、削除するときは⼗分に注意をしましょう。
この会は2 時間30 分ほどたっぷり時間をかけてやっています。全体の流れは次のようになります。
1. まずMTG スペースに移動します（重要）
2. 担当箇所の分割単位は画⾯単位・設計層単位・機能単位などのいずれかに決めます
3. 各⾃担当箇所を決めます。⾃分が過去に実装した場所でもいいし、敢えて触れたことのない箇所でもいいでしょう
4. 担当する箇所を宣⾔し、他の箇所まで波及しそうなときは必ず声掛けできるようにします
5. x.y.z(次期バージョン名)の改善というissue を作り、最新の開発⽤ブランチから専⽤のブランチ(ex:lint-x.y.z) を切ります
6. そこからさらにそれぞれの名前をサフィックスにしたブランチ名を作ります(ex:lint-x.y.z-ogapan)
7. 先述の約束事を考慮しながら各⾃Lint 警告を潰していきます
8. 2 時間経過したら、専⽤のlint ブランチに対して各々プルリクエストを投げます。その際はissue の番号も貼って関連付けます
9. メンバー間で回す形で相互にレビューするようにします。約束事にしたがって怪しいところがあったら適切な対応を取りましょう
10. プルリクエストのマージ先ブランチが正しくなっているかよく確認しましょう
11. 問題なければマージし、テストが通ることを確認してから本流となる開発⽤ブランチにプルリク・マージします
12. 時間内に終わるのが理想ですが、無理に急いで確認が漏れるような事態は避けるようにします
撲滅会を実施するタイミングですが、リリース直前はリスクが⾼いため、リリースした次の⽇の午前中いっぱいを使うようにしています。アプリをリリースする頻度はおよそ2週間に1 度なので、この会の開催頻度もそれと同様になります。
開始に⾄るときには、時間をまとめて取るやり⽅と毎⽇少しずつやるやり⽅のどちらがいいか検討しました。集まって相談しながらやるため、毎⽇少しの時間のために離席して集まるのは若⼲コストがかかると考えました。また、まとめて時間を取ってやったほうが勢いよくやれていいのでは、という話し合いのもとで前者を採⽤しました。
チームのKPT のKeep で「この会を始めてからLint が出ないようなきれいなコードを意識して書くようになった」と意⾒が挙がったときは感動して椅⼦から転げ落ちました。まだ4 度ほどしか実施していませんが、かなりの量の警告が消えて治安が良くなってきました。しかしこの会は今後の⼤きなリファクタリングに向けたスタートでしかないので、撲滅をゴールにするのでなく、その先の未来を⾒据えて引き続き頑張っていきます。
9.3 改善の改善
どんな⼤義名分を持って⽇々の業務時間を削ってまでこのような時間を確保しているのか。それは単にプロダクトやチームをよりよくするためです。これらの時間はユーザーに対して直接成果を出すための時間ではないので、漫然とやらずに何のために時間を使っているのか意識することを怠ってはいけません。
よいプロダクトを世に出していく責任をもっとも多く背負っているPM としては、業務時間を圧迫させる勉強会を設けることは苦渋の決断だったかもしれません。しかし将来的に必ず⼤きな成果となりユーザーに⼤きな効果をもたらすという現場からの⾔葉を信じてくれた偉⼤なるPM に、この場を借りて⼼よりお礼申し上げます。とはいえ、実はこの場を借りなくても常⽇頃感謝の意はPM に伝えています。今やれていることが当然のことだと奢らず、直接⾔葉で感謝の意を伝え続け、それぞれの時間でどんな成果が得られたのか、第三者にも分かるようにしておくことが肝要です。活動内容をドキュメント化したり、活動内容の振り返りにPM も⼊れるなど⼯夫が必要でしょう。
先述したようにメンバーのモチベーションはとても⼤事です。今はまだ始めたばかりなので問題なく続いていますが、⼿法をいくら変えても飽きが出たり、慣れから⽣じる慢⼼のようなものが出て⼤きなミスに繋がることが懸念されます。そもそも私が現実を⾒えていないだけで、実は問題なく続いていることがもう錯覚かもしれません。そのあたりはしっかりPM と連携をとってメンバーのモチベーションに合わせた最適な⼿法や時間調整ができるよう常に模索していきたいです。
ユーザーによりよい価値を届けられるよう、これからも⽇々改善を⽌めずやっていきます。そんな思いこそが、本当のやっていきなのかもしれませんね。
著者：おがぱん/@ogapants
軽い気持ちでコラムを書いていたら章になりました。最⾼の校正をしてくださったなかてぃるさんとfrom-unknown さんに深く御礼申し上げます。
140年の歴史ある会社が、AIやデータを駆使した開発を現場で実践しています。是非疑問や感想を #nikkei_dev_book をつけてツイートしてください！
全章を一括して購入されたい方はこちらの記事をご購入ください。
https://note.mu/nikkei_staff/n/n44623c9b9ab4
この記事を購入すると、この下に第９章だけのダウンロードリンクが表示されます。
ここから先は
¥ 100