米Target社の受入型集合研修(Dojo)でのモブプログラミングとDevOps

DevOpsDays Tokyo で来日してくれた、米Target社の  Michael Migliacio さんの記事を訳しました。衣料品小売の会社で、DevOpsやモブプログラミングを実践できるチームを作るための研修のお話です。

tech.target.com

 

一緒にレベルアップしよう - 多様な経験を持つ人々のチーム

Posted by Kin Wong & Michael Migliacio
Apr 15, 2019

人々の成長を促すために、みんなの経験をどうやったら楽しく共有しあえるのか? … 私たちがエンジニアリングリーダーとしていつも直面している課題です。それには献身的で規律正しくある必要があり、最も大事なのはコミュニケーションです。チームメンバーのあいだで継続してコミュニケーションと対話が行われるよう促すことは、必ずしも簡単なことではありません。うまいやり方を探すのは、多くのみなさんが思う以上に大変な道のりなのです。

“小打も積もれば大木を倒す” Little strokes fell great oaks. - 日本のことわざ (訳注: 少しづつの努力を続ければいずれ大きなことが起こせるという意味)

道場の門を叩く

さまざまなチームの人たちが、Target(訳注: 筆者たち)の没入型学習環境(訳注:受入型研修施設)である道場(Dojo)にやってきて、さまざまな理由で助けを求めます。例えば、製品のプロトタイプ作成、アジャイルの習得、DevOpsのベストプラクティスの実践などです。ビジネスニーズを解決するために集められた、できたてのチームが訪れることもあります。最近訪れたチームはその典型でした。API型のWebアプリによって、コントロールルームの在庫を迅速・正確に管理できるようにするために、店舗ホスティングの経験の豊かな人たちが集められていました。このアプリはゼロからの新規開発で、弊社のCI / CDパイプラインを通じてデプロイされます。チームはスクリプト作成とDBクエリーの経験は持っていましたが、RESTfulの概念とCI / CDは多くのメンバーにとって馴染みがなく、オンボーディング(全員を参加させる)には膨大な時間を投資する必要がありました。

一緒に変わる

最初のステップは、技術知識の基盤を確立することでした。午前中、チームは講義に参加して教室スタイルで概念の紹介をうけます。午後に入ると、午前中に教わった概念を強化するように設計されたワークショップや実地体験をおこないます。このアプローチはチームが前に進むのを助け、コラボレーションを促進する環境を作り出すのに役立ちました。ソースコード管理、基本的なPythonスクリプト作成、RESTfulサービスの使用などのケーススタディを含む、様々な形式のアクティビティがあり、すべてチームとしてやり遂げるよう設計されています。ほんの数日間のハンズオン活動によるコラボレーションによって、チームの真の生産性が解き放たれました。「モブプログラミング」を通じて。

モビングで心を一つにする

f:id:wayaguchi:20190516121442p:plain

モブプログラミングはソフトウェア開発のアプローチの一つで、チームが1つのモニター、1つのコンピューター、および1つのキーボードを介して同時に成果物に取り組みます。各チームメンバーには、数分間キーボードを担当する「ドライバー」役が回ってきます。時間はタイマーで測り、時間になったら交代です。キーボードにさわらない人も開発に積極的に参加し、技術的なハードルを乗り越えたり、解決策を調べたり、概念を説明したりしてドライバーを助けます。 モビング(Mobbing)はチーム全体の活動です。お互いが黙ってスクリーンにコードを書いていくのを眺めあう活動ではありません。

タイマーを忠実に守って行うことは本当に大切なことで、規律のないモビングだと、「キーボードを奪い合う」チームや、キーボードで積極的にタイプせず「絶ってしまう」チーム、取り組んでいることをコロコロ変えるチームになってしまうことがよくあります。Dojoでは、チームメンバー全員の参加を繰り返し促していくことや、Mobsterタイマーを使うことで、こうした問題を軽減します。Mobsterはオープンソースのツールで、参加者全員に順番を回したり、交代の時間になったら画面にちょっとしたメッセージを表示することで、確実に交代していくことを助け、「チームとしてソフトウェアを作る」ことに全員が集中し続けられるようにします。

このチームにとってモブプログラミングの利点は計り知れませんでした。モビングによって、各チームメンバーはグループと知識を共有できたのです。また、コードの作成、リファクタリング、およびテスト中にチームメンバーがアイデアを生み出す頻度が高まりました。モビングの各セッションを通して、生産的な会話が自然と頻繁に起こりました。

テスティング

今日のビジネス環境では、チームがビジネスの敏捷性と迅速にソフトウェアを展開するための器用さを備えていることは、関係を保つ上で不可欠です。ソフトウェアの変更やアップデートへの需要が高まっているため、CI / CDパイプラインの中で自動的にテストを行うことが不可欠です。この問題に対応するために、店舗ホスティングチームは、APIを作成する際にスペック駆動型開発(spec-driven development)を用いました。別の表現をすれば、Swaggerで定義されるAPI仕様は、どんなコードが書かれるより前に完成していました。このアプローチはチームにとって非常に役立ちました。チームは作業開始時点で各エンドポイントのデザインを詳細に理解することができるようになったからです。 Swaggerによってもたらされる互換性問題を解決するオープンソースPythonテストライブラリpytestと組み合わせることで、チームはAPIエンドポイントの開発と並行して、ユニットテストと統合テストの堅牢なライブラリを構築することができました。

f:id:wayaguchi:20190516121643p:plain

Pytestにより、このチームは堅牢なテストライブラリを構築し、それらをDroneのCI / CDパイプラインに統合することができました。何か新しいコードがマスターブランチにチェックインされると、Droneのジョブが起動され、、アプリケーションを構築し、Dockerコンテナにデプロイし、テストスイートを人手の介入なしに実行します。チームはテストとCI / CDを組み合わせて行うことで、開発プロセスを通して日々発生するエラーをキャッチできるテストインフラを獲得し、それによって自分たちがやりたい実験ができる自信を得ました。

結果

店舗ホスティングチームはすぐモビングできるようになり、研修中に醸成された信頼関係を大事にするようになりました。チームは一種の「集団意識」で活動するようになり、各メンバーはリズムを崩さずに交代できるようになりました。さらに、考えたことや意図は効果的に伝達され、キーボード操作の引き継ぎがあっても作業を続けるすことができます。モビングによって、チームが一緒に失敗し、一緒に学び、そして一緒にミスを修正することが可能になりました。チームはたった数週間のうちに、FlaskによるAPI開発、CI / CD、Python、PytestによるTDD、自動化、機密情報管理まで、幅広く取り組めるまでになったのです。

