スクラムマスダーの日記

アジャイル、スクラムに関連した内容が多めです。

『チームビルディング超実践ガイド』のレビューに参加しました!

ふりかえりで著名な森さんが執筆された同人誌『チームビルディング超実践ガイド』が、2月29日に出版されます。今回、レビュアーとして書籍の出版に携わることができました。

hurikaeri.booth.pm

本書は、技術書典8での販売を予定されていました。
ただ、コロナウイルスの影響もあり、残念なことながら、技術書典は中止となってしまいました。

techbookfest.org

今回、2月29日に、プロジェクトマネージャー保護者会のイベントが開催され、『チームビルディング超実践ガイド』の出版は、無事行われる運びとなりました!

hurikaeri.hatenablog.com

レビューに参加させていただいたので、『チームビルディング超実践ガイド』の紹介をさせていただきます。

対象読者

この書籍は、チームに所属するすべての方におすすめできる内容となっています。働いている方で、周囲の方と関係性のない仕事に携わっている方は、いらっしゃらないと思うので、働くすべての方に、おすすめできると思います。

といっても、一番の対象の方は、マネージャーやリーダーの方です。
チームメンバーが働く時間に対して、ある程度コントールできることから、改善やワークの時間を取り入れやすいためです。
特に、新しくマネージャーやリーダになった方には読んでいただきたい内容です。

書籍概要

書籍の内容は、大きく2つに別れており、

  • よりよいチームとは、どのようなチームであるのか
  • よりよいチームにするためには、どういう方法があるのか

を紹介しています。

よりよいチームは、みなさんが想像される通り、

  • 心理的安全性の高い状態
  • 自律的である
  • 学習に対する前向きさ

といった要素があるチームです。
こういった内容は、既存の書籍にも書かれている内容で、みなさんも納得されると思います。

『チームビルディング超実践ガイド』の一番のポイントは、チームをよりよくするために何をすればよいのかの具体的な手法を紹介していることです。

より良いチームのためのWhyやWhatを理解するだけでは、現場で実践することはできません。
Howも深く理解することで、初めて現場で実践することができます。

『チームビルディング超実践ガイド』は、そのHowがたくさん紹介されています。
現場で実践するときのハンドブックになる書籍となっています。

書籍について、まとめたチートシートがすでに公開されています。
https://cdn-ak.f.st-hatena.com/images/fotolife/v/viva_tweet_x/20200214/20200214154918.jpg

このチートシートを見て、気になるHowがある方は、ぜひ『チームビルディング超実践ガイド』を読んでほしいと思います。

また、すでに序文は公開されているので、とりあえず読んでみたいという方は、以下のブログを御覧ください。

hurikaeri.hatenablog.com

おわりに

技術書典(今回は残念ながら中止ですが…)は、関西在住の僕にとって、縁遠いイベントですが、レビューという形で、関わることができたので、非常によい経験をさせていただきました。
機会をくださった森さんには、非常に感謝しています!

ぜひ、みなさん、『チームビルディング超実践ガイド』を手にとっていただければと思います!

カンファレンスのスライドまとめブログを書くだけで十分貢献できるよ

こんにちは。スクラムマスダーです。

1月は、私のブログ閲覧数が一年で一番多い月です。
なぜかというと、Regional Scrum Gathering Tokyo(以下、RSGT )というスクラムに関するカンファレンスのスライドをまとめたブログを毎年書いており、多くの方に閲覧していただいているからです。

scrummasudar.hatenablog.com

scrummasudar.hatenablog.com

scrummasudar.hatenablog.com

抽象、具体を問わず技術やエンジニアリングやプロセスなどについてブログやSNSで発信している方にとっては、「スライドまとめブログなんて・・・。」と思われる方も、いらっしゃるとは思います。

ただ、カンファレンスに参加した、していないに関わらず、後日スライドを確認したいことは、数多くあると、私個人は感じています。

今年もRSGTのスライドまとめブログを書いたことで、いくつかのブログにリンクを張っていただきました。少なくとも、リンクを張っていただいた方には有用なブログであったということです。
「これで会社報告用の資料作成がはかどります!」とご連絡いただいたこともありました。

ここ最近では、SRE NextのスライドまとめQiitaが多くのいいね数を獲得しており、Twitterなどで何度か見かけました。

qiita.com

ブログやQiitaを書くことはハードルが高いように思いますが、スライドまとめブログは、個人の感想を書くこともないですし、ほぼ作業をするだけで書き終えることができます。

加えて、多くの方に見ていただき、有用に活用いただけることも多いです。また、そのブログがSNSで拡散されることによって、カンファレンスに興味を持つ方が増え、カンファレンス自体に認知を高める効果もあり、カンファレンスに微力だとは思いますが、貢献できていると思います。

現在では、数日に渡るカンファレンスや1日であってもマルチトラックで多くのセッションを行うカンファレンスが、一年間にいくつも開催されいていると思います。

まずは「自分があとで見直す際に便利だからまとめておこう」くらいの軽い気持ちで、スライドまとめブログを書いてみてください。

それだけで十分参加したカンファレンスに貢献できたと思いますよ。

