書評。『正しいものを正しくつくる』を読んで顧客との共創に向け腹をくくる

著者の市谷さんがあとがきに書いているように、「正しいものを正しくつくる」は、プロダクトをアジャイルにつくるということに関する、市谷さんのここ5年を中心とした実践に基づく、まさしく冒険の記録です。

本書は入門書ではありませんが、経験の浅いスクラムマスターにとっては、第2章「プロジェクトをアジャイルにつくる」・第3章「不確実性への適応」は、Scrumというフレームワークの良いリファレンス実装として役立つでしょう。特に期待マネジメントや余白(バッファ)調整について詳しく、アジャイル開発になんらかの形でかかわるマネージャにとっても面白いはずです(個人的に「広さでコミットし深さで調整するプランニング」が気にいりました。とてもわかりやすくバランス感覚のあるスコープ調整のガイドとして有用です)。

プロダクトを成功させる=アウトプットだけでなくアウトカムを出す、には「正しいもの」が何であるか、価値はどこにあるかを探索する必要があります。第4章「アジャイル開発は2度失敗する」・第5章「仮説検証型アジャイル開発」は、プロダクトオーナーはもちろん、POをサポートするスクラムマスターやチームメンバーも是非読んでおきたい内容です。もちろん、「正しくないものを正しく作ってしまった」経験のある私にはとても刺さりました。うん。やっぱりユーザーインタビューのような軽い検証を複数回行うべきだったな。。

本書の全編に横たわるメッセージは、「壁を超えること・壊すこと」。

私もプロダクトのPOをしていた時、チームとの間に壁がなかったかと問われると自信がありません。第6章「ともにつくる」は、そんな、何かとしんどいPOの機能を代行する「プロダクトオーナー代行」が印象に残ります。

アジャイルスタジオ福井でのリモート開発でも、お客様のシャドーとしてPO代行を置くことがあります。ただ、その際でもPO代行はあくまで「仕様ホルダー」としての役割に徹するのですが、本書では、一部の意思決定にまで踏み込んだPO代行について提案しており興味深い。曰く「プロダクトオーナーなる唯一絶対の存在の民主化」。まさにアジャイルを越える挑戦であり、 ユニークです。らしいな、と思いました。

f:id:HappymanOkajima:20190721223058j:plain

5年前の私は、社命でそれまでの事業部を離れ、各部署から集まった有志と事業検討の横断プロジェクトを始めました。その中の一人が市谷さんで、仲間と一緒に新しい受託開発の形について様々な検討をして一区切りついた後、旅立ち、開発とビジネスの境目を越境し、活躍の場をどんどんと広げています。本書は、そんな市谷さんの知見を惜しみない勢いで言語化した、(現時点での)集大成とも言えるでしょう。

前回のブログでも軽く吐露したのですが、受託開発を生業とする私にとっても、「アジャイルのその先」は常に頭から離れないテーマで、顧客と開発者の垣根がない共創世界をどうやってWin-Winの形で実現するかが優先課題となっています。

本書は、そんな私にとっては、先に越境した先輩からの道しるべのように読めました。市谷さん、ありがとうございます。

 

ポストアジャイルに受託開発屋は存在するのか? ~ Agile Japan 2019 に参加して

今年も Agile Japan に参加しました。10回目の今回はなんと800名もの方が参加されたということで、確かに、会場の熱気というかぎゅうぎゅう感がとても良い雰囲気でした。実行委員を始めスタッフの皆さん、お疲れさまでした。いつもありがとうございます。

実は私、第1回の Agile Japan で実行委員としてクロージングセッションを担当させていただきました。あれから10年、私も、私の主なフィールドである受託開発もずいぶん変わりました。

happyman.hatenablog.jp

10年まえのブログを読み返してみたのですが、「私は今まで、実は自分はアジャイルな人ではないと思っていた」とのフレーズがありました。確かに当時は計画駆動型の開発にアジャイルなチームビルディングを持ち込むことに力を入れてます。

