無駄と文化

実用的ブログ

サービス・プロジェクト改善のモチベーション

この記事は GYOMUハック/業務ハック Advent Calendar 2018 の5日目の記事です!
4日目の担当は Kouta Sasaki さん、6日目の担当は otoan_u さんです。

f:id:todays_mitsui:20181205192929j:plain

どうも、未経験からたったの7年でエンジニアになった三井です。

プログラムを書き始めて16年ほど、プログラムを業務に活かしはじめて7年ほどになります。
今年に入って人生で初めて「プログラマ」という肩書きで働き始めました!ちなみに昨年は管理部所属で情シスやってました!

プログラマやり始めて1年経ったので、なんとなく自社サービス・自社プロジェクトを改善していくモチベーションについて書きますね。


機能追加と改修・修正が繰り返されてゆく自社サービス

企業としてサービスを開発し、提供している場合、リリースして終わりというわけにはいかず、当然 機能追加と改修が繰り返されていくことになります。
もし大きな不具合が見つかれば急いで修正ですね。

そんな機能追加と改修・修正が繰り返されてゆく自社サービスの質を高く保っていくために重要なことがあります。
それは開発チームのモチベーションを高く保つことです。

チームのモチベーションが低ければ、サービスの質はだんだんと低下していく傾向にありますし。
逆にモチベーションを高く保つことで、リリース当初は荒削りだったサービスの質を徐々に高めていくこともできます。


サービスをより良くしていくためのモチベーション

では、サービスをよりよくしていくレベルでモチベーションを高く保つために必要な要素って何でしょう?
いろいろな切り口からいろいろな回答を上げることができそうですが、私は現場に立ってサービスを作っていく側として一つ確証に近いものを持っています。

モチベーションを高く保つために必要な要素、それは、
プロジェクトに関わるエンジニア一人ひとりが『このサービスは我々のものだ!』と感じられること です。


エンジニア一人ひとりが『このサービスは自分のもの』と感じられていれば、機能や仕様について各々が主体的に考えることが出来るようになり、自ずとクオリティも高まっていきます。
逆に、エンジニアが『自分のものではないサービスを仕方なくメンテしている』と感じてしまうと、機能追加には消極的になり、見直しが必要な仕様でも放置して開発を進めてしまいがちです。

プロジェクトメンバーが『このサービスは我々のもの』と感じられるために有効な仕掛けはいくつかあります。
今回はその中でも最も簡単な方法について書きます。


最も簡単で、強力な方法

最も簡単な方法とは バージョン管理 です。
『え、それだけ?』と思いましたか?それだけです。

弊社には会社の歴史から見て比較的古くから続く バージョン管理されていないプロジェクト がありました。ちょっとした CMS なのですが、弊社のビジネスにとっては地味に大切なものです。
このプロジェクト、Git リポジトリに変更を記録してはいるもののバージョン番号は振られていないし、コードも書き足し書き足しで秘伝のタレと化していました。

私が今年の1月にそのプロジェクトに join してすぐに、そのサービスに関わることを億劫に感じている自分に気付きました。

  • ちょっとの機能追加を重く考えてしまっている
  • 修正作業のやる気がおきない

そんな感情です。
なんだかプロジェクトを自分でコントロールしている気がしないし、改善しているはずなのに楽しくないのです。

いま思えば、改善が「見えない」ことが何よりもストレスだったのだろうと思います。


附番せよ、記録せよ、

バージョン管理のキモは 今すぐ始められて、目に見える ことにあります。
上記のプロジェクトにもバージョン番号を振るようにしました。

とはいえ最初は適当です。長い事やってるプロジェクトなので v3.0.1 から始めました。


バージョン番号の運用方法をもう少し具体的に、

  1. 週に1回のペースでリリースしてバージョン番号を上げる
  2. 修正リリースでもマイナーバージョンをガンガン上げていく
  3. Git Commit 時にコミットメッセージにプレフィックスを導入
  4. チーム向けにリリースノートも書きはじめた

