# プロダクトの概要
高速プロトタイピングツールの開発・運用
# プロジェクトの目的
コードを書かずに本物のアプリのようなプロトタイプを作成できるサービスです。
プロトタイピングすることによって早い段階での価値検証を可能にし、フォードバックサイクルを細かく回し、それによりプロダクトの品質を良くしていることを目的にしています。
競合とは違い、「早く」「簡単に」プロトタイプを作成できることを売りにしています。
日本だけでなく、海外でも使われるプロダクトを目指しており、3ヶ国語対応、海外に営業拠点を設置など海外展開にも力をいれていました。
# チーム体制
- プロダクトマネージャー: 1人
- UIデザイナー：2人
- バックエンドエンジニア：3人
- フロントエンドエンジニア：3人
- iOSエンジニア：1人
- Androidエンジニア：1人
- MacOSエンジニア：1人
# プロジェクトにおける自身の役割
- フロントエンドエンジニア(バックエンドも少々)
- エンジニアリングマネージャー(最大12人、最終的には5人)
- 評価、採用、人員計画、勤怠管理
- プロダクトマネージャー補佐
- KPIの設定、進行管理、カスタマーサクセスと
# 課題とアクション、結果
## エンジニアとして
### ランディングページリニューアルの遅延への対処
リリース一周年を記念して、ランディングページのリニューアルプロジェクトを別のエンジニアが1人で対応していたのですが、スケジュールに大きな遅延が発生し、急遽対応を行いました。状況としては約3ヶ月とっていた期間のうち、2ヶ月半経過したところで半分程度しか実装が終わっていない状況でした。
原因としてはプロジェクトマネジメントする人がおらず、進捗やタスクの管理をすべて担当エンジニアに任せていたことでした。そのため、エンジニアは実装に手がいっぱいで残りのタスクはどれぐらいで終わるのか把握しておらず、気づいたら期限まで2週間というところになっていました。
そこで私がやったことは以下の3点です
- 残りのタスクをすべて洗いしてホワイトボードに張り見える化。ゴールを明確にする
- 上記のタスクの優先順位を決める
- 優先順位とボーダーラインをステークホルダーと相談
- 私も入れても期日までにボーダーラインに到達することは難しいということを伝え、急遽もうひとりヘルプを打診しました
タスクが見える化してあったので、3人での実装もスムーズに行うことができ、期日どおりにリリースすることができました
### コーディング上の課題への対応
コーディングしている中で、ここが書きづらい、もっとこうしたほうがいいのでは？などコーディング上の課題をしばしば感じることがありました。ですが、それをチームメンバーへ伝える場がなく、チャットで流す、一部の人と相談などで対応していたのですが、それをメンバー各々が続けているうちに人によってコーディングにばらつきがでていることに気づきました。これ以上ばらつきを広げてはいけないと思い、コーディング上の課題をストックしておく場をつくりそれを定期的にふりかえり、対策・方針を決める場をつくりました。
これにより、決めた方針をもとにコードレビューをすることができるようになったのでコーディングのばらつきが抑えられました。また、メンバー各々が考えていることをオープンにすることにより相互に学習できる機会にもなりました。
※ なお、既存のばらつきに関しては以下の方針をとることにしました
- リファクタリングの期間を改めてプロダクトマネージャーと相談する
- 機能実装のついで修正できるものを修正してしまう(ボーイスカウトルール)
こうすることにより、機能実装を遅らせることなくコードの品質を少しずつ上げていこうという共通認識をチーム内でとることができました。
### 各種botの作成
社内でSlackを日常的に使っていることもあり、できるだけSlackで完結できるように様々なbotを作成し、生産性の向上につとめました。
- フィードバック登録bot
- Slackのあるチャンネルにユーザからのフィードバックを投稿するとフィードバックを管理しているシートに文字列がたまっていくbot
- 日常的に使用しているSlackに投稿することにより、ちょっとしたユーザからのフィードバックを登録しやすくなった、どのようなユーザニーズがあるのか可視化されるようにエンジニアもユーザの要望から機能を考えることができるようになった
- フィードバックは定期的に棚卸しし、開発計画の参考になった
- 例) 解約率が上がってる → 解約者のフィードバックをみるとワイヤーフレーム機能に不満が多いことがわかる→ワイヤーフレーム関連のフィードバックをまとめ、優先順位と期間を決めて改善プロジェクトを行い解約率の抑制しよう
- プルリクエスト作成bot
- developからmasterへの差分が機能単位でわかるdescriptionが設定されたプルリクエストをslackから生成できるbot
- リリースされる機能がひと目でわかるようになり、関係者の確認が大幅に軽減された
- KPI投稿bot
- 追っているKPIと現在の数値のギャップを報告するbot
- チーム全員に数字の意識をつけるために
- これによりslack内でKPIへのアクションの会話がうまれた
- 数字への意識が向上した
- GitHubメンション通知bot
- GitHubでメンションされても気づかないという問題があったためGitHub上でメンションされたらSlack上でもSlackのユーザ名でメンションするというbot
- これにレビュー漏れが少なくなった
- 退職後、機能をブラッシュアップしたbotを個人的に開発しました
- https://github.com/deepblue-will/mention-to-slack
### 作業と進捗の見える化
当時、ある機能の実装することを決めたらエンジニア、デザイナーがアサインされ、プロダクトマネージャーと相談したながら進めていくという流れでした。明確なリリース日は進めながらリリース日のスコープを決めていくというやり方でした。
ここで、問題だったのが作業の終盤にならないとリリース日が決まらず、ステークホルダーにうまくコミュニケーションができないという問題、また、進捗を見えないので、どこまでやっているのか、なにをやらないといけないのか各々のよくわかっていませんでした。
そこで私がやったことは以下のことです
- 仕様ドキュメントを作成しプロジェクトメンバーとプロジェクトのスコープの認識を揃える。想定外のことが発生したら都度ドキュメントを修正して共有する
- タスクを1日以下の粒度で分解し、大体のリリース可能日をきめる
- 一日の終わりにテスト環境に成果物をデプロイし、プロダクトマネージャーやデザイナーからフィードバックをもらう
これにより以下の効果がありました
- スコープ外のことはやらなくなったため工数が削減
- スコープと早めの成果物の共有で、手戻りをすくなく
- 仕様ドキュメントが最終的に残るので、のちのち機能の概要を確認するのに役に立った
- 早めに想定リリース日がわかったこと、仕様ドキュメントがあったこと、テスト環境に実装中のものがデプロイされていたため、ユーザーへの周知を行うカスタマーサクセスチームへの連携がスムーズになり実装のリリース可能日にユーザーへの周知の準備の行えた
- ステークホルダーに進捗を伝えやすくなった。これぐらいタスクがあって、いまはここです。テスト環境で最新の実装状況は確認できますなど
結果としては以下の通りです
- プロジェクト開始から終了まで待ち時間が発生することなく、最短でユーザーに価値を届けることができるようになった
- プロジェクトメンバーから、いままで1番仕事がしやすかったと褒めの言葉をいただけた
## マネージャーとして
### 評価の納得度の向上
導入した評価制度の設計上の問題やメンバーとのコミュニケーション不足により社員の評価への不満が大きいという問題があり、この問題に対して以下のことを行いました
- CTO主導でのエンジニア評価制度の策定
- 1on1の内容を再考
まず、評価の満足度が低い問題の原因の１つに発揮した技術力が評価されないという点がありました。
これを解消するためにCTO、他のエンジニアマネージャーでエンジニアの評価方法を検討するプロジェクトを開始しました。
評価方法のプロトタイプ作成とフィジビリティテストでの被評価者からのフィードバックを何度か行い約半年でエンジニア評価を行うことができるところまで完成させることができました。このプロジェクトではCTOは他社、各エンジニアマネージャーはメンバーからのヒアリングを担当し、週または隔週で情報を持ち寄り方向性を決めていくという形で進めてきました。
つぎに評価の満足度の低かった問題として、半期に1回しか評価に関するコミュニケーションを行ってなかったことです。そこで私は隔週で行っていた1on1の時間をつかい、評価の認識のズレを少なくなるようなコミュニケーションをとるようにしました。やったことは以下2点です。
- 期首に立てた目標の進捗の確認
- 普段の業務に対してのフィードバック
- 良いことも悪いことも
評価制度の策定と1on1でのコミュニケーション改善の結果、半期ごとにとっている従業員サーベイのスコアが改善しました。また、エンジニア評価導入前に聞こえていた評価に対する不満は導入後には聞かなくなりました。
### ユニット定例の開催
会社や部署、プロダクトの動きをメンバーに伝える場がなく、先が見えなくて不安を感じていたメンバーが多いという問題があったので、定期的にそういった情報を伝えたり疑問に答える「ユニット定例」を週1、30分で開きました。
このユニット定例の結果として、1on1でより深い話ができるようになりました。
ユニット定例で共有可能な情報はすべて開示しているので、1on1ではよりプライベートな相談やフィードバック、目標の進捗確認などに時間をさけるようになりました
### 開発合宿の開催
以下の問題を解決すべく開発合宿の企画、実行を行いました
1. エンジニアチーム内に閉塞感・マンネリ感がでてきた
2. リニューアル後の技術のキャッチアップが全メンバーできてない
- ※ 一部のメンバーで新しい技術スタックでのリニューアルプロジェクトを進めていた
開発合宿を行おうと思った背景として、私は1.の問題を解決したいと考えていました。その解決策として場所を変えてエンジニア全員で集まって集中してなにかに取り組むのはどうだろうかと考えました。この案を実行するために以下のことを行いました。
- エンジニア全員にヒアリング。開発合宿があったらやりたいかどうか
- 開発合宿で何をやるか有志のエンジニアとディスカッション
- これにより2.の問題の解決も開発合宿の目的に追加されました
- 上記を踏まえ上司と相談
開催後、再度参加者にアンケートをとった結果このような声が聞けたので成功だと思っています。
- 普段見れない笑顔がみれた
- 邪魔されずに集中して技術のキャッチアップにとりくめた
- 新しいことに挑戦するのに前向きになれた
また、開発合宿の内容はブログにして発信しました
https://goodpatch.com/blog/gpdevcamp-vol-2/