そんな私も、今では開発の在り方についてごく自然にアジャイルに考えていますし、業務でも、主にSOEやDXと呼ばれる分野向けに Agile Studio Fukui にてリモートアジャイル開発サービスをやってます。ゆっくりなようで10年あればずいぶん変わりますね。

 

本題に戻ります。今回の基調講演はGROOVE X の林さんによる「マネージャー不在の洞窟型組織」でした。最高にかわいくて賢い家族型ロボット「LOVOT」の開発と組織マネジメントを通じて、価値創造はアジャイル開発に帰着したことをアジャイルに必要な航海能力は見通しの悪いところで踏みとどまる能力。それをサポートしてくれるフレームワークがScrumだと考えている」という言い回しで表現されていました。

あと、「フラット組織で失敗しているベンチャーが多すぎて、出資者はフラット組織に懐疑的。なのでウォーターフォール的に出資者には計画や見通しを(変換して)説明する」という現実的なお話も。

他に印象に残ったのは、クリエイティブに製品開発を行うためにフラットな組織作りをするにあたって、

  • (スコープが良く変わるような)新しい製品づくりだと組織の壁がそのまま製品の壁になるように思える
  • 仲良しフラット組織だろが階層が多かろうが、船頭が多すぎるのはだめ
  • フラット型組織だと、262法則の下位2割が減る。上位の2割と中間6割の区別がなくなっていく。そして(カオスなのに)活気がある
  • 「飽きる」をポジティブにとらえる。学びが素早い人は飽きっぽい人が多いので、飽きだした人を組織に縛らない
  • 自由を愛していたと思ってジョインしても、いざマネージャがいないチームに入ると戸惑いを感じるもの。数か月後、水が合わないなと実感した人は辞めていくこともある

のこと。実際にビジネスと開発の垣根のない組織で内製で価値創造にトライされている方の言葉は迫力があり、受託開発を生業とする立場としての率直な感想は「俺の出る幕でないな」。

もちろん、特定の領域ではベンダーの技術やサービスを利用されることもあるでしょうが、ますますそれは、非競争領域でコモディティな分野になり、それはそれで、お仕事としてはありなんでしょうが、エンジニアリングを売り物とする受託開発会社やSIerとしてはいかがなものか?

あるいは、アジャイル時代だろうが今後も残る一括請負のSORメインで品質の高さに鎬を削るのか?

事業会社ではなく受託開発の会社でエンジニアリングに誇りをもって仕事を続けられるのはどのような形なのか?

アジャイル開発が日本に紹介されて15年ぐらいでしょうか。アジャイルな開発(自己組織化されたチーム主導によるビジネスも開発も隔てのないやり方)が今後当たり前になり、やがてアジャイルという言葉も使わなくなった時代が来るとき、受託開発という仕事はどうなっているのか、受託開発屋の一員として、それを想像し、その世界でのありたい姿のビジョンを持ち、それに向けて歩みを進めましょう。

 

Scrum教えながら若手メンバーに伝えたかったこと ~(続)限られた時間でScrumを効果的に教える

前回は、開発経験がほとんどない弊社の若手に、ScrumのことをScrumで教えてみたことについてお話しました。

happyman.hatenablog.jp

今回はその続きです。

見積もり通りに終わるとは限らないこと

前回、見積もりまでは終わらせているので、優先度が高かったグループのカード4つをスプリントバックログに移動させるところからスタートです。

  • スクラムとは何か知りたい → 5P
  • スクラムマスターが具体的に何をする人なのか知りたい → 2P
  • アジャイル開発のスタートってどんな感じか知りたい → 2P
  • スクラムがうまくいってる or いってないサインを知りたい → 1P

すべて時間内に終わらせることができれば、ベロシティは10Pになりますね。

まずはこの中で一番優先度が高かった、「Scrumとは何かしりたい」からスタートです。頭から全部説明しだすと終わらないので、私が一番大事だと考えるポイントに絞って説明しました。

それは、Scrumは経験的プロセスに基づくこと。つまり、検査と適応、フィードバックループの重要性です。ウォーターフォールのように事前にギチギチに定義されたプロセスでは、計画通りにタスクが終わればうまくいくけど、それが実際には容易ではないことは、彼らなりの経験に基づくイメージを持ってもらえたようです。

