2024.10.01
自社の社内情報を未来の“ゴミ”にしないための備え 「情報量が多すぎる」時代がもたらす課題とは?
リンクをコピー
記事をブックマーク
吉岡良治氏:これならやっていけそうだということがわかったので、次にそのプロセスを最適化していきます。
まずはPlatform as a Productという取り組み自体を仮説検証をしていきました。ミニマムに始めてうまくいきそうだという手応えを感じたので、それをより良くしていくためには何が必要かを考えます。まずは課題を見つけて、その課題を仮説として実際の改善に取り組む。
プロダクトマネジメントにおけるフィードバックループの考え方はだいたいのことに適用できるなと思っていて、そもそもの取り組み自体の改善にもこういった概念を使ってやっています。6週間ごとにやるので、基本的には半期ごとのスコープでの検証になっています。
リリースサイクルが6週間なので、半期でもだいたい回せるのは4サイクル。4サイクルぐらい回して検証できるので、いくつかの大きめなテーマを取り入れて、この改善に取り組みました。
まずはフィードバックの質を高めたいので、リリースアイテムのフォーマット改善に着手しています。今だと概要、仮説、リリース、検証の4項目を作って、それぞれに対してより詳細かつ必要な観点を記載するようにしています。また、自分たちだけでレビューをしていてもしょうがないので、チーム外から評価をもらう方法も探しています。
1つ、よくあるのがユーザーインタビューというかたちで社内のユーザーを呼んで、実際にレビューをしてもらう。その時も、実際に作成したサービスのインターフェイスに対して置き換えたプルリクエストのDiffみたいなものを作って「これぐらいシンプルになるんだけど、どう思う?」みたいなところでコードの差分を見てもらって、関係するエンジニアにレビューしてもらうようなこともやっていきました。
それともう1つはリリースサイクルに対しても、プランニングとレビューを導入しています。このプロダクトマネジメントは、最初は自分が始めたんですが、最終的にはチームで回せるようになることが重要だと思っています。
そのための第一準備としてプランニングとレビューというのを導入しました。必要な準備としては、まずは「GitHub」のIssueでフォーマットを整備します。
その上で、プランニングのレビューとプロセスをリリースサイクルに組み込んで、そのレビューをする責任者を任命します。最初はというか今もそうなんですが、マネージャーの自分が担当しています。
あとは、各チームのテックリードに、プランニング前にリリースアイテムという6週間の計画を立ててもらって、それを事前にレビューした上で、リリースサイクルが終わったらアイテムごとにレビュー、状況確認をする。定義を満たしていれば責任者が承認する。GitHub Issueで管理をしているので、Labelを付けるということをやっています。
(スライドを示して)これは情報量が少ないリリースアイテムですが、こんな感じでIssueを作って。右にLabelがあるんですが、こんな感じで承認していくプロセスを回しています。
他にもいろいろとやっていたんですが、今日は発表時間が短いので、ここでは割愛します。
最後に存在感を出すというところで、僕らのバリューの中に「Presence」というバリューがあります。開発した機能を評価してもらうためには、能動的な成果の共有を大切にする必要があります。その評価から学びを得て次の開発に活かすということが、このバリューのことなんですけど。
やはりただ単に開発しただけだと使ってもらえないんですね。
使ってもらえないと、結局のところはフィードバックが得られない。やはり使ってもらうためには自分たちのほうから能動的にアピールすることがすごく大事なので、ここが自分たちのバリューにも含まれています。いくつか社内で取り組んでいるものがあるので、ここでも軽く紹介しようと思います。
1つは、これはみなさんもやっているかもしれませんが、社内向けのリリースノートです。隔週でAll-Hands Meetingをやっているんですが、そこで完成したリリースアイテムに対してIssueにリリースノートをまとめて、社内のチャンネルで共有するということをやっています。
もう1つはプロダクトチャンネルです。関係者を集めてやり取りをするチャンネルなんですが、例えばDarklaunch v2ブログを見てもらえばいろいろと詳細とかが載っています。Darklaunch v2というプラットフォームを作っていたんですが、#darklaunch-dev-jaというチャンネルを作って、ここでいろいろとやり取りをしています。
そこには要望リストがあったり、気軽にチームに対してメンションしてもらえば反応するようなかたちになっているので、そこでやり取りを行っています。
(スライドを示して)また、部内キックオフみたいなところでも、主にチームごとのロードマップ計画とか進捗、グループの戦略・戦術などもこまめに共有していて、右のような資料を作って説明していたりします。
あとはブログですね。ブログは主に社外向けにやっているものだと思いますが、実はこれも弊社では立派なアピールツールになっていて。弊社ではブログ記事を書くと、別の領域の関係者がレビューをしてくれるんですね。
なので、プラットフォームの記事を書くだけで、それをレビューした人に知ってもらえるので、それもある種の社内の宣伝にもなったりします。
つまるところ、結局は作るだけじゃなくて、やはり認知してもらうということがフィードバックにはすごく重要なんじゃないかなと自分は思っています。結局自分たちの目的はプラットフォームを利用してもらってフィードバックを得ることなんですよ。
でも、知ってもらわなければその便利な機能も使ってもらえないので、結局フィードバックは得られない。なので、とにかく自分たちから能動的にアプローチをしていって、社内にPresenceを出すことが非常に重要なことなんじゃないかなと今でも思っています。
まとめです。自分たちがなぜここにいるのかをちゃんと言語化しよう。基盤をプロダクトとして捉えて、プロダクトマネジメントの手法を活用する。どのような改善もフィードバックループというものを素早く回すことがやはり大事だというところと、フィードバックを得るには能動的に成果を共有して、ちゃんと認知してもらおうねという話になりました。
以上になります。ご清聴ありがとうございました。
関連タグ:
2024.10.29
5〜10万円の低単価案件の受注をやめたら労働生産性が劇的に向上 相見積もり案件には提案書を出さないことで見えた“意外な効果”
2024.10.24
パワポ資料の「手戻り」が多すぎる問題の解消法 資料作成のプロが語る、修正の無限ループから抜け出す4つのコツ
2024.10.28
スキル重視の採用を続けた結果、早期離職が増え社員が1人に… 下半期の退職者ゼロを達成した「関係の質」向上の取り組み
2024.10.22
気づかぬうちに評価を下げる「ダメな口癖」3選 デキる人はやっている、上司の指摘に対する上手な返し方
2024.10.24
リスクを取らない人が多い日本は、むしろ稼ぐチャンス? 日本のGDP4位転落の今、個人に必要なマインドとは
2024.10.23
「初任給40万円時代」が、比較的早いうちにやってくる? これから淘汰される会社・生き残る会社の分かれ目
2024.10.23
「どうしてもあなたから買いたい」と言われる営業になるには 『無敗営業』著者が教える、納得感を高める商談の進め方
2024.10.28
“力を抜くこと”がリーダーにとって重要な理由 「人間の達人」タモリさんから学んだ自然体の大切さ
2024.10.29
「テスラの何がすごいのか」がわからない学生たち 起業率2年連続日本一の大学で「Appleのフレームワーク」を教えるわけ
2024.10.30
職場にいる「困った部下」への対処法 上司・部下間で生まれる“常識のズレ”を解消するには