はじめに
こんにちは。
オープンワーク株式会社で開発を担当している 市川と申します。
もうすぐ桜の季節ですね。紅葉よりは桜派なので楽しみです。
最近28歳になりまして、オープンワークに入社した2年前は男性エンジニアの中で一番若かったのですが、
後輩が続々と入ってきたり、22卒エンジニアも間も無く入ってくるので、ちょうど平均年齢くらいになりそうです。
年相応の貫禄のある人になる、がとりあえずの目標です。
さて今回は、弊社制度の一つであるMVP制度について書いていこうと思います。
私も過去一度選ばれたことがあるので、その時うまくいったことや振り返りなど書いていこうと思います。
私自身常に模索しておりますが、開発者としてどのように立ち回るとプロジェクトがうまくいきやすいのか、悩んでる方の一助になれば幸いです。
カメラ目線ではないですが、MVP発表でコメントをしていた時の写真です。
受賞当時のプロジェクトですが、OpenWorkリクルーティング という、
リクルーティングサービスの顧客満足度向上を目的に機能開発・改善を行っていたプロジェクトでした。
スカウトや応募管理、クチコミ分析機能の改善等を行いました。
MVP制度とは
まず、どんな制度かについてですが、Most Valuable Playerを選出する制度になります。
弊社では、チームやプロジェクト単位で四半期に1度MVPを選出しています。
選ばれると賞金がもらえるので結構嬉しいです。
選出の基準ですが以下の基準で総合的に判断されます。
- 目標の達成度
- ミッションへの貢献度
- ACTION STYLEの体現度
目標は、チームやプロジェクト毎に持っているものですね。期初に設定するものになります。
ミッションは会社のミッションです。「 ひとりひとりが輝く、ジョブマーケットを創る。」です。
ACTION STYLEというのは、弊社社員が働く時に持つ行動指針を定義したものになります。具体的な内容は後述します。
ACTION STYLEについて
では、どんな行動指針が定義されているのかを紹介します。
- Act for All：部分最適にならず、全体最適を作り上げよう
- Be Honest：自分都合にならず、常に社内外へ誠実であろう
- Create the Next：過去を踏襲するのではなく、未来に向けて変化を創出しよう
- Direct Yourself：組織に依存するのではなく、自分で自分を動かそう
書いてあることは理解できると思いますが、
これをどのようにして自分の仕事に結びつけるかが難しいところです。
当時プロジェクトとしてこのACTION STYLEの体現度が評価されましたが、
具体的には期限内に機能のリリースをしたことだけではなく、それがどうすれば使われ浸透するかを考え実行し、利用率に好影響を与えたところでした。
そしてその中でも、開発者としては機能のリリースを「安全な形で早くリリースすること」で貢献できたと思っています。
また、それを実現するにあたり私はACTION STYLEのうち、特にBe HonestとCreate the Nextに注力していました。
次の章からはその時実行した内容と、元々抱えていた課題について話していきます。
それまでの課題
まず、「安全な形で早くリリースする」というところに対し、元々課題として以下のようなものがありました。
① 障害、リリース失敗の発生
現場ではよくある話ですが、とりあえず動くものを作ってテストは最後にやる、
しかしリリースが近くなってきて焦ってテストし、バグに気付けずリリースされてしまう。
また、障害が起きるとその対応に工数を使うのでさらに納期が迫って焦り、障害が起きやすくなるという負の循環に嵌っていました。
② 開発スピードの遅延
弊社のエンジニアは開発だけではなく、スケジュール管理や他チームとの調整も自分で行います。
また、リリースするまでに必要な作業は自分で見つけ、消化していきます。そのため、考えることが多く難易度は高めです。
開発業務を行ったことがある方はわかると思いますが、集中して作業する時間を確保出来ないと効率的に進められません。
そして現実は、人とのやり取り > システム開発 という割合になってきたりします。
加えて歴史のあるプロダクトなので、ソースが繰り返し継ぎ足され仕様が複雑化していました。
そういった仕様の経緯を知る人は少ないので、リーダーや長く携わっている人に質問が集中する状態でした。
結果、開発スピードが落ちていきました。
まとめると、質もスピードも不足していたという状況ですね。
課題①に対して改善したこと
課題①に対しては現状の進め方を見直す、Create the Nextの観点で質を改善していきました。
よく言われる質とスピードはトレードオフではない、というのはその通りで、
質が低くなっていたからこそスピードも落ちていた面があったので、そのあたりに目をつけました。
テストやUX検証の進め方を見直し
まず、テストって好きな人あまりいないと思いますが、なぜ好きじゃないかというと、大変だからだと思います。
量が多くて大変、パターンが多くて大変、準備するデータが面倒..等
それを解決するために有効なのは、リリース単位を小さくするか、テストを段階的に行って1度のテストを少なくすることだと思います。
今回は比較的実践しやすそうな後者を選びました。
（それまでは開発を全てやり切ってからテスト・UX検証をしていました。）
やることは単純で、タスクを大きすぎない単位で分割し、タスク完了の都度テストとUX検証を行うだけです。 こうすることで1回のテストが楽になるだけではなく、「ここまではテストしたから大丈夫」という心理的な安心が得られます😌
同じ作業量でも心に余裕があると焦らず実施できるので、その期の障害はほぼ0件（小さいもの1件のみ）に抑えることができました。
また、それまでテストは基本的に開発者のみが行っていましたが、
開発者以外のメンバー（プロジェクトメンバーに限らず、普段プロダクトを使っている社内のコンサルメンバーも含む）にも実施してもらうことで、気付きづらいバグや適切でないUXを見つけることもできました。
課題②に対して改善したこと
次に課題②に対してですが、質を高めた上で早くリリースできるように工夫しました。
「質の高いものが早くリリースされること」を 開発者としての誠実さ（Be Honest）
という考え方で改善を進めました。
役割分担の見直し
まず、人の作業量や確保できる集中時間には限度があるので、「開発をするメンバー」と「開発以外全て行うメンバー」で分けました。（私は後者）
スクラムマスターと開発者の関係性みたいなものです。
開発以外の作業だとだいたいこんなものがありました。
- 他PJ、ビジネスメンバーからの質問対応
- 障害対応
- 目標外の細かい開発
- コードレビュー
加えて開発メンバーが作った機能のテストケースを作ったり、テスト実施なんかもやりました。
これによって毎日開発は一定以上の速度で進んで行きました。
コミュニケーション方法の見直し
弊社では連絡ツールとしてslackを主に使っているのですが、
特にリモートになってからお互いの状況が見えにくくなり、コミュニケーションが前より難しくなっていました。
そこで、簡易的な日報を始めました。 日報というと硬いイメージがありますが、こんな感じで自由に進捗を報告する緩いものでした。
また、日報以外にも質問しやすい空気や環境を作るために、気軽に発信できるチャンネルを作ったりもしました。
このようにして他のメンバーの状況が分かるようになると、特に「開発以外全て行うメンバー」が誰にどんなサポートが必要なのか把握しやすくなり円滑に業務が進みやすくなりました。
まとめ
今回はMVP制度と、選出の基準になるACTION STYLEを、どのように意識し業務改善を行っていったかの実例をご紹介しました。
実践自体はうまくいきましたが、これを今後何も考えずとも実行されるような仕組みにしたり、他のPJにも浸透させたりするところが続けての課題になってくるので、次回以降はそういった内容もご紹介できたらと思います。
おまけ
プロダクトマネージャーの高橋さんからもコメントいただきました。ありがとうございます。
各エンジニアが自分だけではなく、PJとしての生産性向上を念頭に行動してくれてとても助かりました！
気持ちよく仕事をしていくために「もっと良い方法あるかな？ありそう、試してみよう！」という感じで自分事として捉え、意見を発信してくれるのでめちゃめちゃやりやすいです。
最後に
今回の内容は一例なので、もしもっといい方法があるという方は是非教えてください。
また、こんなエンジニアと仕事したいプロダクトマネージャーの方もカジュアル面談等いつでもお待ちしています！
https://vorkers.jp/recruit/job