今回の講習に例えれば、15分単位に何を話すか細かく決めてその通りに進めることもできるだろうけど、事前の計画通りに終わるかはやってみないとわからないし、そもそも、計画通りに説明を聞き終えても、みんなが満足できるかはわからないよね、という話です。

ちなみにこのスプリントでは、ポイントを絞ったとはいえ、Scrumの3つの役割や5つのイベント等について説明をしたりして、90分の時間すべてを費やしてしまいました。最後に「これらの説明で納得できたか?さらに質問はないか?」を確認し、カードをDoneレーンに移動させます。

このカードは5ポイントの見積もりだったので、これが現時点でのベロシティになります。始める前は10Pぐらいいけるかな、と思っていたのですが、実際にはできませんでした。これは実際のプロジェクトでもよくあることです。

ということをみんなにお話して、最初のスプリントは終了です。

ふりかえりと改善が大切なこと

この講義では教える側の私がScrumチームなので、私はひとりで(頭の中で高速に)ふりかえりを行い、時間がかかりすぎてしまってこのペースでは最後まで終わらない状況を、次の手段で改善してみることにしました。

  • カードに書いてもらった内容について追加で質問し、本質に絞って話ができるよう記入意図を再度確認する
  • 無駄口を減らす

まあ、要はペースアップしたいわけなのですが、「あとは本を読んでおいて」という時間短縮よりは効果的だと思います。

で、結果的に、次のスプリントではベロシティが8Pに伸び、時間内にすべて終えられる可能性が高まりました。

f:id:HappymanOkajima:20190619170614j:plain

ホワイトボードのスプリントバックログ

スプリント中には割り込ませないこと

もともと講義は座学だけでなく、実際の現場(アジャイルスタジオ福井で実施されている実プロジェクト)を見てもらいたいと思っていました。タイミングよくこの日はあるプロジェクトのプランニングの日なので、チームのスクラムマスターに相談し、見学にいっても良い時間帯あるなら教えて頂戴とお願いしておきました。

で、ちょうど午前のスプリントを実施している最中にメッセージが届き、13時30分から30分程度なら良いですよ、とのこと。

この段階で「今からASFに見学に行きましょう!」というのは簡単なのですが、そこはScrumなのでそれをせず、「1Fを見学する(ASFは一階にあるのです)」というカードを書いて、「学びたいことバックログ」に追加しつつ、プロダクトバックログには、いつでも誰でも追加できることを改めて説明しました。

見学は、次のスプリントの最初に行いました。狙ったわけではないのですが、スプリントには割り込みを許さないことを体験してもらうことができ結果オーライです。

習っただけではできない。後は自分たちで考えて行動すること

と、このような感じで徐々にベロシティを向上させ、最終的には、元々予定していた時間内に、学びたいことバックログをすべてDoneにすることができました。アジャイルやScurmのことだけでなく、翌週からの自由課題にそれをどうやって活かすと良いのか等、実践的で差し迫った課題にもある程度は応えられたのではないかな、と思います。

しかし、知っていることとできることは全然違います。無茶苦茶悩むんじゃないかな。アジャイルにならない可能性もあるんじゃないかな。チームとしてうまく機能しないことも多いんじゃないかな。ベロシティが上がらず課題が完成しないプレッシャーを感じるんじゃないかな。

苦労はすると思いますが、自分たちで考えていろいろ失敗し、Scrumの本質の一つである、検査と適応、そしてフィードバックの重要性を実感してもらえると良いなぁ。と、思います。

 今回、ScurmをScrumで教えるということを、本格的に試してみました。自分としては、限られた時間の中で、私が伝えたかったポイントを、本人たちが期待する優先度で伝えることができ、良かったんじゃないかなと評価しています。

ただ、本当はどうだったのか、本当に役に立ったのか、彼らチームの活動成果とフィードバックを待ちたいと思います。

 

 

限られた時間でScrumを効果的に教える

ほとんどScrumやアジャイルについて知識がない人たち向けに、限られた時間でどうやって教えると良いかいろいろ試してみたというお話です。

