
2025.02.12
職員一人あたり52時間の残業削減に成功 kintone導入がもたらした富士吉田市の自治体DX“変革”ハウツー
リンクをコピー
記事をブックマーク
吉岡良治氏:これならやっていけそうだということがわかったので、次にそのプロセスを最適化していきます。
まずは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を出すことが非常に重要なことなんじゃないかなと今でも思っています。
まとめです。自分たちがなぜここにいるのかをちゃんと言語化しよう。基盤をプロダクトとして捉えて、プロダクトマネジメントの手法を活用する。どのような改善もフィードバックループというものを素早く回すことがやはり大事だというところと、フィードバックを得るには能動的に成果を共有して、ちゃんと認知してもらおうねという話になりました。
以上になります。ご清聴ありがとうございました。
関連タグ:
2025.02.06
すかいらーく創業者が、社長を辞めて75歳で再起業したわけ “あえて長居させるコーヒー店”の経営に込めるこだわり
PR | 2025.02.07
プロジェクトマネージャーは「無理ゲーを攻略するプレイヤー」 仕事を任せられない管理職のためのマネジメントの秘訣
2025.02.04
日本企業にありがちな「生産性の低さ」の原因 メーカーの「ちょっとした改善」で勝負が決まる仕組みの落とし穴
2025.02.05
「納得しないと動けない部下」を変える3つのステップとは マネージャーの悩みを解消する会話のテクニック
2025.02.06
落合陽一氏や松尾豊氏の研究は社会に届いているか? ひろゆき氏が語るアカデミアの課題と展望
2025.01.07
1月から始めたい「日記」を書く習慣 ビジネスパーソンにおすすめな3つの理由
2025.02.05
エンジニアとして成功するための秘訣とは? ひろゆき氏が語る、自由な働き方を叶えるアプリ開発とキャリア戦略
2025.02.03
手帳に書くだけで心が整うメンタルケアのコツ イライラ、モヤモヤ、落ち込んだ時の手帳の使い方
2025.02.03
「昔は富豪的プログラミングなんてできなかった」 21歳で「2ちゃんねる」を生んだひろゆき氏が語る開発の裏側
2025.02.10
A4用紙を持ち歩いて殴り書きでアウトプット コクヨのワークスタイルコンサルタントが語る、2種類のメモ術
【手放すTALK LIVE#45】人と組織のポテンシャルが継承されるソース原理 ~人と組織のポテンシャルが花開く「ソース原理」とは~
2024.12.09 - 2024.12.09
『これで採用はうまくいく』著者が語る、今こそ採用担当に届けたい「口説く」力のすべて
2024.11.29 - 2024.11.29
【著者来館】『成果を上げるプレイングマネジャーは「これ」をやらない』出版記念イベント!
2025.01.10 - 2025.01.10
片付けパパ対談【特別編】 整理術×行動術×メモ術で、仕事も人生も自在にデザイン!
2024.12.16 - 2024.12.16
日本を変える 中小企業リーダーズサミット2025
2025.01.30 - 2025.02.12