限られた時間でScrumを効果的に教える
ほとんどScrumやアジャイルについて知識がない人たち向けに、限られた時間でどうやって教えると良いかいろいろ試してみたというお話です。
普段、外向けには、「スクラムマスターやプロダクトオーナーの認定取りたい人向けの丸々二日間のコース」をサポートすることが多いのですが、社員に対して教えるときは、「内容を絞って、1日とか半日でお願い」という形になりがちです。
なので、オーダーを受けたときからから相当狙いを絞り込みます。「来週から現場でスクラムマスターをやらなくちゃいけない」という人と「来週からスクラムチームに入る」人と「とりあえず概要を知りたい」という人とでは、フォーカスするポイントはかなり違うでしょう。
今回は「教育期間中の新人2名が自由課題で何か作る。彼らのチームには二年目の先輩も薄く入る。期間は来週から7月末まで。Scrumでやらせたいので基礎を教えてあげてください」というお題でした。
弊社はアジャイル開発を売りにしており、例年の新入社員もそれを理解して志望しているわけですが、だからといってアジャイルな開発をしたことがある人はなく、ほとんどが入社してから経験することになります。
また、そもそも「ソフトウェアをチームで開発すること」自体が未経験な人も多く、「ウォーターフォールとの比較」みたいな話は響きません。なので、Scurm自体の価値をいかにわかってもらえるか、が勝負となります。
「学びたいこと」バックログをつくりながら動機・困りごとを掴む
彼らには「来週から始まる自由課題をこなしたい」という達成動機があります。もちろん「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の実践による気づきは大きかったです。やっとのことで、今の時代に必要とされるチームやリーダーシップが腹に落ちた実感が芽生え、自分の考えや組織としてのビジョンとして整理することができました。
この間、成功ばかりではなく、むしろ失敗の方が多いのですが、組織と自分のビジョンの足並みを都度確認し調整しながら致命的になる前に改善し、お互い少しづつ成長できているのかな、と思います。
ちなみに、10年まえにお話させていただいたのは記念すべき初回だったとのことで、180という数字に重みを感じます。すごく活発なコミュニティで、呼んでいただけて光栄でした。ありがとうございました！
ガチガチのウォーターフォールの若手で起きそうな失敗を体験した話
最近、平日は可能な限り夕食を作るようにしています。「家事は分担すべし！」的な大げさな話ではなくて、私のほうが奥さんよりかなり早く帰れるので、自然にそうしています。
今まではカレーや鍋くらいしか作ったことがなく、何をするにしてもWebのレシピサイトを調べながらです。料理の基本がまったくできてないので、レシピ通りに作るだけで大概はそれなりの味に仕上がり、大変助かります。
ただ、昨日は鶏肉のオイスターソース炒めを作ったのですが、見事に「素人がレシピ通りに作る落とし穴」にはまってしまいました。
レシピには次のように書かれていました（実際は分量などが具体的に書かれています）。
- 下味用：酒、塩コショウ…
- 合わせ調味料：水、オイスターソース、酒…
- 鶏肉を一口大にカット。下味用の酒、塩コショウを入れて軽くもみこんでおく。
- 玉ねぎピーマンは角切りにする。合わせ調味料を先に混ぜあわせておく。
- 油で鶏肉を炒める
- 鶏肉に火が通ったら野菜を加え軽く炒め、合わせ調味料を回し入れる。
私はこのレシピ通りに手順を進めまして、まず鶏肉をカットして下味をつけます。次に、野菜をカットし合わせ調味料に混ぜあわせて、と。
たぶん、料理の基本ができている方なら、この時点で私の間違いに気が付くかと思います。私はカットした野菜を合わせ調味料と混ざ合わせてしまったんですよね。
鶏肉を炒めて、そのあとに、「合わせ調味料に浸かった野菜」をフライパンに投入することになったのですが、この時点でやっと違和感が。「これって野菜炒めてるんじゃなくて煮てるよなぁ。あと、合わせ調味料を回し入れるって、今更どうするんだ？」
そうです。これって正しくは、「カットした野菜をフライパンに投入し炒め」その後「合わせ調味料を回し入れる」なんですよね。
間違いの原因は、「2．玉ねぎピーマンは角切りにする。合わせ調味料を先に混ぜあわせておく。」という説明を誤解して、「角切りにした野菜と合わせ調味料を混ぜちゃった」ことにあります。
だったら角切りと混ぜ合わせは別のステップで書いてよー。って正直思いましたが、結局おいしく食べられるものになったので別にOKです。
レシピはある意味詳細設計書みたいなもので、手順通りに作れば、誰でも同じようなクオリティで料理が作れるものです。ただ、基本的な知識がない人だと、ちょっとした書きっぷりが誤解を生み、結果全然違うものができちゃうこともあること、身をもって体験したけです。
これってソフトウェア開発でもそうだよなぁ。これぞ伝言ゲームの失敗例です。誤解を生まないためには極めて高い質で設計書を書ききる必要があるうえに、システムは料理より（通常は）複雑でややこしくそもそも書ききれないのでは、と。
アジャイル開発では伝言ゲームではなく対話による共通理解を重視しますし、お互いにフィードバックすることで勘違いを防いだり知識の少なさを補う仕組みがあります。モブプロなんかもそうですね。
オイスターソース炒めも、奥さんと一緒に作ってれば間違いに早めに気が付いたはずです。ただ、私の調理はあまりにも手際が悪くドタバタなので、一緒に料理してくれるレベルに早く到達しないとなぁ。
失敗からのフィードバックを徹底しベロシティを100倍にした男
ソフトウェア開発とかScrumの話ではないんですけどね。。
ゴールデンウイークに、月桂冠大倉記念館に行ってきました。酒飲みでなくても知っているあの月桂冠です。
中興の祖である大倉恒吉さんはとてつもない改善スピリッツをお持ちで、幼少より現場で仕事を体にしみこませつつ、どうしたら品質の良い酒が造れるかを一生かけて追求されていたそうです。結果、一代で事業規模（石高で表現されていたので生産量でしょうか）は100倍に。
失敗からのフィードバックをは「注意帳」というノートに事細かに記録し、失敗を成功につなげる仕組みを作っていたとのことで、スクラムマスターとして、とても共感できました
説明書きを読む限り、この注意帳は恒吉個人だけでなく、店舗全体で共有されていたと思われます。お店の売り子や職人みんなで集まって読み合わせなどしてたのかしらん、と想像が膨らみます。
実際には、恒吉さんは改善だけで規模100倍を達成したわけではなく、当時では画期的だったガラス瓶詰めのお酒を商品化したり、経理の効率化のために洋式簿記を導入したり、当時では超ハイカラな「月桂冠」を酒の名前にしてブランディングをしたりと、あらゆる方面でイノベーションを起こしていたわけです。
改善とかイノベーションという言葉を気軽に発しがちな仕事してる立場として、すごく刺激受けました。ここまでやらないと、成功はしないんだな、と。
ちなみに、月桂冠大倉記念館は伏見稲荷からもほど近く、近くには坂本龍馬で有名な寺田屋旅館があったりして、京都日帰り旅行にはちょうど良い場所でした。400円でお酒の試飲もできたり、おすすめです。
自分で気が付くことの難しさに気が付く ～ アスカン2019でお話したこと
少し前の話になりますが、4月24日の「明日の開発カンファレンス2019」で、POやったときの失敗と教訓についてお話をさせていただきました。売り上げは本当に35,400円でした。ROIについては、、スライドに書いてありますので興味ある方は見てみてください。
内容に関しては、なんでこうなっちゃんだろう？ってことを、事実ベースで掘り下げ（追求）してます。自分の記憶ではなく、証拠となる資料を探しました。
プロジェクトだったり事業の区切れだったり、何かあると当然ふりかえりはするんですが、深層心理に気が付かないというか、見てみぬふりをしてしまうことがあるな、ということを直視する必要がありますね。四半世紀も同じ会社で働いているとなおさらです。
プレゼンのスタイルに関しては、「法廷劇」を目指しました。本当は二人でやりたかったんですが、都合よく相方が見つかるわけもなく、今回は初演ということもあり一人芝居です。いつか本来の形でやりたいなぁ、と思ってます。
最後になりますが、アスカンスタッフの皆様、ありがとうございました。
締めのパネルディスカッションにも参加させていただき、有意義で楽しかったです。こだわりのある老舗のお弁当も、成功談の直後に失敗談となるセトリもおいしかったです！
アジャイル時代のリーダーシップ ～ DevLOVE関西
私が受託開発プロジェクトで現場リーダーをしていたころには、アジャイル開発は日本のプロジェクト現場・コミュニティに着実に根付き始めていました。
当時の私は、朝会・かんばん・ふりかえりなど、アジャイル開発の一部のプラクティス（「プロジェクトファシリテーション」と呼ばれます）を実際にプロジェクトに導入し、チームのために有用であると実感していました。
ただ、プロジェクトを成功させるには現場リーダーのリーダーシップと行動がとても大切だと思っていて、会議やトラブル対応などの現実的なシチュエーションで使える、心構えやテクニックをまとめた本を書きました（「プロジェクトを成功させる現場リーダーの技術」絶版）。
あれから十数年経ち、アジャイル開発も当時とは比較にならないほど普通になり、私も「アジャイル」と名のつく開発組織のディレクターになりました。それまでの間、Scrumを中心にアジャイル開発を基礎から学び、様々な実践者の方々の話を聞くにつれ、リーダーシップとチームの在り方について、現場リーダーのころとは違うマインドセットを持てたことを感じています。
5月17日に、10年ぶりに、DevLOVE関西でお話をさせていただくことになりました。当日は、この「アジャイル時代のチームやリーダーシップ」について、いろいろと議論できればと思います（オープン・スペース・テクノロジー形式での対話ありなんです）。 devlove-kansai.doorkeeper.jp
おまけ。2009年の発表スライドです。DevLOVEだけに「愛」をテーマにしてて、何やら重いｗ。当時、私は開発者や現場リーダーではなくマネージャをしてて、いろいろなギャップに思い悩んでいた記憶があります。
総売り上げは35,400円。POとして失敗から学んだこと～「明日の開発カンファレンス2019」
私はScrum研修のトレイナーとして、POについてお話をすることもあるのですが、だからといって自分がPOとして成功するとは限りません。
実際、POとして2017年の夏にローンチしたサービスは、ビジネス的に振るわず、2年足らずのうちにクローズしています。
原因はいろいろと求めることができます。私はこのサービスのPOであると同時に、受託含めた事業全般の責任者でもありました。そのコンフリクト・利益相反があったかもしれません。
また、アジャイルチームの育成の仕方や、そもそものゴール設定に問題があったかもしれません。チームを成長させることは、いつだって簡単ではありません。
ただ事実として残るのは、このサービスの総売上が35,400円であったことです。
ふりかえるのは辛いぐらいの経験なのですが、この貴重な失敗で得た学びを、4月24日（水）に、大田区産業プラザPIO コンベンションホールで開催される「明日の開発カンファレンス2019」で、生生しくお話をさせてもらいます（夕方からのパネルディスカッションにも参加させていただきます）。
「総売り上げ：35,400円 ~ 受託エンジニアが自社サービスのPOをやって学んだこと。」
永和システムマネジメントはソフトウェアの受託開発を生業にしていて、私もその最前線で20年以上やってきました。そんな私が企画し、プロダクトオーナーとして関わった自社Webサービスが、先日ひっそりと終了しました。「ニーズがなかったね」の一言で済ますのではなく、一体何が悪くて、そこから何を学ぶのか？受託から共創にシフトする時代に求められるエンジニアのスキルとマインド、そして組織の形とは？といったことを、プロダクトオーナー・エンジニア双方の視点でお話させていただきます。
↓ ただいま事前登録中です。よろしければお申込みください。
