ジョブカンアドベントカレンダー 9日目。ジョブカン開発の@yottaburgerです。
私がジョブカンにJOINする以前のキャリアで得た知見ベースでのPOEMとなります。
私はファーストキャリアが製造業向けのソフトウェア営業で、特にトヨタ系の自動車業界とのかかわりがそれなりにありました（ちなみにその後SEを経てジョブカン開発に入りました）。
トヨタの製造プロセスからIT業界へ輸入されたものと言えば「カンバン」が有名です。
他にも「なぜなぜ分析」や「カイゼン」などもそれなりに知られた言葉かと思います。
今回はそれらの中から 「5S」 (ごえす、ふぁいぶえす)を紹介します。
5S とは
工場現場などで用いられる有名な標語のひとつで、製品不良、生産性悪化、労働災害など様々な問題を防ぐための基礎とされるものです。
- 整理（使わないものは捨てる）
- 整頓（置きっぱなし出しっぱなしにしない）
- 清掃（次にすぐ使える状態にする）
- 清潔（上記を常にキープする）
- しつけ（上記を全員が習慣づける）
の5つをまとめたものです。
似たような言葉が多くてちょっと混乱しますね。
5Sについての紹介はこの辺りの記事がわかりやすいです。
プログラミングへの5Sの流用
上記を一見して皆さん察したと思います。
「これ、プログラミングあるあるじゃん」 と。
ちょっと解きほぐしてみましょう。
整理
一番わかりやすいのは「デッドコードを残さない」です。
SE世界など一部の現場では「動いているコードは触るな」という不文律があり、私が以前所属していた職場では時限ロジックと呼ばれる条件分岐まみれになっていました。
// 時限ロジックサンプル 消費税計算
public static Integer get_shohizei(Integer 商品金額) {
Integer 税額;
// 実行日に応じて消費税額を変更
if (TODAY.before(DATE_20140401)) {
税額 = Math.round(商品金額 * 0.05);
} else if (TODAY.before(DATE_20191001) {
税額 = Math.round(商品金額 * 0.08);
} else {
税額 = Math.round(商品金額 * 0.1);
}
return 税額;
}
この発想もある意味理解できますが、自分たちで主体的にコードを管理できる場合はやはりいらないものは消したほうが良いでしょう。
また、冗長なコードをDRYに書き直すなども整理に含まれそうです。
整頓
置き場所が不適切なロジックを残すなという話です。
とりあえず下書きのつもりで 「なんでもクラス」 に全てを書いてみたり、実装規約上はサーバー側処理で外部APIコールすべきところを面倒がってフロント側に実装したりなど、皆さん身に覚えがあると思います。
（そしてうっかりそのまま残してコミットしてしまった経験もあると思います）
ほかにも
- コーディング規約やMVCモデルなどに基づいて、適切な場所にロジックを配置する
- ファットモデルやファットコントローラを作らないよう、適切に責務の分割を行う
- 使用頻度が高いものは共通クラスなどに切り出して呼び出せるようにする
- いなくていいものをとりあえずGlobalに置いたり、基底コンポーネントに残したりしない
などなど。
この辺りは正直個人開発では大した問題にはならないため、チーム開発経験が薄い新規メンバーが特に悩みそうなポイントです。
清掃
コードそのものと挙動のセルフチェックです。
- LinterやFormatterをかける
- 変数名や出力文言の統一
- 単体テストを書く・エッジケースまで試す
- 動作確認をする
- わかりづらい箇所にコメントを書く
といった、コミット前にやるべき当然の確認＆お掃除ですね。
あわただしい状況になるとおろそかにされがちな部分ですが、これをしっかりやることで余計な確認やバグの見逃しを防ぐことができます。
清潔
プログラム全体を通して、常に正常な状態が保たれていることの確認です。
ここまでくると個人の管理範囲を離れます。
CI(継続的インテグレーション)の活用や、回帰テストの整備などが必要でしょう。
監視チームを設置するというアプローチもありそうですし、定期的に古いコードを点検する催しを行うなどの仕組み化を行うのもよさそうです。大手ITサービスが実施しているバグバウンティもある意味で清潔を維持するための取り組みと言えそうです。
しつけ
各メンバーが実装規約を遵守する状況を作ります。
そのためには適切な規約の整備と教育体制が必要です。
なおどんなに規約を厳しく作っても最終的に人間はサボるので「守りやすいルール」と「ルールを逸脱できない仕組み」の提供もセットで考えるのがいいです。
・前者はeslintを自動で効かせられる環境を整備し、全メンバーが共通で使用できるようにするなど。
・後者はGitHubの機能を活用して、自動テストとレビューが完了しないとデプロイできないようにするなどです。
ソフト面でのルールをいくら厳しくしても最終的にルール違反が起こることについては畑村陽太郎先生の「失敗学」シリーズを読むと面白いです。
【失敗学のすすめ】
サービス全体における5Sの適用
プログラミング部分以外にも、5Sの目線はWEBサービス開発の様々なところで活かせそうです。
ざっと例を挙げると、以下は掘り下げると面白そうですね。
アーキテクチャ設計
「整頓」はまさに「どこに何を置くか」が先に来るので、クリーンアーキテクチャやドメイン駆動設計と絡めて考えるべき観点です。
環境構築
必要なライブラリ群やDDLに適切にアクセスできる、などです。
現代ではDockerやMakeツールなんかを用いて簡単に同条件の開発環境や本番環境を用意できます。
これは工数削減に繋がるだけでなく、作業者や環境間で微妙な差異が生じること（そしてそれが予期せぬ挙動につながること）を防ぐためにも有効そうです。
チケット(Issue)管理
積みっぱなしのタスク😟
適切にグルーピングや優先度設定がされてないIssue😫
UI/UX設計
UXの側面では「Less is More」でありKISSの原則1を重視すべきです。
長年続いたサービスではついついユーザビリティを後回しにした機能追加が行われがちですが、どこかで立ち止まって断捨離や配置見直し、そしてUXルールの整備と徹底を行えるのが理想的です。
おわりに
いかがでしたか？
エンジニアの基礎学習といえばリーダブルコードなどのコーディング指南書が有名ですが、根底の考え方は相通じるものがあるように感じます。
ちなみに私は昔とある居酒屋チェーンでアルバイトをしていましたが、そこでは「QSC」という言葉が使われていました。「クオリティ、サービス、クレンリネス」の略で、こちらもちょっと5Sに似た概念です。
他業界からも学べるものは吸収して、よりよいサービスを作っていきたいですね。
お知らせ
DONUTSでは新卒中途問わず積極的に採用活動を行っています。
詳細はこちらをご確認ください。
-
いろいろ訳がありますが私は「Keep It Simple, Shit!」が気に入ってます。 ↩