店舗ホスティングチームによって提供されたMVP(最低限の実行可能な製品)は期待を超え、新しいチームはソフトウェアエンジニアリングの概念を学び、さらに大事な、大きな相互信頼を獲得しました。

 

- - -

Kin WongとMichael Migliacioは、Targetでソフトウェアエンジニアリングチームをより良くすることに焦点を当てているシニアエンジニア/ Dojoコーチです。

 

(翻訳はここまでです)

本記事の翻訳には様々な方のレビューをいただきまして、特に松元健さん、新井剛さん、荒井裕貴さん、木村卓央さんからは修正提案を頂き、マージしております。ありがとうございました。他にもご指摘がございましたら、ご連絡いただければ幸いです。

 

 

モブプロの聖地 Hunter Industriees で学んだこと 〜 複数モブ編

日本は長かったゴールデンウィークが開けるということで、戻って働けるのかしらという話が飛び交ってますが、いかがお過ごしでしょうか。引き続き Hunter Industriees にいまして、学んだことをメモしておこう、というエントリです。前回のエントリは単体のモブプロについて気がついたことが中心でしたが、今日は複数モブについてです。 

f:id:wayaguchi:20190501053212j:plain

Hunterで学んだことその8: 仕事領域 = モブ != 人

3つのモブを持つプロダクトに参加していているのですが、それぞれのモブは同じコードベースで、別の仕事をしています。モブごとに紙ベースのタスクボードをホワイトボードに作っていて、WIPは1に制限されてます。

これは私がソフトウェアを作る人生の中でも初めて体験したのですが、モブは作業場所なだけでなく、どの部分をいじっているか、も示します。フィーチャーブランチを切らず、トランクベースで開発しているので、同じところをいじるとマージが発生しますが、声をかけて避けているようでした。目の前で衝突とマージは起こっていません。作業が終わったらコミットして、 git push / pull / テスト で同期します。

Hunterで学んだことその9: ウィンドウはそのまま!

モブごとに2枚のディスプレイを使っているのですが、ウィンドウの配置はそのままにします。前の作業で開いたウィンドウはそのまま。IDE、シェル、ブラウザ、クラウドの管理コンソールのウインドウは基本すべてそのまま置いときます。シェルのヒストリに必要なものは全部残ってますので、思い出したり調べたりするのが楽です。ローカルで起動した開発用のサービスなどもそのまま使い続けます。ということなので、初めて参加する人がいても、環境構築タスクはありません。

ウインドウ構成の基本は、右画面がコードで、左画面がUI(ブラウザ)でした。テストを書くときは、左右にそれぞれコードとテスト。SQLスキーマやデータを調べるときは、左画面がDBで右がコード。ログを見るときも左画面に出すことが多かったです。

デプロイはもちろん自動化しているので、ローカルでの確認から、デプロイまでは一貫しています。本番リリースもモブで決めているようです。

ということなので、初めて参加する人がいても、環境構築タスクはありません。

Hunterで学んだことその10: モブでメールを出し、モブでメールを受ける

モブごとにメールアドレスが付与されているので、モブからメールを出し、モブで受ける感じです。「メール本文にモブの参加者名を書いておく」という慣習のようでした。

ハードウェアが絡む開発の場合、ハード内蔵ファームウェアの開発者との連絡が必要になります。Hunterではハードウェアの担当や、運用監視の担当は別のオフィスにいるのですが、適宜電話やチャット、メールで連絡を取ります。連携するハードウェアの実機も置いてあるので、常に確認しながら進み、何かあれば運用担当にログを解析してもらったり、ハードウェアの担当にファームウェアの仕様を確認してもらったり。「都合のいいとき電話して」といっておいて、モブはいつでも電話に出る、というようなこともやっていました。あと、近くのオフィスの人はたまに歩いてモブまで来てました。

Hunterで学んだことその11: やり方はモブ次第、モブをまたいだ問題解決も

3つのモブがあるのですが、びっくりしたのはやり方がバラバラなことでした。スキルも、タイマーの時間もバラバラ。モブで決めて、実験する。変えたほうがよければ変える。テストファーストで進めるかどうかもモブ次第でした。ローカルに置くテスト用のサーバの起動の仕方すらまちまちなのがすごいなと思いました。正解を決める判事も、取り締まる警官もいないので、正義を争う宗教論争にもならないのだろうなと思います。

ある時、隣のプロダクトから「ちょっとこれから一人参加してくれない?SQL query についてのセカンドオピニオン欲しいんだけど」と相談があって、一人手を挙げてさっと動いていきました。

Hunterで学んだことその12: このPCしばらく使えないから、あっちのモブに行こう

ちょうど大きめのWindows Update がありまして、モブ用のPCにアップデートを当てるためにしばらく使えない、ということになりました。他にもちょっと不調があったみたいで、しばらくだめだぞと。そこで10分もかからずに「あっちのモブで作業しよう」ということになりました。幸いカンファレンスで人がいないので、隣のモブスペースはあいてます。

移動して、さて前の仕事をそのまま継続するのかと思ったら、なんと移動先のモブのやりかけの仕事をはじめました。一人は隣のモブをやってた人だったので、内容はわかるのですが、さっきの続きじゃないのかーい。

「仕事領域 = モブ != 人」なので、考えてみれば、そのままの環境で作業を進めるほうがよいのですが、驚きました。

Hunterで学んだことその13: 休憩はいつでも

休憩はいつでも取ります。ちょっと抜けるわー、って言って電話に出たり、おやつを買いに行ったり。残っている人でモブは進みます。コードがよくわかっている主力の二人が抜けたときにも、そのまま続きをトライしていました。進みは悪いかもしれないけど、ちゃんと自分で考えて進めてみる。少なくとも学習は進むのだろうなと思いました。

ちょうど16時になったときに数人帰って、主力の二人が残ったのですが、グリーンの状態で15分くらいリファクタリングしてました。それもまた見てて勉強になりました。

Hunterで学んだことその14: カンファレンスで人が半分いないときも進む

ちょうどカンファレンスが重なって、半分くらいモブからいなかったのですが、残った人でバグフィックスやPOからの優先の要望を着々と進めてました。

Hunter の場合は、見積もりもしないし、事前にビジネス側に進捗の約束を行わないので、ベロシティが落ちるとか、スケジュールに間に合わない、と焦ることはあまりないようです。逆に、人がいないから、上司がいないから、ということで進めないこともないようです。

・・・という状態で大丈夫にするために、経営陣との間で様々な調整をしてきた結果だと思いますので、他の組織で簡単に真似できるものでもないのでしょうけれど、信頼貯金を貯め、ソフトウェアについて理解のある経営陣であれば、できるのかもしれません。