「アジャイルな開発だと、プロダクトの価値から作り始めることが出来た」は結果論だと思う

アジャイル開発が浸透するにつれて、プロダクトの責任者(スクラムの場合、プロダクトオーナー)だけでなく、開発者が「プロダクトの価値とはなにか?」を考えることが多くなってきたと感じています。

そして、プロダクトが成功したといえる場合、「アジャイルな開発だと、プロダクトの価値が高い部分から作り始めることが出来た!」という理解になると思います。
しかし、その考え方は、生存者バイアスだと、私は思っています。
※プロダクトが成功したと言える状況の時点で、素晴らしいことではあります。

なぜ「アジャイルな開発だと、プロダクトの価値から作り始めることが出来た」は結果論なのか、なぜ「アジャイルな開発は、プロダクトの価値の高い順番で開発する」という捉え方があまりよくないのかを記します。

そもそもプロダクトの価値とは?

プロダクトの価値とは、一体何なのでしょうか?
もちろん、それぞれのプロダクトで、様々な指標があると思います。

ただ、一点言えるのが、「そのプロダクトの価値で儲けることができるのか?」ということです。

単にお金を得るだけであれば、様々なやり方があるとは思います。

  • 顧客から対価をもらう
  • 投資家から投資をしてもらう
  • 社長から予算を承認してもらう

などです。

しかし、儲けるということは、基本的に、顧客から対価をもらうに収束すると考えています。

なぜなら、投資や予算の承認を継続するには、顧客から対価をもらうが必須だからです。 投資家は、そのサービスが稼ぐことで株価を増やしたいという目的があります。社長から予算をもらうといっても、そのサービスで売上や利益を見込めないのであれば、事業として畳むでしょう。

アジャイル宣言の背後にある原則にある継続

アジャイル宣言の背後にある原則には、

アジャイル・プロセスは持続可能な開発を促進します。
一定のペースを継続的に維持できるようにしなければなりません。

と記載されています。
持続可能な開発をアジャイルは目指しているわけですが、仕事で実践する限りは、お金が必要なことは明白です。
無給で働く人はいないですし、会社を運営するだけでも色々な税金や経費はかかっているからです。
※個人やコミュニティで開発する上でも、どこかからはお金を引っ張ってくる必要があます(PCでプログラミングするだけでも、PCを買ったり、電気代やネット代を支払っているので、お金は必須。)

プロダクトの価値は市場に出さないと分からない

では、「プロダクトの価値」が儲ける内容であるかは、いつわかるのでしょうか?
結論としては、市場に出して初めて分かると、私は考えています。

もちろん、市場に出す前に、仮説検証で、将来の顧客やユーザーにヒアリングや実際に使ってもらうことは可能です。
しかし、これらの活動はあくまで仮説の確度を高めるために行っており、実際に顧客から対価をもらっていないからです。
※もちろん、プロダクトの成功する確率を上げるために、市場に出す前の仮説検証という行為自体は必要だと、私は考えています。

そのため、アジャイル開発では、プロダクトの価値の高い順番で開発することはなく、あくまで市場に出す順番で開発しているということになります。

プロダクトの価値は変化する

また、プロダクトの価値は常に変化します。それは、市場や顧客のニーズが変化するからです。

今後作る開発内容については、もちろん開発する順番を変更することで、市場や顧客の変化に対応することが可能です。
しかし、すでに開発済みのプロダクトの開発した順番を変更することはできません。

市場に出すまでに、顧客のニーズが変わったり、競合企業の状況によって、顧客が購入した決め手は、開発した順番の1番目や2番目ではなく、10番目であることも十分に想定できます。 1番目に開発した価値より10番目に開発したプロダクトの価値が高いことも十分あるのです。

つまり顧客にとっては開発する順番は関係なく、その中でアジャイル開発で変化に対応するサイクルを回しているかは全く関係ないのです。

プロダクトの価値だけを作っても市場には出せない

プロダクトの価値は、そのプロダクトの本質といえる部分で非常に重要なのですが、それだけを開発してもプロダクトをリリースすることができません。
おそらくログイン・ログアウトといった機能やユーザー登録機能は必要ですし、Webサービスであればインフラを構築する必要があります。
つまり、本質的にプロダクトの価値につながらない内容であっても、リリースするために必要な開発内容があるということです。

アジャイルで開発しようが、ウォーターフォールで開発しようが、市場に出すまでに開発する必要があるものは開発する必要があるのです。

アジャイルな開発な場合、むしろ継続的インテグレーションや継続的デプロイを効果的に運用するために、開発初期段階で、インフラの構築やユニットテストの自動化といったことを行うことが多いです。

プロダクトの価値につながる開発を実施しする前に、上記のような足回りの整備をしてから取り組んだ方がよいと考えています。

おわりに

色々と書きましたが、市場に出さない限りはわからないし、市場に出すことこそが改善のサイクルを回す最大の原動力になるので、改善のサイクルを回して、顧客から対価をもらえるように、アジャイル開発をうまく利用しようということでした。

ただ、「アジャイルな開発だと、プロダクトの価値から作り始めることが出来た」という考えれる状況って素晴らしいと思うんですよね。なんたって、顧客から対価を継続的にもらえているのですから。