- 講演資料:Webフロントエンド、改善の積み重ね
![ヤフー株式会社 マーケティングソリューションズカンパニー開発本部/第6代黒帯(JavaScript) 穴井宏幸氏](http://cz-cdn.shoeisha.jp/static/images/article/10465/10465_001.jpg)
「KAIZENアワー」は、エンジニア同士の課題解決と啓発の場
穴井氏は現在、Yahoo! JAPANの社内ベンチャー制度から生まれたリッチラボ株式会社で、スマートフォンのリッチ広告事業やWebサービスの設計・開発に携わっている。Yahoo! JAPANでは長年にわたってハッカソンイベント「Yahoo! JAPAN Hack Day」を開催しており、その中で生まれた有望なアイディアは社内起業という形で独立させてきた。リッチラボもその一つで、2017年9月には設立から3年を迎えた。
同社は、開発チームの技術向上や課題解決、自己研鑽のための時間である「KAIZENアワー」を設けている。毎週金曜日の夕方に1時間の枠を取り、出席メンバーは各自がそれぞれ決めたテーマで改善活動を実施する。
「内容は例えばコードを修正したり、わからないことについて調査したり、普段から大事だと思っているけれど、業務が忙しくて手がつけられないことをやってみたりと人それぞれです。改善であれば何でもいいという融通が利く形をあえて取っていて、最後の5分でそれぞれの成果を発表し、お互いをたたえ合っています。つまり、課題解決の場であり、エンジニアが相互にモチベーションを啓発する場となっているのです」
軽いノリで始めた週1回の集まりが、改善の場として社内に定着
穴井氏がKAIZENアワーを思いついたきっかけは、Node.jsのカンファレンスとして知られる「東京Node学園祭2016」にて、「サイボウズの開発を支えるKAIZEN文化」の発表を見たことだった。サイボウズ社では「KAIZEN DAY」や「KAIZEN合宿」といった取り組みが展開されており、穴井氏も興味を持った。しかし、リッチラボは社員数19名のベンチャー企業ということもあり、通常の業務を止めて丸一日もしくは泊まり込みで実施するのは難しいと感じた。
「そこで、まずはとりあえず週1時間でやってみて、続かなかったらやめればいいし、大丈夫そうであれば続けようといった軽いノリで始めました」
KAIZENアワーが始まったのは、2017年の2月。半年を過ぎたところだが、成果は上々だという。金曜日が祝日の場合は前日に繰り上げて行うなど、ほぼ毎週の開催を続け、常に4~5人がコンスタントに参加している。時間数で数えてみると、累計で約88時間になっていた。
![「各会の参加人数×1時間」で、累計88時間の改善活動が行われた](http://cz-cdn.shoeisha.jp/static/images/article/10465/10465_003_s.png)
「最近は改善活動という発想自体が社内に定着した印象です。また、私たちの活動を見て『面白そうだから自分たちもやってみよう』と、似た取り組みを始めたチームも出てきています。自分としては、軽い気持ちで始めたわりにはうまくいっていると考えています」
「1時間でできる」「小さな単位でわかりやすく」が継続の秘訣
KAIZENアワーでの主な改善テーマは、大きく3つある。まず、いわゆる「割れ窓をふさぐ」こと、つまり職場や業務の小さな問題を放置せずに改善し、質の高い仕事ができる環境を整える取り組みだ。2つ目が「技術負債の解消」、そして3つ目は「運用効率を上げる」ことだ。技術負債の解消の具体的項目としては「依存オープンソースソフトウェア(OSS)のバージョンアップ」「ドキュメントを書く・正す」「不要になったコードの削除」「アンチパターンの排除」などが挙げられる。
穴井氏は、KAIZENアワーを実施する上で個人的に設けている“方針”があると明かす。例えば「1時間でキリがつくように行う」「プルリクエストはなるべく小さく、わかりやすい単位で行う」といったことだ。というのも、フロントエンドエンジニアは穴井氏一人で、むやみにプルリクエストを投げても、バックエンドのエンジニア2人にコードのレビューで負荷がかかってしまう懸念があるからだ。
「小さな変更でも、それが実際に動くかどうかはその都度ローカルで起動して動作確認しなくてはならないので、なるべく小さな単位でわかりやすく依頼しないと、毎週のKAIZENアワーのたびにプルリクエストが積み上がっていくばかりです。とはいえ小さい課題ばかりこなしては、それ以上の進歩は望めないため、大きめの課題は段階を踏んで取り組むように工夫しています」
ツールのコーディングスタイル統一に挑んだが問題は山積み
穴井氏は、KAIZENアワーで実施した取り組みの中から「1時間でコツコツできる改善例」を紹介した。そして、「これから自分の職場で改善活動にチャレンジする人には、最低限の時間でできることから始めるのを勧めます」と話す。
「改善に取り組んでみたいけれど、『工数が3人日かかる』などと最初から切り出しては上司も納得してくれません。でも『1時間でできますから』と言えば、説得しやすいのではないでしょうか」
今回紹介されたのは、穴井氏がコーディングスタイルの統一を試みた際の事例だ。リッチラボでは現在2つのB2Bツールを使用しているが、それぞれ開発時期が違うため、コーディングスタイルが異なっているのが問題だった。具体的には、JavaScriptの構文チェックツール「ESLint」のルールセットが新旧2つ存在するため、一方ではチェックを通るコードがもう一方では通らない問題が生じていた。新しいルールセットに統一しようと考えたが、単純に古い方を切り替えるだけでは大量のエラーが出てしまう。
![古いプロジェクトの独自ルールを新しいプロジェクトのeslint-config-airbnbに統一する](http://cz-cdn.shoeisha.jp/static/images/article/10465/10465_002_s.png)
「最初2000件くらいあった問題を、かなり頑張って777まで減らしましたが、これでも1時間ではとても解決できません。また、単純にプルリクエストとして投げると、差分が膨大になってしまう。レビュアーの手間も考えて、手作業での移行をいったん断念しました」
段階的な修正とツールを使った効率化&自動化で問題を解決
そこで穴井氏は、段階的に修正していくことと、その過程を効率化できるツールを利用することを考えた。ステップとしては主に3段階。最初に行ったのが「Prettier」というコードフォーマッターの導入だ。このツールはESLintが修正できないルールでも直すことが可能だという。
「最初に設定する項目は少なく、あとは自動でやってくれるので導入も速い。約2000件のエラーの2割くらいは、このツールが自動的にフォーマットしてくれました」
次に、Prettierでも直せなかったルールをいったん全て無効にした。その上で、KAIZENアワーやその他の開発のついでに修正する。作業を1時間ごとに区切って、コツコツと直していくのだ。
「無効にした中から、修正したいルールを有効にしてESLintを実行し、エラーになったら直すというサイクルを、エラーがなくなるまで繰り返します。その過程で、機械的に直せそうな部分を見つけた場合は、『JSCodeshift』を利用します」
JSCodeshiftはFacebook製のリファクタリングツールキットで、変換処理をJavaScriptで記述し、機械的にリファクタリングすることが可能だ。こうして手作業と自動処理ツールを併用しながら、根気よく作業を進めていく。
穴井氏はセッションの後半、さらに詳しいツールの利用法や改善におけるアプローチなどを、具体的なコードをふんだんに引用しながら紹介していった。
問題の解決にとどまらない成長の場として、今後も継続を目指す
セッションの結びとして穴井氏は、KAIZENアワーを通じたこれまでの改善の取り組みを振り返り、「楽しかった」と話した。担当案件の進捗が悪く、今週は何もできなかったと感じているときも、自分の関心のあることをアウトプットして、週末にすっきりとした気持ちで帰宅できる環境は貴重だという。
また「改善」というと、「技術負債の解消=マイナスをゼロに転じるためのリカバリー的な活動」と思われがちだが、納期の都合などで一度そのままにした問題に改めて向き合い解決することで、次に似た問題が出てきた場合でもすぐに対応できるようになる。
「これは自分たちにとっての成長だと思っています。つまりKAIZENアワーは、問題の解決だけでなく成長の場としても機能しているということです。今後も継続し、リッチラボの開発組織をより強くしていけたらと願っています」
穴井氏は抱負を語り、セッションを締めくくった。
お問い合わせ
Yahoo! JAPAN