普段、外向けには、「スクラムマスターやプロダクトオーナーの認定取りたい人向けの丸々二日間のコース」をサポートすることが多いのですが、社員に対して教えるときは、「内容を絞って、1日とか半日でお願い」という形になりがちです。

なので、オーダーを受けたときからから相当狙いを絞り込みます。「来週から現場でスクラムマスターをやらなくちゃいけない」という人と「来週からスクラムチームに入る」人と「とりあえず概要を知りたい」という人とでは、フォーカスするポイントはかなり違うでしょう。

今回は「教育期間中の新人2名が自由課題で何か作る。彼らのチームには二年目の先輩も薄く入る。期間は来週から7月末まで。Scrumでやらせたいので基礎を教えてあげてください」というお題でした。

弊社はアジャイル開発を売りにしており、例年の新入社員もそれを理解して志望しているわけですが、だからといってアジャイルな開発をしたことがある人はなく、ほとんどが入社してから経験することになります。

また、そもそも「ソフトウェアをチームで開発すること」自体が未経験な人も多く、「ウォーターフォールとの比較」みたいな話は響きません。なので、Scurm自体の価値をいかにわかってもらえるか、が勝負となります。

「学びたいこと」バックログをつくりながら動機・困りごとを掴む

 彼らには「来週から始まる自由課題をこなしたい」という達成動機があります。もちろん「Scrumで開発すること自体への興味・関心」という内発的な動機も、「上司からScrumでやれと言われたので覚えなくちゃ」という外発的な動機もあるでしょう。

いずれにせよなんらかの動機はあるでしょうから、今回はそれを信じて、「皆さんが学びたいこと書き出してください。それを大事だと考える順番で、それぞれ満足するまで教えますよ」という宣言からスタートしました。はい、講義自体をScrumで進めるスタイルです。 

新人向けScrum研修

 実際彼らが書いてくれた「学びたいこと」バックログアイテムには次のようなものがあがりました。彼らにとっての動機(困りごと)が見える、よいバックログだと思います。

  • スクラムとは何か知りたい
  • スクラムの流れをもっと知りたい
  • スクラムマスターが具体的に何をする人なのか知りたい
  • アジャイル開発のスタートってどんな感じか知りたい
  • スクラムがうまくいってる or いってないサインを知りたい
  • 実際の手ごたえを知りたい
  • どのような開発がアジャイルに向いているのか知りたい
  • チームワークを良くしたい
  • 成長したい
  • 楽しく仕事がしたい
  • より良いものを作りたい
  • (一日二日で身につかないと聞くが)どうすれば身につくか知りたい
  • (来週から始まる)自由課題で実践できるようになりたい
  • アジャイル事業部とITS事業部での違いを知りたい

バックログアイテムがそろったら次は優先度決めですね。彼らと話をしながら、学びたいこと順に並べていきます(本来はすべてに順序を付けるところですが、今回はある程度グループ化して、グループの優先度としました)。

当然、教える側としてはある程度想定したカリキュラムというかテキストは準備しますが、彼らが興味を持たないテーマを一生懸命教えても無駄になるので、彼らの欲するまま教えます(さらに、彼らにも「今回はこのような教え方しますよ。これ自体がScrumですよ」と伝えます)。

実際、アジャイル教育では定番の紙飛行機ワークを準備していったのですが、バックログを整理する段階で、彼らは入社後すぐに全社教育の一環で経験済みであることがわかり、今回はやらないことを決めました。

プランニング・見積もり・受け入れ条件。合意してからスタート

スプリントの長さはあらかじめ決めていませんでしたが、終了時刻が決まっているので、それと、バックログのグループの数から逆算して、90分(80分+10分休憩)スプリントで行こうと決めて、参加者にもその旨説明しました。

この段階でホワイトボードにかんばんを書き、TODOレーンに一番優先度の高いグループのバックログアイテムを移動します。移動する際は、一つ一つカードの内容を読みながら、私が「要望を満たすには、この内容を教えれば良いな」と納得するまで会話します。

