ガチガチのウォーターフォールの若手で起きそうな失敗を体験した話
最近、平日は可能な限り夕食を作るようにしています。「家事は分担すべし！」的な大げさな話ではなくて、私のほうが奥さんよりかなり早く帰れるので、自然にそうしています。
今まではカレーや鍋くらいしか作ったことがなく、何をするにしても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サービスが、先日ひっそりと終了しました。「ニーズがなかったね」の一言で済ますのではなく、一体何が悪くて、そこから何を学ぶのか？受託から共創にシフトする時代に求められるエンジニアのスキルとマインド、そして組織の形とは？といったことを、プロダクトオーナー・エンジニア双方の視点でお話させていただきます。
↓ ただいま事前登録中です。よろしければお申込みください。
一枚の付箋で肩こりを和らげる
ずっとずっと、肩こりや首筋の強烈なハリに悩まされていたのですが、この度改善が見られたのでご報告です。やったことは、付箋に「歯」と書いて仕事中一番目に付くところに貼っただけ。
2週間ぐらいたちますが、徐々に首筋のハリが緩和され、肩こりも楽になりました。ひどい時は、大好きなブレスオブワイルドも遊べないぐらいだったんですが、この付箋のおかげで、ついにポーチの全開放を実現しました！
…
種明かしというか、実際は、自分が「TCH（Tooth Contact Habit）」を持っているかもしれないという気づきがスタートです。文字通り、歯（の上下）をずっと接触させている癖ですね。癖なのでなかなか気が付けないのですが、たまたま見た以下のサイトのおかげです（実際、知覚過敏にも悩んでました）。
私は、特にPCで作業しているとき、気合を入れるつもりなのかわかんないのですが、口を「ぐっ」と、閉じ続ける癖がありました。 その際当然ながら、上下の歯が触れ、顎の筋肉に余計な力がかかっているんです。もしかすると、ゲームしてるときもそうだったかもしれません。
なので、付箋に「歯」と書いて、それを見たときにに意識的に口元を「ふわっと」緩める癖付けをしました。PCの前じゃないときも、（口は閉じたままで）歯の上下が触らないよう気を付けます。
加えて、顎やこめかみの筋肉の簡単なマッサージ（指の腹でぐりぐり）をたまにやっているうちに、気が付いたらハリや肩こりが緩和されていました。
すべての肩こりの原因がHCTだとは思えませんが、自分もそうかも？という方は、一度試してみてください！
今時の議事録事情
4月1日、永和システムマネジメントにも7名の新入社員が入社しました。みんなフレッシュで良い刺激になりますね。
うちの場合、これからマナーなど共通的な教育があり、その後、配属先に分かれての教育に切り替わっていくわけなんですが、議事録の書き方を教える機会はないようなので、今時の事情を踏まえつつ、大事な点について、あらためて書いてみたくなりました。
ソフトウェアの現場で昔ながらの議事録を書く機会は減っている？
対面コミュニケーションを重視するアジャイル開発が増えているのが理由なのかどうかわかりませんが、少なくともこの5年間、私は「昔ながらの」議事録を書いていませんし、書かせたこともありません。
「昔ながらの議事録」は概ね以下の内容で、昔はWordとかで書いて参加者にメールで回覧してました。内容的には、単なるメモではなく、目的と結論が大切です。
- 日時
- 場所
- 出席者
- 目的
- 結論
- アクション
- 議論の内容
- 次回予定
今はみんなで議事録を書きながらのミーティングが主流？
じゃあ今はどうしてるのと聞かれると、Google Docs などのコラボレーションツールを活用することで共同編集し、打ち合わせが終わった段階では書き終えているスタイルでしょうか。専用のサービスも増えていますね。
私も、（ツールを使ったコラボレーションに慣れている）社内の仕事ではよく使います。複数の部署が絡んでいて主導権が固まってなかったり、要望がふわふわの状態だけどキックオフが始まっちゃうことって、実は結構あるんですけど、そんな場合は次のようなステップで進めています。
- Googleスライドで最低限のアジェンダを3分で書いて即参加者に共有する
- 集まった目的とかゴールをアジェンダを見ながらレビューというか意識合わせし
- 事実関係をヒアリングしながら最新状況として皆でメモしつつ
- 最低限、「今の課題は何で、次までに何をアクションすべきか」までを皆で認識する
- 打ち合わせ終了予定の5分から10分程度前から、口に出して、「皆さん、次のアクション見えましたか？」「今日のゴールに満足ですか？」など、締めに向けたまとめに入っていく。
こうやって、皆の意識を議事にフォーカスしてもらい、目的達成に向けた課題や手順をクリアにしていきます。コラボツールを使ってみんなで編集することで効率化することでタイムボックス守りつつ、「結論出なかったので次回持ち越しね」を断じて避けるのがポイントです。
コラボで効率よくタイムボックス云々って難しくないです？
ここまで読んだ新入社員の人が「理屈はわかったけど、スピード感もった意識合わせとか課題出しとか、難しくないですか？」といいたくなる気持ちはわかります。うん、多分、難しい。それは、議事録とか打ち合わせ以前に、仕事そのものに対する慣れが必要になるからです。
社会人になると、作業ではなく仕事を期待されます。自分の頭で目的を考えたり課題を発見する必要があるし、もちろん、具体的な行動と成果が期待される。
私は、会議という場には、仕事の要素が濃縮されていると思います。なので、まずは「昔ながら議事録」を身に着けて、仕事のスキルアップの一助にしてみてください。質の高い議事録スキルは仕事をするうえで、とても価値があります。
今でも議事録を書く機会はあります。チャンスがあれば議事録係に手を挙げてください。以下の記事が役に立つと思います。