Hunterで学んだことその15: 金曜夜にコミットしない

これは海外の企業でよく聞くパターンですが、やはり金曜の夕方に慌ててコミットやデプロイはしません。コミットはすることがあると思いますけど、テストが通っている事が前提で、慌てません。「また月曜朝に考えよう」で作業終了してました。

Hunterでは、金曜14時から「Learning Time」になっていて、作業を中断してそれぞれの学習に時間を使います。AWSのe-Learningをやったり、言語を勉強したり、組織に関する本を読んだり、ということをしているようでした。

Hunterで学んだことその16: モブ解散後は自由時間

毎日だいたい16時にモブは解散になりますが、さっさと帰る人もいれば、個人ブースでメールを読んだり、勉強したり、様々に時間を使っているようでした。

16時に外に出てみると、まあ明るい。夏時間ということもあり。こんなに早く帰っていいのかな、と思いながらスーパーで惣菜買って帰る毎日でした。

だいたいメモしたことは書きました

だいたいメモは以上なのですが、まだ数日いるので、また気がついたことがあれば書くかもしれません。あと、写真をいろいろ撮ったのですが、これはそのうちまとめて許可もらって貼るつもりでいます。

下は、雨がふって出てきたカタツムリ。珍しいそうです。

f:id:wayaguchi:20190430035130j:plain

 

 前回のエントリはこちらです。あわせてどうぞ。

kawaguti.hateblo.jp

 

モブプロの聖地 Hunter Industries で学んだこと

日本方面は、平成最後とか、令和こんにちわ、連休ながーい、という噂を聞いておりますが、私はなぜか米国に来ていて、フィーバーに参加できておりません。アベンジャーズは一応、公開日に観に行きました。字幕ないし、アメリカンジョーク(推測)とかは聞き取れなかったんだけど、そんなのどうでもいい感じの映像美でしたね。

Hunter Industries にお邪魔してます

モブプログラミング・ムーブメントを生み出した、Hunter Industries に来てます。2年前に半日だけお邪魔したんですけど、モブ自体には参加してなくて、もうちょっといろいろわかりたいな、と思いまして。1月にRegional Scrum Gathering で来日してくれた、Director のクリスさんにお願いしてみたら、いいよーってことだったので、お邪魔しに来ました。

f:id:wayaguchi:20190503120445j:image

ビザの関係で生産活動には従事できないのだけど、横で立ってるのもなんなので、モブには参加させていただいています。ただ、たまに回ってくる私の番でやっていることといえば、「alt-tab押して」「もうちょっと上にスクロールして」「xxxって打って」っていう指示をもらってちょこちょこ動かす程度だったり、他の人同士で議論してたりとかしてて、なんか申し訳ない限りです。いることによって生産性は押し下げていることは間違いないです。

f:id:wayaguchi:20190427014919j:plain

Hunterで学んだことその1: 帰るの早くて、体調良さそうで、機嫌もいい

だいたい16時にモブは終わり。多くの人は「またあしたー」ってサーッと帰っちゃいます。それもそのはず、始業は8時。8:30くらいにはモブが始まって12:00-13:00のランチを挟んで、休憩入れつつモブし続けます。

全体的に日本の職場に比べると余裕を持って仕事してる感じはあります。サボってるわけじゃないんだけど。代わりに、体調悪そうな人が職場にいません。機嫌も悪くない。変わった人はいますけど、機嫌はいいです。

そういえば、変わった人が機嫌悪いと怖いですよね。自戒を込めて。

Hunterで学んだことその2: モブの集中度合い

ペアプロやモブプロは集中するから効率がいい、というような説明をすることがあるんですけど、実際Hunterではどうなのか気になりますよね。

モブは大きな二枚のスクリーンの前で仕事するんですけど、感覚的には、SFで出てくる戦艦の司令室みたいな感じです。ドライバーがオペレータで、周りの人が状況確認しながら意思決定していく。

作業中、ずっと話してるのが印象的です。朝会の時だけ集まって話して、あとは自席で静かに作業する日本のありがちな現場とは対局です。たまに歓声あがってます。いいやり方見つかったんでしょうね。

予定があれば、いつ抜けても大丈夫です。30分くらいで大体ふりかえりや休憩を入れるので、そのタイミングで抜けるケースが多いようです。

Hunterで学んだことその3: 調査と打ち合わせとテストとコミット

コード書くだけじゃなくて、いろいろなことをモブでやります。

  • テスト (BDD)、デプロイ
  • アラートの調査
  • Webでライブラリや書き方を調べる
  • コミット、git pull/push (モブ間で同期)
  • ミーティング (電話会議)
  • メールを読む (POから、問い合わせ、人事異動)

これらすべてを分担しないで、モブでやっていきます。常に情報が共有され、アップデートされるわけです。 

Hunterで学んだことその4: 慎重なコーディング

割とコード書くこと自体に慎重だと思いました。「こうしようと思うけどどう?」「いいね」という合意があって初めてコードを入力します。動作は最低限。ガーッといじることがないので、操作ミスがほとんど起こりません。

Webで調べた時にも、他のファイル見た時にも、コピペはそれほど多くないです。今時はIDEの力でミススペルは見つけてくれるからっていうのはあるかも。とにかく打ってコード補完を使う印象です。もちろんマジックナンバーとかはコピペですけど。

コミットのコメントも、ナビゲーターが言うことをドライバーが入力していきます。他のナビゲーターが「いいね」と言ったり、アイデアを足したり。

ペアではなくモブなので、3人以上を想像するかもしれませんが、最小の実施人数は2名です。4-5人の時もありますが、6人になった時は、しばらく後にみんなで相談して割ってました。

Hunterで学んだことその5: 「いいね」ってちゃんと言う

そこで、見逃しがちなポイントが「いいね」の表明です。ちゃんと他の人が言ったことに、同意するのかどうかを表明するのが大事っぽいです。だいぶ相手をしてくれているAndyの口癖は「Cool」です。

同意を表明することで、モブは前に進んでいくみたいです。

Hunterで学んだことその6: 立ち止まることを恐れない

モブの作業は進んでいくのですが、わからないところが出てくると、ちゃんと立ち止まって議論します。イラついたり焦ったりして適当に前に進むことがありません。

じゃあ今日の仕事が終わらなければどうするのか?Hunterでは見積もりをしません(No Estimation)。いつまでになにをやらなければいけないという約束もしません。