するとどうでしょう。たったのこれだけで機能追加や不具合修正に やりがい 的なものを感じるようになりました。

もちろん、バージョン番号を振るなんて改善の見える化において初歩の初歩なんです。
それでも!バージョン管理 する/しない の間には大きな隔たりがあるのです。


さて、上記の運用ルールには一つひとつに狙いがあります。
それを具体的に見ていきましょう。


1. 週に1回のペースでリリースしてバージョン番号を上げる

本プロジェクトにおいて、それ以前に 定期リリース という概念はありませんでした。
それを大きく変えて、 機能追加がある限りは週1回のペースでマイナーバージョンを上げてリリースする ようにしました。

基本は月曜日の朝にバージョンを上げるかどうかの判断をし、上げると決めたら13時を目処にリリースに向けた作業をする流れです。


そうするとバージン番号がガンガン上がっていきます。
大きな機能追加があれば月曜でなくともリリースするので、もうどんどんバージョン番号がインクリメントされます。楽しい😉

人間は数字が少しずつインクリメントされるのを見るだけでテンションが上がってしまう生き物なんですよ。
楽しさは何よりもモチベーションの源になります。

※ ピンと来ない人は自分の預金通帳の残高が1秒間に1円ずつ増えていくのを想像しましょう


2. 修正リリースでもマイナーバージョンをガンガン上げていく

これは人にも依ると思いますが、私にとって不具合の修正作業はとてもネガティブなものでした。
だって、不具合を出した事は恥だし、修正って生産的じゃないし。

しかし!修正リリースでも積極的にバージョン番号を上げる方針にしました。
修正に付きまとうネガティブな感情をやわらげたくて。

これは一種の「問題の再定義」になっています。
非生産的な修正作業という認識を組み替え、バージョン番号が上がっていくさまを見せることで『これだけ不具合をぶっ潰して、サービスをより良いものにした!』と思えるようになったんですね。
これも改善の見える化です。


3. Git Commit 時にコミットメッセージにプレフィックスを導入

この手法は三井が発明したものではないので 参考記事 を見てもらいたいんですが。
バージョン番号の付番と同時に、Git 運用時のルールとして 「コミットメッセージのプレフィックス」 を導入しました。

プレフィックスを付けることのメリットは枚挙に暇が無いですが、メインは、

「お!このタイミングでめっちゃいい機能が追加されとるやんけ!」

とか

「お!ここらへんでめっちゃ不具合潰していい感じにしとるやんけ」

とか後から振り返って楽しむ用です。


4. チーム向けにリリースノートも書きはじめた

上記のようなことをして改善の見える化が出来るようになったので、次のステップとして、隔週のペースでリリースノートをまとめるようにしました。
とはいえまずはチームメンバー向けです。

リリースノートと言うと、本体のサービス改善とは別の作業のような気がしてしまいますが、
プロジェクトチームから外に向けては やってる感 を見せる事が出来ますし。
他部署の人間的には 新機能にいち早くキャッチアップするきっかけ になっているんじゃないかなと思います。

言ってみれば、エンジニアだけでなく会社全体で『このサービスは我々のもの!』と思うための仕組みですね。


まとめ

今回はエンジニアチームのモチベーションを高める簡単な、でも強力な方法、バージョン管理について書いてみました。

社内で使うちょっとしたツールであれ、ビジネスの基幹に関わるサービスであれ、自社開発しているものであれば積極的に・おおげさにバージョン管理してみましょう。
「小さなツールだから...」なんてのは関係ありません。

バージョン番号を附番し、記録をはじめた瞬間からそのサービス・プロジェクトは 我々の物 になります。
そしてサービス・プロジェクトが我々の手中にある限り、それを無限により良くしていくことができるのです。
そう、他でもない、我々の手でね。


私からは以上です。