改善活動 継続宣言 - 現場からは以上です

対象読者

• 開発組織における改善活動の意義について考えたい人
• NE開発部の文化について知りたい人

要約

社内で開催された終日改善イベント「KAIZEN JAM」に初めて参加しました。普段のチームとは別のチームの方々と仕事をすることで、多くの気づきを得ることができました。社内には、まだまだ自分のやれること、学べることがたくさんあることを実感し、それに対して楽しみを感じています。

「KAIZEN JAM」が「改善」について考える良い機会を与えてくれました。また、感想の記事を書くにあたり「改善」という言葉から、製造業における「品質は工程で作り込む」という考え方を思い出しました。これは設計から製造までの各工程で品質を確保していくという考え方です。ソフトウェア開発においても、質を高めるための改善を各工程で継続することが重要であることを再認識しました。

私はコードを書く現場の一員として、今回の「KAIZEN JAM」から得られた気づきを日々の改善に繋げられるような行動に変えていくことを宣言します。

KAIZEN JAMとは

プロダクトコードを中心に普段の業務で気にはなっているけど手をつけることができていない改善を丸一日かけて行うイベントです。

去年の記事は雰囲気がわかりやすいです↓
https://zenn.dev/neinc_tech/articles/83cf2ff2a4d811

重要なポイント

• なるべく普段一緒に仕事をしないメンバーで構成する

みんなが取り組んだこと

• スロークエリ改善（私が参加したもの）
• UX向上のためのバリデーション追加
• UX向上のためのエラーハンドリング追加
• UI調整
• デッドコード削除
• クエリ実行時はコメントにバックトレースを追記する

私が学んだこと

① SQLに関する知識や観点の獲得

• どう書くとINDEXが効かなくなるかの視点が増えた
• EXPLAINをもっと活用できると思えた

② これからもっと他チームの人を頼ろうと思った

• 誰がどの技術に関して詳しいのか、興味があるのかがわかった
• こちらが相談すれば、アイデアやヒントをくれる人が周りにいることに気づいた
• 10年以上この会社にいる先輩は本当に頼もしい存在だと思った
  • 会社が大切にすべき人材だと思う

③ どの部署の人とも仕事ができるし、そうすることで成長の機会が生まれる

• チームで身につけたコードレビューの仕方が、どこでも使えるものになってきていると感じた
  • いつものチームメンバーに感謝
• 普段はあまり考えないことに関しては、わからないことがたくさんあったが、一緒に仕事をしていくことで身につくだろうという感覚があった
• まだまだ尽きぬ知識欲とそれを活かせるようになる自信があるから、チーム外の人とも仕事をしたいと思った

自動車産業と改善、それを思い出す

「改善」という言葉から私が想起するのは、トヨタ自動車が提唱した「自働化」を実現するために行われている「改善」です。
トヨタ自動車のコーポレートサイトにある「トヨタ生産方式」には下記のような記載があります。

トヨタ生産方式における「自働化」は、いわゆる「自動化＝オートメーション」に「人間の知恵」をつけた「ニンベンのついた自働化」です。

「作業改善」こそが、自働化の原点です。どんなに機械やロボット、ITが優れていても、それ以上の進化はできません。進化のために改善を続けられるのは、人間だけです。

https://global.toyota/jp/company/vision-and-philosophy/production-system/

車部品の設計者として仕事をしていた頃、3か月間だけですが、トランスミッションの組み立てラインで仕事をしたことがあります。現場では小さい改善が日々行われていることを目の当たりにしました。「床や機械が汚れやすい原因を取り除く」、「道具や部品箱の配置を変える」、「組み立てを楽にする補助工具を作成する」などの活動です。コストを下げることはもちろんですが、人に依存しない品質を担保すること、安全性を高めることなどが改善の目的です。

改善から得られた知見が、現場の作業要領書や生産ラインの図面に反映されるだけでなく、組み立てやすい部品の設計などにもつながります。「品質は工程でつくりこむ」という言葉があるように、各工程における品質を確保を高めるために行う積み重ねた改善が質のよいプロダクトが作り上げるのです。これはソフトウェア開発にも適用できる重要な考え方です。

「KAIZEN JAM」は、いままでに書いたコードをふりかえり、各工程において質を高めるためにできることを全体で認識したり再確認したりする機会になっていると思います。
このイベントで取り組んだことを例に挙げるのであれば、スロークエリにならないコードをみんなが意識してかけるようにするにはどうするか、UIUXの観点から足りなかった考慮はなにか、デッドコードはいつ生まれていつ削除されるべきか、調査しやすいログを残す方法はないかなどです。

私達の普段の業務時間は、プロダクトの価値を高めることや必須の対応業務に優先して充てられます。そうしているうちに、「改善」の意識を忘れたり、ないがしろになってきたりするのですが、「KAIZEN JAM」はその大切さを思い出させてくれるように思います。

今回はせっかく改善とそこから学ぶ機会をもらったので、プロダクトの質を高める為の仕組みに変える案を考えてきました。

継続的な改善につなげるための具体案

「KAIZEN JAM」で得た知見から、プロダクトの質を高める仕組みがつくれないかと考え、Github Actionsのコードを書いてみました。差分があるファイルの種別や中身にあわせてレビュー時における観点をまとめたドキュメントのリンクや簡易的なチェック項目をコメントに記載するものです。

対象

• 特定の拡張子やディレクトリのファイルを編集した場合
• SQL編集を編集した場合

画像は提案用に作成したサンプルコードの結果です（コメントはAIに考えてもらったもので、社内の本当のチェック項目ではない）。簡単なものではありますが、これをチームに提案してみようと思います。

うまく運用できたらまた記事を書きたいと思います。