実はこれは昔 Woody Zuill がIT部門の長を引き受ける時にCEOに出した条件です。その結果、得られたものはちゃんと人の目が行き届いていて、バグの少ないないコード、そして、不具合の報告があればすぐに取り組むチーム、と言えるかもしれません。

私が参加したことや、カンファレンス参加者が多かったりして、スピードが下がるところもあるのですが、「そんな日もあるさ」と言ってました。事実としてそうなんですけど、日本の会社だとあんま言ったら怒られそう。 

Hunterで学んだことその7: BDDのコードカバレッジリファクタリング重視

BDDでの自動テストを重視しています。Specification by Example といって、仕様を想定ケースのテストコードとして書き出すのですが、それをやり続けます。「どんなテストを書くべき?」と言う議論もよく行われます。

コードカバレッジも一応見ています。ラインカバレッジや分岐のカバレッジに目標値はなく、テスト時に必ずカバレッズがチェックされて画面に表示されるので、それを見て、ふーんという感じ。機能 = ストーリーカードあたりに数個のテストは必ず書いているようです。

「どういうテストを書くべきかな?」「うーん、この機能だと...とかはどう?」「いいね。どこに入れるかな」「xxxってファイルあたりじゃないかな」「名前はどうしようか」「xxxxとか?」「うーん、xxxxとか」「それいいね」みたいな議論をよくしていました。

テストを先に書くかどうかはモブによって違うみたいです。モブ間の差異どうしてるかの話はまた書きますね。

Hunterで学んだことその8: ゼロバグリリース

テスト上で既知のバグ = Greenになっていないテストをゼロの状態でリリースします。Zero Bugs ないし Zarro Boogs というプラクティスです。ソースコード管理ソフトウェアにpushする際のフックスクリプトにもテスト実行が入っていて、チェックします。

コミットログもモブで編集して、コミット内容も2人以上で確認して、コミットします。トランクベースで直接最新の本線にコミットするときもあるし、試行的にやる時にはブランチを切ったりもしてました。

7年ほど前の最初のモブチームでは1年半バグが出なくて、その結果、人数を拡張してみることになったそうです。目の前の機能やコードを全員で見て進め、設計も見直します。設計の見直しといっても、UML図を眺めながら唸るなんてことはほとんどなくて、コードを見ながらよりよい名前をつけ、メソッドをくくり出したりするリファクタリングが中心です。すべてが一歩一歩。粗製乱造されて行数だけが多いコードとは対極にある感じはします。専従のQA担当はいません。

 

つづきます

いかがでしょうか。すでにモブプログラミングやBDDをやられてる方からすると、普通に想像できる事が多いのかなと思います。

今回書いているのは「モブプログラミング」という手法の話ではなく、現在の Hunter Industries で行われているプラクティスを、私の目で観察したところです。あと、日本語で書いている都合上、スタッフの人達に読んでもらうこともできないので、ちゃんと訳して確認してみるとちょっと違うよ、というところはあるかもしれません。にしても、何かしらみなさんのご参考になれば幸いです。

複数モブのすすめ方とかは、また数日中に書きますね。(追記: 書きました。)

kawaguti.hateblo.jp

旅行の余談 : リゾート気分

モブについてはいったんここまでにします。ここからはちょっと旅行の話を。

最寄りの大きな空港はサンディエゴなので、初日はサンディエゴに一泊して、海リゾート気分でした。

f:id:wayaguchi:20190425093920j:plainf:id:wayaguchi:20190425111101j:plain
f:id:wayaguchi:20190425111050j:plainf:id:wayaguchi:20190425114332j:plain

翌日からは丘の上のAirBnBで山リゾート気分です。

f:id:wayaguchi:20190426054552j:plainf:id:wayaguchi:20190426113041j:plain

今日は駐車場で同僚の車に少しぶつけてしまって、レンタカー会社の指示で地元警察のチェックを受けるなど、新しい体験をしました。従業員の皆様におかれてはまったくもって邪魔でしかない状況ですが、私は元気です。ぶつけた相手の車の持ち主は初日のモブ仲間のScottで、終始笑顔で保険会社や警察と連絡とってくれて、ナイスガイでした。Hertzのレンタカーだとハワイに24時間対応の日本語デスクがあって助かりました。安心大事。


ではまた。

プロダクトオーナーは常に血液を送る心臓のような働き

Jim Coplien さんの認定スクラム研修シリーズが終わりました。つぎはまた6月に来るそうです。あとScrum Book (スクラムパターンの本) もいよいよカウントダウンで、もうすぐ出るみたいですよ!

f:id:wayaguchi:20190328163339j:plain

プロダクトオーナーの研修を手伝いながら、多く受けた質問が「プロダクトオーナーって大変すぎませんか?」でした。いやぁ、間違いなく大変ですよね。

皆さんのお話を聞きながら、プロダクトオーナーの立ち位置について、ハッと気づいたことがありました。

 

サッカーのフォーメーションにたとえて考えてみる

サッカーというのは11人の味方プレイヤーが協力して、ボールを相手チームの奥にあるゴールに入れると得点、というゲームです。手を使うことが禁じられているので、ボールを誰かが確実に保持するということが出来ず、足元にボールをキープしたり、他の人に蹴ってパスしながら、相手チームの11人の隙をついてボールを運んでいく必要があります。相手ゴールに近いエリアを担当して、攻撃を担うフォワード、自陣に近いところで守備すなわち相手がキープするのボールを奪ったり、前に進むのを防ぐディフェンスという大まかな分担があります。絵に描くとこんな感じ。

f:id:wayaguchi:20190330184446j:plain

上が相手のゴールで、そこに近い人がフォワード、下側にいるのがディフェンスです。(絵では省略してますが、相手チームも同じ人数が上下反対の構成でいます。)

 

作る人と売る人の分業の世界

ソフトウェア開発ビジネスは、長らくメディアを買ってもらったり、作る行為そのものをあらかじめ買い上げてもらう、事前支払いのモデルがほとんどでした。作る人が作ったものを売る人が売ってくるか、またはあらかじめ作る人の時間を売る人が売ってくることで、売上が立つことになります。サッカーのフォーメーションだとこんな感じ。

f:id:wayaguchi:20190330184449j:plain

今も、こう考えている人が多いんじゃないかと思います。営業部隊を「フロント」と言ったりすることがありますね。顧客に商材を説明して、契約を取ってくるのが、フロントの大事な仕事です。

そして、売りものを作るのが作る人の仕事です。ちゃんと売れるものをちゃんと作る。売れそうなものを考え、予算を取り、人を集め、ものを作って、流通に乗せて届ける。

 

デリバリーの大きな変化

