「レガシー」を保守したり、刷新したりするにあたり得られた知見・ノウハウ・苦労話 by Works Human Intelligence カレンダー、3日目の記事になります。
はじめに
プロダクトや開発環境に限らず、どんな会社にも多かれ少なかれレガシーなメソッドがレガシーなまま残っているものです。
だれも見ていない予定表に記入するルール、冗長な二重の申請手続き、印刷した紙ベースでのコードレビューetc.
何をレガシーとするかは主観による部分も大きいですが、誰もが「これ意味あるの？」「もっといい方法ないの？」と思いつつ、なんとなく続けられている規則もあるでしょう。
そういったレガシーをどうやってカイゼンしていくか、という話になります。
どんなレガシーがあるか
イメージをもっていただきやすいように、実際に過去に遭遇し、自分または周囲の人がカイゼンを試みたレガシーな社内メソッドを挙げてみます。
- 社内のコミュニケーションツールがDMのみのメッセンジャーしかなく、雑談や、地理的に離れたオフィス間でコミュニケーションが生まれない
- ⇒slackを導入し、雑談のためのチャンネルを設けた
- プロジェクトで得られた知見、開発のノウハウを共有できるツールがなく、社内のメーリングリストに時々放流されるが、すぐに流れてしまってリファレンス性がない
- ⇒社内Wiki・ブログを導入し、更新がチャットに通知されるようにした
- 勤務表を手書きで管理しており、冗長の承認も目視での確認とハンコ
- ⇒スプレッドシートとGASベースで入力・時間計算を自動化した
- メール添付しか社外とファイル共有する手段がなく、パスワードのメールを別送していた
- ⇒ファイル共有ストレージを採用
カイゼンのためのいくつかのやり方
具体的にどういう方法でカイゼンしていくことができるか、思いつくものを過去の経験まじえいくつか挙げてみます。
ただ始める
組織に残るレガシーなメソッドの多くは、ただ「誰も変える人がいないから」というだけの理由で残っていることが多々あります。
そういったものは、変えたいと思った人がただ「変えます」と言って変えてしまえば、案外誰の反対もなく変えることができてしまうものです。
心配なら「うまくいくかわからないですが、とりあえずやってみたい」くらいの表現で承認を得ましょう。
ダメだったやめるだけで、何も失うものがありません。
メリット・制約を整理し、承認を得る
導入に経費やコンプライアンス上の許可が必要なものについては、気軽に「変えます」で始めることができないものもあるでしょう。
その場合の王道は、以下を整理して提示し、承認を得ることです。
- 従来のやり方の不便・問題点
- 新しいやり方で何が解決されるか
- 今までできていて、できなくなることはあるか
- 新しい方法の効果を検証できるか（どうやって検証するか）
しかし、なかなかここまで準備して取り組もうとすると腰が重くなるもので、それこそがレガシーの残っている理由だったりするものです。
特にメリット・デメリットの調査や検証に時間がかかりそうなものの場合、仕事の隙間時間をつかって奉仕精神でやろうとすると精神衛生上もよくないので、まずは「効果が見込めるかも？」という時点で、その調査・検証自体を仕事として取り組む時間をもらうという手もあります。
勝手にはじめる
一定期間内・プロジェクト内など、小さい単位で導入できるものについては、新しい期間・プロジェクトがスタートするタイミングで、勝手に導入してしまう、という手もあります。
特に自分や自分のチームだけで始められるような性質のものであれば、まず小さい範囲で勝手に導入し、これまでと全く同じ（または改良された）アウトプットを出してみせてから、実は今回はこういう方法をとりました、という形で共有すると、受け入れられやすかったりします。
並行して始める
今までのやり方を続けたまま、それと並行して始めてしまう、という方法がとれる場合もあります。
これまでのやり方を捨てたわけでないので、誰にも文句は言われないはずです。
他の人も巻き込むとなると、手間に抵抗を感じる人がいると思いますが、まずは希望者のみ使ってみてください、という形でも良いと思います。
しばらくは二重に手間が生じることになりますが、ある程度運用の実績ができたタイミングで、レガシーの廃止を提案します。
注意点とTips
レガシーに敬意を払うこと
レガシーコードに対する姿勢と同じことだと思いますが、一番やってはいけないことは「なんでこんな無駄なことをやってるですか」のように、レガシーなメソッドを全否定すること です。
たいていは、歴史的経緯があってそうなっているものです。
今はレガシーでも、当時は多くの問題を解決した手法かもしれません。
先人に敬意を払う姿勢を忘れないことが、導入の受け入れられやすさにもつながります。
機が熟したことを理由にする
前項と繋がる話ですが、「もっといい方法がある」と言われると、もともと従来の方法を導入した人にとっては気分のいいものではありません。
それが権限のある人だと、承認をしぶる気持ちも生まれるものです。
新しい方法を導入する「機が熟した」ことを理由にすると、誰も傷つけることなく生産的な話につなげることができます。
「以前はクラウドサービスの信頼性が高くありませんでしたが、今では十分な実績があるので…」
「これまでは人が少なかったので大丈夫でしたが、社員も増えてきたので…」
といった言い方を使えると良いと思います。
最初はなにがなんでも成功させる
これまでより良い方法ですと提案して導入して、最初の成果がいまいちだと、期待したわりには……という感じで、新しい方法の評価が下がります。
特に現状維持バイアスにより、人は方法が変わること自体を嫌うため、これまでと変わらないくらいの成果だと「今までのほうがよかった」という印象になりかねません。
導入したら、特に最初の1回は、なにがなんでも成功させる気合いで運用するのが良いと思います。
一度始めたら、目につくようにする
新しい方法を導入して満足してしまうと、業務上必須な類のものでないかぎり、定着せずにすぐ捨てられてしまうことが往々にしてあります。
導入したあとは、忘れられてしまわないよう、人の目につくところにそれを配置しましょう。
自分が率先して利用するのはもちろんのことです。
以上
レガシーなメソッドは、それが解決できなかった課題も含めて、新たな方法に価値付けしてくれる「資産」であるといえます。
故きを温ねつつ、カイゼンを続けていきましょう。