例えば、「スクラムとは何か知りたい」と「スクラムの流れをもっと知りたい」の違いは何ですか?とか、「もっと知りたいということは、すでに何か知っているのですか?」とかです。(ちなみにこの例の場合、結果的に「スクラムの流れをもっと知りたい」というアイテムは「スクラムとは何か知りたい」と統合しようとの合意で取り下げられました)。

次は見積もりです。TODOに移動させたあと、それぞれのカードにポイントを書き込みます。リファレンスがあるわけではないので最初の一つ(今回は「スクラムとは何か知りたい」)は「えいや」で5ポイントと決めて、あとはそれに対して相対的にポイント付けをします。

先ほどの、具体的にどんなことを聞きたいか・教えられるかを会話しているので、私も「どんな説明をしようか、どの資料を使おうか」がクリアで、ポイントを使った相対見積もりが可能となります。

最後に「このカードがDoneに移動する条件は、要望を出した皆さんが納得して受け入れた場合ですからね」と説明し、スプリントを開始します。

自分たちがすでにScrumの中にいることに気が付いてもらう

 ここまでの説明を通じ、今日の講義は(今までと違って)次のようなものだと理解してもらえました。

  • 自分が具体的に学びたいことを
  • 自分が大切だと思う順番で
  • それぞれ自分が納得するまで
  • 時間いっぱいまで無駄なく
  • 学ぶことができる

加えて、講義を受ける自分たちがお客様(PO)で、教える岡島がScrumチームに例えらえることも説明し、「Scrumでの開発はこのような形なんだな」ということにも、なんとなく気が付いてもらえたかと思います。

 長くなってきたので、今日はこのあたりで。次回は内容について少し掘り下げられたらと思います。

 

 

受託や開発やリーダー以外の経験で学んだこと ~「DevLOVE関西 #180」

180回目のDevLOVE関西でお話をさせていただきました。2009年からの10年、組織を改善するために何をしてきたのか、自分の経験だけではなく、私たちのチームで取り組んでいる内容も盛り込みました。

当時、私は現場リーダーから部門のリーダーにかわったころで、アジャイル開発での経験で身に着けた現場リーダーの技術を、どうやったら部署レベルで使えるのか、何か課題なのか、いろいろ試行錯誤していました。

その後、さまざまな経験を得て今に至るのですが、特に直近5年の事業開発/PO経験やScrumの実践による気づきは大きかったです。やっとのことで、今の時代に必要とされるチームやリーダーシップが腹に落ちた実感が芽生え、自分の考えや組織としてのビジョンとして整理することができました。

この間、成功ばかりではなく、むしろ失敗の方が多いのですが、組織と自分のビジョンの足並みを都度確認し調整しながら致命的になる前に改善し、お互い少しづつ成長できているのかな、と思います。

www.slideshare.net

ちなみに、10年まえにお話させていただいたのは記念すべき初回だったとのことで、180という数字に重みを感じます。すごく活発なコミュニティで、呼んでいただけて光栄でした。ありがとうございました!

ガチガチのウォーターフォールの若手で起きそうな失敗を体験した話

最近、平日は可能な限り夕食を作るようにしています。「家事は分担すべし!」的な大げさな話ではなくて、私のほうが奥さんよりかなり早く帰れるので、自然にそうしています。

今まではカレーや鍋くらいしか作ったことがなく、何をするにしてもWebのレシピサイトを調べながらです。料理の基本がまったくできてないので、レシピ通りに作るだけで大概はそれなりの味に仕上がり、大変助かります。

ただ、昨日は鶏肉のオイスターソース炒めを作ったのですが、見事に「素人がレシピ通りに作る落とし穴」にはまってしまいました。

レシピには次のように書かれていました(実際は分量などが具体的に書かれています)。

  • 下味用:酒、塩コショウ…
  • 合わせ調味料:水、オイスターソース、酒…
  1. 鶏肉を一口大にカット。下味用の酒、塩コショウを入れて軽くもみこんでおく。
  2. 玉ねぎピーマンは角切りにする。合わせ調味料を先に混ぜあわせておく。
  3. 油で鶏肉を炒める
  4. 鶏肉に火が通ったら野菜を加え軽く炒め、合わせ調味料を回し入れる。