ソフトウェア開発は新しい分野ですが、多くの変化を経験してきました。パソコン、インターネット、クラウドスマホ、データサイエンス、機械学習 ...。作り方も届け方もお金のもらい方も変化してきます。

パソコン(やワークステーション)の普及によって、開発現場は大きく様変わりしました。といってもその前を知らないのですが、少なくともパソコン普及以前はすべての人が汎用的なコンピュータを使うということはなかったはずです。作るのも変えるのも、一部の人しかできなかったのではないかと想像します。しかしパソコンやUnixワークステーションは、作る装置も使う装置も同じという特徴がありました。農地や工場に行かなくても、誰でも作る側に回れるのです!なので誰かにお願いして作って貰う必要が本質的にはありません。同じ部屋の中で、欲しいものを作れます。しかも外から買ってくることもできるし、買ったものと作ったものを組み合わせて使うこともできます。

そこで、分業をなくしてチームで作ろう、というのがアジャイルスクラムの考え方です。あなたは営業、あなたはデザイナー、あなたはプログラマー、あなたはマネージャー、と決めたとしても、目の前のパソコンはケチらない限り共通です。

 

スクラムのプロダクトオーナーと開発チーム

以下の絵はスクラムのプロダクトオーナーと開発チームの関係について書いたものです。プロダクトオーナーはビジョンや情報に基づき、プロダクトバックログを開発チームに提示できるように頑張ります。開発チームはプロダクトバックログの優先順位に従ってデリバリーできるように頑張ります。

f:id:wayaguchi:20190330184453j:plain

プロダクトオーナーは開発チームにバックログアイテムを提供し続ける

先ほどのサッカーの絵と並べたら、面白いことに気がつきました。f:id:wayaguchi:20190330184457j:plain

先ほどの図とは逆で、ゴールに近い上側、価値を届けるフォワードが開発チーム、下側でネタを提供するのがプロダクトオーナー、に見えてきました。

 

常に血液を送る心臓のような働き

特に現在はサブスクリプションモデルが多くなってきています。企業は使う前に契約でお金を取るより、使っただけ支払って貰う方式に変わってきました。ユーザーはいつでも契約を終了することができます。

継続的に使い続けてもらわないと、収入が発生しないのがサブスクリプションモデルです。顧客を引きつけるために、常に革新的なアップデートを提供し続ける必要があるのです。

f:id:wayaguchi:20190330184504j:plain

プロダクトオーナーは、そのために開発チームに常にプロダクトバックログアイテムを提供し続けないと生きていけません。そうしないと、開発チームは価値のある機能を迅速に届け続けることができないのです。脳や手足に常に血液を送り続ける心臓のように、ずっと動かないといけないのかもしれません。

f:id:wayaguchi:20190330184507j:plain

プロダクトオーナーとしては、いいボール供給してガンガン得点してもらえるといいですね。

f:id:wayaguchi:20190330184421p:plain

 

 

Fun! Done! Learn!とスクラムとXP

沖縄でみんなでつくった Fun! Done! Learn! が広がりをみせていて、作った人の一人としてとても嬉しいです。ちなみに私の貢献は寝坊して起きてきた朝に「いいねそれ!」って言ったことと、「Deliverは長いし、汎用性考えるとDoneのほうが使いやすそうだし、なにより英語でも日本語でも語呂がいい」って主張したくらいです。つまりだいたい私のおかげだと思っております(壮大な勘違い)。

yattom.hatenablog.com

大事なポイントは、私たち、全然教えてないのに、これだけ広まって、成果の声が届いていることです。これは、なんかすごいものを、見つけてしまったのではないかと感じています。みなさんの共通の、心のなかにあったものを、見える化できたんじゃないかと。

f:id:wayaguchi:20190223135437j:plain f:id:wayaguchi:20190223141744j:plain f:id:wayaguchi:20190223144437j:plain

このエントリは、私の心の中にあったものを、書き出してみたものです。Fun! Done! Learn! とは一体なんなのだろうか。私なりの捉え方です。(捉え方は人それぞれでよいと思います。)

KPTじゃだめなの?

私としてはKPTを否定したいつもりは1ミリもありません。第一人者である天野勝さんからお話聞いたときに「Keepで現状よかったことをちゃんと認識するのが大事」というのを聞いて、ほんとにそうだなぁ、と思っています。ProblemやTryの前に、ちゃんとKeepがあるのがいいんですよ。課題認識と改善のネタ出しは大事なんですけど、それだけでは、チームにないことばかり話してしまいます。

メンバーが自信を持って前に進むには、ちゃんと、できてることを認識して、増やしていかないといけません。チームにできることがあるから、次の仕事の依頼があるわけですし。チームの価値を、自分たちがわかってないと売れないし、誰かに言わないと勘違いしてた時に直せない。

これだけ! KPT

これだけ! KPT

 

スタート・ストップ・コンティニュー

海外の書籍では、ふりかえり手法としてスタート・ストップ・コンティニューがよく参照されていて、海外ではデファクトスタンダードなのかなと思います。やめること、続けること、始めてみること、ですね。

チームや個人の態度とかではなくて、事実としてコトを認識して、合意するのがよいところなんじゃないかと思います。犯人探しより、「問題対私たち」の状況を作って、ポジティブに対応できそう。

gamestorming.com

XPとプロジェクトファシリテーションが日本のアジャイルコミュニティを牽引してきた

日本では、2000年代前半からXPコミュニティがアジャイルコミュニティを推進してきました。また、フルのXPを入れられなくても、見える化などを進めましょうということで、プロジェクトファシリテーションと銘打って、ふりかえりやタスクかんばんを中心に普及を進めてきた、という流れがあります。

objectclub.jp

まず開発チームで、ふりかえりをやってみましょう、と。ウォーターフォールのままでも、今週やったことをちゃんとふりかえって、課題があれば解決を考えていきましょう。そこからアジャイルは始まるんじゃないでしょうか、という提案でした(と思います)。

もちろんいまでも、XPを中心にしているチームがありますし、プロジェクトファシリテーションやふりかえりを中心に普及活動されている方がいます。

www.ogis-ri.co.jp

スクラムの中で使うことを考える

で、2010年代は日本でもスクラムが普及してきまして、最近はスクラムからアジャイルに入った人たちが多いかなと思います。私がスクラムを教えたりカンファレンス運営をしている都合上、多く耳に入ってくるってだけかもしれませんけれど。

