このブログで「読んだ」記事を書くのは実は初めてです。
なので拙い書評になるかもしれませんが、これもこのブログに新しいコンテンツを提供するための第一歩としてやってみます。
今回読んだのはこちらの「スクラム」という本です。
早川書房
売り上げランキング: 15,652
読んだ背景
まずは自分事からになるのですが、自分は本格的な「スクラム」を体験したことはありません。以前に、開発チームを率いていたときに、よりチーム開発を促進するために、アジャイルの考え方やスクラムの手法について勉強し、エッセンスとして活用したことはありました。 いま、DevOpsを中心とした技術支援の仕事をしているのですが、今まではテクノロジーとしてコンテナをどう使うかとかCI/CDのパイプラインをどう作るかのようなところをやることが多かったです。 そこにプラスして、より技術をうまく活用できるためのチームや組織にも着目していけるように、改めてスクラムについて勉強してみようと思いこの本を読みました。
この書籍について
この書籍についてですが、作者は「ジェフ・サザーランド」という人なのですが、ソフトウェアの世界にスクラムを生み出した人の一人といわれており、この「スクラムガイド」を書いた本人です。
彼がどのような過程でスクラムを作っていったのかが具体的に書かれています。 スクラムはソフトウェア開発の文脈で生まれたものですが、この手法自体はソフトウェア開発だけでなくあらゆる仕事に適応できるものです。 この書籍の内容も、ソフトウェア業界以外の人も十分に読んで楽しめる内容になっている点は重要なポイントと思っています。
特に着目したポイント
スクラムで何が重要か、とかそういう観点では書きません。書き始めると膨大になりますし。
自分がこの本を読んで、自分の経験と照らし合わせたときにここは注意しておきたいというポイントを２つに絞って簡単にまとめます。
1. プロダクトオーナーが示すビジョン
スクラムを実践していく上で、いろいろ重要なポイントはあると思います。 その中でも、「プロダクトオーナー」の存在は非常にキーポイントと感じました。 というのも、書籍の中でも書かれていますが、プロダクトは「2割の機能が8割の価値を作っている」と言われています。 この2割をどう作るか、何を選択するか、これをコケるとどんなにいいスプリントを回しても意味がないと感じます。
かつて、自分はプロダクト開発でとある失敗をしました。 これはまだ大学生の頃だったのですが、当時は「機能は多ければ多いほど良い」。そう考えていました。 多くの機能をつけすぎたそのプロダクトは、何をしていいプロダクトなのかユーザからわからなくなり失敗しました。 そのプロダクトが実現したい一番コアの部分をどうシンプルに実装するかが重要であることを学んだ出来事でした。
プロダクトオーナーはまさに、MVP（minimum viable product）をいかに作り出せるかがキーだなと感じています。
一方で、プロダクトオーナー任せというのも違う話だと思いますし、本の中でもそれを示唆することが書かれていました。 プロダクトオーナーはチームメンバとのコミュニケーションを通じて、プロダクトの方向性を考えていく必要があるし、価値観を押し付けるのではなく、チームで納得する必要があるというところを考えると、チームメンバーも無責任ではいられないです。
2019/7/1 追記
プロダクトオーナーについて先輩と会話したところ、実際ここはつまづきポイントとのこと。プロダクトに対する愛が大事、というのもうなずける。
また、自分がスクラムマスターの役割について理解が十分でなかったので聞いてみたところ、基本的にスクラムマスターは、メンバーがスクラムをうまく実践できるように、取り計らうことが重要な役割。プロダクトオーナーからの過剰なリクエストから守ったり、スクラムという手法に関するアドバイスだったり。
2. やりがちなマルチタスク
結構細かいことですが、個人的に心に刺さったのは「マルチタスクを行うな」の部分です。いろいろと考えさせられる場面でした。 スクラムは、限られた時間の中で最高のパフォーマンスをチームで出すことを目的にしています。パフォーマンスを阻害する要因については徹底的になくすことをうたっています。 その１つとして「マルチタスク」が書かれていました。 マルチタスクは効率性を落とす他、頭の切り替えのコンテキストスイッチがいかに無駄かが書かれていました。
なぜ、自分がこれが心に刺さったかといえば、まさにそれに悩まされてきたからです。 前職では、かなりのマルチタスクでの業務が必要な環境で、脳みその疲れを感じていました。一方で、マルチタスクも何度もやっていると少し慣れてくるのですが、マルチタスクできる自分頑張っている、と勘違いしていた時期もありました。 明確に、マルチタスクはむだでありやめろと書かれておりいろいろと考え直さなければいけないと思いました。
しかし、マルチタスクが必要とされる職場環境でどうそれを変えていくか、それは非常に難しい問題です。なかなか簡単にできることではありません。 自分の経験から思うこととしては、業務が自動化されていない環境で特にマルチタスクが発生しやすと感じています。 システムを複数運用していれば、それぞれのシステムで様々なことが日々起きます。他部署からの依頼もたくさんきます。セルフサービス、自動化、ここを進めていないとどうしてもマルチタスクな業務環境が増えていってしまうと思います。
あるいは、興味があちこちにいって１つのことに集中できなくなってしまうこともあると思います。（まさに自分） この点については、自分一人で改善しやすいポイントかなと思います。書籍の中でも「半分できたはなにもできてないのと同じ」と書かれているとおりです。 今調べていること、やりかけていることは、きちんとアウトプットしきるまでやる、ここは個人から始めやすいと思うのでやっていきたいです。
さいごに
本書を読んで、過去に経験したこととリンクして、考えさせられることが多かったです。あのときにどうしたらよかったのか、そんなヒントも得られたと思っています。 この本では、ソフトウェア開発以外にも教育の現場などでのスクラムの活用も書かれています。しっかり、スクラムの本質を理解していけば、ソフトウェア開発以外の日常の仕事に活かせると思います。