私はこのレシピ通りに手順を進めまして、まず鶏肉をカットして下味をつけます。次に、野菜をカットし合わせ調味料に混ぜあわせて、と。

たぶん、料理の基本ができている方なら、この時点で私の間違いに気が付くかと思います。私はカットした野菜を合わせ調味料と混ざ合わせてしまったんですよね。

鶏肉を炒めて、そのあとに、「合わせ調味料に浸かった野菜」をフライパンに投入することになったのですが、この時点でやっと違和感が。「これって野菜炒めてるんじゃなくて煮てるよなぁ。あと、合わせ調味料を回し入れるって、今更どうするんだ?」

そうです。これって正しくは、「カットした野菜をフライパンに投入し炒め」その後「合わせ調味料を回し入れる」なんですよね。

間違いの原因は、「2.玉ねぎピーマンは角切りにする。合わせ調味料を先に混ぜあわせておく。」という説明を誤解して、「角切りにした野菜と合わせ調味料を混ぜちゃった」ことにあります。

だったら角切りと混ぜ合わせは別のステップで書いてよー。って正直思いましたが、結局おいしく食べられるものになったので別にOKです。

レシピはある意味詳細設計書みたいなもので、手順通りに作れば、誰でも同じようなクオリティで料理が作れるものです。ただ、基本的な知識がない人だと、ちょっとした書きっぷりが誤解を生み、結果全然違うものができちゃうこともあること、身をもって体験したけです。

これってソフトウェア開発でもそうだよなぁ。これぞ伝言ゲームの失敗例です。誤解を生まないためには極めて高い質で設計書を書ききる必要があるうえに、システムは料理より(通常は)複雑でややこしくそもそも書ききれないのでは、と。

アジャイル開発では伝言ゲームではなく対話による共通理解を重視しますし、お互いにフィードバックすることで勘違いを防いだり知識の少なさを補う仕組みがあります。モブプロなんかもそうですね。

オイスターソース炒めも、奥さんと一緒に作ってれば間違いに早めに気が付いたはずです。ただ、私の調理はあまりにも手際が悪くドタバタなので、一緒に料理してくれるレベルに早く到達しないとなぁ。

 

失敗からのフィードバックを徹底しベロシティを100倍にした男

ソフトウェア開発とかScrumの話ではないんですけどね。。

ゴールデンウイークに、月桂冠大倉記念館に行ってきました。酒飲みでなくても知っているあの月桂冠です。

www.gekkeikan.co.jp

中興の祖である大倉恒吉さんはとてつもない改善スピリッツをお持ちで、幼少より現場で仕事を体にしみこませつつ、どうしたら品質の良い酒が造れるかを一生かけて追求されていたそうです。結果、一代で事業規模(石高で表現されていたので生産量でしょうか)は100倍に。

失敗からのフィードバックをは「注意帳」というノートに事細かに記録し、失敗を成功につなげる仕組みを作っていたとのことで、スクラムマスターとして、とても共感できました

説明書きを読む限り、この注意帳は恒吉個人だけでなく、店舗全体で共有されていたと思われます。お店の売り子や職人みんなで集まって読み合わせなどしてたのかしらん、と想像が膨らみます。

実際には、恒吉さんは改善だけで規模100倍を達成したわけではなく、当時では画期的だったガラス瓶詰めのお酒を商品化したり、経理の効率化のために洋式簿記を導入したり、当時では超ハイカラな「月桂冠」を酒の名前にしてブランディングをしたりと、あらゆる方面でイノベーションを起こしていたわけです。

改善とかイノベーションという言葉を気軽に発しがちな仕事してる立場として、すごく刺激受けました。ここまでやらないと、成功はしないんだな、と。 

f:id:HappymanOkajima:20190516124245j:plain

大倉恒吉の失敗帳

ちなみに、月桂冠大倉記念館は伏見稲荷からもほど近く、近くには坂本龍馬で有名な寺田屋旅館があったりして、京都日帰り旅行にはちょうど良い場所でした。400円でお酒の試飲もできたり、おすすめです。