スクラムを前提として考えた時に、ふりかえり(レトロスペクティブの役割はちょっと変わるのかもしれないな、と気づきました。(いやそれは違うぞというご意見もお待ちしてます)

スクラムおさらい

スクラムではPDCAサイクルに似ていて、スプリントと呼ばれる1-4週間のサイクルを、プランニング→ワーク→レビュー→レトロスペクティブ(ふりかえり)で一周します。

  • プランニング : チームとして取り組める範囲を予想し、実施計画を立てる
  • ワーク : 仕事を進め、各プロダクトバックログ項目を完成させ、出荷判断できる状態にする (毎日デイリースクラムをして動的に再計画を行う)
  • レビュー : 成果物を関係者に見せてフィードバックをもらう、状況をアップデートしてプランを見直す
  • レトロスペクティブ : 計画、実施、フィードバックを踏まえ、チーム自身で進め方について見直す

それぞれのミーティングや役割はいろいろ決まっている(ベストプラクティスがある)のですが、目指すところは、

  • ワークの時間をなるべく中断なく、多くとって、
  • チームが自律的に作業を進められるようにし、
  • 進め方の改善もチーム自身で行うことで、
  • 顧客や組織の課題に対応できるチームを作る

ということです。作る人々(チーム)を中心にして、アウトプットを出しながら、ちゃんと育っていくようにする。 

f:id:wayaguchi:20190311044156p:plain

Ping Pong Game ピンポンゲームでスクラム体験ワークショップ - Speaker Deck

 スクラムは経験主義に基づく

スクラムでは、レトロスペクティブをやる前に、まずはプランニングをしているわけです。プランニングの完了時点までに、チームがワークに着手できる状態にします。チームはこのスプリントで自分たちが何をやろうとしていたのかを知っている前提です。

また、デイリースクラムでもやり方を話し合っていたり、レトロスペクティブ以外に、やり方を話し合うチャンスがいくつもあります。チームのコミュニケーションを密に保つのが特徴です。

そして、スクラムは「経験主義(empirical)」に基づきます。チームの実力は、前回までの スプリントの成果をもとに予想します。「チームはどうあるべき」という理想論ではなく、過去の実績値に基づいて天気予報のように先をみていこう、というのが根底にあります。速度=ベロシティの予測で、昨日の天気*1というのを聞いたことがある方も多いと思います。まずちゃんと現実を見ようよ、ということです。誰かが決めた目標値ではなく、自分たちの体温を見て、今日の体調を確認しようということです。

スクラムのレトロスペクティブで陥りがちな罠

一方で、これはスクラムのコミュニティでよく聞くのですが、「レトロスペクティブでKPTをつかっているのだけど、Problemばかりが出る。また、Tryがまったく着手されなくて残る」ということがあるようです。

この問題はチームのマンネリ化を呼んでしまうので、対策として「Tryはアクションアイテムとして必ず次にやるようにする」という話もよく聞きます。よいことと思います。自分たちでそう決めるなら、特に。

でも、なんかルールが増えていっても、あんまり楽しくない感じがします*2。なにか大事なことが言語化できてない気がする、と感じていました。

レトロスペクティブの第一法則

以前、レトロスペクティブの祖であるノーム・カースさんの第一法則を紹介しました。

どんな道をだどったにせよ、当時の知識・技術・能力・利用可能なリソース・状況の中で、みんなができる限り最高の仕事をしたはずです。それを心から信じます。 

kawaguti.hateblo.jp

これを調べた時、「これだ!」って思いました。

まずは、これを言語化したらいいと思うんです。自分たちは、ベスト尽くして、なにをやってきたのか。現状のベストの確認です。

そのあと、沖縄で生み出されたばかりの Fun! Done! Learn! に出会うわけですが、そこでも「これだ!」って思うわけです。みんな同じようなこと考えてたんですね。

自分たちがやったことにフォーカスする

改善案を考える前に、まず、現状をちゃんと見回すべきだと思います。このスプリントでなにをやってきたのか。なにが楽しかったのか (または大変だったのか)。そこからなにが学べたのか。...  シンプルにこれを見直すためのフレームワークがFun! Done! Learn! です。

そこには、感覚的なものも含め、事実しかありません。感情もまた、その時誰かが感じた事実です。実際やってみた人たちから「すごくたくさん事実が集まる!」という反響もいただきます。

そんな事実も、時間がたってしまうと記憶が風化して、あいまいな思い出に変わってしまいます。ですので、スプリントの最後にやって、まだ新鮮な記憶のうちに、共有するとよいのではないかとおもいます。

f:id:wayaguchi:20190310190240p:plain

https://speakerdeck.com/kawaguti/fun-done-learn?slide=34

ProblemもTryも仮説にすぎない 

その事実の上に、課題を見つけ、解決策を考えていくとよいはずです。私の感覚だと、事実を話し合うと、自然と課題や解決策の話も出てきます。やったことがあることには、もっとうまくやる方法のアイデアが出てくるものだと思います。

人は、学び続ける動物である。なぜそういえるかというと、人が問題を解いていたり、新しい問題の解を見極めたりする時どういうことが起きているかを詳細に観察してみると、人は、何かが少し分かってくると、その先にさらに知りたいこと、調べたいことが出てくることが多いからだ。人はなにも知らないから学ぶのではなく、何かが分かり始めてきたからこそ学ぶ、ともいえる。

(第一章 P.13-14)

教育心理学概論 (放送大学教材)

教育心理学概論 (放送大学教材)

 

だってみんな、今後もずっと付き合っていくような、自分たちの仕事なら、もっとよくしたいと考えますよね。もっと効率的で、価値が高い仕事をして、お客さんやユーザーさんに喜んでいただいて、ちゃんとお金をいただきたい、と考える。

そこを信じましょう、というのがスクラムの根底であり、アジャイルでも語られていることです。アジャイルマニフェストの12の法則に、こうあります(下段は私が作った反例です)。 

f:id:wayaguchi:20190311043631p:plain

Flipped Agile Manifest - Speaker Deck

まずは、自分たちの目で、自分たちがやってきたことをちゃんと見る。そのうえで、もっといいやり方を考えていく。この順番が大事だと思います。

ベターベターの積み重ね 

話は飛びますが、トヨタ自動車豊田章男社長が、年頭のメッセージで、トヨタの文化は「ベターベターの積み重ね」だとおっしゃっていました。これを見たとき、まさにそれだ!と思いました。ちゃんと現場をみて、自分で動いて、よりよい方法を一つ一つ試していく。スクラムでもその意識が大事なんじゃないかなと思います。このビデオとても素晴らしいので是非どうぞ。


INSIDE TOYOTA #1 豊田章男からのメッセージ ~”自分”のためにプロになれ!~

 

結論: Fun! Done! Learn! は現状のチームを把握するのにとってもいいよね!

ということで、とっちらかってますが、Fun! Done! Learn! は現状のチームを把握するのにとってもいいよね!っていう思いを書きました。今日よりも明日。今週よりも来週。仕事は続くよどこまでも。いいチームを目指していきましょう。

みなさんが、いい成果を出せることを願ってます!

 

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

 
ユーザーストーリーマッピング

ユーザーストーリーマッピング

 
ジョイ・インク 役職も部署もない全員主役のマネジメント

ジョイ・インク 役職も部署もない全員主役のマネジメント

 

 

 

 

*1:このメタファーはXPコミュニティから来ていると聞きました

*2:そもそもスクラムなので、次にやると決めたなら、プロダクトバックログに載せるべきだとおもうのですが...。

「さよならメインストリーム」に参加した。

昨日は角さんがFacebookで共有してくれたイベントに参加してました。明治大学渡邊恵太研究室が単独で開催しているイベントで、司会も先生本人という。ほんとすごいなと思います。企業のTechConfを手作りでやってきたので共感ビシバシでお手伝いしたくてムズムズしてしまいました。中野に明治大学のキャンパスがあるってことを初めて知りましたし、素晴らしい取り組みだなと思いました。

keita-lab.jp

急に入れた予定のため、というか私が午前中仕事しなかったせいで、最初のトークセッションだけで中座してしまったのですがとても楽しめました。

深津さん「面白いもの作れる人は、鉛筆と紙があれば作れるので、鉛筆と紙を無限に供給すれば良くて、大理石とノミを提供しても...」

深津さん「共同体の箱の中で普遍的に機能するものを考えてる」

深津さん「炎上するものとかスキャンダルが評価されるシステムにすると、そういうものが評価されるんだと学んでそういうものが増える」「運営としては(よいものを)見せることが大事で、チュートリアルは副次的なもの」

深津さん「日本のメーカー言うほど技術好きじゃないよね問題。技術者は技術好きなんだけど、会社総体として技術好きじゃなかったり、技術者を大事にしてなかったり」

深津さん「酒好きかつビジネス感覚のある人がやる酒屋が必要」

 

 

メモが深津さんに寄り過ぎていて、お前どんだけ深津さん好きなんだよと...。

最後に、新聞社とかのアプリと、Noteでの取り組みはどんなところが違うのかをしつもんしたのですが「もちろん全然違います」というご回答でした。もうちょっとちゃんと質問できたら面白くできたかなと思い反省しております。

 

f:id:wayaguchi:20190309073329j:plain

f:id:wayaguchi:20190309073332j:plain

f:id:wayaguchi:20190309073336j:plain

f:id:wayaguchi:20190309073340j:plain

f:id:wayaguchi:20190309073344j:plain

 

Joy, inc. のリチャード・シェリダンさんの基調講演書き起こしが公開されました。

Regional Scrum Gathering Tokyo 2018で基調講演をしていただいたRechard Sheridanさんの講演の書き起こしが、ログミーTechさんで公開されました。3回にわけて毎日更新だそうです。

logmi.jp

ネガティブイベント、官僚化、そしてシャドーIT

ネガティブイベント、つまり悪い物事が起こると、組織が反応を起こしますよね。ソフトウェア業界であれば、それは分厚い本のようなものです。文書による承認、委員会の招集、ミーティング、誰かが承認しないといけない申請書で埋め尽くされた分厚い本です。ソフトウェア開発のライフサイクルといった書類です。私たちは、カオスから脱却しないといけません。そしてその分厚い本を司るプロジェクトマネジメントオフィス(PMO)を設立します。

そして官僚主義に至ります。全く仕事が終わらない状態(カオス)から脱却しようとしたのに、今度は仕事を始めることすらできなくなるのです(官僚主義)。待つ必要があるからです。サイン(ハンコ)、書類の承認、委員会の会議、誰かが何かを決めることを待たねばなりません。そしてもちろん、そんな状態でも、仕事しないといけないし、終わらせないといけません。

そしてシャドーITが根を張ります。皆、物事を終わらせるために、システムの外側で作業を始めるのです。その結果、私たちはカオスと官僚主義の両方に同時に放り込まれます。

f:id:wayaguchi:20190305002140p:plain

これがまさに私の人生でした。ここでまさに、私は自分の専門分野に対して心が折れてしまったのです。

 

エクストリーム・プログラミング(XP)とデザイン思考(IDEO)との出会い

悲しみについてお話ししましょう。この業界におきるもっとも悲しい物語は、例えば非常に長時間、一生懸命働いていたのに、ある日上司が来て「この案件はキャンセルになった。もうやめだ。この仕事が世に出ることは決してないだろう。新しいプロジェクトがあるからとりかかってくれたまえ」と言われたときなどです。プロジェクトが葬られると同時に、自分の一部も消えてしまいます。

私はそういった経験をしていました。そして探求の旅を始め、この本にたどり着きました。ケント・ベック著『エクストリームプログラミング』です。

エクストリームプログラミング

エクストリームプログラミング

 

そして私は、カリフォルニアにある商業デザイン企業IDEOの動画も視聴しました。まず書面で読んでから、動画を見たのです。するとその瞬間、私の頭の中で何かがカチッとはまりました。すべてのことが突如はっきりと明快になり、私は自分のやりたいことがわかりました。 


ABC Nightline - IDEO Shopping Cart

 

オープンスペースではなく、オープンカルチャー

私たちのやり方を見学するために、世界各地から年間3千から4千人が訪れます。見学者が大きな入り口のドアをくぐると、見えるのはこの光景です。広々としたオープンな環境です。多くの見学者はオープンスペースをあまり好まず、いやがります。オープンスペースは、ソフトウェア開発の環境としては良くないのではないか、と考える人が大勢います。「リッチ、オープンスペースはうまくいかないと説く本を何冊も読んだが、なぜメンローではうまくいったのだろうか」と聞かれます。

私はこう答えます。「私たちが作ったのは、オープンスペースではありません。オープンなカルチャーです。このスペースは、私たちが根底に持つ、風通しの良さ(オープンネス)、透明性、コラボレーションといったカルチャーの価値観を反映しています。私たちの職場は騒音であふれていますが、これは働く時に立てる物音であり、週末に応援するスポーツチームの得点についておしゃべりする声ではありません。働く音なのです。

f:id:wayaguchi:20190305002326p:plain

人間とは何かという概念を拡張する

35年前、ネイスビッツはすでに現代にタイムリーなこの言葉を書いているのです。「21世紀最大の発明は、技術そのものではなく、人間とは何かという概念を拡張するものになるだろう」

この言葉は、技術を軽んじているわけではなく、人間の方がより大切であると訴えています。私たちは時にそれを忘れてしまっているように感じます。

f:id:wayaguchi:20190305002410p:plain

そこで、社内の対話を変革するためには、デジタルに頼らないことにしました。Slackでもメールでもなく、メッセージアプリでもありません。私たちの言うところの「ハイスピード・ボイス・テクノロジー」です。

 デイリースタンドアップ

毎朝10時、アラーム時計が「ボーン、ボーン」と鳴ると、全員が立ち上がり、円陣になります。デイリースタンドアップミーティングには、60人から70人が出席します。(写真を指して)全員が出席します。犬も出席します。

f:id:wayaguchi:20190305002625p:plain

バイキングの兜を持ってペアで発表する

私たちはペアで仕事をしていて、ペアで発表をするために起立します。バイキングの兜が回ってくれば、ペアのパートナーとあなたが、自分たちが今やっていることを話す番なのです。話し終われば次のペアに兜を渡します。話し終われば、さらに次のペアに兜が渡されます。兜は70人の手を渡り、全員が話し終わると、テーブルの上に戻されます。こうしてミーティングは終了します。通常30分くらいの長さです。

f:id:wayaguchi:20190305002654p:plain

 

logmi.jp

ショウ&テルで顧客に報告 (実際は顧客が報告)

メンローでは役割が逆転します。私たちが、顧客に前の週の進捗を報告するのではありません。顧客側にコンピュータとマウスを配置し、進捗中のソフトウェアをスクリーンに投影して、「顧客が」私たちの前週の作業を「メンロー社員たち」に見せ、メンローの担当者がそれを見学するのです。

f:id:wayaguchi:20190305135902j:plain

計画ゲームで顧客と協調的に計画を行う

作業は全て、インデックスカードに手書きで書き込まれます。見積は1時間単位で立てられ、カードは見積の大きさに合わせて折りたたまれます。こちらが16時間のカード、8時間カードはこれ、4時間カードはこれくらいの大きさです。大きさで判別できるようになっています。

f:id:wayaguchi:20190305140055j:plain

 実行するのは開発チーム。すべてをペアで進める

ひとたびプランが完成すれば、全員の目につく場所に貼り出されます。全ての紙片について、縦はそれぞれペアが費やした5日間の作業内容を示し、横に貼り出したひもは5日間のサイクルで現在どのあたりかを示しています。ひもは、工程が進むにつれ、時計のように毎日進みます。

f:id:wayaguchi:20190305140152j:plain

 QAチーム(実際はQAを担当するペア)が完了を評価する

メンローでは、プログラマーたちには「完了したと思う」と表現してもらいます。QAチームがチェックをしその了承を得られれば、緑の評価を得られます。緑の評価をもらえることは、プログラマーたちにとって非常に喜ばしいことです。メンローにおける「緑ドット」は、プログラマーにとって幸せと喜びの象徴です。

f:id:wayaguchi:20190305140257j:plain

 ハイテク人類学者はUXリサーチから要件定義を担う

メンローのハイテク人類学者たちは、世界にでかけて行き、相手が暮らしている環境の中で相手を観察します。トヨタの人たちの言うところの「現場へ行く」ですね。働いている現場に行く理由は、相手のワークフローや習慣、生き方の目標、働き方を表現する言語を把握するためです。

f:id:wayaguchi:20190305140412j:plain

 実験してよう!やってみて学ぼう!

だからこそ、私はみなさんに、このシンプルな言葉を覚えて帰っていただきたいのです。もし誰かがみなさんに「うちの会社ではうまく行かないだろう」と言ったら、みなさんは相手の顔を見て、「そうかもしれない。でも、実験してみよう」と言うのです。「ノーと言う前に試してみよう。何が起こるかを見てみようじゃないか」

logmi.jp

顧客やステークホルダーを巻き込むには

なぜなら、我が社ではプロジェクトを壊すものは2つあると信じています。1つ目は、「恐れ」です。恐れても、悪いニュースは無くなりません。恐れは、悪いニュースを隠してしまいます。私たちは、恐れを克服するには、問題を進行させず、迅速に対処します。

プランが遅れ気味で、顧客がカード(注:プラン作成用の手書きカード)を吟味している時には、顧客はテーブルにカードを並べながら、直に個人的に参加しているのです。カードは壁に貼り出され、5日以内にディスカッションを始めます。すると顧客は、私たちが仕事をするためには、自分たちの仕事がどれだけ大切か理解し始めます。なぜなら、顧客が仕事を終わらせないと、私たちの仕事にも影響が出るからです。

要するに、シンプルに全体を見える化するのです。顧客との新たな関係を築くことができます。言うのは簡単ですが、実際にやるとなると、非常に難しいですよね。ありがとうございました。

自分たちでやり方を変えていく

すると彼らは言いました。「赤ドットには、『停滞』や、『完了したと思う・QA待ち』など、いろいろな意味がありすぎて、赤だけでは成り立たなくなってきたのです。しかもQAで問題が見つかれば、前のカードの指示まで戻ってやり直さなくてはなりません。そこで、チームが『オレンジのドットを使う』という実験をしたのです」今では、オレンジドットが「完了したと思う、QA待ち」という意味を持つようになりました。

委員会も、大きなミーティングもありませんでした。誰かが小さなオレンジドットのシールを持って来て「オレンジドットを使ってみよう」と言ったのです。10年ほど前のことです。以来、私たちはずっとオレンジのドットシールを使い続けています。

講演資料はこちらです。 

speakerdeck.com

  

 

ジョイ・インク 役職も部署もない全員主役のマネジメント

ジョイ・インク 役職も部署もない全員主役のマネジメント

 

お試し版もあります。 

 

logmiを見直して

一年たった今見直しても、すばらしいお話だったと思います。2000-2001年ごろにちゃんと走り出している人たちがいて、ずっと工夫しながら続けてきて、当時「うちには難しいな」と思って諦めた多くの人たちにとって、背筋を伸ばさせられるトークになったのではないかと思います。でも、全然今からでもできるんじゃないかと思います。具体例もあるし、十数年分の経験を積み重ねてきたのですから。しかも飛行機に乗ってミシガンに行けば(デトロイトから30分です)、簡単に見せてくれるんです。残念ながら偉い人の北米視察コースには入ってないと思いますが。

RSGT2018では、Microsoftのエンジニア、河野通宗さんの基調講演も行われました。こちらもクラウド時代のエンジニア像として、生々しく話してくれています。LogmiTechでどうぞ!

logmi.jp