受託や開発やリーダー以外の経験で学んだこと ~「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円でお酒の試飲もできたり、おすすめです。

自分で気が付くことの難しさに気が付く ~ アスカン2019でお話したこと

少し前の話になりますが、4月24日の「明日の開発カンファレンス2019」で、POやったときの失敗と教訓についてお話をさせていただきました。売り上げは本当に35,400円でした。ROIについては、、スライドに書いてありますので興味ある方は見てみてください。

 

www.slideshare.net

内容に関しては、なんでこうなっちゃんだろう?ってことを、事実ベースで掘り下げ(追求)してます。自分の記憶ではなく、証拠となる資料を探しました。

プロジェクトだったり事業の区切れだったり、何かあると当然ふりかえりはするんですが、深層心理に気が付かないというか、見てみぬふりをしてしまうことがあるな、ということを直視する必要がありますね。四半世紀も同じ会社で働いているとなおさらです。

 プレゼンのスタイルに関しては、「法廷劇」を目指しました。本当は二人でやりたかったんですが、都合よく相方が見つかるわけもなく、今回は初演ということもあり一人芝居です。いつか本来の形でやりたいなぁ、と思ってます。

最後になりますが、アスカンスタッフの皆様、ありがとうございました。

締めのパネルディスカッションにも参加させていただき、有意義で楽しかったです。こだわりのある老舗のお弁当も、成功談の直後に失敗談となるセトリもおいしかったです!

 

アジャイル時代のリーダーシップ ~ DevLOVE関西

私が受託開発プロジェクトで現場リーダーをしていたころには、アジャイル開発は日本のプロジェクト現場・コミュニティに着実に根付き始めていました。

当時の私は、朝会・かんばん・ふりかえりなど、アジャイル開発の一部のプラクティス(「プロジェクトファシリテーション」と呼ばれます)を実際にプロジェクトに導入し、チームのために有用であると実感していました。

ただ、プロジェクトを成功させるには現場リーダーのリーダーシップと行動がとても大切だと思っていて、会議やトラブル対応などの現実的なシチュエーションで使える、心構えやテクニックをまとめた本を書きました(「プロジェクトを成功させる現場リーダーの技術」絶版)。

あれから十数年経ち、アジャイル開発も当時とは比較にならないほど普通になり、私も「アジャイル」と名のつく開発組織のディレクターになりました。それまでの間、Scrumを中心にアジャイル開発を基礎から学び、様々な実践者の方々の話を聞くにつれ、リーダーシップとチームの在り方について、現場リーダーのころとは違うマインドセットを持てたことを感じています。

5月17日に、10年ぶりに、DevLOVE関西でお話をさせていただくことになりました。当日は、この「アジャイル時代のチームやリーダーシップ」について、いろいろと議論できればと思います(オープン・スペース・テクノロジー形式での対話ありなんです)。 devlove-kansai.doorkeeper.jp

 

おまけ。2009年の発表スライドです。DevLOVEだけに「愛」をテーマにしてて、何やら重いw。当時、私は開発者や現場リーダーではなくマネージャをしてて、いろいろなギャップに思い悩んでいた記憶があります。

www.slideshare.net

総売り上げは35,400円。POとして失敗から学んだこと~「明日の開発カンファレンス2019」

私はScrum研修のトレイナーとして、POについてお話をすることもあるのですが、だからといって自分がPOとして成功するとは限りません。

実際、POとして2017年の夏にローンチしたサービスは、ビジネス的に振るわず、2年足らずのうちにクローズしています。

原因はいろいろと求めることができます。私はこのサービスのPOであると同時に、受託含めた事業全般の責任者でもありました。そのコンフリクト・利益相反があったかもしれません。

また、アジャイルチームの育成の仕方や、そもそものゴール設定に問題があったかもしれません。チームを成長させることは、いつだって簡単ではありません。

ただ事実として残るのは、このサービスの総売上が35,400円であったことです。

ふりかえるのは辛いぐらいの経験なのですが、この貴重な失敗で得た学びを、4月24日(水)に、大田区産業プラザPIO コンベンションホールで開催される「明日の開発カンファレンス2019」で、生生しくお話をさせてもらいます(夕方からのパネルディスカッションにも参加させていただきます)。

 

「総売り上げ:35,400円 ~ 受託エンジニアが自社サービスのPOをやって学んだこと。」

永和システムマネジメントはソフトウェアの受託開発を生業にしていて、私もその最前線で20年以上やってきました。そんな私が企画し、プロダクトオーナーとして関わった自社Webサービスが、先日ひっそりと終了しました。「ニーズがなかったね」の一言で済ますのではなく、一体何が悪くて、そこから何を学ぶのか?受託から共創にシフトする時代に求められるエンジニアのスキルとマインド、そして組織の形とは?といったことを、プロダクトオーナー・エンジニア双方の視点でお話させていただきます。

 

↓ ただいま事前登録中です。よろしければお申込みください。

asucon.alleyoop.jp

 

一枚の付箋で肩こりを和らげる

f:id:HappymanOkajima:20190404114102j:plain

勤務先のディスプレイ

ずっとずっと、肩こりや首筋の強烈なハリに悩まされていたのですが、この度改善が見られたのでご報告です。やったことは、付箋に「歯」と書いて仕事中一番目に付くところに貼っただけ。

2週間ぐらいたちますが、徐々に首筋のハリが緩和され、肩こりも楽になりました。ひどい時は、大好きなブレスオブワイルドも遊べないぐらいだったんですが、この付箋のおかげで、ついにポーチの全開放を実現しました!

種明かしというか、実際は、自分が「TCH(Tooth Contact Habit)」を持っているかもしれないという気づきがスタートです。文字通り、歯(の上下)をずっと接触させている癖ですね。癖なのでなかなか気が付けないのですが、たまたま見た以下のサイトのおかげです(実際、知覚過敏にも悩んでました)。

www.hhk.jp

私は、特にPCで作業しているとき、気合を入れるつもりなのかわかんないのですが、口を「ぐっ」と、閉じ続ける癖がありました。 その際当然ながら、上下の歯が触れ、顎の筋肉に余計な力がかかっているんです。もしかすると、ゲームしてるときもそうだったかもしれません。

なので、付箋に「歯」と書いて、それを見たときにに意識的に口元を「ふわっと」緩める癖付けをしました。PCの前じゃないときも、(口は閉じたままで)歯の上下が触らないよう気を付けます。

加えて、顎やこめかみの筋肉の簡単なマッサージ(指の腹でぐりぐり)をたまにやっているうちに、気が付いたらハリや肩こりが緩和されていました。

すべての肩こりの原因がHCTだとは思えませんが、自分もそうかも?という方は、一度試してみてください!