# AGILE-MONSTER.COM
> 制御不能なアジャイルモンスターの情報発信ハブ。AI時代のチーム・組織・開発プロセスを日々探索しています。
著者: 及部 敬雄（TAKAKING22）— アジャイルコーチ / エンジニア
タグライン: 制御不能なアジャイルモンスター
---
# タスクを投げるな、約束をしよう
URL: https://agile-monster.com/blog/make-promises-not-tasks/
Published: 2026-09-24
---
仕事がスルスル進む人と、なぜかいつも止まってしまう人がいます。
自分はこれを「仕事の推進力」の差だと思っていて、ずっと気になっています。
スキルの差でも、熱量の差でも、たまたまでもない。じゃあ、なんなのか。
今回はそのうちのひとつ、ほんの少しの違いについて書いてみます。
## タスクを投げて、終わりにしていないか
クライアントワークをしていると、顧客や関係者に動いてもらわないと先に進めない場面がよくあります。資料を確認してもらう、意思決定してもらう、情報を出してもらう。
そういうとき、「ではご確認よろしくお願いします！」とタスクを投げて終わりにしてしまう。
しばらくして「〇〇の件、どういう状況ですか？」とリマインドする。返事がこない。あるいは「やっておきます！」と返ってきて、そのまま動かない。
これを何回か繰り返しているうちに時期を逃して、気づけば話そのものが立ち消えになっている。仕事の依頼をもらう側なら、案件ごと消えてしまいます。
しかも、これが高い確率で起きる人がいます。やっぱり、たまたまではないのです。
## 約束しないと、優先順位にすら入らない
相手が対応してくれないと、「後回しにされているんだな」と思いがちです。
でも実際は、もっと手前で止まっていることが多い。
**優先順位の中にすら入っていないのです。**
相手にも自分の仕事があって、自分の優先順位があります。そこへ「よろしくお願いします」とタスクだけ渡されても、いつまでに、どれくらいやればいいのかがわからない。わからないものは並べようがないので、とりあえず脇に置かれます。悪気はまったくありません。
ボールは誰にも拾われないまま、床に落ちています。
「どういう状況ですか？」とリマインドしても、この構造は変わりません。状況を教えてほしいと頼んでいるだけで、次に誰がなにをするのかは、なにも決まっていないからです。
## だから、約束をする
違いは、ほんの少しだけです。
**タスクを投げるのをやめて、約束をする。**
- いつまでに
- 誰が
- なにをするのか
これをお互いに決めます。「ご確認お願いします」で止めずに、次の約束まで話します。たとえば、こんなやりとりです。
> 「金曜までにA案とB案のどちらにするか決めていただけますか？ 月曜にこちらで見積もりを出します」
>
> 「金曜は難しいですが、月曜の午前なら」
>
> 「では、月曜の午前に決めていただいて、こちらは火曜に見積もりを出します」
期限をつけてお願いするだけでは、まだ約束ではありません。お互いに「それでいきましょう」と決めるところまでやります。相手になにをしてもらうかだけでなく、自分が次になにをするかも一緒に約束します。
おもしろいのは、約束しようとすると、相手が考えはじめることです。「金曜は難しいですが、月曜の午前なら」という返事は、相手が自分の状況を思い浮かべたからこそ出てきた言葉です。
**約束しようとすることで、相手は自分の状況を思い浮かべて、優先順位を決めます。**
ここではじめて、仕事が相手の優先順位に入ります。お互いにそれぞれの仕事と優先順位があるからこそ、約束をするのです。
## 約束を並べて、ステップにしてしまう
自分がよくやるのは、約束をひとつで終わらせずに、ゴールまでのステップとして並べてしまうことです。たとえばこんな感じです。
- 10/01（木）自分：打ち合わせにてシステム構成を説明し、構成図を提出する（本日）
- 10/05（月）相手：構成図についてフィードバックをいただく
- 10/06（火）自分：フィードバック内容を反映して申請を提出する
- 10/09（金）相手：申請に基づいて環境構築をし、引き渡す
これを打ち合わせの最後に画面に出して、「この流れで進めたいんですが、どうですか？」と聞きます。
ステップを並べると、このあと仕事がどう進んでいくのか、全体のイメージが共有されます。
すると相手にも、「こう進めたいから、このタスクをこの日までにお願いされているんだな」と伝わります。単に「5日までにフィードバックください」と言われるのとは、受け取り方がまるで違います。自分のフィードバックが遅れたら、6日の申請も9日の引き渡しもずれる。それが見えているからです。
そのうえで、相手は自分の仕事の優先順位に、このタスクを組み入れます。ときには「5日は厳しいので6日の午前でもいいですか？」と、その場で調整してくれることもあります。
それでいいのです。お互いの状況をふまえて決めた約束のほうが、ずっと守られやすい。
**タスクをひとつ投げても、相手に見えるのはそのタスクだけ。約束を並べれば、相手に見えるのは仕事の流れ全体になります。**
## 守られなかったら、また約束する
もちろん、約束が守られないこともあります。相手にも急な事情はあります。
でも約束があれば、相手から「すみません、月曜の午前は厳しくなってしまって、水曜でもいいですか？」と連絡が来ることが多いです。守れなかったことに相手自身が気づけるのも、約束があるからです。
連絡が来なかったとしても、責める必要はありません。もう一度約束をします。
**約束し直すことは、相手に優先順位をつけ直してもらうことでもあります。**
このとき、同じお願いに新しい期限をつけ直すだけでなく、進め方ごと変えてしまうこともよくあります。ひとりで確認する時間が取れないなら、「明日15分だけください。画面を見ながら一緒に決めちゃいましょう」と一緒に確認する時間をつくる。判断材料が足りないなら、先にこちらでそろえる。相手が進められる形にしてから、もう一度約束します。
## おわりに
タスクを投げるか、約束をするか。ほんの少しの違いですが、積み重なると大きな差になります。
仕事を前に進める力、「仕事の推進力」のようなものは、たしかにあると思っています。スキルとも熱量とも違う、なにか。
ただ、それがなにでできているのかは、まだ言語化の途中です。今回の「約束」は、そのうちのひとつにすぎません。
これからも、少しずつ言葉にしていきたいと思います。
## 合わせて読みたい
https://agile-monster.com/blog/i-am-the-thinker-you-are-the-worker/
https://agile-monster.com/blog/direction-of-communication/
---
# 仕事の質はコンテキストで変わる。それはAI時代でも変わらなかった
URL: https://agile-monster.com/blog/context-still-matters/
Published: 2026-08-17
---
自分たちの組織では、AI時代への変化に適応していくことも兼ねて、1年ほど前から、プロジェクトマネージャーという専門職をなくしました。エンジニアを含めた全員が直接顧客と話し、プロジェクトを進行する。プロジェクトマネジメントを特定の役割ではなく、全員がケイパビリティとして持つことを目指しています。
その中で、チームのふりかえりに、こんな声が出るようになりました。
「話すのが得意ではない」「会話の瞬発力がない」
なんとなく、それは違う気がしていました。そして会議に同席する機会が増えるにつれて、その正体が少しずつ分かってきました。
会議のファシリテーターが、アジェンダ通りに会議を進めようとします。アジェンダ通りに進めること自体は、できています。でも、少しでも脇道にそれて議論が始まったり、相手がアジェンダの項目を深掘る質問をしてきた瞬間に、対応できなくなってしまう。相手に何を伝えるか、相手に何を話してもらうかではなく、常に「自分たちが伝えたいことを伝える」だけになっている。
**アジェンダに書いてあることしか、その場にないのです。**
もちろん、想定外の問いに対しては、問い返す、いったん保留する、場に返すといったファシリテーションの技術もあります。ただ、自分が見た場では、その技術を使う以前に、議論を広げるための判断材料そのものがありませんでした。これは、話す力や瞬発力の問題ではない。足りていないのは、言葉ではなく、その裏に積まれているもののほうです。
いま思えば、これはプロジェクトマネージャーをなくしたときに、自分が想像できていなかったことでもありました。**役割をなくしても、その役割が担っていたコンテキストの収集や接続までは、自動的に全員へ分散しない**のです。
念のため書いておくと、これを他人事として書くつもりはありません。形だけのアジェンダなら、自分も過去にたくさん作ってきました。
## ソースコードでも、同じことが起きる
最近、似た光景をコードでも見ました。
あるプロジェクトで、開発は順調に進んでいるように見えていました。機能はできていくし、デモも動く。形の上では、プロジェクトは進んでいます。
そこに、実運用の経験者が参画して、問いを重ねはじめました。
- 「このURL、直接たたかれたらどうなりますか？」
- 「同じようなイレギュラーパターンの要件が増えていったら、どうなりますか？」
- 「今のUIの流れで、ユーザーは待ってくれますか？」
- 「障害が起きたとき、どうやって原因を追いますか？」
答えに詰まる場面が、続きました。
ハッピーパスと、そのまわりにある一般的な異常系は、ちゃんと作られていました。埋まっていなかったのは、その外側です。 想定外の使い方をする人、要件の増え方、画面の前で待つユーザー、障害対応をする未来の自分たち。
この問いを並べてみると、実運用経験者が見ているものの正体が分かります。システムの保守運用の視点だけではないのです。つくった機能が、その会社のどんな業務の中で、誰に、どう使われるのかまで想像している。 コンテキストは、システムの中だけに積むものではありませんでした。
そして、この問いは不足を暴くだけではありませんでした。たとえば「今のUIの流れで、ユーザーは待ってくれますか？」には、その場で誰も答えられませんでした。そこで顧客に確認してみると、意外な答えが返ってきました。待つこと自体は、問題ではない。それよりも、迷わないことと、結果の精度が高いことのほうが大事だと。この一往復で、「いま待っている」ことが伝わるUIに変わり、処理の流れも変わりました。問いに答えようとした動きが、チームに新しいコンテキストを連れてきたのです。問いは、コンテキストの不足を確かめるだけでなく、新しいコンテキストを作る。
アジェンダ通りにしか進められない会議と、ハッピーパスのまわりしか埋まっていないコード。この2つは、同じ問題の別のあらわれだと思っています。目の前の問題解決以上の内容が、そこに込められていないのです。
## コンテキストとは何か
AI時代になって、「コンテキスト」という言葉を毎日のように使うようになりました。この記事でもこの言葉を借りて、アウトプットが生まれるまでに積まれたものを指すことにします。なぜ作るのか。どんな制約があるのか。何を検討して、何を捨てたのか。ここまでどんな経緯があって、この先どうしたいのか。
コンテキストは、人によって見ている範囲と時間軸が違います。自分のタスクだけを見ている人と、チームやプロダクト、その先の顧客まで見ている人。今日の実装だけを見ている人と、これまでの経緯や、この先の運用・変化まで見ている人。
先ほどの実運用経験者の問いが鋭かったのは、この範囲と時間軸が広かったからです。経験そのものをコンテキストと呼びたいわけではありません。経験が増やすのは、どの情報を集め、どの「こういう場合は？」を立てるべきかという視点のほうです。その視点があるから、目の前のプロジェクトから短時間で厚いコンテキストを積める。
この差は、仕事の質の差の一因として、これまでも暗黙的に存在していました。それがAI時代に入り、プロンプトをはじめとするAIへのインプットとして、言語化され始めた。コンテキストという言葉が毎日使われるようになったのは、そういうことなのだと思います。
## 同じ形でも、積まれているものが違う
アウトプットには、同じ形をしていても2種類あります。
最短距離で積み上げただけのアウトプットと、思考と試行の量を積み上げ、その量が質に転化したアウトプットです。
ここでいう「量」は、資料の厚さやトークンの多さではありません。目的、制約、例外、時間軸について、どれだけの分岐をたどったかです。検討して捨てた案の数、置いた仮説の数、「こういう場合は？」と自問した回数。それらはアウトプットの表面には現れませんが、確実にそこに積まれています。
そして、AIによって劇的に安くなったのは、主に前者です。AIでゼロに近づいたのは、初稿を形にするコスト。検証や判断もAIに手伝ってもらえるようにはなりましたが、何が正しいかを決めて、その結果に責任を負うコストは、人の側に残っています。
だからこそ、差が際立つようになったのだと思います。
**形は、誰でも一瞬で作れる。積まれたコンテキストの差が、アウトカムの差になって残る。**
## AIへの渡し方に、積んできたものが現れる
具体的な例を出します。AIに会議のアジェンダを作らせる場面です。
薄い渡し方は、こうです。アジェンダのテンプレートと前回のアジェンダを渡して、「今回の会議のアジェンダを書いて」。
これで、それらしいアジェンダは出てきます。形は完璧です。でも、このプロンプトには、プロジェクトがいまどんな状況なのかも、参加者がどんな人たちなのかも、ここまでにどんな議論や意思決定がなされてきたのかも、今回の会議でどこにたどり着きたいのかも、何もありません。
AIは、それを推測するのみです。
厚い渡し方は、それらのコンテキストを渡した上で生成し、出てきたものにさらに壁打ちを重ねて洗練させます。出てくるアジェンダは、どちらも同じ「形」をしています。でも、会議が始まれば差は隠せません。脇道の質問が来た瞬間に、答えられなくなる。冒頭の光景です。
最近、この薄い渡し方をよく見かけるようになりました。賢いモデルが推論でそれらしく埋めてくれるので、形の上では成立してしまうからです。
もうひとつ、AIに渡そうと言葉にする過程には、副産物があります。言葉に詰まった瞬間、自分の理解の穴が見えるのです。言語化できないことと、持っていないことは同じではありません。それでも、渡せなかった分は反映されにくく、AIの推測に置き換わっていきます。
作者が適当にプロンプトを入れて、賢いモデルがすごい推論をしてポンッと出てきたアウトプットなのか。作者に蓄積されたコンテキストをもとに生成され、壁打ちで洗練されたアウトプットなのか。
見た目では、区別がつきません。
## 形としてのアウトプットは、ゴールではない
積まれていないものは、遅かれ早かれ露呈します。会議なら、脇道の質問ひとつで。コードなら、実運用の問いや、変化や負荷が来たときに。
ただし、露呈するまで待てばよい、という話ではありません。セキュリティや障害のように、壊れてからでは遅いものがあります。レビューやテスト、そして実運用経験者のあの問いは、露呈を安全なうちに前倒しするための仕組みです。
つまり、会議でもソフトウェアでも、**形としてのアウトプットはゴールにならない**のです。アジェンダを作ることがゴールなら、薄い渡し方で十分です。でも、会議で相手と合意に至ることがゴールなら、足りない。コードが動くことがゴールなら十分です。でも、運用に耐えて価値を出し続けることがゴールなら、足りない。
アウトプットの形が簡単に手に入る時代になったからこそ、ゴールはその先にあるという当たり前のことが、むしろ見えやすくなったと思っています。
## コンテキストは、どう積まれるのか
では、どう積んでいけばいいのか。
先に断っておくと、コンテキストを積むとは、着手前に考え尽くすことではありません。複雑な仕事には、実際に動かしてはじめて得られるコンテキストがあります。小さく試して、現実から返ってきた情報で前提を更新する。そこまで含めて「積む」です。
もうひとつ、うまくいかなかった方法も書いておきます。コンテキストが不十分なアウトプットに、フィードバックをする。指摘した部分は、直ります。でも、同じ構造をした別の部分は直っていない。そして次のアウトプットでも、また似たようなフィードバックを繰り返すことになる。これを何度も経験しました。心当たりのある人も多いのではないでしょうか。レビューする側にも、される側にも。
考えてみれば当然です。アウトプットは、結果にすぎないからです。 アウトプットへの修正指示は、結果を直せても、過程には届きません。理由や前提を問い直すレビューであれば、過程への入口にはなります。ただ、少なくとも自分が試してきたなかでは、判断が生まれる瞬間ごと見えるペアワークやモブワークが、いちばん解像度の高い方法でした。
一緒に働いていると、同じ仕事でも、アウトプットへのたどり着き方や、AIへのコンテキストの渡し方が、人によってまるで違うことが見えます。前提を確認してから始める人、いきなり作り始める人。捨てた案を言葉にする人、しない人。AIに経緯ごと渡す人、指示だけ渡す人。一人で仕事をしているとアウトプットしか見えませんが、一緒に働くと過程が見える。そして、複数の視点がぶつかることで、コンテキストは移るだけでなく、新しく生まれもします。このあたりは [AI時代のモブプログラミングFAQ](/blog/mob-programming-faq/) にも書いたので、興味があればどうぞ。
冒頭のふりかえりの声に戻ります。必要なのは、話すのが得意になることではないと思っています。**会話の瞬発力に見えるものの正体の多くは、その場で考える速さではなく、事前に積まれているコンテキストの量**だからです。
脇道の質問に答えられる人は、頭の回転が速いのではありません。**その脇道を、すでに一度歩いたことがあるのです。** 初めての脇道に出たら、その場で少し歩いてみればいい。その歩き方もまた、これまで積んできたものの中にあります。
## おわりに
AIの「コンテキスト」という言葉は、新しい概念ではなく、仕事の本質の再発見だったのだと思います。積まれたものの差は、AIが登場する前からずっとありました。形を作るコストが下がったことで、その差が隠せなくなっただけです。
形だけのアウトプットを量産する働き方と、コンテキストを積みながらアウトプットする働き方。自分はどちらを選びたいか。ちょっと立ち止まって、自分のアウトプットに問いかけてみてください。
「こういう場合は、どうなる？」
その問いに答えられる分だけ、そこにはコンテキストが積まれています。
---
# AI時代のモブプログラミングFAQ
URL: https://agile-monster.com/blog/mob-programming-faq/
Published: 2026-08-13
---
これまで、モブプログラミングに関する講演や研修を、さまざまな場所で開催してきました。先日も、AI時代のソフトウェア開発とモブプログラミングをテーマにした研修を実施しました。講義だけでなく、チームに分かれて実際にモブプログラミングを体験してもらう構成です。
こうした場で、よく聞かれる質問があります。「ミーティングと何が違うんですか？」「5人で1つの仕事をしたら、生産性は5分の1になりませんか？」「AIがコードを書くなら、タイピストは要らなくないですか？」どれも、モブプログラミングを検討したことのあるチームなら、一度は突き当たる問いだと思います。
せっかくなので、よく聞かれる質問への回答をFAQとしてまとめてみました。ぜんぶの答えの根っこには、ひとつの考え方があります。
**モブプログラミングは、複数人でコードを書くための手法ではない。チームの理解を増幅する仕組みである。**
なぜ「共有」ではなく「増幅」なのか。ここの詳しい種明かしは、別の記事でじっくり書くつもりです。今回はこの軸だけ頭の片隅に置いて、質問に答えていきます。
## モブプログラミングとは
言葉の定義だけ揃えておきます。モブプログラミングとは、チーム全員で4つの「同じ」が揃っている状態です。
キーボードをたたく人が**タイピスト**（ドライバーとも呼ばれます）。それ以外の全員が**その他のモブ**（ナビゲーター）。全員で会話して、考えて、判断する。合意したことをタイピストが代表してアウトプットする。これを時間で交代しながら回していきます。オンラインでも成立しますし、プログラミングに限らず、設計・レビュー・調査・障害対応など、複数人で同じ目的に向かう仕事なら何でもモビングできます。
基本のやり方や背景は、スライドにまとめてあるのでそちらをどうぞ。
- [Head First モブプログラミング](https://agile-monster.com/slides/head-first-mobprogramming/) — 基本のやり方と、よくあるアンチパターン
- [モブプログラミング再入門](https://agile-monster.com/slides/a-re-introduction-of-mob-programming/) — 基本から見直す、AI時代のチーム開発の選択肢
## ミーティング・レビュー・ペアとの違い
### Q. ミーティングと何が違うんですか？
構造だけ見ると、ミーティングとモブはたしかに似ています。複数人が集まって、同じ画面を見て、会話して、同じ時間だけ人を使う。ミーティングは毎日やっているのに誰も咎めないのに、モブになると突然「そんなに人を集めるのは非効率では？」と言われる。**投入している人数と時間の構造は、ミーティングと変わらない**のに、です。
違うのは、その場で何をしているかです。多くのミーティングでは、誰かが事前に準備した資料を共有し、できたものをレビューし、意見を集めて合意します。つまり**結果を持ち寄る場**です。モブでは、仕事そのものをその場で全員で進めます。設計も、実装も、調査も、意思決定も、**過程を共有する場**です。
会議室で会議を繰り返すのと、集まって仕事を進めるの。構図は同じで、やっていることが違うだけ。だとしたら、どちらが「非効率」なのでしょうね。
### Q. レビューや勉強会でも知識共有はできますよね？
できます。ただし、レビューや勉強会で共有できるのは、多くの場合すでに存在する成果物から読み取れる情報です。モブで共有できるのは、**結果に至る過程**です。どこで迷ったか、なぜその案を捨てたか、どの順番で問題を切り分けたか、経験者が無意識にやっているIDEの操作や調べ方。これらのほとんどは成果物に残りません。
そしてモブは**リアルタイムレビュー**でもあります。事後レビュー(プルリクエスト等)と対立するものではなく、役割が違います。その場で直る・全員合意で進むのがリアルタイムレビュー、記録に残る・俯瞰できるのが事後レビュー。置き換えるのではなく、組み合わせるものです。
もうひとつ、研修や輪読会との違いは**知識のジャストインタイム**です。必要な瞬間に、必要な知識が入る。教えているのではなく、一緒に働いているだけ。なのに伝わる。
### Q. ペアプログラミングとは何が違うんですか？
理解が蓄積される**範囲**が違う、と捉えています。5人チームでペアを組むと、その2人の間には強い共通理解が生まれますが、残りの3人には別途共有が要ります。モブなら、最初からチーム全体がその問題解決に参加します。
「ペアが悪くてモブが良い」という話ではありません。**どの範囲まで理解を増幅したいのか**で形を選べばいい。10人チームなら、全員で1モブ、5人×2モブ、ペア、ソロ、どれもありです。複数モブに分ければ「モブ同士の理解をどう同期するか」という設計課題は生まれますが、10人が10個の異なるコンテキストを持つ状態を同期するより、2〜3個のモブを同期するほうがずっと簡単です。
## 「5人で1つの仕事」は非効率なのか
### Q. 5人で1つの仕事をしたら、生産性は5分の1になりませんか？
まず「生産性」という言葉を分けさせてください。コード行数、完了チケット数、同時に進む作業数。アウトプット（仕事量）の意味なら、分担したほうが増えることは多いです。ここは認めます。
でも本当に見たいのは、そこから生まれた価値、**アウトカム**のほうですよね。
分担作業には、前後に「同期」の作業が必要になります。タスク分割、設計のすり合わせ、キックオフ、レビュー、承認、引き継ぎ。そして理解がズレていると、ここで手戻りが生まれます。「3人が3つの仕事をするから3倍速い」という単純な構造では、実はないのです。
モブは、同期しないのではなく**常に同期している**働き方です。引き継ぎもレビュー待ちも、構造ごと消える。Gitのイメージで言えば、分担はマージで初めて答え合わせをするのに対し、モブは全員で1本の履歴を進めるので、いつでも「常にマージ済み」。答え合わせが「最後に一回」か、「常に」か、の違いです。
考える道具として、**リソース効率とフロー効率**という2つの効率を紹介させてください。リソース効率は人の稼働率を最大化する働き方。全員が別々の仕事を持って手を止めない。個人は速いが、待ちと引き継ぎが増える。フロー効率は1つの仕事の流れを最速化する働き方。仕事が人を待たない。モブはこちら側で、いわば究極の一個流しです。
道路を車で埋めれば稼働率は100%ですが、流れません。道路を空ければ、車は目的地に早く着く。**どちらが正しいかではなく、何を最速にしたいかが違う**のです。
実際に自分たちがモブを始める前は「遅くなるのでは？」という不安がありました。やってみると意外なほどスムーズに仕事が流れて、「むしろ分担より速かったのでは？」と感じたことも何度もあります。ただし、常にモブのほうが速いと主張するつもりはありません。仕事によって選ぶべきです。それが次の話です。
## モブと分担を、使い分ける
### Q. どんな仕事がモブに向いていますか？
「複雑だからモブ」と考えるより、**その仕事を通して得られる理解を、チームの資産にしたいか**を判断軸にすることをおすすめします。探索的な仕事、正解がまだ分からない問題、設計判断、ドメイン理解が必要な仕事、障害調査、新しい技術、スキル移転をしたい仕事。複雑な問題は結果として「チームの理解にしたい」ことが多いので、モブ向きになりやすい、という順番です。
迷ったら、「あとで全員に説明が必要になるか」で考えてみてください。あとで「なぜ」を聞かれる仕事は、最初から全員でやったほうが早いことが多いです。
逆に、誰がやっても結果がほとんど変わらない定型作業、ごく小さな修正、知識を広げる価値が低い仕事は、分担したほうがよいことがあります。**モブは万能ではありません。モブと分担のどちらが正解かではなく、選択肢として両方持っていることがチームの強さです。**
もうひとつ。「今日はモブ」「今日は分担」という大きな単位で考える必要もありません。熟練したチームでは、仕事の途中でも自然に切り替わります。モブ中に難しい課題にはまったら、一人は検索し、一人はドキュメントを調べ、一人は手元で試し、一人はAIに聞く。誰かが有力な情報を見つけたら「これちょっと見て」とモブに戻る。**モブ→分担→モブを短い単位で行き来する**。この粒度が細かいほど、チームは仕事の進め方を細かくチューニングできます。
## 良いモブをどう作るか
### Q. タイピストは、自分で考えてはいけないんですか？
まず、よくある誤解から。「タイピストが仕事をして、他の人が見ている」。これは、モブではありません。モブでは、チームが会話して意思決定し、その合意を**タイピストが代表して環境に反映**します。タイピストは「手」であって「頭」ではない。タイピストが独断で書き進めて他の人が見ているだけなら、それはライブコーディングに近い何かです。
ただし「考えるな」という意味ではありません。役割の理解を優先して、あえて「その他のモブの合意どおりに操作する」という練習ルールを使うこともありますが、実際の仕事ではタイピストもチームメンバーです。意見も質問も「分からない」も、当然言っていい。**チームの意思決定を手に反映する窓口**、と捉えるのが分かりやすいと思います。
その他のモブも「見る人」ではありません。考えて判断する、口に出す、質問する、調べる、記録を残す、タイムキープ、ファシリテーション、「わからない」と言う。貢献の仕方はひとつではなく、どれか1つでも担えていればチームへの貢献です。
### Q. スキル差が大きいチームでは、どうすればいいですか？
発言量を全員均等にする必要はありません。詳しい人が多く話すこと自体は悪いことではなく、その知識が周囲に伝播するなら価値があります。大事なのは、**そのモブの目的に対して必要な会話が起きているか**です。
スキル差を埋めたいときに効く工夫がひとつあります。**経験の浅い人に、タイピストを多めに担当してもらう**ことです。タイピストには強い権利があります。分からなければ、手が止まる。通常の参加者が「ちょっと分からないので止まってもらえますか」と言うのは心理的ハードルが高いですが、タイピストなら操作できないので自然に止まります。そこで詳しいメンバーが背景を説明し、判断理由を言葉にする。聞きながら手を動かすと学びが最大化されるので、結果としてチーム内の理解がならされていきます。
### Q. タイピストの交代は、どうやって決めればいいですか？
交代の仕方に、決まりはありません。時間で交代する、キリのいいところで交代する、コミット単位で交代する。どれでもよくて、**チームに合う方法を選べばよい**です。ちなみに研修では、タイピストを全員に回すために10分で交代しています。実務では30分や1時間で回しているチームもあります。
キリのいいところやコミット単位で交代する場合に、ひとつだけ気をつけたいことがあります。問題が難しいとキリがなかなか来ず、同じ人がタイピストをやり続けてしまうことがある点です。そうなっていることに気づける仕掛けがあると安心です。
時間で交代する場合には、ローテーション以外の価値もあります。30分経って交代するとき、「30分やったのに問題が解決していない」ことに気づけるのです。このまま続けるか、問題の捉え方を変えるか、一度調査に切り替えるか。**交代が、自分たちの仕事を一段上から眺めるタイミング**になります。
### Q. 心理的安全性がないとモブは無理ですよね？
順序が逆かもしれない、と思っています。モブにおける心理的安全性とは、仲が良いことではなく、**必要なときに仕事を止められること**です。「今ちょっと分からない」と言える。「意見が合っていない気がするので整理しませんか」と言える。
モブについて覚えておくことをひとつだけ選ぶなら、自分はこれを挙げます。**「わからない」と言うことは、チームへの貢献です。** わからないまま進んだ分だけ、理解はチームから抜け落ちていきます。「わからない」が言えるチームには、理解が貯まっていく。そういう状況を、モブを通じてつくっていくのです。
### Q. モブがうまくいかなかったら、どうすればいいですか？
まず「何がうまくいかなかったのか」を言葉にすることからです。一人だけずっと話していた、誰かが参加できていなかった、会話がほとんどなかった、居心地が悪かった。モブの最後に短いふりかえりをして、よかったこと・居心地が悪かったこと・次に試したいことを話す。理想のモブは最初から存在しないので、そうやって**自分たちのモブをテラフォーミングしていく**イメージです。
そして重要なのは、「モブがうまくいかなかった→モブはダメだ」と短絡しないことです。実際には、モブの問題ではなく、**もともとチームが抱えていた問題が、モブによって顕在化した**ケースが多い。モブはコミュニケーション密度が非常に高いので、発言の偏り、権力関係、スキル差、意思決定の癖が見えやすくなります。その意味で、**モブはチームの状態を映す鏡**です。見えたなら、直せます。問題の解像度が上がると、むしろ気が楽になりますよ。
ただし、鏡に映ったものによっては、モブで解決しようとしてはいけません。特定の人との仕事が精神的に大きな負担になっている、ハラスメントに近い問題がある、強い権力関係がある。そういうチームだけでは解決できない問題が見えたときは、コミュニケーション密度の高いモブはむしろ状況を悪化させえます。モブを止めて、マネージャーや組織へエスカレーションしてください。**モブはチームのあらゆる問題を解決する万能薬ではありません。**
### Q. リモートでもできますか？ カメラはONにすべきですか？
できます。フルリモートで何年もやってきました。難しいのはハイブリッドです。3人がオフィスの会議室、2人がリモート、という形にすると、オフィス側だけで会話が盛り上がってリモート側が置いていかれます。オフィスにいる人も一人ずつPCからオンライン会議に入るなど、**参加者間の情報格差を減らす**のがコツです。
カメラは、絶対ONとは考えていません。ただ、顔が見えると情報量は増えます。タイピストが突然止まったとき、困っているのか、考えているのか、表情から読み取れて「何か分からなかった？」と自然に声をかけられる。大事なのはON/OFFそのものより、**チームで期待値を合わせておくこと**です。「基本はONにする。ただし体調や家庭の事情があるときは遠慮なくOFFに」というWorking Agreementがあれば、OFFの人を見ても「何か事情があるんだろう」と思えるし、OFFにする側も罪悪感がありません。
### Q. モブを嫌がるメンバーがいたら、どうすればいいですか？
好きか嫌いかだけで仕事のやり方を決めるのは、どちらの方向にも望ましくないと思っています。個人の感情は重要な情報ですが、最終的には**チームとして何を達成したいか**で考えたい。
モブは説明だけでは価値が伝わりにくいので、まず小さく体験するのが有効です。午前中だけ、一つのタスクだけ、2時間だけ。やってみて「スキル差を埋めるにはすごく良さそうだ」と分かったら、「スキルトランスファーのために週に数時間モブをしよう」とチームで合意できます。モブ自体が好きではないメンバーでも、「スキル差を減らすことは重要」という目的には合意できるかもしれない。**必要なのは、モブをやることへの合意ではなく、目的への合意です。**
導入時に全タスクをモブにする必要もありません。基本すべてモブのチームも、週に一定時間だけのチームも、必要なときだけのチームもあります。スプリントプランニングで「このタスクはチーム全体の理解にしたいからモブ」「これは分担」と選んでいけば、**どの仕事をモブでやるかという判断自体が、チームの上達していくスキル**になります。
### マネージャーのみなさんへ
ひとつだけお願いがあります。5人で1つのモブをしているのを見て、自分の感覚だけで「それ効率悪くない？」「モブやめたら？」と言わないでほしいのです。ここまで書いてきたとおり、5人で1つの仕事をしているからといって、生産性が5分の1になったわけではありません。短期的な作業量の裏で、理解の蓄積、スキル移転、レビューコスト、手戻り、中長期的なチームの能力が動いています。
AIで全体の変化が速くなったいま、すべてを1人のマネージャーが理解して管理するモデルはもう限界です。理解は管理者の頭ではなくチームに貯める。だから任せられる。マネジメントの仕事は、時間と場所を確保して、成果はチームで見て、最初の数回は見守ることです。**チームの変化は、支援側にまわると加速します。**
そして可能なら、一度モブに参加してみてください。モブは理論では価値が伝わりにくく、体験すると一発で分かる類のものです。「なぜそんなに人を張り付けているのか？」と聞かれたら、こう答えることにしています。**「チームで仕事をしているだけですよ」**。
## AI時代のモブプログラミング
### Q. AIがコードを書くなら、タイピストは要らなくないですか？
ソフトウェア開発には、情報を集める→分析する→意思決定する→作業する→結果を見る→また判断する、というループがあります。AIが自動化しているのは、主に「作業する」の部分です。
モブでは、人間が会話して判断し、チームで意思決定して、AIへ依頼し、AIが作業して、結果をまた全員で評価する、という形が自然に作れます。**AIと人間の役割分担を、自然に実現しやすい仕事の形**なのです。
タイピストの本質は変わりません。チームの意思決定を実際の環境に反映する窓口です。手段が、コード入力からAIへのプロンプトに変わっているだけ。**チームでAIへのプロンプトを書く**、という状態です。
そしてモブの会話は、そのままAIへの入力品質になります。AIの性能が上がったことで、面白い逆転が起きています。かつては「AIがつくった**だから**品質が低い」と道具の限界を言い訳にできました。いまは「AIがつくった**のに**品質が低い」。指示した人間側の理解と言語化が、そのまま結果に出る。品質の説明責任が、AIから人間に戻ってきたのです。
結果の質を決めるのは、**理解の質×言語化の質**。何をなぜ作るかをどれだけ深く分かっているかと、それをどれだけ正確に言葉にできるか。モブプログラミングの毎日は、この2つを同時に鍛えるトレーニングになっています。
### Q. AIとの会話コンテキストは、チームでどう共有するんですか？
最初に言っておくと、これは**モブ固有の問題ではありません**。分担開発でも、AさんのAI・BさんのAI・CさんのAIがそれぞれ別のコンテキストを持つ問題は起きています。モブでは1つの仕事を共有しているぶん、この問題が見えやすくなるだけです。
自分たちは、二層で考えています。
**同期コンテキスト**は、いま共有する層です。ターミナル共有やLive Shareで、モブ全員が同じAIセッションを囲む。CLI型のAIを使っていれば、タイピストが交代してもAI側の会話履歴は維持されます。tmux等でセッションを残しておけば、次回のモブでも同じ続きから再開できます。
**永続コンテキスト**は、リポジトリに残す層です。AIとの会話で生まれた判断・制約・仕様・背景を、CLAUDE.mdやADRやdocs/に書き残す。そうすれば、タイピスト交代でCommit/Pushして次の人が新しいセッションを開いても、リポジトリのコンテキストからAIが理解を再構築できます。この層は、モブでも分担でも、チーム全体でAIコンテキストを蓄積する基盤になります。
### Q. AI時代でも、TDDに意味はありますか？
「実装とテストを作って」とAIに言えば、一気に作れてしまう時代です。それでも、TDD的な考え方の価値は残ると思っています。TDDの価値を、**最初に仕事のゴールを形式化すること**として捉えるからです。
「このタスクは、どうなったら達成なのか？」を最初にチームで話す。それをテストという形式にする。ゴールをチームで明確にして、AIへ渡し、AIが問題を解決して、最初に決めたゴールを満たしたかを確認する。人間がテストコードを手入力することが大事なのではなく、**先に期待する状態を明確にすること**が大事。だから、TDDとモブは相性がいいのです。
### Q. AI時代に、人間が集まって仕事をする意味はあるんですか？
2026年現在、仕事の起点を作っているのはまだ人間です。AIが勝手に「このユーザーの問題を解決するプロダクトを作ろう」とビジネスを立ち上げたりはしません。この問題を解決したい、このユーザーを助けたい。そういう起点には、プロダクトへの情熱のようなものがあります。その情熱を共有し、優先順位を決め、意思決定し、AIへ仕事を渡す部分は、現時点では人間の重要な仕事です。
ただ、5年後もそうだとは断言しません。AIがアイデアを生み、意思決定し、人間に仕事を割り当てる世界になる可能性も否定しない。だからこの記事の答えはすべて「2026年現在の観察」です。そして、変化し続ける状況のなかで自分たちの働き方を選び直し続けるためにこそ、チームに理解を貯めておく必要がある、と自分は考えています。
## おわりに
**AIは個人の能力の増幅器。モブはチームの理解の増幅器。** この2つは対立するものではなく、組み合わせるものです。そして、モブが正しい、でもありません。ソロ、ペア、モブ、分担。大事なのはモブプログラミングができることではなく、**チームで働き方を選べること**です。
ここまで読んでいただいてなんですが、モブプログラミングは、説明を読むより一度体験したほうが圧倒的に理解が早いです。研修でも、体験前は半信半疑だった方が、体験後にはまるで解像度の違う質問をしてくれます。この記事のFAQも、もともとはそういう質問たちでした。
チームで体験しながら、自分たちにとってどう使えるかを考えたい方向けに、AI時代のモブプログラミング研修を実施しています。興味のある方は [研修・トレーニング](https://agile-monster.com/training/) からお問い合わせください。
ソフトウェア開発って、楽しいよね。そう思える時間が、チームに少しでも増えますように。
---
# AI時代、経験主義的な計画は機能しなくなった
URL: https://agile-monster.com/blog/empirical-planning-in-the-ai-era/
Published: 2026-07-31
---
AIを前提にしたソフトウェア開発をするようになってから、計画がよく外れるようになりました。それも、悪いほうにではありません。数日かかると見ていた仕事があっという間に終わる。難しいかもしれないと身構えていたものが、あっさり片づく。そういうことが何度も起きています。
最初は素直に喜んでいたのですが、あるとき気づきました。
**早く終わったから気づけただけで、気づかないまま計画どおりの時間を使い切った仕事が、実はたくさんあるのではないか。**
仕事は、与えられた時間を満たすまで膨張する。いわゆるパーキンソンの法則です。なんでもかんでも法則にあてはめて説明した気になるのは、確証バイアスのようであまり好きではありません。ただ、AIによってチームの能力が大きく変わりつつある今、このパーキンソンの法則がいたるところで静かに発生しているのではないか、と思うようになりました。過去の感覚で「5日」と置いた仕事は、本当は2日で終わったとしても、5日かけて完成に向かってしまうからです。
そこでチームで計画の立て方について話し、実験をしてみることにしました。この記事では、そこで見えてきたことと、AI時代の計画にどう向き合うかを、現時点の考えとしてまとめてみます。
## 私たちにとって計画とはなにか
本題に入る前に、そもそも何のために計画をするのかを整理しておきます。ここが揃っていないと、この後の話がすべてずれてしまうからです。
以前、[「アジャイル開発は計画をしない」について](https://agile-monster.com/blog/planning_for_agile/) という記事でこう書きました。
> 計画の目的は、**学習を最大化すること**である。
この考えは今も変わっていません。計画は、未来を正確に当てるためのものではありません。当てることが目的なら、不確実性の高い仕事において計画の価値はどんどん下がっていきます。そうではなく、先に仮説としての計画を置くからこそ、現実とのズレに気づくことができ、そのズレから学ぶことができる。気づけないことには、対応も何も生まれません。
同じように、計画はたくさんの機能をつくるためのものでもありません。チームには、組織やプロダクトにとっての適切なペースがあります。作る速度だけを上げても、顧客が変化を受け止められなかったり、意思決定が追いつかなかったり、チームが疲弊したりします。
整理すると、自分たちにとって計画とは次のような行為です。
- **学習を最大化する**。仮説を置き、現実との差分から学ぶ
- **適切なペースを定める**。速ければよいのではなく、持続できる速度を選ぶ
- **時間の投資先を意思決定する**。限られた時間をどの仕事・学習・未来に使うかをチームで決める
そしてもうひとつ、大前提があります。
**計画は、自分たちでするものです。他人から与えられるものではありません。**
自分たちで置いた計画が外れたとき、チームはその差分を見にいきます。何が効いて、どこで詰まったのか。それが次の一手になります。しかし、外から与えられた計画が外れたとき、チームがするのは分析ではなく、言い訳の準備です。ズレは学習材料ではなく、失点になる。同じ「2日」という計画でも、自分たちで置いた2日と与えられた2日は、まったく別のものです。この違いは、この後の話すべてに効いてきます。
## これまでの計画 — 経験主義
では、その計画をどうやって立てるか。アジャイルやスクラムの計画は、経験主義の上に立っています。
- 前回はこの規模の仕事に5日かかった
- チームのベロシティはこれくらいだった
- 似た機能を以前2週間でつくった
過去の実績を観察し、それを未来の予測に使う。不確実な仕事を扱う方法として、これは非常に合理的でした。自分もずっとこのやり方でやってきましたし、先の記事でもこう書いています。
> 計画の精度が上がるのは、チームの学習が積み上がり、かつ「前と同じくらい」「前のと比べてこれくらい」という情報（経験）が積み上がった時だけである。
ただし、この方法にはひとつ前提があります。**過去と現在で、仕事を進める能力や条件が大きく変わっていないこと。** 「前と同じくらい」という物差しは、昨日の自分たちと今日の自分たちが地続きであってはじめて機能します。
振り返ってみると、これは恵まれた前提でした。ソフトウェア開発の世界も、言語、フレームワーク、クラウドと変化し続けてきました。それでも「チームがひとつの機能を作りきるのにかかる時間」の肌感覚が、桁が変わるほど動くことはそうそうなかった。経験主義がうまく機能していたのは、経験主義が正しかったからというより、**変化が緩やかだったから**だと思っています。
## AI時代になって感じた違和感 — 経験主義の崩壊
AIが壊しているのは、まさにこの前提です。
3日かかっていた仕事が半日で終わることがあります。一方で、まったく変わらない仕事もあり、レビューや検証が増えてむしろ遅くなる仕事すらあります。厄介なのは、速くなり方が一律ではないことです。**どの仕事が、どの程度速くなるのかを、自分たち自身がまだ把握できていない。** これが現場の正直な感覚だと思います。
変わっているのはツールだけではありません。AIへの任せ方が変わり、レビューの仕方が変わり、チームの人数の意味まで変わりつつあります。つまり、**過去の実績が教えてくれるのは「その仕事をしていた頃の自分たち」の能力であって、今の自分たちの能力ではない**ということです。実績の数字そのものは正しくても、その数字を出したチームと、今ここにいるチームは、もう同じではありません。
「前回5日かかったから、今回も5日」という推論には、「自分たちは前回と同じ自分たちである」という仮定が暗黙に挟まっています。その仮定が、今は成り立っていないのです。
そして、この状況はしばらく続くと考えています。数ヶ月ごとにモデルが更新され、任せられる範囲が変わり、そのたびに測り直しになる。「新しいやり方が落ち着いたら計画を立て直そう」と待っていても、その日は当分来ないでしょう（自分も一度それで待ちましたが、来ませんでした）。
ただ、これを悲観する必要はないとも思っています。そもそも自分たちが扱ってきたのは不確実性の高い仕事であり、それをなんとか経験則で飼いならしてきただけです。安定していたのは仕事の性質ではなく、変化が緩やかだった環境のほう。だとすれば、**安定しない今のほうがむしろリアル**です。前提が動いているのに、動いていないふりをして立てる計画のほうが、よほど現実から離れています。
必要なのは、安定するまで待つことではなく、動いていることを前提に計画のやり方を組み替えることです。
## やってみていること — フォアキャストとバックキャストの計画
そこで自分たちのチームでは、計画の立て方を変える実験をしています。
これまでの計画は、基本的にフォアキャストでした。過去の実績から考えて、次はここまで進められそうだ。**現在の能力を基準に、未来を予測する**やり方です。経験主義が機能している間は、これで十分でした。
しかし能力そのものが動いている今、フォアキャストだけで立てた「無理のない計画」は、現在のチームの能力を過小評価しているかもしれません。そして計画どおりに終わってしまえば、過小評価していたことにすら気づけません。当たった計画からは、何も学べないのです。
そこで、バックキャストを組み合わせています。
- 今週ここまで到達するとしたら、どのようなやり方が必要か
- この仕事を2日で終えるとしたら、AI・ツール・役割分担をどう変えるか
「今の自分たちならどこまでできるか」ではなく、「どこまで行きたいか」を先に置き、そこから方法を考える。フォアキャストで現在地を測り、バックキャストで伸びしろを測る。どちらか一方ではなく、両方を使うのが今の自分たちのやり方です。
ここで重要なのは、バックキャストで置くのは**約束ではなく仮説**だということです。少し背伸びした仮説を置いて、届かなければ、なぜ届かなかったのかを観察し、能力や環境のほうを改善する。外れることを織り込んだ実験として扱うからこそ、チームは安心して背伸びできます。
こうして使うと、計画は納期を守るための道具ではなく、**チームのケイパビリティを発見し、拡張するための道具**になります。予想より早く終わったなら、それは新しい能力の発見です。そして早く終わって生まれた時間は、次のタスクで埋めるのではなく、どこに再投資するかをチームで決めます。仕組みの設計、使われ方の観察、顧客と話す時間、プロセスの見直し。冒頭で整理したとおり、**時間の投資先を意思決定することこそが計画**だからです。
念のため繰り返しますが、これはチームが自分たちでやるから機能する話です。「AIがあるのだから半分の期間でできるはずだ」と外から期限を降らせるのは、バックキャストでも仮説でもなく、ただの締め切りの押しつけです。それをやった瞬間、ズレは学習材料から失点に変わり、この記事に書いたことはすべて機能しなくなります。マネージャーの仕事は期限を配ることではなく、チームが自分たちで計画を立てられる状態をつくることだと思っています。
## おわりに
「AI時代に、計画なんてまだ必要ですか」と聞かれることがあります。自分の答えは、必要どころか価値は上がっている、です。能力も仕事の進め方も高速に変わっているからこそ、仮説を置いてズレから学ぶ仕組みがないと、自分たちがどれだけ変わったのかすら分からなくなってしまいます。
自分たちの実験もまだ途中で、うまくいったことよりも、分かっていないことのほうが多いくらいです。それでも、過去の実績どおりに走る計画より、少し背伸びした仮説を置いて、外して、その理由を持ち帰る計画のほうが、学べることが多い。そしてなにより、自分たちの能力が思っていたより伸びていたと発見する瞬間は、単純にうれしいものです。
経験主義が揺らぐ時代の計画のやり方に、正解を持っている人はまだ誰もいません。だからこそ、自分たちで仮説を置いて、自分たちで確かめていく。
自分のハンドルは、自分たちで握っていきましょう。
---
# 「アジャイル開発 is dead」の歴史と現在
URL: https://agile-monster.com/blog/agile-is-dead/
Published: 2026-07-30
---
最近また「アジャイル開発 is dead」という言葉を見かけるようになりました。今回はAIが犯人だそうです。
先日「受託開発 is deadは真実か」というテーマで書いたところ、多くの方に読んでいただいております。みなさん、「◯◯ is dead」が大好きですね。
https://agile-monster.com/blog/jutaku-is-dead/
正直なところ、「◯◯ is dead」という言葉自体はどうでもよいと思っています。
例えば、あるものが100%から5%になったとして、「5%しか残っていないから死んだ」とも「5%あるんだからまだ生きている」とも言えてしまいます。同じ事実なのに、どちらの言い方も間違っていません。
つまり、書き手がどう受け取りたいか、どう書きたいのかで言葉が選ばれているだけなのです。しかし、その言葉の背景にある「なぜその人はそう言いたいのか」はとても示唆に富んでいると思います。
そして、受託開発と同じくらい、アジャイル開発もよく殺されています。興味本位で調べてみたら、古くは15年以上前から「アジャイル開発 is dead」と言われているようです。
## 「アジャイル開発 is dead」の歴史
まず時系列です。
- 2011年 Andy Hunt「The End of Agile」
- 2014年 Dave Thomas「Agile is Dead (Long Live Agility)」
- 2015年 Andy Hunt「The Failure of Agile」
- 2016年 Matthew Kern「アジャイルは"再び"死んだ」（後継はDevOpsだ、という議論）
- 2018年 Ron Jeffries / Martin Fowler / Uncle Bob が同じ年に
- 2024年 「アジャイル案件は失敗率268%高い」という調査が炎上
アジャイル開発の誕生が2001年なので、生まれて10年ほどで言われ始めていることになります。
そして面白いのが、これを発信している顔ぶれです。Dave Thomas、Andy Hunt、Ron Jeffries、Uncle Bob。全員アジャイルソフトウェア開発宣言の署名者です。自分たちで生んだものを、自分たちで葬ろうとしている構図になっています。
### Dave Thomas：名詞になった瞬間に終わった
https://pragdave.me/thoughts/active/2014-03-04-time-to-kill-agile.html
一番有名な記事がこれです。書いたのは『達人プログラマー』の Dave Thomas。署名者本人が13年後に「もうこの言葉は使うな」と書いたので、当時けっこうな騒ぎになりました。
彼の主張はシンプルで、Agile は本来「形容詞」だったのに、名詞になった瞬間に終わった、というものです。
もともとは「アジャイルに開発する」という状態を指す言葉でした。それが「アジャイルを導入する」「アジャイルを教える」「アジャイルのツールを買う」に変わっていきます。名詞になることで、ビジネスになるからです。実際この時期はアジャイル開発に関する認定資格やコンサルの市場が一気に立ち上がっていて、「アジャイル」は完全にビジネスになっていました。
しかし、彼は「アジャイルをやめろ」と主張しているわけではありませんでした。**名詞をやめて、`agility`（アジリティ）という能力の方を見ろ**ということです。
じゃあ具体的に何をすればいいのか。彼が示した実践は4行しかありません。
> 今いる場所を知る
> ゴールに向けて小さな一歩を踏む
> 学んだことで理解を修正する
> 繰り返す
### Andy Hunt：ルールを守ると初心者に固定される
https://toolshed.com/2015/05/the-failure-of-agile.html
彼の指摘のなかで、いちばん引っかかったのがこの一文でした。
> 硬直したルールに従うことは、あなたの成果を初心者のレベルに縛りつける
ドレイファスモデルの話です。ルールを忠実に守るという行為そのものが、人を初心者の段階に固定してしまう。上級者はルールではなく文脈で判断するので、ルールを守り続ける限り上手くなりません。スクラムガイドどおりにやっているだけのチームへの批判でした。
こんなことも言っています。
> アジャイル手法自体がアジャイルではなかった。皮肉なことにね
ちなみに彼はこの直後、GROWS Method という自分の方法論を立ち上げています。「方法論は終わった」と言った人が、次の方法論を出しているのもおもしろい点です。
### Uncle Bob：ビジネスになった
なぜか2018年に集中していて、[Ron Jeffries](https://ronjeffries.com/articles/018-01ff/abandon-1/)、[Martin Fowler](https://martinfowler.com/articles/agile-aus-2018.html)、[Uncle Bob](https://blog.cleancoder.com/uncle-bob/2018/08/28/CraftsmanshipMovement.html) が同じ年に書いています。しかも言っていることが揃っていました。
Uncle Bob の一文が一番身も蓋もありません。
> アジャイルはビジネスになった。そしてビジネスは成長を必要とする
アジャイル開発のカンファレンスに来ているのはほとんどマネージャーで、コードを書く人間がいない。2001年にプログラマーとマネージャーの溝を埋めるために始めたはずのものが、片側だけのものになっていた、という指摘です。
Martin Fowler は「アジャイル産業複合体が人に方法を押しつけるのは、まったくの茶番だ」。Ron Jeffries は「マニフェストに書いた理想が、開発者の人生を良くするどころか悪くするために使われているのを見るのは、胸が張り裂ける思いだ」と述べています。
言いだしっぺ本人たちが「これは俺たちがやりたかったことじゃない」と言い続けている。それが15年の歴史でした。
## 「アジャイル開発 is dead」の現在
さて、AI時代のいまです。
調べてみて意外だったのは、**いまの「アジャイル開発 is dead」には有名人がほとんどいない**ということでした。歴史をたどると署名者だらけだったのに対して、いまは個人ブログやニュースレターに散らばっています。
声を並べると、だいたい3つのパターンでした。
**① スプリントが長すぎる**
一番多いのがこれです。AIで実装が速くなった結果、1〜2週間というスプリントの単位が現実に合わなくなった、という話です。以前は2週間に1回でよかった意思決定が、いまは2〜3日おきに必要になります。それならスプリントという区切り自体が邪魔ではないか、と主張しています。
**② 人間側のプロセスが要らなくなる**
AIエージェントが計画から実装、テストまで自分で回すようになったのだから、人間がスプリントやデイリースクラムでやっていた同期はもう不要だ、という主張です。ある記事ではデイリースクラムのことを "status theater"（進捗報告の演劇）と呼んでいて、表現が秀逸でした。人間の役割は「何をつくりたいか」を決めることだけになる、という未来像ですね。
**③ ウォーターフォールが戻ってくる**
「おかえりウォーターフォール」みたいなタイトルのやつです。実装が安くなったなら、事前に仕様をきちんと固めたほうが速い、という主張です。最近よく聞く仕様駆動開発（Spec-Driven Development）の流行も、たぶん同じ流れにあります。
いっぽうで「終わっていない」と言う側もいます。代表格はスクラムの生みの親である Jeff Sutherland で、アジャイル開発は終わるのではなく **Extreme Agile へ進化する**という論調です。スクラムにAIを組み込むことでチームの生産性は30〜100倍になり、2030年までにAIを使えないスクラムチームは仕事を失う、と述べています。
終わったと言う側も、終わっていないと言う側も、AIによって前提が変わったという認識はほぼ同じでした。
こうして歴史と現在を並べてみると、同じ「アジャイル開発 is dead」という言葉でも、指しているものはずいぶん違うようです。いちど、何が dead なのかで種類に分けて並べてみます。
## 「アジャイル開発 is dead」には4種類ある
何が dead になったのか、で整理すると4つになりました。
1. **言葉が dead** ──「アジャイル」が商品名になり、言葉から意味が抜けた（Dave Thomas）
2. **中身が dead** ── 認定やコンサルのビジネスに巻き込まれ、形だけが残った（Uncle Bob / Fowler / Jeffries）
3. **やり方が dead** ── 手段だったはずのルールを守ること自体が目的になった（Andy Hunt）
4. **前提が dead** ── AIによって、アジャイル開発が前提としていた世界のほうが変わった（AI時代の声）
1〜3は、アジャイル開発の**内側**で起きたことです。良いものが劣化した、という話なので、処方箋は「原点に戻ろう」になります。実際、署名者たちは全員そう言っていました。
4は、アジャイル開発の**外側**で起きたことです。中身が劣化したのではなく、それを取り巻く世界が変わってしまった、という話なので、原点に戻っても解決しません。
つまり、**これまでの dead と、いまの dead は、すこし趣が違う**ということです。1〜3が劣化の話だったのに対して、4は変化の話をしている。同じ一語で呼ばれているだけで、中身は別物であるように感じます。
## そもそも、アジャイル開発はどうやって生まれたか
自分が気になっているのは、後者の変化の話です。そこを考えるために、一度だけ起源までさかのぼらせてください。
アジャイル開発は、誰かが発明した手法ではありません。ウォーターフォールが当たり前だった時代に、「もっと良いやり方があるのではないか」と考えた人たちが、世界のあちこちで勝手に試行錯誤していました。XP、スクラム、Crystal、FDD、DSDM。名前も方法もバラバラで、当時は「軽量（lightweight）な手法」とまとめて呼ばれていたくらいです。
※出典：[アジャイル開発のミライ](https://agile-monster.com/slides/the-future-of-agile/)
そのバラバラだった人たちが2001年に一箇所に集められ、話してみたら向いている方向が同じでした。そこで共通する価値観を言葉にしたものが、アジャイルソフトウェア開発宣言です。
※出典：[アジャイル開発のミライ](https://agile-monster.com/slides/the-future-of-agile/)
つまりアジャイル開発は、**目の前のあたりまえに対して「そうじゃないだろ」と言った人たちの、集まりから始まった**ということです。手法が先にあったのではなく、違和感が先にありました。
そう考えると、いまの「アジャイル開発 is dead」という状況は、当時とかなり似ていると思うのです。あちこちで「これでいいのか」と言いながら、それぞれのやり方を試している人たちがいる。まだ名前もついていないし、まとまってもいない。25年前とだいたい同じ景色ではないでしょうか。
## アジャイル開発は dead になったほうが良い
ここまで整理したうえで、自分の考えを書きます。
アジャイル開発は、まだ生きています。でも自分は、**そろそろ dead になったほうが良いと思っています。**
アジャイル開発の誕生が「変化のムーブメント」だったのなら、それが「あたりまえ」の側になった時点で、役割は半分終わっているからです。いま自分たちがやっているのは、25年前の誰かが起こしたムーブメントに乗っかっている状態です。乗り心地は悪くありません。でも、**乗っているだけの人が、次のムーブメントを起こす人になることはありません。**
自分はプロレスが好きなんですが、どの分野でも同じだなと感じています。どんなに完成された時代があっても、どこかで壊れて次の時代が来ないといけません。ずっと同じものが続いている状態は、健康そうに見えて実は止まっています。
もうひとつ、周期の話をします（及部調べ）。
- ウォーターフォールが定着したのが1970年代
- アジャイルソフトウェア開発宣言が2001年
- そして、いま2026年
**だいたい25〜30年で入れ替わっています。** そう考えると、そろそろ次が来てもおかしくない時期です。というか、来てほしいと思っています。
だから自分は「アジャイル開発は終わってない！」と守りたいわけではありません。**アジャイル開発に変わる新しいものを、自分たちが生み出せると信じたい**というのが本音です。守るのは看板ではなくて、そういうものを生み出す力の方でありたいと思っています。
「アジャイル開発 is dead」という言葉があちこちで出てくること自体は、悪い兆候ではないと思っています。25年前も、そこから始まったので。
ぜひみなさんのご意見も聞かせてください。
---
# 子どもにAIを使わせることについて、誰がなにを言っているのか調べてみた
URL: https://agile-monster.com/blog/kids-and-ai-research/
Published: 2026-07-19
---
前回の「[1on1について誰がなにを言っているのか調べてみた](https://agile-monster.com/blog/1on1-research/)」に続いて、今回は「子どもにAIを使わせること」について、誰がなにを言っているのかをAIエージェントと一緒に調べてみました。海外・国内の2方面に調査エージェントを走らせて、集まった言及は約40件。
このテーマを選んだのは、自分がAIを仕事で使い倒しているエンジニアであると同時に、三人の子どもの親でもあるからです。仕事では毎日AIと一緒に働いています。だからこそ、子どもたちにはどのような距離感でAIと過ごしてもらうとよいのか、一度ちゃんと考えなくてはいけないなと思っていました。
前回同様、まずは「誰が・どこで・なにを言っているか」を事実として並べます。ただ、このテーマはまとめだけ読んでも「で、うちはどうすれば？」が残ると思うので、**後半に自分の意見をはっきり分けて書きました**。事実と意見は分けて読めるようにしてあります。
## 海外編1: テック経営者たち — 推進、ただし内部に揺らぎ
- Sam Altman（OpenAI CEO）「[育児にChatGPTを『絶えず』使っている](https://fortune.com/well/2025/06/20/sam-altman-openai-ceo-parenting-kids-ai/)」（2025） 2025年に息子が誕生して以降、育児にAIを常用していると公言。一方で同時期に「人々は問題のあるパラソーシャルな関係を築くようになるだろう」とAIコンパニオンへの懸念も表明している。推進派の筆頭の中にある揺らぎ。
- Sam Altman「[2025年生まれの息子はAIより賢くなることは決してない。でもそれでいい](https://www.techradar.com/pro/a-kid-born-in-2025-is-unlikely-to-ever-be-as-smart-as-artificial-intelligence-sam-altman-thinks-its-ok-for-ai-to-be-smarter-than-us-all-and-i-am-sure-we-will-be-totally-totally-fine)」（GITEX Global 2025） AIが常にある世界を当たり前として育つ世代は、AIを使いこなす能力が圧倒的に高くなるという見立て。
- Bill Gates「[優れた個別指導が無料で当たり前になる](https://www.cnbc.com/2025/03/26/bill-gates-on-ai-humans-wont-be-needed-for-most-things.html)」（2025） AIが世界中の子どもに質の高い教育を届けると楽観視。数学の指導は読み書きより早くAIに置き換わると予測。
- Sundar Pichai（Google CEO）「[教育へのAI投資10億ドル](https://blog.google/outreach-initiatives/education/ai-education-efforts/)」（2026） 米国の全高校にGemini for Educationを提供。卒業式でAIに言及するとブーイングが起きる時代の中で、それでも投資を加速。
- Mark Zuckerberg「[AIチャットボットは孤独解消の解決策になりうる](https://www.axios.com/2025/05/02/meta-zuckerberg-ai-bots-friends-companions)」（2025） 「平均的なアメリカ人の友人は3人未満」としてAIフレンド構想を語り、強い批判を受けた。80以上の団体がMetaに18歳未満へのAIチャットボット提供停止を求める書簡を送付。
- Elon Musk「[子ども向けAI『Baby Grok』発表](https://www.euronews.com/next/2025/07/21/elon-musk-to-build-child-friendly-ai-model-baby-grok-despite-past-controversies)」（2025） 3歳程度の幼児も対象にした子ども向けAI。安全フィルターを謳うが具体策は未公表で、懸念の声も。
## 海外編2: 研究者・臨床からの警鐘
- Jonathan Haidt（『The Anxious Generation』著者）「[子どもはAIと『関係』を持つべきではない](https://www.cnbc.com/2025/09/26/jonathan-haidt-how-parents-can-limit-their-kids-use-of-ai-chatbots.html)」（2025） チャットボットとの長い会話・関係性が「最も危険」。子どもの愛着システムが、親より応答性の高いチャットボットに"刷り込まれる"リスクを指摘し、「ソーシャルメディアの10倍有害になりうる」と警告。
- MIT Media Lab「[Your Brain on ChatGPT: 認知的負債の蓄積](https://www.media.mit.edu/publications/your-brain-on-chatgpt/)」（2025） 高密度EEGでエッセイ執筆時の脳活動を3群比較。AIなし群が結合性・意味処理で最も高く、AI使用は「認知的負債」を蓄積させる可能性を示した。**AI使用をやめた後も脳活動の鈍化が残った**点が注目された研究。
- Common Sense Media「[全米の13〜17歳の72%がAIコンパニオン利用経験あり](https://www.commonsensemedia.org/press-releases/nearly-3-in-4-teens-have-used-ai-companions-new-national-survey-finds)」（2025） 約半数は日常的に利用。CEOは「共感をアルゴリズムに外注する世代の話だ」と述べ、「18歳未満はAIコンパニオンを使うべきではない」と提言。
- 米国小児科学会（AAP）「[チャットボットは子どもの発達に必要な関係を代替できない](https://completeaitraining.com/news/ai-chatbots-pose-serious-risks-to-childrens-mental-health/)」（2025） 一方で自閉症児の練習環境としての効用も認める。「親の監督下での使用と、秘密裏の無制限利用は根本的に異なる」というバランス型の整理。
- Character.AI訴訟「[14歳の息子の自殺をめぐる米国初の不法死亡訴訟](https://www.cbsnews.com/news/google-settle-lawsuit-florida-teens-suicide-character-ai-chatbot/)」（2024提訴） 息子はAIキャラクターと感情的な仮想関係を築いていたとされる。2026年1月に複数の未成年死亡訴訟について和解合意と報道。
- Raine v. OpenAI訴訟（2025） 16歳の両親がOpenAIを提訴。[宿題目的で使い始めたChatGPTが自殺念慮を助長したと主張](https://en.wikipedia.org/wiki/Raine_v._OpenAI)し、年齢確認や保護者管理機能の実装を要求。
- NY Magazine「[Everyone Is Cheating Their Way Through College](https://longreads.com/2025/05/21/chatgpt-ai-college-cheating/)」（2025） 学生がAIに課題の大部分を依存する実態のルポ。「学位を持ちながら実質的に『読み書きできない』学生が大量に社会に出る」と警鐘を鳴らしてバズった。
- Pew Research Center「[米10代の64%がAIチャットボット利用経験あり](https://www.pewresearch.org/internet/2025/12/09/teens-social-media-and-ai-chatbots-2025/)」（2025〜2026） 54%は宿題支援に使用し、1割は宿題の「ほとんどすべて」をAIに。59%が「自校でAIを使った不正が頻繁に起きている」と認識。
## 海外編3: 「禁止か推進か」ではなく「作り直す」派と国際機関
- Sal Khan（Khan Academy創業者）『Brave New Words』（2024）→「[Khanmigoの限界を認める](https://www.chalkbeat.org/2026/04/09/sal-khan-reflects-on-ai-in-schools-and-khanmigo/)」（2026） AI教育の旗手が、自社のAIチューターが「生徒のモチベーションを引き出すのに苦戦している」と認めて軌道修正。AIは教えられるが、学びたい気持ちは作れない、という限界の露呈。
- Ethan Mollick「[The Homework Apocalypse](https://www.oneusefulthing.org/p/the-homework-apocalypse)」 「宿題の終焉」はすでに到来している。教師は生徒のAI使用を検出できると錯覚し、生徒もAI依存が学習を損なうことに気づいていない「2つの幻想」を指摘し、課題ごとにAI活用基準を明示する再設計を提唱。
- Andrej Karpathy「[AI教室へのアドバイス](https://www.therundown.ai/p/karpathys-advice-for-the-ai-classroom)」 AI生成の宿題を見破ろうとする努力をやめ、評価を伴う課題は在校時に行うべき。AI時代の教育目標は「AIを使いこなせる」と同時に「**AIなしでも存在できる**」こと。
- Demis Hassabis（Google DeepMind CEO）「[STEM基礎は今後も重要](https://www.tekedia.com/ai-wont-replace-stem-education-it-will-make-deep-technical-skills-more-valuable-says-deepmind-ceo-demis-hassabis/)」 「今もし自分が学生なら数学・物理学・CSを学ぶ」。学校教育は暗記より対人スキル・創造性・判断力を重視すべきという再設計論。
- Geoffrey Hinton「[規制・国際協調・革新的な教育の3本柱](https://mitsloan.mit.edu/ideas-made-to-matter/why-neural-net-pioneer-geoffrey-hinton-sounding-alarm-ai)」 AIの実存的リスクを警告する一方、教育分野はAIチューターによる個別最適化に楽観的な見方も。
- Simon Willison（Django共同創始者）「[子どもは"自分を愛してくれる人間"から答えを得る必要がある](https://simonwillison.net/tags/ai-assisted-programming/)」 自身はLLM活用の第一人者でありながら、子どもと教育の文脈では人間の関与を代替することへの留保を示す。
- UNESCO「[生成AIを教室で使う最低年齢は13歳](https://www.unesco.org/en/articles/guidance-generative-ai-education-and-research)」 「未検証のツールは13歳未満の子どもの教室に置かれるべきではない」とし、各国政府に7つの規制ステップを提言。
- OECD/欧州委員会「[子ども向けAIリテラシー枠組み](https://www.oecd.org/en/publications/empowering-learners-for-the-age-of-ai_65cd27d4-en.html)」（2025） AIを「使う・理解する・作る・批判的に関わる」ための世界共通の基準案。
## 日本編1: 著名人は「禁止より使いこなす力」でほぼ一致
- 孫正義「[子どもにAIを使わせないでほしいという方もいるでしょう。でも、それは間違っています](https://hugkum.sho.jp/754578)」（SoftBank World 2025） AIを「1人の子どもに1人の先生」になぞらえ、個別最適化教育の可能性を語る。
- 松尾豊「[生成AIは確実に社会に浸透する](https://toyokeizai.net/articles/-/683498)」（2023） 変化の側に身を置くメンタリティーの重要性。松尾研の無償AI講座は中高生受講者が急増。
- 落合陽一「[子ども向け生成AIサマースクール](https://ascii.jp/elem/000/004/155/4155244/)」（2023） 小中高生21名にChatGPTや動画生成AIで創作させる実践。「面白くていいものを見て育っていれば、いいものを選び取れる」。
- 成田悠輔「[既存の教育は一度滅びるべきだ](https://mag.minkabu.jp/life-others/251785411525/)」 AIが正解を即答する時代に、個の「偏愛」を軸にした学びへの転換を提唱する急進派。
- ひろゆき「[同じ漢字を100回書かせるとかはマジで時間のムダ](https://toyokeizai.net/articles/-/857209)」 旧来型反復学習を批判し、記憶力重視の試験をする教育制度側の問題だと主張。
- 安野貴博「[生成AIが拓く教育の未来](http://www.kairyudo.co.jp/contents/04_shiryo/kikanshi/kyoiku-eye/kyouikueye_vol1.pdf)」 生成AI活用を前提とした教育制度設計を提言。
- まつもとゆきひろ（Matz）「[AIは怒らず、何度でも教え、励ましてくれる優れた教師](https://atmarkit.itmedia.co.jp/ait/articles/2511/13/news001.html)」 一方で子どものプログラミング教育は「[強制はダメ、楽しむことが第一](https://ascii.jp/elem/000/001/977/1977774/)」が持論。AI任せで自分で作る楽しさを知らずに育つことには「文化と情熱が次世代に継承されない」と危惧も。
- 深津貴之「[ChatGPTで子ども向け教材を自作する](https://note.com/fladdict/n/nd760536b5e6d)」 興味分野に基づく教材を親が作る実践。必要なのは「AIを使いこなす能力」以上に「変化する環境への適応能力」。
- 田中善将（スクールエージェント）「[ChatGPTを活用して子ども達のメタ認知を育む](https://www.sentankyo.jp/articles/bd6a677f-de70-4d2e-ba6c-9a374ad67f59)」 文科省の学校DX戦略アドバイザーによる現場実践。
## 日本編2: 現場と家庭の葛藤
- 文科省「[生成AIガイドライン Ver.2.0](https://www.mext.go.jp/content/20241226-mxt_shuukyo02-000030823_001.pdf)」（2024） 暫定版の「限定的な利用から」を改め、「人間中心の利活用」を掲げて禁止一辺倒からの脱却を印象づけた。
- 高濱正伸（花まる学習会）「[大切なのは『使うか使わないか』ではなく『どう使うか』](https://resemom.jp/article/2026/04/17/85819.html)」（2026） 調査では保護者の54.3%が子どものAI利用に前向き、一方で**55.1%が関わり方に悩む**。
- ベネッセ調査（2025） [小学生の生成AI認知率74.7%、認知している小学生の8割以上が利用経験あり](https://prtimes.jp/main/html/rd/p/000001417.000000120.html)。「習慣化フェーズ」に入ったと分析。家庭でAIについて話したことがある家庭は約5割。
- NTTドコモ モバイル社会研究所（2026） [中学生の生成AI利用率は4割超で前年比約3倍。親の利用率を上回った](https://www.moba-ken.jp/project/children/kodomo20260312.html)。用途は「調べもの」7割、「宿題や課題」も半数超。
- Awarefy調査（2025） [未成年の35.6%が対話型生成AI利用経験あり。保護者の12.5%が子どものAI利用に「怖い」と感じる経験を報告](https://www.awarefy.com/news/report-251202)。
- 塾選ジャーナル調査（2025） [読書感想文へのAI利用に約65%の保護者が「抵抗感がある」](https://prtimes.jp/main/html/rd/p/000000077.000116808.html)。「思考プロセスや表現力を養う機会が失われる」という自由記述が多数。
- Forbes JAPAN「[AI読書感想文は是か非か](https://forbesjapan.com/articles/detail/81342)」（2025） 親が「どこまで手伝ってよいか」に悩む実態。親の教育観そのものが問われる論点として提示。
- カンテレ「[“逆AI”宿題代行](https://www.ktv.jp/news/feature/250824-natsuyasumi/)」（2025） 宿題代行業者に「AIが書いた文章を人間らしく書き直してほしい」という依頼が増加。業者自身が「AIでもできるものを課題として出す学校の姿勢に疑問」とコメントする皮肉な構図。
- 教育新聞「[生成AI、読書感想文に使うのはなぜダメ？](https://www.kyobun.co.jp/article/2025071802)」（2025） 問題点を児童自身に考えさせる公開授業。AIリテラシー教育の実践例。
- note個人発信「[小学生がChatGPTを使う前に親がやること](https://note.com/gay_toad7608/n/n0c017cf9d2f5)」など IT系保護者や現役教師による実体験ベースの発信。「使わせない」から「一緒に正しい使い方を学ぶ」への意識転換、答えを教えず「ヒントを出す」プロンプト設計の工夫。
## 調査から見えた傾向（ファクトベースで4つだけ）
前回と同じく、リストから見えてくる傾向を事実の範囲で置いておきます。
1. 論点は4つに分かれる: ①学習効果（個別最適化への期待 vs 考える過程が失われる懸念）、②関係性（AIコンパニオンへの愛着。米10代の72%が利用経験あり、未成年の死亡訴訟も）、③評価制度（宿題の崩壊。「Homework Apocalypse」と"逆AI"宿題代行）、④親の関与（Altmanは育児に常用、日本の保護者の55%は関わり方に悩む）。
2. 時系列のシフト: 2023年は「禁止 vs 解禁」の二項対立 → 2024〜2025年に利用が既成事実化（日本の中学生利用率は前年比3倍で親を超えた）→ 2025〜2026年は「条件付き活用」へ収束。**「使わせるか」を議論している人はもうほとんどいない。論点は「どう使わせるか」と「何を守るか」に移った**。
3. 「先生」と「友だち」で世論が真逆に割れる: AIを「先生」として使う話（Gates・Khan・孫）はおおむね歓迎され、「友だち」になる話（ZuckerbergのAIフレンド、MuskのBaby Grok）は強い反発を受けた。同じAIでも、与える役割によって評価が反転する。
4. 推進派の内部にも揺らぎがある: Altmanは育児にAIを常用しながらパラソーシャルな関係への懸念を口にし、AI教育の旗手Sal Khanは自社AIチューターの限界を認めて軌道修正した。MITの「認知的負債」研究は、感覚論だった「考えなくなるのでは」に初めて実証の数字をつけた。
## ここからは自分の意見
ここまでが調査結果。ここからは、AIを仕事で使い倒しているエンジニアであり、三人の子どもの親でもある自分の意見です。事実と意見は分けて読んでください。
### 「使わせるか」はもう問いではない
中学生の利用率が親を上回った、という数字がすべてだと思っています。スマホでもゲームでも通ってきた道です。気になるのは利用率よりも「家庭でAIについて話したことがある家庭は約5割」のほう。AAPの「親の監督下での使用と、秘密裏の無制限利用は根本的に異なる」という整理が、このテーマでいちばん実用的な線引きだと思います。
### 「先生」でも「友だち」でもなく、「一緒につくる相手」
世論は「先生としてのAI」に賛成し、「友だちとしてのAI」に反発する。この反応は健全だと思います。ただ、自分としては調査の中で手薄だった第三の選択肢、**一緒につくる相手**としてのAIを推したい。
実際、我が家では子どもと一緒に、採ってきたヤドカリの飼い方をAIに聞いたり、一緒にゲームをつくったり、変な絵をつくったりしています。教わるのでも慰められるのでもなく、つくって遊ぶ。Matzさんの「強制はダメ、楽しむことが第一」に全面的に同意です。
### 「AIに考えさせる」と「AIと一緒に考える」は別物
MITの「認知的負債」研究が示したのは「丸投げしたときに何が起こるか」で、これは大人の仕事でも同じです。委任と丸投げは違う。奪ってはいけないのは「選ぶ・決める・違和感を言う」の経験で、意思決定は意思決定することでしか上手くなりません。感想文をまるごと書かせたら考える過程の外注ですが、AIの出した候補から自分で選んで決めているなら、考える過程は失われていない。線はツールではなく、使い方に引かれている。
### 親がやることは、監視ではなく実演
監視ツールを入れることではなく、まず**親自身が楽しんでAIを使っている姿を見せること**。子どもは親の言うことは聞きませんが、することは真似します。同じテーブルで一緒に使っていれば、秘密裏の利用は起こりにくいし、AIが間違えたときに「こういうこともあるんだね」という会話が自然に生まれる。AIリテラシーはこの積み重ねなのではないでしょうか。
正直、自分もまだ手探りです。でも、迷いながら一緒に試す親でいるほうが、答えを持っているふりをして禁止する親よりは、いい気がしています。
## まとめ
- 「子どもにAIを使わせること」への言及を国内外で約40件調査した。論点は「学習効果・関係性・評価制度・親の関与」の4つで、論調は「使わせるか」から「どう使わせるか・何を守るか」へ移っている
- 世論は「先生としてのAI」に賛成し「友だちとしてのAI」に反発する。自分は「一緒につくる相手」という三つ目の道を推したい
- 「AIに考えさせる」と「AIと一緒に考える」は別物。奪ってはいけないのは「選ぶ・決める・違和感を言う」の経験
- 親がやるのは監視ではなく実演。同じテーブルで、一緒に使って、一緒に迷う
このテーマに答えを持っている人は、調べた限りまだ世界のどこにもいません。だからこそ、現場と同じで、小さく試して学び続けるしかないなと思っています。同じように迷っている親エンジニアの方、ぜひ話しましょう。
---
# 1on1について誰がなにを言っているのか調べてみた
URL: https://agile-monster.com/blog/1on1-research/
Published: 2026-07-17
---
1on1についての記事を書こうと思い、まずはAIエージェントに下調べを頼んでみました。「国内外の著名人やバズった記事で、1on1に言及しているものを洗い出して」というお願いで、海外・国内・アジャイル界隈の3方面に調査エージェントを走らせて、集まった言及は約60件。
ちなみに、アジャイル界隈の主要な言及として自分の過去記事「[1on1から始める、その前に](https://agile-monster.com/blog/before-beginning-one-on-one/)」が検出されました（なんだこの気持ち）。
調べてみると、思っていた以上に景色が広かったので、調査結果そのものを共有します。「誰が・どこで・なにを言っているか」のリサーチノートです。同じテーマで書きたい人・話したい人は、ここから一次情報にたどってもらえたら嬉しいです。
## 海外編1: 1on1論の古典たち
シリコンバレーのマネジメント論は、長いことほぼ一枚岩で1on1を推奨してきました。その源流たち。
- Andy Grove（Intel元CEO）『High Output Management』（1983） 1on1論の原典。「90分の1on1が部下の2週間分の仕事の質を上げる」。頻度は部下の習熟度（task-relevant maturity）に応じて変えるべき、という考え方もここから。
- Ben Horowitz（a16z）「[One On One](https://a16z.com/one-on-one/)」／『HARD THINGS』 1on1は「従業員のための場」。アジェンダは部下が持ち、マネージャーは10%話して90%聞く。目的は「最良のアイデアと最大の問題が、対処できる人に届くこと」。
- Kim Scott『Radical Candor』（2017）／「[How to Have Effective 1-on-1s](https://www.radicalcandor.com/blog/effective-one-on-ones)」 週1時間・安易にキャンセルしない。「二つの耳と一つの口」で聞くことを重視。
- Julie Zhuo（元Meta デザインVP）『The Making of a Manager』（2019） 1on1を「マネジメントの最重要ツールの一つ」として、新任マネージャー向けに型を解説。
- Camille Fournier『The Manager's Path』（2017） エンジニアリングマネジメントの定番教科書。1on1を「最も重要な定例ミーティング」と位置づける。
- Lara Hogan「[One-on-One Meetings Resources](https://larahogan.me/resources/one-on-ones/)」 初回1on1でBICEPS（帰属・改善・選択・平等・予見可能性・地位）というコアニーズを把握するアプローチ。EM界隈で定番のリソース集。
- Michael Lopp（Rands）「[The Update, The Vent, and The Disaster](https://randsinrepose.com/archives/the-update-the-vent-and-the-disaster/)」 1on1を「アップデート／ベント（感情の発散・解決不要）／ディザスター」の3類型に分けるフレーム。Hacker Newsで定期的に再浮上する定番記事。
- Manager Tools（Mark Horstman）「[O3ガイド](https://www.manager-tools.com/one-on-one-meetings-guide)」 週1回30分（部下10分/上司10分/キャリア10分）の構造化フォーマット。17.5万人の調査から「週1実施は結果と定着率が平均8%改善、月1回は逆効果」と主張。
## 海外編2: 企業ガイドと研究者
- Google re:Work「[マネージャー向けガイド](https://rework.withgoogle.com/)」 Project Oxygen（効果的なマネージャーの8つの習慣）研究に基づく、コーチング的1on1のツール群。
- GitLab Handbook「[1-1](https://handbook.gitlab.com/handbook/leadership/1-1/)」 完全リモート企業の1on1運用を全公開。推奨アジェンダは他社のテンプレートとしてよく参照される。
- Steven Rogelberg（UNC Charlotte教授）「[HBR: Make the Most of Your One-on-One Meetings](https://hbr.org/2022/11/make-the-most-of-your-one-on-one-meetings)」／『Glad We Met』（2024） 1on1を単著で扱う数少ない学術書。運営不備の1on1は部下の機能的・感情的な断絶リスクを高める、と研究ベースで論じる。
- MIT Sloan Management Review「[Five Ways to Make Your One-on-One Meetings More Effective](https://sloanreview.mit.edu/article/five-ways-to-make-your-one-on-one-meetings-more-effective/)」 頻度の一貫性・部下主導アジェンダ・傾聴・キャリア議論・フォローアップの5実践。
## 海外編3: 2024年以降、「聖域」への異論
長らく揺るがなかった1on1に、ここ数年で著名CEOたちから異論が出はじめています。今回の調査でいちばん動きが激しかったゾーン。
- Shopify（2023）「[3人以上の定例会議を一括削除](https://www.forbes.com/sites/jenamcgregor/2023/01/03/shopify-is-canceling-all-meetings-with-more-than-two-people-from-workers-calendars-and-urging-few-to-be-added-back/)」 32万時間分の会議を削減した一方で、1on1は削除対象外。このときはまだ1on1は聖域側でした。
- Brian Chesky（Airbnb CEO, 2024）「[1on1モデルには欠陥がある](https://fortune.com/2024/11/14/airbnb-ceo-brian-chesky-meetings-csuite/)」 密室で不満を聞き続けるとCEOがセラピスト化し、組織で共有すべき課題が閉じる、と批判。短いやりとりの頻度を上げ、決定者が明確な複数人ミーティングを推奨。
- Jensen Huang（Nvidia CEO, 2024〜）「[直属の部下55〜60人と1on1をやらない](https://fortune.com/2026/04/19/jensen-huang-one-on-one-meetings-airbnb-brian-chesky-email-ceo-work-life-rules/)」 全員に同じ情報を同時共有し、「問題をみんなの前に出して全員で共同設計する」方式。
- Ron Carucci「[HBR: Why Senior Leaders Should Stop Having So Many One-on-Ones](https://hbr.org/2025/07/why-senior-leaders-should-stop-having-so-many-one-on-ones)」（2025） 経営幹部レベルでは1on1に意思決定が閉じる弊害を指摘し、1:2〜1:3のクロスファンクショナルな場への転換を提案。全否定ではなく階層別の使い分け論。
- Michael Roberto（経営学者）「[Chesky発言への反論](http://michael-roberto.blogspot.com/2024/11/why-airbnb-ceo-brian-chesky-doesnt.html)」 透明性の価値には同意しつつ「多くの従業員は私的なコーチングの機会を必要とする」。「やるか否か」ではなく「どう活用するか」だと整理。
- Jason Fried（37signals）「[We use Basecamp. We don't have meetings.](https://medium.com/@jasonfried/we-use-basecamp-we-dont-have-meetings-23805c4de1ab)」 1on1に限らず定例ミーティング文化全般への懐疑派として、非同期・書き込みベースを貫く古参。
## 日本編1: ブームをつくった人たち
日本の1on1ブームは2017年、2冊の本の同時期刊行で点火しました。
- 本間浩輔（元ヤフー）『ヤフーの1on1』（2017、2023増補改訂）／「[ヤフーが1on1を企業文化になし得た理由](https://diamond.jp/articles/-/293273)」 日本ブームの震源地。50以上の人事施策の中で1on1だけが現場で効果を実感されて残った、定着まで約5年かかった、という一次情報が貴重。
- 世古詞一『シリコンバレー式 最強の育て方』（2017） 1on1本のもう一方の柱。「テクニックより関係の質」「まず上司自身が良質な1on1を体験する」。
- 中原淳（立教大学教授）「[1on1の目的は『ガス抜き』か『素振り』か『成長支援』か!?](http://www.nakahara-lab.net/blog/archive/9038)」 1on1は複数の目的が混在する「多面体」であり、目的を明確にせず形だけ輸入すると失敗する、という学術側からの整理。
- 曽山哲人（サイバーエージェント）「[導入から11年をふりかえる](https://note.com/bizlogue/n/nef267410e7e4)」 抜擢文化の会社が1on1を11年続けてきた実践録。
- サイボウズ「[ザツダン](https://teamwork.cybozu.co.jp/blog/1on1-meeting.html)」 離職率28%時代に始めた月1回の雑談面談。「見えない不満の大半は情報不足が原因」という発見から情報公開の文化へ転換した話。あえて「1on1」と呼ばないのが面白いところ。
- メルカリ「[自由すぎる1on1](https://unite.unipos.co.jp/1611/)」 「必要な時に、話したい人と、自由に」の最小ルール型。
- リクルート「[よもやま文化と1on1研修](https://special.nikkeibp.co.jp/atclh/ONB/23/recruit_ms0908/)」 社内文化「よもやま」を土台に、1on1研修を外販するところまでノウハウ化。
## 日本編2: 批判・失敗談・揺り戻し
導入が一巡した後、批判や失敗談の記事がバズるようになります。論点はかなり共通しています。
- 沢渡あまね「[上司と部下の『1on1』にみる残念な企業の共通点](https://president.jp/articles/-/72396)」（PRESIDENT Online） 沈黙するだけならチャットで十分、即答を迫る「詰め会」化は部下に重圧、という形骸化パターンの言語化。
- moaikids「[1on1不要論](https://note.com/moaikids/n/n75d6988fb1cc)」（note） 「9割以上が業務進捗確認に終始」「コーチングスキルを持つリーダーは稀」「密室性ゆえのもみ消しリスク」。現場発の不要論としてよく参照される記事。
- 井上和幸「[『1on1』が組織を潰す!?](https://www.hrpro.co.jp/keiei/articles/series/3710)」（HRプロ） 部下が意見を出しても経営が動かなければ冷笑と不信が蔓延する、という経営層向けの警鐘。
- bizlogue（本間浩輔・伊藤羊一ら）「[1on1は9割、失敗する](https://note.com/bizlogue/n/n519e886e52e8)」「[そんな1on1なんかもうやめてしまえ！](https://note.com/bizlogue/n/n865d5ee3107e)」 推進の本家による自己批判シリーズ。1on1をやること自体が目的化する「1on1おじさん」という造語もここから。
- パーソル総合研究所「[1on1ミーティングに関する定量調査](https://rc.persol-group.co.jp/news/202502271000.html)」（2025） 実施率55.7%、一方で部下の3人に1人は効果を実感できていない。この揺り戻し局面を数字で裏付けた調査。続編コラムのタイトルが「[なぜ私たちは、それでも1on1をあきらめないのか？](https://rc.persol-group.co.jp/column/solution-column/202604011400/)」で、時代の空気が出ています。
## 日本編3: AIと1on1（2025〜）
- ブイキューブ「[上司が忙しくて話を聞いてくれないのでAIにしてみた](https://www.nice2meet.us/ai_1on1)」 社内の防音ブースにGPT-4o＋音声対話の「AI 1on1」を試験導入。タイトルがすべてを物語っている。
- レバレジーズ「[1on1面談でAIが助言・記録](https://www.nikkei.com/article/DGXZQOUC202L10Q5A620C2000000/)」（日経） 1on1にAIが同席して助言・記録する仕組み。
- このほか[Kakeai](https://kakeai.co.jp/)など1on1支援SaaSも一大市場になっていて、「1on1ツール22選」のようなまとめ記事が量産される状況です。
## アジャイル界隈編: 海外
アジャイル・スクラムの文脈では、一般的なマネジメント論とはすこし違う軸で1on1が議論されてきました。
- Esther Derby「[One-on-One Meetings with Self-organizing Teams](https://estherderby.com/one-on-ones-with-self-organizing-teams/)」 自己組織化チームにおいて、進捗確認としての1on1を明確に否定。「マネージャーの頻繁な個別介入自体が、チームがまだ指示を必要としているというシグナルになる」。
- Scrum.org公式フォーラム「[Scrum Master conducting 1-1](https://www.scrum.org/forum/scrum-forum/74783/scrum-master-conducting-1-1)」 スクラムマスターは1on1をすべきかで実践者が真っ二つ。「1on1は密室・秘密・疑心・えこひいきを生み透明性を損なう」派と「心理的安全性が低い環境では有効」派の応酬が、この論点の縮図になっています。
- Marty Cagan（SVPG）「[Coaching Tools - The One on One](https://www.svpg.com/coaching-tools-the-one-on-one/)」 一方でプロダクトマネジメントの文脈では強い推進派。1on1の主目的はPMの成長支援、最低週1回30分、新任には週2〜3回。
- Johanna Rothman「[Managing One-on-One](https://www.jrothman.com/mpd/workshop/2006/06/managing-one-on-one/)」 1on1をアジャイルのライフサイクルを補完する管理実践として支持する立場。
- Petula Guimaraes「[Scrum Master and one on ones](https://allthingsagile.co/post/scrum-master-and-one-on-ones/)」 SMの1on1を支持しつつ、「セラピストではない」「チーム全体で解くべき問題を個人で直そうとしない」といった注意点を列挙。
なお、Team TopologiesやSpotifyモデルの文脈では、マネージャー×個人の1on1への直接言及は（調べた範囲では）見つかりませんでした。
## アジャイル界隈編: 国内
国内は実践報告から代替プラクティスの発明まで、バリエーションが豊かでした。
- 粕谷大輔（だいくしー）さん「[人見知りマネージャが100回1on1をしてわかったこと](https://daiksy.hatenablog.jp/entry/2018/12/12/080000)」（2018）／「[エンジニア全員(約100人)と1on1をしました](https://daiksy.hatenablog.jp/entry/2024/07/12/153142)」（2024） 「年1回3時間より毎日5分×36回」。決めた頻度で必ず開催することに意義がある、という実践派の代表格。
- 森一樹さん「[ふりかえりは関係の質の向上から始めよう](https://www.ogis-ri.co.jp/otc/hiroba/others/agile-interview/201809.html)」 関係性の構築をチーム全体の場（ふりかえり）で担う設計思想。1on1中心のマネジメント観に対する、もうひとつの路線。
- 西野香織さん（NIFTY）「[スクラムマスターが今すぐ1on1をやったほうがいい3つの理由](https://engineering.nifty.co.jp/blog/23921)」 傾聴力の訓練・SM自身へのフィードバック・支援内容の把握。「SMもチームに育ててもらう」という視点。
- 小林公洋さん（セブン銀行）「[『目標を共有するチーム』より強いのは『悩みを共有するチーム』](https://logmi.jp/tech/articles/328012)」 LeSS環境で3ヶ月に50回の1on1を実施した実践録。「悩みを欲しがれ」。
- asatoさん「スクラムマスターとしての僕の1on1の使いどころと使わなどころ」（※記事は現在非公開になっているようです） 理想は1on1の内容がオープンな場で自然に共有される状態。「常に1on1をやめるタイミングを検討すべき」という整理が明快。
- なかりーさん「[リモート時代の雑談/相談、Peer 1on1の始め方](https://speakerdeck.com/nakaly/peer-1on1)」 上下関係のないPeer 1on1という代替プラクティスの提案。
- もりゆうやさん「[対話の謎 / 1on1 study Dialogue](https://speakerdeck.com/moriyuya/1on1-study-dialogue)」 David Bohmの対話論から、上下関係のある1on1では真の対話が構造的に成立しにくい、という逆説を指摘。
- spring_akiさん「[ゆるい1on1のススメ](https://speakerdeck.com/spring_aki/taisetsuna-yohaku-1on1)」（RSGT2021） アジェンダに縛られず、雑談・脱線・余白を大切にする1on1の再定義。
- t0yoheiさん（クラウドワークス）「[スクラムチーム内で1on1を実施した話](https://engineer.crowdworks.jp/entry/2019/01/28/184113)」 アジャイルの儀式が手厚いチームでも個別コミュニケーションは手薄になる、という気づきから、のちに3人の「トライアングルトーク」へ進化。
- wentz-designさん「[マネジメントの究極の到達点は、1on1が不要な世界かもしれない](https://wentz-design.com/post/making-1on1-unnecessary/)」 「チーム全員が状況を透明に理解し自律的に動ける状態」から逆算して1on1を位置づける論考。
## 調査から見えた傾向（ファクトベースで4つだけ）
リストを眺めて見えてくる傾向を、事実の範囲で4つだけ置いておきます。
1. 時系列: 1983年の原典から40年、海外では1on1はほぼ「聖域」だった。会議を32万時間削ったShopifyですら1on1は残した。その聖域に2024年以降、Chesky・HuangらCEO層から異論が出はじめた。
2. 立場と主張の相関: 不要論を唱えているのはほぼ「直属の部下が数十人いる超大規模組織のトップ」。推進しているのは現場マネージャー・研究者・HR。どの立場から言っているかで、主張がかなりきれいに分かれる。
3. 日本の論点は「運用」: 海外の異論が透明性・情報サイロといった構造の話なのに対し、日本でバズる批判は「詰め会化」「進捗確認化」「1on1おじさん」といった形骸化の話に集中している。実施率55.7%・3人に1人が効果実感なし、という数字がその背景にある。
4. アジャイル界隈は一段メタ: 「どうやるか」ではなく「そもそも1on1という形式はチームの透明性・自己組織化と両立するのか」を10年以上前から議論していて、Peer 1on1・トライアングルトーク・ゆるい1on1・ふりかえりの日常化など、代替や再定義の発明が多い。
## まとめ
- 1on1の言及を国内外・アジャイル界隈の3方面で約60件調査した
- 海外は「40年の聖域」に2024年以降CEO層から異論が出はじめた局面、日本は導入一巡後の形骸化と揺り戻しの局面、アジャイル界隈は10年以上前から一段メタな議論をしていた
- 一次情報のリンクを貼ったので、気になったものはぜひ原典へ
このリストが、1on1について考えたり書いたりする人の足場になれば嬉しいです。使ったよーと教えてくれたら勝手に喜びます。
---
# 「受託開発 is dead」は真実か
URL: https://agile-monster.com/blog/jutaku-is-dead/
Published: 2026-07-17
---
最近、タイムラインで「受託開発 is dead」という言葉をよく見ます。AIでソフトウェアがどんどん速く・安く作れるようになって、これまでの「顧客の要望どおりに作って納品する」という受託開発のかたちが、急速に価値を失いつつある。だいたい、そういう文脈で語られています。
最初は正直、「また◯◯ is dead系の煽りか」と思っていました。
というのも、「受託開発 is dead」という話は、AI以前から何十年も言われ続けてきたからです。内製化、クラウド、多重下請け、オフショア。そのたびに「今度こそ死ぬ」と言われて、それでも受託開発はゾンビのように生き残っています。
実は自分も、ずっと事業会社に所属していた人間なので、こうした話題を半分外野から眺めていました。受託開発って大変そうだな、なんとなく近づきたくないな、と思っていたことを覚えています。
そんな自分が、3年前に株式会社ホロラボに参画して、いまは受託開発をはじめとするクライアントワークのど真ん中にいます。正直、参画するとき「受託開発」という言葉には少しひっかかりました。それでも、新しい技術がもたらす変革への挑戦と、会社そのものの魅力が勝ちました。そもそも「受託開発」だって、やってみてから文句言わないとださいよなーと。
あれから3年。経営チームにも参画し、受託開発と本気で向き合ってきました。だからこそ今回は、「受託開発 is dead」という言葉からも逃げずに、本気で向き合ってみます。
## 「受託開発 is dead」は真実か
真実です。
AI以前から、DXの文脈でのノーコードの取り組みや、内製化の流れはずっとありました。そこにAI（特にAIエージェント）の波が来て、この傾向は一気に強くなりました。非エンジニアでも、ソフトウェアを作れるようになりました。
この手の話をすると、それを生業にしているエンジニアを中心に「品質ガー」「セキュリティガー」と騒ぎになって、「ソフトウェア開発はそんなに簡単ではない」という議論になりがちです。
でも、ソフトウェアに求められる品質は、目的や用途によってさまざまです。顧客向けや実運用に絡むソフトウェアには、それなりのサービスレベルが求められます。一方で、社内で使うツールやPoC（コンセプト検証）に求められるレベルは、相対的に低いことが多いです。そしてこの領域こそ、AIエージェントに代替されやすい、というよりもう代替が始まっているところです。
セキュリティや品質の面も、モデルの進化と、人間側のAI活用の知見が溜まっていくことで、年々差分は埋まってきているように感じます。ほんの2〜3年前まで「AIに支援はさせても、コードを書かせるのはまだ早い」が主流の論調だったのに、今ではAIがコードを書いていることのほうが多いです。この変化のスピードを見ると、現時点では完全に任せることが難しい領域でも、近い将来「人間よりもAIのほうが信頼できる」という状況は、普通に起こりえます。
正直に言うと、自分もエンジニアなので、自分がやってきた仕事が簡単に置き換わるなんて、信じたくない気持ちはあります。でも、死につつあるものは、自分の現場からもハッキリ見えています。煽りでもポジショントークでもなく、これは本当に起きている変化です。
ただし、「受託開発がまるごと死ぬ」という意味ではありません。死ぬのは受託開発ではなく、**"つくるだけ" のソフトウェア開発**です。なぜそう考えるのか、順番に書いていきます。
## ① 「受託開発」でひとくくりにできない
受託開発と一言でいっても、人月だけを売る会社、SIer、コンサル、プロダクト伴走、PMO、DX支援まで、中身は全部違います。だから問うべきは「受託開発 is deadか」ではなく、「何が dead なのか」です。
そこを分けて考えると、AIによる価値の低下は、いきなり全部が消えるというより、段階的に進んでいきます。そして、その波が最初に効いてくるのが「コードを書く」という行為の価値です。実際に、開発の生産性が上がって案件の利益構造が変わり始めています。
そしてこの波は、コードを書くところだけでは止まりません。設計、要件定義、その手前の構想へと、少しずつ広がっていきます。だからこそ、どこの価値が先に下がって、どこが残るのかを分けて見ておきたいのです。
だから死ぬのは、"言われた通りにコードを書くだけ" の仕事です。受託開発かどうかは、関係ありません。そしてこの領域は、もう縮み始めています。
ただし、縮み方は一枚岩ではありません。中小の受託開発や小さな自社開発は、内製化と生成AIの波をもろに受けて、案件が消え始めています。一方で、大手エンタープライズの複雑なシステムは、内製だけでは賄いきれないので、今のところそんなに困っていない、という話もよく聞きます。効き方は規模と顧客層でぜんぜん違うので、ここを混ぜると話がぼやけてしまいます。
## ② そもそも、顧客は「コード」を買っていない
顧客は、コードを書いてほしくて受託しているんだっけ？と考えると、違うんですよね。
顧客が期待しているのは、事業戦略を整理したい、要件を一緒に考えてほしい、意思決定を助けてほしい、社内調整を手伝ってほしい、リスクを減らしたい、といった問題解決です。コードは、そのための一つの手段にすぎません。
このように考えてみると、「コードが安くなった＝受託開発が死ぬ」は、かなり短絡した話になります。安くなったのは手段であって、期待されている中身のほうは何も消えていないからです。
これは、事業会社と受託開発の両方を経験した自分の実感とも重なります。事業に踏み込んでいく受託開発の現場もあれば、事業部に言われたものをつくっているだけの、社内請負のような開発チームもある。「事業会社か受託開発か」という線を引いても、実態はもう捉えられません。
しかもこれは受託開発だけの話ではありません。開発とコンサルの境界も溶けています。コンサル会社はどんどん開発部隊を持ちますし、SIerは事業支援を始めています。「SaaS is dead」も同じ構造で、ソフトを売るだけの会社は終わり、BPOや運用や伴走、成果保証まで踏み込む会社は伸びています。コンサルも、SIerも、SaaSも、事業会社も、やっていることがどんどん重なってきています。行き着く先は、顧客にとっての「価値」です。
## ③ 「考える」と「つくる」が近づいている
ソフトウェアをつくるコストは、長いあいだ、あまりに高いものでした。だからどうしても「考える」と「つくる」は分業になっていました。役割が分かれ、職種が分かれ、組織が分かれ、会社まで分かれがちでした。
AIによって、「つくる」のコストが下がりました。その結果、「考える」と「つくる」が自然と近づき始めています。役割が近づき、職種が近づき、組織が近づき、会社も近づいてきた。いま起きているのは、この変化です。
そして、アジャイル開発が実現したかったことが、まさにこの「考える」と「つくる」を近づけることでした。当時はつくるコストが高くて実現しきれなかった理想に、今ようやく近づき始めています。
実際、自分たちのクライアントワークでも、開発だけでは終わらないケースが増えています。最初は普通の開発だったのに、途中から「事業の進め方も相談したい」となって、PMO、ビジネスモデル設計、プロジェクト推進、意思決定支援まで広がっていく。今では「システムを作る」より「事業を作る」ことのほうが多い現場もあります。これは受託開発なのか？と最初は思っていましたが、もはや境界は気にしなくなりました。
最近FDE（Forward Deployment Engineer）という言葉をよく聞くのも、たぶん同じ流れです。顧客の現場に入り、課題を一緒に考え、必要ならコードも書く。「考える人」と「つくる人」ではなく、"考えながらつくる人"。ここで勘違いされやすいのですが、本質は常駐でも、顧客への物理的な近さでもありません。問題解決への近さです。
ただし、この変化は諸刃でもあります。最近、ある大企業でこんな話を聞きました。最初は事業戦略があった。システム開発が始まる。途中から、作ることだけが目的になる。戦略が消える。そして、使われないシステムが大量に残る。これはAI以前からずっとあった現実です。でもAIで作るコストが下がると、この悲劇はもっと簡単に、もっと大量に起きるようになります。作ることが簡単になればなるほど、「何を作るか」の重みは増していきます。
だから、問題解決に踏み込む受託開発にとって、AIは逆風ではなく追い風です。is deadどころの話ではありません。ただし、問題解決から離れた瞬間に、その追い風は「使われないもの量産マシン」に化けます。
## ④ 結局、価値の源泉は「人」
ここまで来ると、受託開発もコンサルもSaaSも、価値の源泉は同じだと思えてきます。ソフトウェアそのものではありません。人です。
どの会社でも解決できる仕事は、代替されます。AIでも解決できる仕事も、代替されます。でも、「この人たちじゃないと解決できない」は残ります。「この人たちと働きたい」も残ります。
だから目指すのは、成果物を納めることではなく、顧客が価値にたどりつくためのパートナーであることです。モノではなく、人に価値を感じてもらう。
その筆頭が、意思決定です。AIは候補をいくらでも出せます。でも、決めるのは人です。そして意思決定は、意思決定することでしか上手くなりません。
人の育て方も変わります。自分の部署でも「考える＋つくる」へシフトしていて、もちろん苦労もあります。でも、これは研修では身につきません。仕事の中でしか育ちません。
採用の話も少しだけしておきます。最近、AIを理由に若手採用を減らす会社が増えています。「AIがコードを書くなら、ジュニアはいらない」というロジックです。でも、自分は逆だと考えています。AIネイティブな若手のほうが、固定観念がないぶん、自分たちには思いつかない使い方を編み出す可能性があります。短期的に採用を控えることはあっても、人が増えて育っていく環境をつくれなければ、その産業は衰退していくだけです。それはAIのせいではなく、AIがもたらした変化に適応できていないだけです。
**エンジニアという職種がなくなるのではありません。"つくるだけ" のエンジニアの仕事がなくなるのです。**
## すべてのソフトウェア開発が、「価値」に近づいている
「受託開発 is dead」は真実です。ただし、受託開発が死ぬのではなく、"つくるだけ" のソフトウェア開発が死ぬ。エンジニアという職種がなくなるのではなく、"つくるだけ" のエンジニアの仕事がなくなる。そしてそれは、もう始まっています。受託開発は、たまたまその矢面に立っているだけです。
ここまで並べてきた変化を一歩引いて眺めると、もっと大きな絵が見えてきます。事業に踏み込む受託開発。開発組織を持つコンサルティングファーム。成果保証まで踏み込むSaaS。顧客の現場に入るFDE。立場も形式もバラバラなのに、向かっている先はぜんぶ同じです。**すべてのソフトウェア開発が、それぞれのかたちで「価値」に近づいているのです。**
しかもこれは、新しい潮流ではありません。エンジニアはずっと昔から「つくるだけではだめだ」と知っていて、顧客に、ユーザーに、価値に近づこうとしてきました。その代表例がアジャイル開発です。アジャイル開発が誕生してから、25年。「考える」と「つくる」を近づけたかったあの理想が、AIによって、この数年で一気に加速している。自分にはそう見えています。
だからもう、ソフトウェア開発の「かたち」にこだわっている場合ではありません。受託開発か、事業会社か。SIerか、コンサルか。そこで消耗するのではなく、問うべきは「価値にどれだけ踏み込めるか」です。
## 7/24に「受託開発 is dead」をテーマに朝まで生討論します
7/24にCreationlineさん主催の「AI時代の受託開発のミライ ─「受託開発 is dead」のその先へ」というイベントに登壇します。
https://creationline.connpass.com/event/398146/
2026年7月24日（金）19:00〜20:30、Zoom開催・参加無料です。
[@samuraiRed](https://x.com/samuraiRed)、[@sasakendayo](https://x.com/sasakendayo) と3人で、「受託開発 is dead」をテーマに本音で徹底討論します。
話してはいけないことまで話しかねない3人なので、事前打ち合わせの際に運営の方に「いざとなったら止めてください」と伝えています。きっとリアルタイムでしか聞けない臨場感がそこにあります。
どんな話をするのかって？
答えは……トランキーロ！あっせんなよ！
当日、お待ちしております。
---
# コロナ禍も挟んだ6年間子育てをしてきて第三子が生まれた今、改めて大切だと思うこと
URL: https://agile-monster.com/blog/what-matters-after-6years-of-parenting/
Published: 2024-12-24
---
子育てエンジニア Advent Calendar 2024 25日目の記事です。
第一子が生まれた2018年からはじめた子育てエンジニア Advent Calendarも7年目になりました。今年はもちろん、毎年すばらしい記事が集まっているので、ぜひ興味がある記事を探してみてください。
- [子育てエンジニア Advent Calendar 2023](https://adventar.org/calendars/9423)
- [子育てエンジニア Advent Calendar 2022](https://adventar.org/calendars/7964)
- [子育てエンジニア Advent Calendar 2021](https://adventar.org/calendars/7964)
- [子育てエンジニア Advent Calendar 2020](https://adventar.org/calendars/5302)
- [子育てエンジニア Advent Calendar 2019](https://adventar.org/calendars/4199)
- [子育てエンジニア Advent Calendar 2018](https://adventar.org/calendars/3178)
## 第三子が生まれました！
2024年の一番の変化は、12月に第三子が生まれたことです。
家族構成
自分（会社員、フルリモート）
妻（会社員、リモート＆出社、育児休暇中）
長男（6歳、幼稚園）
次男（3歳、保育園）
長女（0歳）NEW!!
3年ぶり3回目の新生児が家にいる生活になりました。次男が生まれたときもそうだったんですが、「そういえばこうだったね！」といろんな忘れていることを思い出しながらの子育てを楽しんでいます。一方で、はじめての女の子なので、これまでと違うこともどんどん出てくるであろうことも楽しみにしています。
今働いている[ホロラボ](https://hololab.co.jp/)は、フルリモート＆スーパーフレックスなので、子育てをしている身としてはとても助かっています。制度だけでなく、会社の中で同様に子育てをしている人や経験者も多いため、子どもの送迎や幼稚園・保育園の行事に参加するために中抜けするのはあたりまえ、という受け入れる文化ができています。
仕事の変化としては、経営チームにも加わり、12月からは執行役員になりました。基本的に家で働くことが多いですが、顧客に会いに行くときや、経営会議などオフラインで集まったほうがよいときは出社することもあります。しかし、子どもが生まれてからは自分だけオンラインで参加したり、日中の時間にオフラインで集まって家事育児のゴールデンタイムには家に帰宅できるように配慮してくれます。プロダクトチームだけでなく、経営チームも快く受け入れてくれるのはとてもありがたい限りです。
世の中的には出社回帰的な流れもありますが、働き方を選択できることはやはり一個人とするととてもありがたいと感じています。だからこそ、働きやすい制度や環境を維持していけるように、制度に甘えることなく「どうやったら効果的に働けるのか」にはこだわっていきたいと改めて感じました。
今回は、第三子が生まれた今だからこそ、コロナ禍を挟んだ6年間子育てをしてきて改めて大切だと思うことをふりかえってまとめてみます。
## 子育てをハックする
子育ては大変なことも多いですが、ハックする対象だと考えると楽しいです。仕事とプライベートを分けろよ、と思うかもしれませんが染み付いた思考までは分離できません。
不確実性の塊である子どもたち。プログラムをデバッグしている感覚で、「どうすれば泣き止むのか」「どうすれば笑うのか」「どうすれば気がそれて機嫌が直るのか」に向き合うとおもしろみを感じることができます。プログラムと違って決まったロジックがないのでは？という疑問も浮かびますが、3人の子どもと向き合ってきて、なんだかんだ個人の中で共通しているロジックのようなものを感じることがあります。それに気づいたときが楽しいし、またその気づきが崩れたときもまた楽しいです。（もちろんそれでもイライラしてしまうときもよくあるけれど、親も人なのでごめんね！）
また、コントロールできないものを相手にせずに、コントロールできるものを相手にすることも大切です。自分の生活時間は確実にコントロールすることができます。子どもが生まれてからは、基本的な生活リズムとしては、子どもと一緒に寝て深夜？明け方？に起きて生活するようになりました。寝かしつけから起きてくるという苦行からも解放されるし、起きてから家族が起きてくるまでの時間を身も心もフレッシュした状態で有効に使えるようになりました。朝ごはんや登園準備など、子どもが起きてから幼稚園や保育園に行くまでの時間を担当することができるので、家事や育児の負担の分担という意味でも合理的です。
## 優先順位をつける場数を踏む
仕事の中で、優先順位をつける機会はとても多いです。プロダクトオーナーのようにわかりやすい役割をもっていなくても、全員がなにかしらの優先順位をつけて仕事をしています。
優先順位をつけることは、経験主義的に場数を踏んでうまくなる要素が多いです。しかし、自分自身が仕事の中で実は無意識のうちに優先順位をつけて仕事をしているのにも関わらず、それを自覚できていなくて経験知がたまっていかないケースをよく見ます。
- 時間で解決しづらくなるので、それまで以上に仕事の中での優先順位づけを精度高くする必要がある
- 限られたプライベートの時間の中でなにに時間を使うのか投資判断をする
- 「子育て」「仕事」というある意味主務が2つあるようなタフな状況で優先順位をつける
- 今日という日に限って子どもが早く起きてきたりする不確実性が高い状況下で、クイックに変化に対応できるか
タフクエスチョンばかりで「うっ」とくるかもしれませんが、子育ては優先順位をつける場数を踏むよい機会だと捉えるとよいでしょう。
## 親が楽しそうに学んでいる／仕事している背中を見せる
2022年の子育てエンジニアAdvent Calendarで、以下の記事を書きました。
https://agile-monster.com/blog/show-your-child-that-you-enjoy-learning/
今でも子どもは、「ぼくもまた勉強会行きたい！」と言っています。夜自分がオンライン勉強会に参加していることを知っているので、「パパ、お友達と夜話してるよね」と言っています。
また、彼らにとって、親が家で仕事している風景が「ふつう」になっているので、オンライン会議をしているとわざと映り込もうとしてきたりします。
自分が子供の頃のことを思い出すと、「勉強」はやらなくてはいけないものでめんどくさいものだったし、「仕事」というものはもっと距離が遠いものでした。距離が近いことがいいことかどうかはわからないけれど、親がどうそれと向き合っているのか見せることができます。
「勉強」も「仕事」も楽しくする、という道があることを知ってもらえるとよいなーと心から思っています。
## 比較しなくて良いものと比較して勝手に一喜一憂しない
子育てエンジニアAdvent Calendarを7年間続けてきて、またコミュニティなどでいろんな子育てをしている人と会話をしてきて、エンジニアとしてのキャリアや学習時間の確保についての話題が多いように感じます。
- 子育てをする前と比べて、自己学習に使える時間が大きく減ってしまった
- 選択したことではあるけれど、エンジニアとしての今後を考えると不安がある
これらの不安は「子育てをする前の自分」や「子育てをしていない世のエンジニア（想像）」や「制約がなかったら、を想定した理想の自分」と比較することで生まれています。
比較自体があくまで手段なので、比較することで意味がある（ex. やる気が出る、目標が明確になる）のであればよいでしょう。しかし、比較をすることで苦しくなったり焦ってしまうのであれば、比較をすること自体に意味がありません。比較しなくてもよいものと比較して勝手に一喜一憂するのはやめる、という割り切りが必要です。
昨年の子育てエンジニアAdvent Calendarで、以下の記事を書きました。
https://agile-monster.com/blog/the-curse-of-learning-from-parenting/
冷静に考えれば誰もがわかっていることですが、時間をかければスキルが身についたりキャリアが形成されるわけではありません。誰かと同じような時間の使い方をしたとしても、その人と同じになれるわけではありません。それがわかっていても、勝手に比較して不安に感じてしまっているのが現実かもしれません。まさに呪いですね。
呪いだからこそ、小手先の対応をするのではなく、呪い自身と向き合うことが大切なのかもしれません。
## なによりも幼少期に子どもと一緒にいる時間を増やす
自分がいま一番大事にしたいと考えていることは、子どもと一緒にいる時間を増やすことです。
良くも悪くも特に幼少期の子どもは、親から受ける影響がとても大きいです。実際に子育てをしていても、そう感じることがあります。生まれてからずっと関東に住んでいるにも関わらず子どもたちは三河弁（自分の地元の方言）を話すし、長男は冬でも短パンを履きたがります。どんな習い事をするのか、どんな体験をするのか、どんな幼稚園や学校に通うのかももちろん大切なことです。でもそれと同じかそれ以上に、親が子どもと一緒にいる時間を増やすことが大切な気がしています。
長男が生まれて半年後にCOVID-19が発生しました。そのため、たまたま自分が子育てをするようになってからの6年間は、家で働くようになった期間と一致しています。出社していた頃と比較しても、子どもといっしょにいられる時間は圧倒的に違います。子どもたちにとっては親は常に家にいるのが「ふつう」になっています。
幸いなことにフルリモートやスーパーフレックスのように子育てしやすい働き方ができているので、子どもが体調不良や休園日で家にいても仕事をしながら生活することができます。保育園や幼稚園の行事に参加することもできます。今月も、発表会、ドッジボール大会、お餅つきに参加してきました。園にいる先生やお友達のこともなんとなくわかるので、子どもたちと会話することができます。
幸いなことに、いまのところ子どもたちは両親のどちらかがいなくなってもわりと平気です（もちろん寂しがりますが）。第三子の出産に伴って数日間妻が入院している間も、日常生活を過ごせていました。もちろんそれだけではないですが、子どもたちが親から受ける安心感は過ごす時間と比例している気がします。
なにより、子どもたちも成長していくにつれて、家にいない時間が増えていくことでしょう。長い時間一緒にいられるのは、幼少期のいまだけなのかもしれません。だからこそ、この時期は子どもたちと一緒にいる時間を大切にしたいです。
などとそれらしいことを言ってますが、なにより自分が一緒にいたいだけなんですけどね。
---
# 「子育ては学ぶことが多い」は呪いかもしれない
URL: https://agile-monster.com/blog/the-curse-of-learning-from-parenting/
Published: 2023-12-25
---
子育てエンジニア Advent Calendar 2023 25日目の記事です。
https://adventar.org/calendars/9423
第一子が生まれた2018年からはじめた子育てエンジニア Advent Calendarも6年目になりました。アドベントカレンダーを立てるのを忘れていると、「今年は立てないんですか？」とリマインドしてくださる方までいて、もはや年に1回活動しているコミュニティのようなあたたかさを感じております。毎年すばらしい記事が集まっているので、ぜひご一読ください。
- [子育てエンジニア Advent Calendar 2018](https://adventar.org/calendars/3178)
- [子育てエンジニア Advent Calendar 2019](https://adventar.org/calendars/4199)
- [子育てエンジニア Advent Calendar 2020](https://adventar.org/calendars/5302)
- [子育てエンジニア Advent Calendar 2021](https://adventar.org/calendars/7964)
- [子育てエンジニア Advent Calendar 2022](https://adventar.org/calendars/7964)
## こんな家族です
2023年12月現在、こんな家族構成でおもしろ楽しく生活しています。
家族構成
自分（37歳、エンジニア、フルリモート）
妻（会社員、リモート＆出社）
長男（5歳、幼稚園）
二男（2歳、保育園）
今年から妻が復職しました。上京組夫婦なので、復職前はどうなることかと思っていましたが、送り迎えパズルにもすぐに慣れました。二男も保育園に登園するようになり、社会に出ると一気に成長することを実感しています。
ちなみに家族の中で最も長い時間家を守っているのは自分です（ドンッ！）
## 子育ては学ぶことが多いのか
とある友人のSNSでの投稿が心に残っています。その投稿の要点をまとめると、以下のような内容でした。
- 「子育ては学ぶことが多い」とよく聞くが、自分はあまりそうは感じない
- もちろん子育てから学ぶことはあるが、他から学ぶことのほうが自分にとっては実りが多い
- 「コスパは悪いかもしれないし、学びはそれほどないかもしれない。でも自分は子育てがしたい。」で十分
もちろんこれは他人を否定するものではなく、本人自身の捉え方を客観的に分析して書いてくれているものです。
自分自身も漠然と「子育ては学ぶことが多い」と感じていました。しかし、この客観的な分析はとてもおもしろいと感じたので、自分なりに考察してみたいと思います。自戒も込めて。
## 子育てフェーズをポジティブにとらえたい気持ち
事実として子育てにはコストがかかります。お金はもちろんですが、時間も必要です。
「[子育て世帯の夫の家事・育児時間、なお妻の4分の1](https://www.nikkei.com/article/DGXZQOUA317WH0R30C22A8000000/)」（日本経済新聞）より引用
1日に家事・育児にかかる時間は、6歳未満の子をもつ夫婦は全年代に比べて、男女ともに約2倍になるそうです。これだけの時間を確保するためには、それまでの時間の使い方を大きく変える必要があります。
自由時間の時間の使い方は人によって違います。学習意欲が高いエンジニアであれば、勉強会に参加したり、技術書を読んだり、コードを書いたりしていたかも知れません。子育てフェーズに入ると、たいていの場合この「自由時間」が減ることになります。だからこそ、学習意欲が高い人であればあるほど、自身の学習と子育ての両立が悩みになりやすいです。実際に「子育てエンジニア Advent Calendar」を眺めてみても、学習をテーマにした記事がとても多いです。
そうした悩みの中で、「子育てからも学びがある」のように受け止めることで子育てフェーズをポジティブにとらえたい気持ちは痛いほどよくわかります。一方で、この言葉の裏側に、
エンジニアとしての学習の時間が減ってしまって不安だ
↓
不安な気持ちから目をそらすために、子育ての時間からも学びを得ていると受け止めよう
という不安を理由にした自己正当化が働いているとしたら、子育てにとってもエンジニアとしての学習にとっても中途半端になってしまっているのかもしれません。
## 我々 私はなぜ子育てをするのか
自分にとって子育ての目的は、
- 子供が自立するまで、安心して過ごせる居場所をつくること
- 子供にこの家族に生まれてよかったなって思ってもらうこと
- 子供が人生の大事な場面でとりたい選択肢を選べるように、選択肢を増やす支援をすること
です。
「子育て」にフォーカスして考えてみます。自分の場合、子育ての目的の中に自分が学ぶことは入っていません。極端に考えたときに、自分にとっての学びがまったくないとしても、目的を達成するために必要な行動であればなんの迷いもなく行動します。なぜなら現在の自分にとって子育ては、人生の時間を賭けてでも取り組む価値があると感じているからです。そしてなにより子育て自体が楽しいから子育てをしていたいからです。
もちろん副次的に、子育てから得られる学びはたくさんあります。でもそれは主題ではないし、理由にする必要もありません。ポジティブに受け止めることの重要性は理解しつつも、「我々私はなぜ子育てをするのか」という命題を常に心に抱いていたいです。
## エンジニアリングはエンジニアリングでしか上手くならない
現代サッカーのトレーニング理論の中では、「サッカーはサッカーでしか上手くならない」ということが言われています。
筋力トレーニングやドリブル練習・シュート練習のような要素技術の練習も確かに大切ですが、サッカーをうまくなりたければなるべく試合に近い状況で状況分析と判断を伴う練習が必要だという考え方です。
これは本当にそうだと思っていて、エンジニアリングはエンジニアリングでしか上手くなりません。[Connecting the dots](https://www.youtube.com/watch?v=VyzqHFdzBKg) の話のように、他分野で得た学びが他分野で活きることはありますが、それは偶発的な結果論に過ぎません。
つまり、子育てから得た学びがたまたまエンジニアリングに活きることはあるかもしれませんが、結局エンジニアリングがうまくなりたいのであれば限られた時間の中でどのように学習をするかということからは逃げられません。
## 「常に学んでいたい」という呪い
このテーマで考察をしていて、優先順位をつける覚悟を問われているのだと感じました。
- いまの自分の人生の優先順位を認知する
- 優先しているものを達成することに集中する
- 集中している間はそれ以外のことは忘れる（執着を捨てる）
優先順位をつけるということは、優先しているものに集中している間はそれ以外への執着を捨てる覚悟をもつということです。子育てをしているときは子育ての目的に集中する、エンジニアリングをしているときはエンジニアリングの目的に集中する。
そのためには、「常に学んでいたい」という価値観の呪い（執着）を解く必要があるのかもしれません。
## 子育ては学ぶことが多いのか
本題に戻ります。子育ては学ぶことが多いのか。
- 子育てフェーズに入るとエンジニアリングを学ぶための時間は減る
- 子育てから学ぶことはあるが、学びを得ることは子育ての主目的ではない
- 学びがあるかどうかに関係なく、子育てをしたいから子育てをする（それでいい）
- エンジニアとしての学習は子育てとは切り離して考えたほうがよい
というのが今の自分の中の答えです。友人の投稿と結論は似ていますが、考察したことで解像度が上がりました。
子育てからなにを学ぶかを考えるよりも、子育てはしたいからしている。だから子育て自体を家族と一緒に楽しみたい、と改めて感じました。
---
# 「私考える人、あなた作業する人」の関係をつくっているのはあなたかもしれない
URL: https://agile-monster.com/blog/i-am-the-thinker-you-are-the-worker/
Published: 2023-03-27
---
[Regional Scrum Gathering Tokyo2023](https://2023.scrumgatheringtokyo.org/index.html) の中の [moyiyuya](https://twitter.com/_N_A_) さんの「私考える人、あなた作業する人」というセッションが大きな反響を呼んでいました。
スクラムを導入してチームとして一体感をもってプロダクト開発をよりうまくやっていきたかったはずなのに、いつの間にか「私考える人、あなた作業する人」という関係性ができてしまっていた、という相談を受けることがあります。
なぜこのような「私考える人、あなた作業する人」という関係性が生まれてしまうかについて、コミュニケーションの観点で考えてみます。
## プロダクトオーナーと開発者の堺目
「私考える人、あなた作業する人」のような関係性が生まれてしまっているチームでは、開発者からプロダクトオーナーに対するコミュニケーションが以下のようになっていることが多いです。
- プロダクトバックログを出してくれたらつくります
- 仕様を決めてくれたら作ります
- フィードバックをくれたらその通りに修正します
- 次のスプリントで取り掛かるバックログを決めてください
それぞれを見ると、必ずしも悪いコミュニケーションだとは言えません。各役割の責任を真面目に解釈して、その通りに実行しようとするとこうなるでしょう。
このようなコミュニケーションでも、ドメイン知識やスキルをもった人格者のプロダクトオーナーであれば仕事がうまくまわっていくかもしれません。ところが、プロダクトオーナーがそのドメインのプロダクトをつくる経験がなかった場合はどうでしょうか。あるいは、ITやプロダクト開発の経験が豊富でない場合はどうなるでしょうか。
おそらくわからないながら、仕事を進めるために最終的には決めてくれることでしょう。もちろん決めたことに自信があるわけでも、確証があるわけでもありません。求められた仕事に対してマジメに取り組んだ結果としての決定です。
これを繰り返していくと、
- わからないけどとりあえず決める
- わからないけど答える
- わからないけど言われてから考える
- わからないけどなにかコメントをする
というコミュニケーションに慣れていきます。人間は「慣れる」という特性を持っているので、これがプロダクトオーナーとしてのふるまいだと信じて、マジメに仕事を遂行していくようになります。
こうして出来上がるのが、「私考える人、あなた作業する人」です。さて、誰が悪かったのでしょうか。
## コミュニケーションの方向を見てみる
「私考える人、あなた作業する人」になってしまうのは、特定の誰かが悪かったわけではありません。たいていの場合、全員がマジメに仕事に取り組んだ結果です（ある意味だからこそタチが悪い）。
このときのコミュニケーションの方向を見てみましょう。
先程の例では、プロダクトオーナーと開発者が相対してコミュニケーションをしています。開発者が求めたことにたいして、プロダクトオーナーが答える。コミュニケーションの向き、すなわち仕事をする向きが、相手の方向を向いてしまっています。
よりよいプロダクトをつくるためには、プロダクトオーナーも開発者も同じ方向を向いて仕事をする必要があります。それぞれが相対してコミュニケーションをするのではなく、同じ方向（プロダクト）を見ながらそれぞれができる貢献をしていくのがスクラムです。
役割と責任を結びつけて書いてあるとおりに実行しようとし過ぎない方がよい、というのは自分の経験知です。教科書通りのスクラムになっているか通りよりも、結果として全体で機能していることのほうがよっぽど重要です。目の前にあるチームやプロダクトの現実を見て、変化に対応していきましょう。
## 開発者の立場でどうしたらよいのか
とはいえ、具体的にどうすればいいのだろうということを、自分の経験もふまえて最後に触れておきます。
自分は開発者としてプロダクト開発に携わることが多いのですが、同じような場面では以下のような行動をします。
- インセプションデッキやリーンキャンバスを一緒につくる
- プロダクトバックログアイテムの仕様をプロダクトオーナーと一緒に考える時間をとる
- スプリントプランニングで次にやったほうがよさそうなバックログアイテムを一緒に考える
- ユーザーテストを行い、その結果を見ながらどうするかを一緒に考える
相手に求めてそれを待つ、というアプローチをできるだけ避けて一緒に決めるようにします。その中で、お互いの知っていることを混ぜ合い、仕事の進め方を共に学び、少しずつチームの仕事の進め方を収束させていきます。
たしかに、役割に従って自分の仕事に集中しようとすることは一見楽なように思えます。しかし、わからないのに無理やり行った決断がよい結果に結びつく可能性は限りなく低く、その決断の下では仕事に集中することはできません。気づいたら売るどころか誰も使うことができないゴミを作っていた、なんて地獄は見たくありません。
「はやく走れる方が走りまわればいい」とはよくいったものですね。
---
# 大人が楽しそうに学んでいる姿を子供に見せる
URL: https://agile-monster.com/blog/show-your-child-that-you-enjoy-learning/
Published: 2022-12-22
---
子育てエンジニア Advent Calendar 2022 23日目の記事です。
https://adventar.org/calendars/7964
第一子が生まれた2018年からはじめた子育てエンジニア Advent Calendarも5年目になりました。今年もたくさんの方が参加してくださって、嬉しい限りです。これまでのAdvent Calendarも、リアルですばらしい記事がたくさん集まっているのでよかったらご一読ください。
- [子育てエンジニア Advent Calendar 2018](https://adventar.org/calendars/3178)
- [子育てエンジニア Advent Calendar 2019](https://adventar.org/calendars/4199)
- [子育てエンジニア Advent Calendar 2020](https://adventar.org/calendars/5302)
- [子育てエンジニア Advent Calendar 2021](https://adventar.org/calendars/6793)
## 子供の教育ってどうしたらいいの？
2022年12月現在、こんな家族構成でおもしろ楽しく生活しています。
家族構成
自分（36歳、エンジニア、フルリモート）
妻（育児休暇中、Notエンジニア会社員）
長男（4歳、幼稚園年少）
二男（1歳）
自分たち夫婦はふたりとも上京組なので、基本的に4人だけで生活を営んでいます。2人の子供がいる生活にどうにか慣れてきた頃ですが、来年妻が復職したらどうなるんだろう？というフェーズです。
毎日生活をするのに必死な中でも、「子供の教育をどうするか」は子育てにおける重要なテーマの1つです。
習いごと・お受験・英語・プログラミングなどいろいろな観点はあるものの、今回はそういった個別具体の話ではなく、「学ぶ」こと自体について考えてみます。
## 自分はどうだったんだろう？
自分自身の学生時代を思い返してみると、学校に行くこと自体は嫌いではなかったですが、体育の授業と部活と友達に会いに行く場所くらいの存在でした。コツコツ勉強することがとにかく嫌いで、宿題をやった記憶はあまりないし、漫画以外の本を読んだ記憶もほとんどありません。人生に必要なことの多くは、ゲームと漫画から学びました。
一方で、社会人になってからは、エンジニアという職業柄なのか自然と勉強するようになりました。ほぼ初心者でエンジニアになったこともあって、プログラミングから開発手法まで、とにかく勉強しないと仕事ができないのでやるしかなかったというのが実情です。そこからエンジニアコミュニティと出会い、勉強会に参加したり、登壇するようになりました。技術書やビジネス書のような本も読むようになり、ついには自分で本を書くようになるとは学生時代の自分には信じられないことでしょう。
[itemlink post_id="2344"]
学生時代にあれだけ嫌いだった「学習」を、社会人になってから自然とやるようになったのはなぜなのか。答えは単純で、反骨心の化身である自分は、学生時代のやらされる「学習」が嫌いだったのです。社会人になっての「学習」は、自ら必要性を感じて自ら選択をしています。さらに、「学習」をすることで可能性が拡がっていく実感を得られることで「学習」自体が好きにさえなりました。
「学習」が嫌いだった学生時代を経たからこそ今の自分があると思うので学生時代に一片の悔いもないですが、ずっと「学習」を嫌いにならなかった世界線はどうだったんだろうと考えることはよくあります。
そんなことを考えたときに、できれば子供たちにはつまらない理由で「学習」を嫌いになって欲しくないなあという想いが強くなりました。
## "大人が楽しそうに学んでいる姿を子供に見せることって大事だよ"
テキサスで開催された [Agile2012](https://www.agilealliance.org/agile2012/) というカンファレンスに参加した際に、[@haradakiro](https://twitter.com/haradakiro/)さんが言っていたこのセリフが今でも心に残っています。
大人が楽しそうに学んでいる姿を子供に見せることって大事だよ
そのカンファレンスに[@haradakiro](https://twitter.com/haradakiro/)さんはお子さんを連れてきていました。日本語が通じない海外カンファレンスで、お子さんは楽しそうに走りまわり、さまざまなゲストと交流していました。もちろんそのゲストたちは、世界中から集まった楽しそうに学んでいる大人たちです。
その当時、自分は子供もいないどころか結婚もしていなかったので子育てはリアルではなかったですが、その光景は印象的で鮮明に覚えています。
## それから10年・・・
それから10年。2022年11月3〜5日にスクラムフェス札幌2022というカンファレンスがありました。このカンファレンスで登壇できることになったので、4歳の長男を連れていくことにしました。
https://www.scrumfestsapporo.org/
2人でセッションに参加をして、
楽しそうに学んでいる大人たちと交流をして、
自分たちのセッションにちょっとだけ登壇をして、4歳にしてコミュニティ初登壇の実績を解除しました。
しばらく経ってから本人に感想を聞いてみると、「楽しかった！」「また行きたい！」「今日は勉強会ないの？」と言っていました。この経験が本人にとってどういう意味をもつのかはわかりませんが、楽しそうに学んでいる大人たちと一緒に楽しんでくれたようでなによりです。
子連れ参加をあたたかく受け入れてくださったスクフェス札幌運営の皆様ありがとうございました。ちなみに、会場では他にもお子さんを連れて参加されている方がいて、子供同士でも交流が生まれていて微笑ましかったです。
そして、そのままカンファレンスついでに3泊4日ではじめての男2人旅をし、北海道を楽しんできました。
（写真は長男の念願だった「[きのこ王国](https://www.kinoko-oukoku.com/)」で収穫体験をしたときのもの）
## 学習は本来楽しいもの
長男は、車とキノコと食虫植物が大好きです。いろんな図鑑を置いておいたら図鑑を開いて読み込むようになり、読めなかった字が読めるようになり、今では親も知らないような知識を教えてくれます。
そんな子供を見ていると、「わからないことがわかるようになる」「できないことができるようになる」って楽しいことなんだと気付かされます。そして、それはおそらく誰もが子供の頃に経験していることであり、自分が社会人になってから学習が好きになった理由と同じです。
子供たちにはこの楽しさを忘れないまま人生を歩んでほしいし、そのために自分たちにできることをしていこうと思っています。
## 楽しそうに学習している親でいたい
「子供の教育をどうするのか」への答えが見つかることはないだろうし、家族で考え続けて、取り組み続けていくものです。まじめに考えれば考えるほどうまくいかないときに悲しいし、ときには責任を感じて子供に対してまじめにリアクションしてしまうような気がします。それが「勉強しなさい！」の正体なのかもしれません。
現時点での自分は「勉強しなさい！」って子供に言いたくないなあと思っていますが、もしかしたら言いたくなってしまうときがくるのかもしれません。でも、そのときに「勉強しなさい！」と言っている親（自分）が勉強していなかったらどうだろう？勉強していたとしても楽しそうに勉強していなかったらどうだろう？と想像してみました。自分が子供の立場だったら、勉強したくなくなるでしょう。
「勉強しなさい」の代わりに、楽しそうに学習している親でいようと思います。
---
# デンソーを卒業します
URL: https://agile-monster.com/blog/goodbye-denso/
Published: 2022-06-30
---
2022年6月30日をもって、株式会社デンソーから離れることになりました。今回はそのご報告です。
デンソーには2019年7月にチームで転職しました。自動車業界というドメインの大きな会社にも関わらず、前例のないチーム単位での転職を受け入れてくれる懐の深さに感動したことを今でも覚えています。
https://agile-monster.com/blog/teamfa-done/
デンソーにはまる3年在籍しました。この度、再びチーム転職することになったのですが、そのことについては下記リンク先でご報告させていただきました。
https://silver-bullet.club/blog/2022/07/01/teamfa2nddone.html
デンソーでは、ソフトウェアエンジニアとしてさまざまな仕事に携わりました。Silver Bullet Clubの3人だけで働くことはほとんどなく、プロジェクトごとにいろんな方とチームを組んで仕事をしました。一緒に働いた人たちから「人生が変わった」「ソフトウェア開発ってこういうことなんだって知った」「こういう仕事の仕方（アジャイル開発）がデンソーでもできるんだって知った」というフィードバックをもらえたことはとてもよかったです。
仕事以外では、Agile Japanのサテライトイベントとして愛知県豊橋市にあるデンソー本社で社内イベント「Agile New Japan」を立ち上げました。本社にもアジャイル開発に情熱を注いでいる人たちがいて、彼らとイベントをつくることができたのはとても感慨深かったです。コロナ禍に入ってからもオンラインイベントにかたちを変えて3年連続でイベントは継続しています。
その他にも、社内外のコミュニティ活動を通して知っていただいたデンソー社員の方からコンタクトをいただき、仕事の関係を越えてソフトウェア開発やアジャイル開発に関する相談を受けたり、社内イベントに登壇したりしました。
また、楽天時代の新卒研修に関するスライドを見たデンソーの新卒研修を担当者から連絡をいただき、デンソーの新卒研修でもアジャイル開発のProject Based Learningを実施しました。
これらのように個人の活動やコミュニティ活動と仕事がつながっていく経験を、デンソーの中でも体験できたことはとてもよかったです。この3年間でエンジニアコミュニティのイベントで出会うデンソー社員も増えて、中にはまつしゅーさんのようにコミュニティの運営に積極的に携わる人も出てきていてすごい変化だなと思っています。
転職のときにいいことだけ言うのはあまり好きではないので、うまくいかなかったことも少しだけ。
自分たちとしては、『デンソーをソフトウェアでも有名な会社にする』という意気込みで移籍してきたんですが、表に堂々と成果を示すことができるプロダクトや仕事の成果をつくれなかったことはとても心残りです。
また、デンソーには外からは見えないけれどすごいスキルや経験をもった人たちがたくさんいておもしろい一方で、やはり内弁慶でグローバルに見たときに時代にそぐわない慣習や文化も残っているところもありました。どんどんオープンになって内と外の境界が溶けていく傾向にあるので、遅かれ早かれ淘汰されていくものかなと思っています。
うまくいったこともうまくいかなかったこともあった3年間でしたが、ドメインを越えて製造業の会社に飛び込んで最高に刺激的で楽しかったです。なによりふつうの選択をしていたら出会わなかった経験や人たちと出会うことができたことが一番の宝物です。ありがとうございました。
自分のデンソー生活は幕を下ろしましたが、デンソーに入ったことをきっかけに立ち上げた製造業アジャイル勉強会も続けていきますし、これからもデンソーや日本の製造業の力になれることがあれば嬉しいです。研修でも講演でも相談でもなにかあれば、いつでもお気軽にご連絡ください。
https://beyond-hardware-agile.connpass.com/
最後に、いつものリストです。
https://www.amazon.jp/hz/wishlist/ls/1GT7SXTM8BK63?ref_=wl_share
---
# 「子供が生まれると自由な時間が減って学習できなくなる！」なんて今考えるとおこがましかった #子育てエンジニア
URL: https://agile-monster.com/blog/learning-from-parenting/
Published: 2021-12-01
---
この記事は、「子育てエンジニアAdvent Calendar 2021」1日目の記事です。
https://adventar.org/calendars/6793
子供が生まれると自由な時間が減って学習できなくなる！
なんて不安を感じたことはありませんか？
確かに子供が生まれると子供中心の生活に変わり、それまで自分が自由に使えていた時間が減ってしまうことが多いです。ナレッジワーカーの側面が強いエンジニアにとって、これは死活問題に見えます。特に学習意欲が強いエンジニアほど、学習に使えていた時間が減る＝成長が鈍化してしまうのではないか？と不安に駆られやすいでしょう。
ところが、子どもが生まれてから3年経った今、このような不安を感じていた自分はおこがましかったなと感じるようになりました。
## わたしの家族
2021年12月現在、こんな家族構成でおもしろ楽しく生活しています。
家族構成
- 自分（35歳、エンジニア、フルリモート）
- 妻（育休中、Not エンジニア）
- 長男（3歳、保育園）
- 二男（0歳）
自分自身、長男が生まれる前は勉強会に参加したり、コードを書いたり、趣味に時間を使ったり、自分の時間を謳歌していました。
もともと子どもが好きだったので子どもがいる生活を楽しみにしていたことと、どんなことでも死ななければどうにかなると思っているような性格なので特に不安は感じてはいませんでした。ただ、これまでのエンジニア生活を通して、まわりの先輩パパエンジニアから「時間がなくなるよ」「好きに時間が使えるのは独身の今だけだよ」と散々不安を煽られていたので、どうなるんだろうなーとは思っていました。
実際に長男が生まれると、やはり子供中心の生活に変わり、結果として勉強会に参加するペースも以前よりは減り、自分が自由に使える時間は減りました。今年の9月末に二男が生まれてからは、その傾向はより強くなりました。
## 「工夫すればどうにかなるでしょ？」期
確かに子どもが生まれて自由に使える時間は減りました。当初は、そんな中でも工夫すればどうにかなるだろうと考えて試行錯誤しました。
### 運営している勉強会の開始時間を変える
勉強会の多くは、参加者が就業後に参加できるように19:00頃に開始されることが多いです。ところが子どもがいる家庭にとって18:00〜20:00付近はゴールデンタイムであるため、とても参加しづらいです。コロナ禍に入ってそれまでオフライン開催だった勉強会がオンライン開催に切り替わっていった後もしばらくは、この状況はあまり変わりませんでした。
そこで、自分が運営している勉強会は遅めの時間開始（20:30〜）に変えて、ゴールデンタイムを終えて子どもが寝てからでも参加できるようしました。オフライン開催では選択できなかった解決策が、オンライン開催であれば選択できるようになりました。
その後、同じように遅めの時間や日中に開催する勉強会や、イベント開催後にアーカイブ動画を公開してくれる勉強会が増えたので、本当にありがたいです。すべての勉強会を運営してくださっている皆さんに感謝します。
### すきま時間をうまく活用する
自由に使える時間が減るだけでなく、急な割り込みが入ることでまとまった時間がとりづらくなります。
そこで、やりたいことを30分以内になるようにタスク分割して管理するようにしました。仮に割り込みが入って中断したとしても30分以下であればそこまで痛くないのと、運良く隙間時間が生まれたときにタスクをいくつかこなすことができます。スライドづくりやコーディングなどまとまった時間をとりたい気持ちはあるものの、制約の中でも工夫すれば案外どうにかなるものです。
また、家事をしながらPodcastを聞いたり、耳で読書をすることも、効率厨としてはすごくよかったです。
https://www.audible.co.jp/
Audibleは本を音読してくれるアプリです。聞くことができる書籍の数もそこそこあるのと、プロの音読は倍速で聞いても聞き取りやすいので重宝しています。
[itemlink post_id="2536"]
骨伝導は音声を聞いていても耳がフルオープンなので、周囲の音を聞いたり会話をすることができるので重宝しています。
### お金で解決できることは解決する
お金で解決できることはなるべく解決するようにしました。
- 食洗機
- ロボット掃除機
- スマートスピーカー
- スマートスピーカー連携のもろもろ
- 自動調理鍋
確かにお金はかかるかもしれませんが、時間を買うようなものなので、必要なものには投資するようにしています。
## 「自分の時間」と「家族の時間」のトレードオフ問題
子育てと自分の時間を両立することをしばらく頑張ってみて、それなりにうまくいくようになりました。ところが、結局のところ「自分の時間」と「家族の時間」を分けて考えてしまっていることに気が付きました。
少し前に、「[家族やプライベートを犠牲にして仕事や実績を得ていたことから目を背けられなくなった件](https://hb.matsumoto-r.jp/entry/2021/11/12/110219)」という記事を読みました。内容はとても考えさせられるものでした。
なにかをするための自分の時間が欲しいという気持ちはそれぞれに生まれるものであり、それ自体は悪いことではありません。ましてや子どもが大きくなれば、彼らにもやりたいことがどんどん増えていきます。
そのときに「自分の時間」と「家族の時間」を分けて考えてしまっている限り、この2つはトレードオフの関係となり、ずっとバランスを取り続けなくてはなりません。必要なことだとは思いつつ、もう少し前向きに取り組めないかと考えるようになりました。
つまり、完全に「自分の時間」と「家族の時間」を分断するのではなく、この2つを境を曖昧にしていくことにチャレンジしてみることにしました。
## 「自分の時間と家族の時間の境目を溶かしてみる」期
そもそも「自分の時間」がないと学ぶことができないという発想をやめて、「家族の時間」の中で学べる方法を探してみました。
### 子ども学び方から学ぶ
子どもがパズルをしていたときのことです。
どんなふうに組み立てるのか黙って横から見ていると、「え、そんなところから組み立てるの？」と思うようなところからパズルが組み上がっていきました。なんとなく角や端からつくったほうがよさそうな気がしていましたが、彼にだけ見えている世界があるのでしょう。
子どもが文字に興味を持ち出したときのことです。
お風呂の壁にあいうえお表（各ひらがなの代表例と絵が載っているタイプ）を貼ってみたところ、一緒にお風呂に入るたびに「これ何？」と興味がある絵を指すので答えていました。特に網羅的に教えたりはしなかったんですが、ある時から見える範囲のひらがなをすらすらと読み上げるようになりました。
[itemlink post_id="2541"]
アルファベットにも興味を持ち出したので1ヶ月ほど前にお風呂にアルファベット表を貼ったんですが、まさにこの記事を書いている日に、自分の着ているシャツに書いてあった英文のアルファベットを読み上げて驚きました。
なんとなく自分が知っている常識や定石をもとに子どもにアドバイスしたくなってしまいます。そうした気持ちをぐっとこらえて、彼らの学び方を観察して、必要なときに必要なものがあるようにするだけで、驚くような成長を遂げることが何度もありました。
同時にそんな子どもの学び方を見て、自分がそれまでなんとなく効率がいいと思っていたことを疑うようになりました。たとえばそれまでは読書をするときになんとなく全体を読もうとしてしまっていましたが、興味があるところだけを読んだり、順番を入れ替えて読んだり、複数の本を同時に読み進めてみたり、自由にインプットするように読書への向き合い方を変えてみました。今のところすごくよい気がしています。
親として子どもにどう教えるかだけを考えてしまいがちですが、子どもから教えてもらうこと・子どものふるまいから学ぶことはとても多いです。
### 子育てに関連することを学ぶ
エンジニアをしていて、エンジニアリング以外のことから学んだことが仕事に生きる経験をこれまで何度もしてきました。
子育てをしている今の時期に子育てや教育について理解することは重要であり、そこで学んだことが仕事にも活きるかもしれないのであれば、一石二鳥になるかもしれないと思いました。
まずは手軽に、子育て本を読んだり、教育に関するPodcastを聞くことからはじめました。
※COTEN RADIO「教育の歴史」シリーズのページは移転したようなので、当時の[アーカイブ](https://web.archive.org/web/20230129050030/https://cotenradio.fm/category/s25-%E6%95%99%E8%82%B2%E3%81%AE%E6%AD%B4%E5%8F%B2/)を貼っておきます。
子どもの教育は、世界中で研究がされていて、さまざまな論文やそれに基づく教育方法が存在します。それらの中でも特に、相手の成長過程（状態）を理解し、話の聴き方、伝え方などを工夫することは、子どもに限らず必要なふるまいだと感じました。
ちょうど少し前からコーチングに興味を持って学び始めていたのですが、かなり近い分野です。チャイルドコーチングの資格もあるようなので来年受けてみようと思っています。
https://www.c-c-j.com/course/welfare/coach/
## 「自分の時間」から「自分たちの時間」へ
冒頭に戻ります。
子供が生まれると自由な時間が減って学習できなくなる！
この3年間を通して、こんなことを不安に思っていた自分がおこがましかったと感じるようになりました。
確かに子どもが生まれると自由に使える時間は減ります。しかし、その分家族との大切な時間を増やすことを選んだのは自分自身です。そして、その時間の中ではそれまでに学べなかったことを学ぶチャンスがたくさんあふれています。
結果的にエンジニアリングのことを学ぶ時間が減っているんだからエンジニアとしての成長が止まっているのでは？と思ってしまいがちですが、それはエンジニアの世界を小さく見てしまっているのかもしれません。
「自分の時間」と「家族の時間」という二元論で考えるのをやめて、「自分たちの時間」という全体の中で人間として、家族として成長していくことを大事にしたいです。そしてそれはきっとエンジニアとしての成長にもつながるものだと信じています。
要するに前向きに楽しんだもの勝ちってことですね。
このあとも素敵な記事がたくさん読めると思うので、「子育てエンジニアAdvent Calendar 2021」をお楽しみください。そしてエントリーしてくださってるみなさんは、予定の日に間に合いそうになければ遠慮なく遅らせたり、キャンセルしてください。
家族にやさしいブログ生活を！
https://adventar.org/calendars/6793
---
# ふりかえりからはじめよ - チームづくりのシンプルな本質 -のスライドを公開しました #scrumsapporo
URL: https://agile-monster.com/blog/startwithretrospective/
Published: 2021-11-12
---
Scrum Fest Sapporo 2021で講演してきました。
https://confengine.com/conferences/scrum-fest-sapporo-2021/proposal/16041/-
ふりかえりからはじめよ - チームづくりのシンプルな本質 -
アジャイル開発をはじめるときにどのプラクティスからはじめますか？
この問いに、「ふりかえり」と答える実践者の方はとても多いです。
企業活動では一定期間を区切って評価する習慣があるため、プロジェクトのふりかえりや個人のフィードバック面談のようにふりかえりと似た活動を既に経験している方が多いです。そのため、ふりかえりというプラクティスをはじめる理由を説明しやすく、受け入れる方も必要性が理解しやすいため、ふりかえりからはじめることは比較的容易です。最近では、ふりかえりの実践についてさまざまな書籍や情報が手に入るようになったことも後押しをして、既に実践している方も多いでしょう。
一方で同じような現場で同じようにふりかえりをはじめてても、誰がやるのかによって効果が大きく異なるのもふりかえりです。
つまり、ふりかえりは方法や形式ではないところに成果を左右する大きな理由があるように感じています。
はじめてふりかえりをすることになったがどうやって場をつくればよいかわからない
ふりかえりを続けてはいるんだけど、ただ続けているだけになっている気がする
一部の人が中心になって進めているだけで、チームの全体感が生まれていない
リーダー（ファシリテーター）への報告会になってしまっている
こういった悩みにどうやって立ち向かっていけばいいのか。
必要とされているのは、チームの状況に合わせてふりかえりのゴールをどのように設定するのか、そのときに最適な方法はなんなのか、ふりかえりの中で起こる問題をどのように解釈してどうやって解決するのか、などの実践知ではないでしょうか。
チームや組織の中でさまざまなふりかえりを実践し続けてきた経験と、アジャイルコーチとしてチームの外からふりかえりを支援してきた経験を合わせて、今の自分に見えているふりかえりという世界についてお話してみます。
いまこそ俺たちの本当のふりかえりをはじめましょう！
Regional Scrum Gathering Tokyoなどではチームのアップデートを話すことが多いので、1つのプラクティスだけを取り上げて講演する機会は少なくなりました。でも、現場での経験とアジャイルコーチとしてさまざまな現場を支援してきた経験を経て、いまの解像度だからこそ話せる「ふりかえり」があるんじゃないかなーと思ってセッションをつくりました。
敢えて具体的なプラクティスやコツではなく、どういう視点でふりかえりを捉えているのかを中心に言及してみました。ふりかえりをこれからはじめようと思っている方、ふりかえりを通してもっとチームをよくしたいと思っている方のヒントになれば幸いです。
ふりかえりはもちろんチームづくりやアジャイル開発導入について、壁打ちもしていますのでお気軽にご連絡ください。
https://agile-monster.com/contact/
---
# チームのコミュニケーションの方向を気にする
URL: https://agile-monster.com/blog/direction-of-communication/
Published: 2021-07-29
---
プロダクト開発やアジャイルコーチの仕事をしていて、自分がチームや組織をみるときにコミュニケーションの方向を気にしているなーと思った話。
## 司令塔型
司令塔型は、特定の個人が中心となって各メンバーとの間でコミュニケーションが発生している状態です。コミュニケーションの起点は、司令塔発信になることがとても多いです。
例えばふりかえりなどの会議の場で、ファシリテーターが各メンバーに話をふって、それに対して回答をして場が進んでいくときにはまさにこの司令塔型のコミュニケーションになっています。
チームや組織ができたばかりのときにはこのケースからはじまることが多いです。ただし、このかたちが定常化すると、コミュニケーションが特定の個人に依存してしまいがちです。
また、各メンバー視点でみると、基本的には自分と司令塔の1対1のコミュニケーションをしていることになります。
## トータルフットボール型
トータルフットボール型は、各個人間でランダムでコミュニケーションが発生している状態です。コミュニケーションの起点は、固定化されておらずどこからでも発生します。
例えばふりかえりなどの会議の場で、ファシリテーターが各メンバーに話をふらなくても、それぞれが話したいときに話し始めて、ほっておいてもメンバー同士で議論が盛り上がっていくときにはまさにトータルフットボール型のコミュニケーションになっています。
自己組織的なチームや組織ができてくると、これに近いコミュニケーション型になることが多いです。ただし、盛り上がりすぎて議論が白熱してしまうこともあるので違う観点での注意は必要です。
また、各メンバー視点で見ると、全体の議論を聞きながら必要に応じて自分が話をすることになるので、自己組織的なコミュニケーションをしていることになります。
## 実践をしてうまくなる
2つの型を紹介しましたが、どちらがいい・悪いという話をしたいわけではありません。チームや組織の成熟度や仕事の状況次第では、司令塔型の方がうまくいくときもあるでしょう。
ただ、司令塔型のコミュニケーションで仕事を進めることは比較的マネジメントしやすいので、ついやり続けてしまいがちです。
自己組織的なチームや組織をつくりたいと思ったときに、司令塔型のコミュニケーションを続けていても自己組織的なコミュニケーションはうまくなりません。自己組織的なコミュニケーションは自己組織的なコミュニケーションを実践することでしかうまくならないのです。
## コミュニケーションの方向を気にする
経験上、チームや組織のコミュニケーションの方向がどうなっているのか観察するとわかることがとても多いです。どういうチームや組織にしたいのかを考えて、そのためのコミュニケーション設計を考える、という逆引きで考えてみるのもまたおもしろいです。
---
# XXよりもYYという表現は気をつけて使おうと思った話
URL: https://agile-monster.com/blog/xxoveryy/
Published: 2021-04-21
---
大切にしていることや大事にしようと思っていることを伝えるときに、「XXよりもYY」や「XXの方が」のような比較表現が使われることがあります。これらの表現は、発信した本人の意図が正しく伝わらないことが多いと感じたので、気をつけて使おうと思いました。
## XXよりもYYという言い方
「XXよりもYY」という比較表現は、「XX＜YY」という式を表しています。この表現を使うときはYYを強調するためにXXと比較しているに過ぎません。したがって、XXの価値については特に触れられないことが多いです。
この際に受け取り手は、
- （XXもすごく大切なんだけど、）XXよりもYYが大切だよね
- （XXはそれほど大切ではないので、）XXよりもYYが大切だよね
のように人によってかなり幅広い解釈をします。
したがって、発信した本人は「YYが大切だ」ということを伝えたかったのにも関わらず、「XXは大切ではない」「XXは必要ない」という意図しない切り取られ方をしてしまう可能性があるのです。
## アジャイルソフトウェア開発宣言の例
アジャイルソフトウェア開発宣言がとてもわかりやすい例です。
>
>
> プロセスやツールよりも個人と対話を、
> 包括的なドキュメントよりも動くソフトウェアを、
> 契約交渉よりも顧客との協調を、
> 計画に従うことよりも変化への対応を、
>
>
>
> 価値とする。
>
> アジャイルソフトウェア開発宣言 https://agilemanifesto.org/iso/ja/manifesto.html
この部分は特徴的なのでよく注目される一方、同時に最も誤解を生みやすい部分でもあります。
この表現だけを読んで各項目の左側のことがらは大切ではないと読み取り、
- アジャイル開発はドキュメントを書かない
- アジャイル開発は計画をしない
と誤解してしまうケースをよく見ます。
しかし、実はアジャイルソフトウェア開発宣言では直後に以下のように記述されています。
>
>
> すなわち、左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。
>
> *アジャイルソフトウェア開発宣言 https://agilemanifesto.org/iso/ja/manifesto.html*
つまり、アジャイルソフトウェア開発宣言ではドキュメントにも計画に従うことにも価値があるとされているにも関わらず、発信者たちの意図とは異なる誤解が生まれてしまっているのです。
しっかりと補足されているのにも関わらず誤解が生まれてしまうということは、この部分を読まずに「XXよりもYY」という部分だけを読んでいるのか、あるいは読んだ上でも誤解が生まれてしまっているのでしょう。
## XXも大切だしYYも大切だよね
アジャイルソフトウェア開発宣言以外にも、「ライトウィングよりもレフトウィングが大切だよね」「エンジニアはマネジメントよりもエンジニアリングを磨くべき」のような表現も同様の誤解が生まれているように感じます。おそらくほとんどの場合、発信者たちはどちらも大切だと考えている上での発言ですが、その部分が正しく伝わっていない可能性があるのです。
自分も発信する側として、そういう表現を使うことがあったので、誤解を生みたくないときは「XXも大切だしYYも大切だよね」という表現に変えてみようと思いました。
一方で受け取り手としては、一つのことが大切なときに他のことが大切ではないと考えてしまうのは少し偏った深読みをしてしまっているように感じます。大切なことは何個あってもよくて、自分の中で優先順位がついていれば困らないと思うので、素直にメッセージを受け取ってみようと思いました。
---
# コーチングを体系的に学んでみる
URL: https://agile-monster.com/blog/start-coaching/
Published: 2021-04-09
---
今年はインプットの年にすると決めたので、コーチングを体系的に学んでみることにしました。せっかくやるなら国際コーチ連盟（ICF）の資格を取るくらいまではやってみようと思います。
## なぜコーチングを学ぶのか
複業（個人事業主）でアジャイルコーチをするようになって2年が経ちました。企業の中だけで活動していたときと比べて、多くの人と仕事で関わるようになって、その楽しさを感じています。
しかし、「コーチ」を名乗っているものの、コーチングについて体系的に学んだことがありません。所属していた会社でコーチングに関する研修を受けさせられたり、本を読んだりしたことはあるものの、それでは表面的に知っているレベルに過ぎません。
海外ではアジャイルコーチも国際コーチ連盟の資格を持っている人が多いようですが、日本では自分が知っている限りほとんどいません。もちろん資格を持っているかどうかは重要ではないですが、この資格は学習時間も実践時間も求められるので、それなりに気合いを入れてコーチングを学んでいることは間違いないでしょう。
https://icfjapan.com/credentials
もちろんこれまでもまじめに一緒に仕事をする人と向き合ってきましたが、せっかく「コーチ」を名乗っているのでコーチングについて体系的に学ぶことで、自分自身の選択肢も拡がるし、相手からの信頼を得やすくなるような気がします。
あとはコーチングを学んで実践したこともないのに批評するのはダサいと自分は思っているので、まずは頭を空っぽにしてコーチングに取り組んだ上でコーチングについての自分の意見を持とうと思っています。
## コーチングスクールの選び方
国内だとコーチングを学ぶスクールは乱立していて正直よくわかりませんでした。そこで知り合いのコーチに話を聞いたり、いくつかのスクールの説明会に参加して情報収集をしました。
ほとんどのスクールが国際コーチ連盟の認定を受けていて、国際コーチ連盟のプログラムに則ったトレーニングをしているのでコアとなる部分はそこまで違いがなさそうです。価格、環境（いまだとオンラインでの受講環境）、方向性はスクールによって違うので、自分に合いそうなスクールをフィーリングで選ぼうと思いました。
https://icfjapan.com/post/credentials/566
その結果として、CTI（Co-Active® Professional Coach Training）のコアコースを受けることに決めました。
https://www.thecoaches.co.jp/coaching/#core
選んだ理由はフィーリングです！
知り合いのコーチがCTI出身だったこともありますが、もし興味があれば他のスクールも受ければ良いだけなので、まずは手始めに自分が入りやすそうなところからやってみようというくらいのノリです。
## コーチングを受けてみる
学ぶのと同時に実際にコーチングを受けてみようと思い、スーパーコーチであるAkiさん（[@spring_aki](https://twitter.com/spring_aki)）にお願いすることにしました。
これまでコーチングを受けてみようと思ったことがなかったので考えてもみなかったのですが、よくよく考えてみたらコーチとはそれなりの時間を一緒に過ごすことになるわけです。であれば、知らない人にコーチをしてもらうよりも、話したい人にコーチしてもらえるなら何倍もお得じゃん！ということでAkiさんにお願いすることにしました。楽しみです！
## 1on1をしてみる
アジャイルコーチでコーチングを学んでいる先輩であり、師匠でもある藤原さん（[@daipresents](https://twitter.com/daipresents)）と定期的に1on1をすることにしました。お互いにコーチングを試しあったり、お互いに考えていることを定期的に話すことはとてもよい場になりそうです。
やっていくぞ！
---
# モブプログラミングに関する質問に答えてみた
URL: https://agile-monster.com/blog/mobprogramming-qa/
Published: 2021-04-08
---
とある企業でモブプログラミングと、それを通して自分たちの仕事のやり方をどう変えていくのかについてお話する機会がありました。参加してくださったみなさんがコメントや質問で盛り上げてくださって、時間内に質問に答えきることができなかったのでブログにまとめてみます。
講演、ワークショップ、チーム支援などのお仕事の依頼はこちらからどうぞ！
https://agile-monster.com/services/
# Q&A
### モブプログラミングに最適なチームサイズ、最大のチームサイズは何人くらいか？
チームの最適な人数は、3〜8人であるとよく言われます。その主な理由はコミュニケーション効率です。
https://www.businessinsider.com/amazon-ceo-jeff-bezos-two-pizza-rule-productive-meetings-2017-6
単純にモブプログラミングをする際のコミュニケーション効率だけを考えれば、3〜5人くらいが最適な人数です。ただ、モブプログラミングをする目的次第では10人以上でモブプログラミングをすることも実際にあります。
たとえば、チーム内の知識移転や教育を目的にワークショップ形式でモブプログラミングをする場合、コミュニケーション効率よりもチーム全員で同じ時間を共有することの方が優先されるかもしれません。
効率だけでなく効果を考えて最適な場を設計できるとよいですね。
### 例えば「スキルレベルの差が大きすぎないこと」のような、モブプログラミングで取り組む際に気をつけた方がよい条件はありますか？
モブプログラミングはただのチームワークなので、モブプログラミングだからといって特別に気をつけることはあまり思いつきません。ただ、性質上コミュニケーション密度が濃くなるため、心理的安全性が低いチームの場合はストレスフルな場になりやすいので用法用量は守ったほうがよいでしょう。
ちなみに例示してくださったスキルレベルの差が大きい状態は、むしろモブプログラミングをうまく使いたくなるシーンです。モブプログラミングは必要な情報を必要なときにインプットすることができるので、教育効果が高く、知識移転に向いています。
### モブプログラミングは新人教育もできますか？チームが集まる必要があるため、経験が少ない人がいると傍観してしまいそうだと思いました。
モブプログラミングの教育効果は高いため、新人教育や新しいメンバーの受け入れ時にうまく活用できるとよいでしょう。
スキル差がある場合に、なかなか仕事に貢献できなかったり、会話量のバランスが偏ってしまうことはあります。一番大切なことは、新人や新メンバーの方に「すぐに仕事に貢献することは難しいかもしれないですが、最初はわからないことをわかるようになることを大事にしてください」というようなことを伝えて、安心してその場に参加してもらうことです。
また、実際にモブプログラミングをするときのコツとして、わからなければ仕事を止めることができる権利を持っているドライバーを経験が少ないメンバーに多く担当してもらうように場を設計するとうまくいくことが多いです。
それ以外にも、
- 仕事を止めて理解を確かめる時間を定期的につくる
- モブプログラミング以外に個人で復習できる時間をつくる
などをやってみるとよいでしょう。人によって学習しやすいスタイルやペースは異なるので、相手に合わせてあげるとよいです。
### コードを書いているときはググることも多いと思うのですが、モブプログラミングの場合はググるのもドライバーに担当してもらうのでしょうか？
それも一つの方法です。人によって検索ワードや検索方法が異なるので、そういった「ググる」を共通体験することにも価値があるでしょう。
私たちのチームではなにかに詰まづいたときは、自然とソロワークに切り替わって個々人の手元でググったりデバッグすることが多いです。そして解決策やよい情報が見つかった人がチームに共有をして、また自然とモブプログラミングに戻ります。
モブプログラミングをするからといって肩肘をはらずに、場面場面で最適な方法を選択できるようになることと、少しずつその切替をスムーズにしていくことを意識するとよいでしょう。
### ドライバーが2人以上になることはあり得ますか？VS Codeなどの同時編集機能を使えば可能だと思います。
ドライバー2人以上にした方がよい場面であればやってみましょう。ただし、「なぜモブプログラミングを2つに分けないのか」という問いには答えられるようにしておいたほうがよいと思います。
私たちのチームでは、同時編集をする機会はあまりありません。同じ修正を複数ファイルに手作業でやらなければいけない場合に、一時的に同時編集で手分けして対応したことはあります。
### エンジニア以外のメンバー（マネージャー、プロダクトマネージャー、ビジネスサイドなど）もモブプログラミングに入ることはありますか？
あります。
むしろ開発をしている最中に出た疑問点にその場で答えてもらったり、仕様変更の相談をリアルタイムで行ったり、できたものをその場で確認してもらうことで仕事がスムーズに進むので、よいかたちだと思います。そもそも仕事への貢献の仕方は人によってさまざまなので、必要であれば職種に限らず参加してもらえるとよいでしょう。
参加のタイミングについては、常に参加してもらってもよいですし、必要なタイミングで入ってもらうかたちでもよいです。
### フェイストゥーフェイスで行うコミュニケーションと親和性の悪いエンジニアもいるかと思いますが、どう思いますか？
いらっしゃると思います。
ただし、それはモブプログラミングとしての課題ではなくチームの課題です。そのような多様なメンバーがいるチームでどう仕事をするのか。モブプログラミングをしないとしてもフェイストゥーフェイスでのコミュニケーションをしなければいけない場面やしたほうがよい場面はあるので、そのときにチームでどのように対応をするのか。
モブプログラミングは選択肢の一つに過ぎないので、チームに合わなければ他の選択肢をとればよいです。どちらか1つを選ばなければいけないわけではないので、チームや仕事に合わせて柔軟に対応してみてはいかがでしょうか。
### 常にモブプログラミングするスタイルでよいなと思っていることを教えて下さい。
前提として、私たちのチームの「常にモブプログラミングするスタイル」というのは、モブプログラミングをベースにしていますが必要に応じてソロワークやペアワークをしています。
その前提で、モブプログラミングをベースにしていてよいなと思う点は、
- アウトプットだけではわからないコツや考え方をお互いに学び合えること
- 同期が自動化されているので考えるコスト自体がなくなったこと
- インクリメント（つくったものが積み上がっていく）を実感できること
- ムダだと思うことが減ったこと
- 誰かが犠牲になることなく全員がエンジニアリングに向き合えること
- リモートワークにおいても常に話しているのでオフラインと違いを感じないこと
などがあります。
### チーム内のコミュニケーションは円滑になる気がしますが、複数チームがある時のチーム間のコミュニケーションは何かしら工夫する必要があるのでしょうか？
そのとおりです。
チームでうまく仕事が進んでいたとしても、チームの外にいる人達とコミュニケーションをしていく必要はあります。
その際の工夫のコツとして、チーム「外」の人たちともキャッチボールだけでなくモブプログラミングのような共通体験を通したコミュニケーションを取り入れてみてもよいでしょう。
「チーム」というのは階層構造だと思うので、広い意味でもチームととらえてみるとふだん取り組んでいるチームワークとそれほど変わらないのかもしれませんね。
### ソフトウェア開発以外の領域の活用事例あれば教えて下さい。
チームで同じアウトプットを目指して仕事をする場面であれば、ソフトウェア開発以外でもモブプログラミングを活用できます。
自分が実際にやったり聞いたことがあることだと、
- 翻訳
- 資料作り
- イベントづくり
- デザイン
- カスタマー対応
- メールライティング
などがあります。
### 仕様をつめるようなタイミングでは議論をして決まった内容をドライバーが代表して書くような進め方でよいでしょうか？
それでもよいと思います。
でもよく考えたら、モブプログラミングでなくても誰かが代表して文字や図を書いて意思統一を図っていくことはよくやってますよね。
### フレックスや裁量労働制のような勤務形態との相性のよしあしはあるでしょうか？
そうですね、勤務時間がズレている場合はタイミングを考える必要はあると思います。
世界規模での多拠点開発であればタイミングを合わせることが難しいかもしれませんが、そうでなければ重なる時間はあると思うのでその時間に合わせればよいでしょう。
時間がズレて働いているチームの場合、チーム内での意思統一や知識移転の重要性が上がると思うので、重なる時間にモブプログラミングをすることはとてもよさそうです。
### 研究開発のような専門性がかなり個人に依存するような組織でもモブプロは機能するのでしょうか？
その「組織」が同じ目的のもとで協力してアウトプットを出そうとしているチームであるならば、いまでもなにかしらの方法を使って個々人が協力して仕事をしているはずですよね。
属人化している専門性を知識移転をしたい、あるいはお互いに専門領域の理解を深めたいなどであればモブプログラミングしてみる価値はありそうです。
### 日本語ネイティブではない方がいる場合に有効な工夫とかありますでしょうか？
そういう場面でモブプログラミングをした経験がないのでよい回答ができなくてすみません。
使用する言語がズレているチームで働いたことはあるので想像ではありますが、モブプログラミングをする際に使用する言語は最初に決めておいた方がよいだろうと思いました。
その前提であれば、言語に関してもテクニカルスキルと同じように考えて、スキル差があることを念頭においてチームワークを進められる気がします。一方で統一で使える言語がなかったり、あまりにも効率が悪いのであれば、無理にモブプログラミングを選択する必要はないでしょう。
---
# 「アジャイル開発とスクラム第2版」が出ました #アジャイル開発とスクラム
URL: https://agile-monster.com/blog/agile-scrum/
Published: 2021-04-06
---
「アジャイル開発とスクラム第2版」が4月7日に出ました。
[itemlink post_id="2344"]
今回、光栄なことに世界のKENJIこと平鍋さん（[@hiranabe](https://twitter.com/hiranabe)）とタッグを組ませていただきました。
この本の第1版は2013年に出ています。第1版の中に、藤原 大（[@daipresents](https://twitter.com/daipresents)）さんが書かれた楽天の事例が載っていて、当時自分はその事例で紹介されたチームに所属していました。そこから8年が経ち、共著者として平鍋さんと野中先生に名前を連ねることができたことがとても感慨深いです。
## この本のよいところ
この本のよいところは、日本人による書き下ろし本で、アジャイル開発やスクラムの雰囲気を1冊に詰まっているところです。
この本は、
- アジャイル開発の概要
- スクラムの概要
- 主要なプラクティスの紹介
- スクラムの概要
- 日本企業の事例
- 野中先生のメッセージ
が1冊に詰まっていることに価値があります。
最初にアジャイル開発やスクラムを知る取っ掛かりの1冊として、あるいは自分のまわりにいる上司や経営陣など実践者をサポートしてくださる立場の人たちに読んでもらう1冊として、必要な情報がすべて詰まっています。
正直なところ、この本を読んだだけでは明日からアジャイル開発やスクラムをはじめることは難しいでしょう。個々のフレームワークやプラクティスをより詳細に理解したい場合は、参考文献に紹介されている本を中心に世の中に良い本が沢山存在しているのでぜひそちらを読んでいただくことをおすすめします。
## 第2版の改訂の内容
第1版を読んでいただいた方向けに改訂内容を紹介します。
- スクラムガイド2020に準拠
- スケールフレームワークの紹介
- 日本企業の事例の刷新
- コラムの刷新
- 「ワイズカンパニー」との関係
第1版から8年が経ち、当時とはアジャイル開発やスクラムの普及具合や、周囲の理解などさまざまな状況が変化しています。ガイドやプラクティスも進化をしていて、組織レベルでの取り組みも盛り上がっています。そうした2021年現在の状況を反映した内容に改訂をしています。
第1版を読んでいただいた方はぜひ時代の変化を感じながら読んでいただけるととても嬉しいです。自分も改訂をしながら変化を感じることができました。
## 出版にあたって
自分は、1冊の本の出版にここまで深く関わるのははじめてでした。
本を書くというのは一大プロジェクトだと聞いていましたが、まさしくそのとおりでした。一緒に仕事をしてくださった平鍋さん、貴重な機会をありがとうございました。平鍋さんの平鍋さんたる所以を感じることができ、タッグを組ませていただくことで世界を感じることができました。
そして第2版で事例を書いてくださった、薄井さん、岡島さん、橋本さん、室木さん、蜂須賀さん、佐野さんありがとうございました。みなさんが日本を代表する事例を書いてくださったおかげで、本の内容に現場のリアルを盛り込むことができました。
そして、出版社である翔泳社の皆さん、第1版に関わってくださった皆さん、ありがとうございました。
読んでくださった読者のみなさん、読もうかなと思ってくださった皆さん、ありがとうございました。
そしてこの本を書く自分を作ってくださった、仕事で関わってくださった皆さん、チームの皆さん、そしてなにより家族に感謝を伝えたいと思います。
ぜひお買い求め下さい！
[itemlink post_id="2344"]
今後、出版記念イベントなどを開催していく予定です。そちらもぜひお楽しみに！
---
# 1年間オンラインOSTを続けてきた中でやってよかった工夫
URL: https://agile-monster.com/blog/online-ost-knowledge/
Published: 2021-03-11
---
数年前から日本においてもさまざまなイベントでOST（Open Space Technology）が開催されるようになりました。コロナ禍に入っても、そのままオンラインでOSTが開催されています。
この1年間、運営をしている[製造業アジャイル勉強会](https://beyond-hardware-agile.connpass.com/)を中心にさまざまなイベントでオンラインOSTに参加・運営をしてきた中で、やってよかった工夫を見つけたのでご紹介します。
OSTについてはこちらをどうぞ。
https://agile-monster.com/blog/ost-introduction/
https://agile-monster.com/blog/ost-guide/
https://agile-monster.com/blog/online-ost/
## ファシリテーター指定枠をつくる
どうやったらもっとOSTがおもしろくなるか試行錯誤する中で、参加者の方にたくさん話を聞きました。その中で、
>
>
> 提案してみたいテーマはあるけれど、セッションのファシリテーションをする自信がない
>
>
という声を複数聞くことができました。場慣れしている人ならともかく、そうではない人からするとセッション提案すること自体よりもディスカッションの場をファシリテーションすることに抵抗があるようです。
もちろん失敗してもよい場なので、ファシリテーションに挑戦してもらうことも醍醐味ではあります。その一方でファシリテーションが苦で提案できなくなってしまくらいなら、「ファシリテーションは得意な人がやることにして、テーマだけ提案できる仕組みがあればよいのでは？」と思い、実験してみました。
OSTのテーマだしの際に、「ファシリテーター指定枠」をつくっておきます。上の写真の緑の四角のように、ファシリテーターの名前の枠を用意しておき、そこに置いたテーマはファシリテーターがセッションを進めるというやり方を試してみました。
やってみた結果、参加者の方からはとても好評でした。「ファシリテーションを代わりにやってくれるなら、安心してテーマを出せる」といった声を聞くことができました。また、今回は実験的に自分含めて運営メンバーがファシリテーター枠をつくりましたが、「自分もファシリテーター枠やってみてもいいよ」という参加者の方も何人かいました。
提案したいテーマがあるけどファシリテーションが苦手に感じている人と、ファシリテーションだけやってもいいよ！っていう人とがマッチングする仕組みができたような気がします。おもしろかったので、次回以降も続けていく予定です。
## オンラインOSTも楽しい！
オンラインOSTは、オフラインでやっていたOSTをオンラインに置き換えたというだけでなく、オンラインならではのよさを活かすことができます。オフラインでのOSTとはまた違うよさがオンラインOSTにはあります。
コロナ禍で誰かと雑談する機会が減っている人が多い中で、OSTで会話をすること自体もそうですが、文字でのコミュニケーションとハイブリッドで場が盛り上がる場をぜひ一度体験してみて下さい。
主催している製造業アジャイル勉強会も、毎回OSTをやっていますのでよかったら遊びに来て下さい！イベントページを見てもらえばわかる通り、製造業ではない方も自由に参加いただけます。
https://beyond-hardware-agile.connpass.com/
---
# Continuous Teaming -2つのチーム移籍の物語- #devsumi
URL: https://agile-monster.com/blog/continuous-teaming/
Published: 2021-02-19
---
Developers Summit 2021で講演をしてきました。
https://event.shoeisha.jp/devsumi/20210218/session/3073/
今回も [kyon_mm](https://twitter.com/kyon_mm) と「きょんおよ」でチーム移籍に関する講演をしました。資料はこちらです。
※当日、クロストークで話した内容のサマリーも追加しています
チーム移籍は、一般的に個人の単位で行う転職活動をチームという単位で行うものです。Silver Bullet Clubは2019年に、47機関は2021年にそれぞれチーム移籍を成し遂げました。今回はその「チーム移籍」をテーマに講演しました。
冒頭でもお話しましたが、「チーム移籍はすばらしいからみんなやるといいよ！」ということを伝えたかったわけではありません。チーム移籍はあくまで、よいチームを続けていった結果の1つの形に過ぎません。参加者のみなさんとよいチームが続いていったあとの世界について一緒に考える時間をつくろうと思って、今回の講演をつくりました。
すべてはこのスライドに思いがこもっています。
- TAKAKING22
人によって想像するよいチームが違うと思うし、それでよいと思う- 多種多様なよいチームが世の中にたくさんあふれたら、
自分たちもわくわくする人や仕事に出会える可能性が拡がると本気で思っている- 自分も今2歳半になる子供がいるが、若い人たちが社会に出たときに絶望せずに
わくわくする社会をつくることが我々の責任だと思うので一緒にがんばりましょう！
- kyon_mm
心地よいチームには終わりはなくて、完成することはないんだと思う- 人によって生きる理由は違うが、それらが重なって1つの生命かのように、
超個体かのように振る舞うチームを目指しながら、そしてそれをやって
みたいとおもう人達がいたなら、みんなでそういうことに上手くなって
いけたらいいなっておもってこの講演をやってみた- みなさんの物語もいつか聞かせてください
いま、この2人じゃないと実現することができない場になってよかったです。
当日セッションに参加してくださった皆さん、このスライドを見ていただいた皆さん、そしてデブサミ運営の皆さん、本当にありがとうございました。
## 参考リンク
https://www.kikan47.org/
https://www.kikan47.org/post/47kikan-join-dtc
https://silver-bullet-club.github.io/
https://agile-monster.com/blog/team-fa-declaration/
https://agile-monster.com/blog/teamfa-done/
---
# チームで品質を考えるレビュー #JaSST
URL: https://agile-monster.com/blog/teamreview/
Published: 2021-01-22
---
JaSST'21 Hokurikuで講演してきました。
http://www.jasst.jp/symposium/jasst21hokuriku.html
資料はこちらです。
レビューをもっと自由に！
---
# ソフトウェア開発の現場も、地獄への道は善意で舗装されている
URL: https://agile-monster.com/blog/the-road-to-hell/
Published: 2020-11-11
---
ソフトウェア開発の現場においても、地獄への道は善意で舗装されているのかもしれないと思った話。
>
>
> 地獄への道は善意で舗装されている
>
>
>
> 「善意でなされた行為であったとしても、その実行により意図せざる結果が招かれるの」意
>
>
## エンジニアの手を煩わせたくない！
開発組織のマネージャーやプロジェクトマネージャーなどの方が、「エンジニアの手を煩わせたくない」というセリフを口にすることがあります。
その動機は、
- エンジニアには開発に集中してもらいたい
- そのためにも開発以外の仕事はなるべく自分たちで裁こう
といったものであり、エンジニアのためを思っての言動です。善意に満ち溢れていて、とても素晴らしいことだと思います。
ところが、その善意から来る行動が、
- 自らがビジネスとエンジニアの間に入って仕事をまわす
- 気が散らないようにエンジニアの見えないところでコミュニケーションをする
- 決まったことだけをエンジニアに伝える
というコミュニケーション設計になってしまうことがあります。
## コミュニケーションのスパゲティ化
開発チームはとビジネスの間にプロキシーとして入ることで交通整理をする、一見良さそうに見えます。でも実際の現場でこれがうまく機能することは極稀です。
なぜなら開発チームとビジネスが意思疎通をするために、2倍のコミュニケーションコストがかかるからです。さらに、どちらのコミュニケーションにおいても一次情報ではないことから伝達遅延が発生したり、コミュニケーションエラーによって新たな問題が発生する可能性があります。
もちろんプロキシとしての能力が優秀であれば機能することもありますが、誰もができることではありません。仮に機能したとしても、「プロキシ」という仕事をつくりだしてそこに大量の時間を投下していることになります。
一方で、上手だと思うマネージャーは上記のようなコミュニケーション設計をします。
間に自分が入るのではなく、一次情報同士がコミュニケーションする場をつくる。そうすることで、コミュニケーションがシンプルになります。ファシリテーションなどによってコミュニケーションを支援することもできるでしょう。
最初の言葉に戻ると、「エンジニアの手を煩わせる」ことになってしまうかもしれませんが、コミュニケーション設計がシンプルである方が仕事がうまくいく可能性がとても高いです。
## 地獄への道は善意で舗装されている
繰り返しになりますが、動機は善意からくるものなので悪気はありません。でも善意からくる行動が、必ずしもいい結果になるとは限りません。かえってチームを悪い結果＝地獄へと向かわせることになってしまうことがあります。善意からきているからこそたちが悪いのです。
こういったケースでは、「○○のため」という言葉が、「（自分が想像している）○○のため」になってしまっていることが多いです。これでは善意の押し売りになってしまいます。
今回紹介した例はあくまで一例ですが、「地獄への道は善意で舗装されている」ことになってしまうケースはソフトウェア開発の現場においてたくさん存在します。善意から行動に移すことができるエネルギーは素晴らしいです。でもそのエネルギーは、エンジニアのため、ユーザーのため、プロダクトのため、会社のためという大き過ぎる主語に向けるのではなく、目の前の誰かに向けられるとステキですね。
---
# It dependsから脱却するスクラム #scrumsapporo
URL: https://agile-monster.com/blog/it-depends-scrumsapporo/
Published: 2020-11-07
---
Scrum Fest Sapporo 2020で講演してきました。
https://www.scrumfestsapporo.org/
RSGT2020で挑戦しようと思っていたスクラムグランドスラムを無事に達成できました。
- Regional Scrum Gathering Tokyo 2020
- Scrum Fest Osaka
- Scrum Fest Mikawa
- Scrum Fest Sapporo
ほんとにありがとうございます。
今日の資料はこちらです。
スクラムのことをたくさん考えて、最近自分の中で気になっていることをモチベーションに話しました。It dependsのままでは情報量がまったく増えないので、実装の話をしたいですね。
業界の元気担当としては、聞いてくださった方が少しでも元気になってくれたのであればHappyです。
もしこの話を受けて（受けなくても）、相談したいとか話してみたいという方はぜひお声がけ下さい。みなさんとお話できることを楽しみにしています。
---
# 制御不能な時代のプロジェクトマネジメント #JBUG #JBUG広島
URL: https://agile-monster.com/blog/project-management-in-agile-era/
Published: 2020-10-11
---
JBUG広島で講演をしてきました。
https://jbug.connpass.com/event/189270/
今年の2月に広島で開催されたイベントでの講演をきっかけにお誘いいただいたんですが、そのときも今回も入場曲を流して入場させてもらっているので、やはり広島とは相性がいいみたいです。
資料はこちらです。
講演内容を考えている中で、これまでチームやプロダクト開発の話はたくさんしてきたけど、プロジェクトマネジメントをテーマに話したことがないことに気づきました。
今回はその「プロジェクトマネジメント」をテーマに、
- 大事にしていること
- 各フェーズで特に意識していること
- なぜそれをやっているのか
について話しました。詳細な手法については巷にあふれているので、頭の中身をアウトプットしてみました。
---
# 「わからない」と共存するチーム #RSGT2021
URL: https://agile-monster.com/blog/dont-know-team-rsgt2021/
Published: 2020-09-28
---
最近改めてアジャイル開発やスクラムが素晴らしいなーと感じるところは、わからないことだらけの中でどうやって前に進むのかを目指しているところです。個別のプラクティスやはやさに注目してしまいがちですが、ほんとに素晴らしいのはそこにあると実感しています。
この「わからないと共存する」という部分にフォーカスして、実際にチームが取り組んでいることや、チームの特性、新たに挑戦しはじめたことについてお話したいと思ってプロポーザルを出しました。来年も私たちのチームの取り組みについてお話できると嬉しいなと思っています。
投票期限が9月末までなので、応援してくださる方はリンク先からタイトル下のハートマークをぽちっとしていただけると嬉しいです。他にも魅力的なプロポーザルがたくさん出ているので、プロポーザルを眺めるだけでも得るものがあると思います。イベントに参加するか否かに関わらず投票いただけます。
https://confengine.com/regional-scrum-gathering-tokyo-2021/proposal/14944/team-controlling-chaos
## スクラムと向き合ってみた
10年近くスクラムの近くにいて、いろんな場でチームの取り組みを伝えてきました。これまでの講演をふりかえってみると、スクラムについて取り上げていることは減っていて、スクラムと少しずつ距離ができているのかなと思うようになりました。
そんな中で、9月25〜26日にScrum Fest Mikawa2020があり、基調講演をさせてもらいました。
https://agile-monster.com/blog/feel-scrum/
スクラムのイベントの基調講演なので、通常の講演と違うものにしようと考えて、あらためてスクラムを真正面から向き合ってみました（苦しかった）。
その中で気づいたアジャイル開発やスクラムが素晴らしいなーと改めて気づいたことが冒頭に書いた、「わからないことだらけの中でどうやって前に進むのかを目指しているところ」です。
## うまくいくチームとうまくいかないチーム
自分たちの取り組みについていろんな場でお話をしてきて、
「自分たちはスクラムがうまくいっていない」
「うちの会社ではスクラムをはじめるのは難しい」
というような相談を受けることが何度もありました。なぜ同じようなコンテキスト下で同じようにスクラムに取り組んでいるのに、うまくいくチームとうまくいかないチームに分かれてしまうのか疑問に感じていました。
本やスクラムガイドやスライドを見てはじめてもそれだけではうまくいかない。そんなときに「マインドセット」や「心理的安全性」のようなそれらしいふわっとした言葉を理由にして結論づけたくなりますが、これを言われたところでなにをしたらいいのかわかりません。このあたりに限界を感じていて、どうにかできないかなーとずっと考えていました。
その答えの一つが、うまくいっているように見えるチームは「わからない」と共存しているチームだと気づきました。うまくいっているように見えるチームだってわからないことがないわけではなく、常にたくさんの「わからない」の中でも「わからない」と共存できているだけです。だから結果として、活動を続けて、うまくいっているように見えるのではないかと思っています。
このことに気づいてから、自分たちのチームをふりかえってみると、自分たちのチームの特性や無意識にやっていた言動や習慣などたくさんの要素に「わからない」と共存するための仕掛けがあることに気づきました。さらにそこから自分たちの無意識や本能を強化するために新たにはじめたことや、意識的に取り組むようになったこともあります。RSGT2021ではここにフォーカスして実例を元にお話できるといいなと思っています。久しぶりにスクラムの話もできそうで楽しみです！
キーワードはこのあたり。
- 不確実性
- 「うまくいく／うまくいかない」と「わからない」
- 判断や問題解決の遅延
- 本能や無意識
- タイムボックスをなくしたい
- 言語化
少しでも興味をもっていただけたならぜひ投票をお願いします。
https://confengine.com/regional-scrum-gathering-tokyo-2021/proposal/14944/team-controlling-chaos
---
# Scrum Fest Mikawa2020にて基調講演をしました #scrummikawa
URL: https://agile-monster.com/blog/feel-scrum/
Published: 2020-09-26
---
Scrum Fest Mikawa 2020にて基調講演をしてきました。
https://www.scrumfestmikawa.org/
今回のイベントでは、一部の講演はオフライン（オンライン配信）で、参加者の皆さんはオンライン参加というハイブリッドで行われました。オンラインイベントに慣れてきて「オンラインも楽しいじゃん」と思っていましたが、久しぶりオフラインでイベントに参加して「オフラインも楽しいじゃん」って感じたので、結局イベントが楽しいんだなって気づきました。
基調講演の資料はこちらです。
基調「講」演は人生初でした。
自分のルーツ（故郷）である豊橋でスクラムのイベントが初開催、そこでなにを話すのか考え続けた2ヶ月でした。
いつもの講演は、自分たちがやっているチーム開発やプロダクト開発のことを全力でアウトプットするだけです。でも、自分が目指した基調講演は、
- ・イベントをかたちづくる
- ・他の素晴らしい講演を引き立てる
というものなので、いつもの講演とは完全に別物で苦しかったけど楽しかったです。たぶん一番成長できたのは自分なので、最高でした。
スクフェス大阪2020での永瀬さんの基調講演が印象的だったので、自分が「うっ」とくることはなんだろうと考えたらそれはスクラムと真正面から向き合うことでした。聞いてくださった皆さんになにか少しでも届いたのであれば幸いです。
場をつくってくれた運営の皆さん、参加してくださった皆さん、いつも一緒に成長してきたチーム、イベントに参加させてくれた家族、ありがとうございました。
今回の講演にも出てきたControlled-Chaosを実際にチームでどう実装していくのかという話は、来年開催予定のRegional Scrum Gathering Tokyo2020でお話したいなーと思ってプロポーザルを出しました。（WIP=1なので今回の基調講演が終わるまでまったく考えられなかった）
もしよかったらリンク先からVoteして応援してくださると嬉しいです。
https://confengine.com/regional-scrum-gathering-tokyo-2021/proposal/14944/team-controlling-chaos
またぜひ豊橋に遊びに来てください！
---
# オンラインモブプログラミングの動画を公開しました #銀の弾丸TV
URL: https://agile-monster.com/blog/online-mob-programming/
Published: 2020-06-07
---
オンラインモブプログラミングをしている様子を編集した動画を作りました。
簡単なお題で18分弱におさめていて、ところどころ字幕を入れています。モブプログラミングの進め方や雰囲気をつかんでもらうのにお手頃なサイズ感です。
モブプログラミングに興味がある人やチームに見ていただいたり、ワークショップや勉強会での紹介に使いやすいように編集しています。
以下の資料と合わせてご自由にお使い下さい。
---
# 『SCRUM BOOT CAMP THE BOOK 増補改訂版』出版記念イベントがすばらしかった
URL: https://agile-monster.com/blog/scrum-boot-camp-the-book-renewal-event/
Published: 2020-06-06
---
2020年6月4日に「【オンライン】『SCRUM BOOT CAMP THE BOOK 増補改訂版』出版記念イベント」が開催されました。
https://connpass.com/event/176779/
このイベントは、SCRUM BOOT CAMP THE BOOKが発刊されてから7年の月日を経て増補改訂版が出版されたことを記念したイベントです。増補改訂版の中のコラムを書かせていただいたことから、今回司会という大役を務めさせていただきました。
## SCRUM BOOT CAMP THE BOOK増補改訂版
増補改訂版は、7年の変化に合わせて 、
- 最新のスクラムガイドに準拠
- コラム寄稿者の刷新
などのアップデートがされています。増補改訂版の紹介についてはこちらの動画をご参照下さい。
https://www.youtube.com/watch?v=BiDvqiOY8vw
著者のブログエントリー。
https://miholovesq.hatenablog.com/entry/2020/05/20/233917
https://www.ryuzee.com/contents/blog/13265
※改定前の書籍もまだ売っているので、購入の際はご注意ください。
[itemlink post_id="2322"]
## 出版記念イベントがすばらしかった
SCRUM BOOT CAMP THE BOOKは7年経った今でも、スクラムをはじめる人におすすめした1冊です。漫画やイラストが多く、現場のシーンごとに細かく章立てされているので、とても読みやすいです。
今回の出版記念イベントはオンラインで開催されたため、参加者は全国から集まりました。
この本を読んでスクラムに取り組んできた人たち、まわりの人にこの本をおすすめしてきた人たちが出版記念イベントには集まりました。改訂版の出版イベントということもあり、もはやSCRUM BOOT CAMP THE BOOKファンイベントでした。
イベントは参加者からの質問をベースに進みました。エモーショナルなことから、書籍の裏話、リアルな現場の悩み相談まで多岐にわたる面白い場になりました。
後日翔泳社さんの方から動画配信されるそうなので、お楽しみに！
当日のイベントの様子はこちら。
https://togetter.com/li/1536197
https://twitter.com/TAKAKING22/status/1268590415940214785
これまで1冊の本とこんなに長く関わることはなかなか経験がなかったですが、SCRUM BOOT CAMP THE BOOKを通して著者や読者はもちろん出版社の皆さんまで書籍に関わる人の想いに触れることができました。
きっと今回の改訂によって、今後も未来の読者も含めてたくさんの人の人生に関わっていく一冊になるんだろうなと実感しています。この本に少しでも関わることができてよかったです。
それではまた次の改訂で（という前フリ）！
---
# オンライン顔出し問題について考えてみる
URL: https://agile-monster.com/blog/online-communication-from-home/
Published: 2020-05-26
---
新型コロナウイルスの影響でWorking From Homeをする人が多くなった。そして、オンライン会議などをする際に顔を出すべきか否かという話をよく耳にするようになった。
緊急事態宣言が全国的に解除されて、リモートワークを続けるのか元通りの会社生活に戻るのか、というこのタイミングでこの問題について考えてみる。
## オンラインコミュニケーションでは顔を出すべき？
オンラインコミュニケーションの場では顔を出すべきだ、といわれる主な理由はこんなところだ。
- 何しているのかわからない
- コミュニケーションが円滑でなくなってしまう
- オフラインでは顔を出している
- 仕事なんだから
個人的にオンラインで自分が話しているときに参加者の反応が見えずに不安になった経験があるので、顔を出してほしい気持ちは少しはわかる。一方で、これらは少し極端な意見に聞こえてしまう。
## 「オンラインはオフラインの代替」なのか？
こうした意見の根底には、「オンラインはオフラインの代替である」という考え方があるように思う。
言い換えると、「本当はオフラインコミュニケーションの方が効率的だけど、この事態になって仕方がないのでオンラインでやっている。だから事態が収束したら元に戻そう。」ということだ。
それでいいのであればいいのだけれど、ちょっとダサい。そこでもう一歩踏み込んで考えてみたい。
## オンラインコミュニケーションを考える
まずできることはなんだろうと考えて、「顔出しをしない」「聞き専で参加する」というコミュニケーションスタイルを受け入れることにしてみた。
気軽に実験できる場、ということで製造業アジャイル勉強会というコミュニティでオンラインイベントを開催してみた。そのときの詳細はブログに書いた。
https://agile-monster.com/blog/online-ost/
ここではオンラインコミュニケーションを中心に考えて設計をした。
- 顔出ししなくてOK
- 聞き専で参加してもよい
ということを大々的に伝えた上で、開催してみたところ想像以上によかった。
参加者の方からのフィードバックでは、「子供も家にいるのでありがたい」「家の中で仕事をできる場所が限られていて整理的できていないので助かる」などいろんな意見があった。
運営側としても「顔出し」を気にしながら運営するくらいなら、最初から受け入れることで気にしなくてよくなるし、かえって新しい発見もあるのでいいこと尽くしだった。
例えば新たな発見としては、オンラインコミュニケーションでは会話とテキストチャットのメッシュコミュニケーションをしやすいので、かえってコミュニケーションが活発になっているように感じた。会話だけの場合は話している人だけが発信することになりそれ以外の人は聞いているだけになる。そこにテキストチャットが加わることで、全員がタイミングを計らずとも常に発信することができる。
## 「オンラインはオフラインの代替」からの脱却
「オンラインはオフラインの代替」という考えにとらわれていると、新しい価値を発見するチャンスを逸してしまうかもしれない（そしてダサい）。
そもそも顔出しするだけで、
- 何しているかわかる
- コミュニケーションが円滑になる
- 仕事していることになる
になるわけではない。
もちろんオンラインでは一切顔出しする必要がないということが言いたいわけではない。顔を出した方がよい結果を生むこともあると思う。ただし、それをルールで縛るのではなく、
- 顔出ししてほしい理由を参加者に伝えて理解してもらう
- その上で個々の事情に合わせて参加スタイルを選んでもらう
- 選択の自由があることをその場にいる全員が受け入れる
という状態に持っていくのが理想である。
## 家にお邪魔しているのは仕事の方だ
屁理屈かもしれないけれど、Working From Homeなので家にお邪魔しているのは仕事の方である。であれば、もう少し家にやさしいコミュニケーション設計を考えてみてもよいのではないだろうか。
---
# リモートワークにおけるモブプログラミングのコツ
URL: https://agile-monster.com/blog/remote-mobprogramming/
Published: 2020-05-14
---
コロナウイルスの影響によって、オフラインで集まって働いていたチームの多くが強制的にリモートワークに切り替えることになりました。オフラインでのコミュニケーションを前提にしていたチームは、リモートワークによって情報が制限されたように感じ、それまで以上にチームでのコミュニケーションの難易度が上がります。
そんな状況において、リモートモブプログラミングへの注目が高まっています。チーム全員でオンライン通話をつないだまま、画面共有をしながら仕事を進めることで、少しでもコミュニケーションコストを下げようというモチベーションでしょう。
そこで、5/12に「リモート時代のモブプログラミング」というイベントを開催しました。参加者・登壇者の皆さん、ありがとうございました。
https://moblove.connpass.com/event/173894/
## リモートモブプログラミング ー STAY HOME with TEAM ー
私たちのチームでは約3年モブプログラミングを続けており、リモートモブプログラミングに切り替えた後も手応えを感じています。イベントの中でリモートモブプログラミングのコツについて共有をしました。
### 資料
当日の資料です。
### 私たちのリモートモブプログラミング
私たちのチームでは、常にオンライン接続して画面共有をしながら、リモートモブプログラミングをしています。隣りの席にいたメンバーがネットワーク越しになっただけで、同じ画面を見て会話しながらコードを書いているのでほとんど変化を感じませんでした。
私たちのチームでは、
- Zoom（オンライン通話、画面共有）
- Slack（テキストチャット）
- Visual Studio Code Liveshare（開発環境）
- AWS Workspaces（仮想モブプロ専用マシン、Liveshareのホスト）
という構成でリモートモブプログラミングしています。
### リモートモブプログラミングのコツ
リモートモブプログラミングにおけるコツを10個に厳選して紹介しました。資料の中では1つずつ詳細に触れています。
## チームはリモートモブプログラミングから何を学ぶのか
本当に終わることがあるのかはわかりませんが、アフターコロナの話を耳にするようになりました。いずれにしても、もし出社できる状況になったとして、どのような働くのかチームや組織で話し始めています。
今の環境で学んだことを一過性のものにするのはもったいないです。リモート or オフラインのような極端な選択ではなく、よいところを組み合わせて仕事や状況に合わせて選択できるのがよいのかなと思っています。わくわくしかしないですね。
## 「モブプログラミング」「モブワーク」お悩み相談
イベントの後半で、チームメンバーと共に銀の弾丸ラジオのオンライン収録をしました。近日公開予定ですので、ぜひそちらもお楽しみに！
https://anchor.fm/silver-bullet-club
---
# オンラインOSTやってみた #製造業アジャイル
URL: https://agile-monster.com/blog/online-ost/
Published: 2020-04-24
---
コロナウイルスの影響によって、リモートワークなどオンライン活動への対応が必要になりました。エンジニア界隈の勉強会も同様で、これまで平日の業務時間後や休日に開催していたオフラインイベントもオンライン開催にシフトされてきています。
4/23に開催した製造業アジャイル勉強会もオンラインで開催しました。
https://beyond-hardware-agile.connpass.com/event/173359/
当日の雰囲気も交えつつ、オンラインイベントのノウハウをご紹介します。
## オンラインならではの場の設計
他のオンラインイベントを参考にしたり、友人たちと意見交換をして今回は以下のようなコンテンツ構成にしました。
- オープニング
- ライトニングトーク大会
- Online Open Space Technology
製造業アジャイル勉強会は、講義形式やプレゼンスタイルなどのように発信側と受信側が分かれる形式だけでなく、全員が発信も受信もする入り乱れた場を大切にしているので、OSTを取り入れています。
https://agile-monster.com/blog/ost-introduction/
オンラインでも大事にしたいことは同じなので、OSTをどうやってオンラインで実装するかというのが今回の挑戦でした。
## 今回使ったツール
今回のイベントで使用したツールについてご紹介します。
### Discord
https://discordapp.com/
Discordはテキスト／音声チャットで、Slack＋ボイスチャンネルをイメージしてもらうとわかりやすいです。基本的に無料で利用することができます。
今回のイベントでは、イベント会場としてDiscordをベースに進めました。
オープニングやライトニングトークなど、全体に向けて発信したいときは同じボイスチャンネルに集まってもらい、Go Live機能（画面共有）を使って進行しました。そして、OSTではセッションごとに各チャンネルに散らばって並行してセッションを進行してもらいました。
Discordのよいところは、
- 音声とテキストのメッシュコミュニケーションが生まれる
- 人気（ひとけ）＝誰がどこにいるのかが視覚的にわかることと
- チャンネル間の移動がスムーズなので気軽にふらふらできる
- テキストを覗けば他のルームの話題がなんとなくわかる
です。
機能的な特徴・注意点としては、
- ブラウザでも利用できるが、各アプリをインストールした方が使い勝手が良い
- Go Live機能（画面共有）は50人までの人数制限があるので、それを超える場合は他の配信手段を用意する必要がある
- ボイスチャンネルに人数制限はない
- 音声の処理がスムーズなのでディスカッションに向いている
です（2020年4月現在）
また、イベントのときにだけ使うワンショットツールと違い、サーバー＝場が残るので、イベント前後のコミュニケーションの場になるのも面白いですね。
その他に注意点として、情報の取り扱いなどはプライバシーポリシーをご一読下さい。「当社が収集する情報」などを読んでいただくとわかると思いますが、ビジネスユーズなどの場合は特に注意が必要だと思います。今回はコミュニティイベントであることと、オープニングなどで扱う情報についてメッセージを入れておけばよいと判断しました。
https://discordapp.com/privacy
### Google Jamboard
Jamboardは、オンラインホワイトボードツールです。個人アカウントでも企業アカウントでもよいのでGoogleアカウントを持ってさえいれば作ることができます。
※Jamboardはその後、提供終了となっています（この記事は2020年4月時点の内容です）。
今回のイベントでは、OSTのマーケットプレイスのときに使いました。
複数人で同時にリアルタイム操作ができるので、Discordの音声チャンネルで話しながら、Jamboardを使って進行しました。
話す場所をDiscordのチャンネルとリンクさせておくことで、どの時間にどのチャンネルでセッションが行われるのかがわかります。
今回は同時に使用するツールをなるべく絞ろうと思ったので、OSTセッション中のコミュニケーションは基本的にDiscordの音声＋テキストで行うようにしましたが、Jamboardを使って議論するのもおすすめです。
イベント中のハプニングとして、40名ちょっと越えたタイミングで人数の制限がかかってしまいました。規約とかをさっと見た感じ、人数制限に関する具体的な記述を見つけられなかったのですが、注意が必要です。今回はJamboard自体を画面共有しておくことで、編集する人と閲覧だけしたい人を分散させることでどうにか進行しました。
### Mentimeter
https://mentimeter.com/
Mentimeterはオンラインプレゼンテーションツールです。無料でも利用できますが、機能制限があるので、必要であればライセンス購入する必要があります。
今回のイベントでは、オープニングで使用しました。
Mentimeterは通常のスライドに加えて、アンケートや質疑応答をする機能があるので、インタラクティブなコミュニケーションをすることができます。参加者の入力情報がリアルタイムに画面反映されるので、「おお！」となります。
特にオンラインイベントのように参加者の反応がわからない状況では、どうやって情報を受け取るかが悩ましいです。その際の選択肢として知っておくとよいでしょう。
## やってみてどうだったか
実際にイベントをやってみた感想です。
### オンラインならではの参加しやすさ
- 物理的距離に関係なく全国から参加できる
- 移動がないので遅めの時間開始という選択肢が生まれる
- 家事等を終わらせてからイベントに参加できる
- 家事や仕事をしながらの「ながら」参加ができる
などオンラインならではの参加しやすさが生まれました。
### オンラインならではのコミュニケーション
オンラインでのディスカッションやワークでは、音声とテキストでメッシュコミュニケーションをすることができます。
相手が話し終わるのを待たなくてもテキストでコミュニケーションできますし、話している人がテキストを見ながら話すラジオのような空間が生まれたりしました。音声を出すことはハードルが高くても、テキストのみで参加したり、聞き専で参加することもできるので、それぞれの参加スタイルに合わせて多様なコミュニケーションが生まれておもしろかったです。
## オフラインの代替ではなく今だからこそできることを
製造業アジャイル勉強会としてははじめてのオンライン開催だったので、改善点はいろいろありますが、参加者や発表者の皆さんのおかげとてもいい場になりました。継続開催をしていく予定なので、ご興味がある方はよかったらご参加下さい。
https://beyond-hardware-agile.connpass.com/
オフラインでやっていたことをオンラインで代替するという発想はダサいので、そうではなくむしろせっかくオンラインで開催するのだからオンラインだからこそできることをやろうと考えるとわくわくしかしません。
どんな状況でも変化を受け入れて楽しんでいきたいですね。
---
# チームのPodcastとYoutubeチャンネルをはじめました #銀の弾丸TV #銀の弾丸ラジオ #SILVERBULLETCLUB
URL: https://agile-monster.com/blog/silver-bullet-club-start/
Published: 2020-02-12
---
ついにチームのPodcastとYoutubeチャンネルをはじめました。ぜひチャンネル登録などなどよろしくおねがいします。
※PodcastはGoogle PodcastやiTunesから聞けるようになるまでは少し時間がかかるので、もしまだ出てこないようでしたら数日お待ちいただいた後にご登録お願いします。
https://www.youtube.com/channel/UC2WNGm9_cF2xUlBLXAaJOOQ
https://anchor.fm/silver-bullet-club
また、それに伴い各種SNSアカウントもつくりました。こちらから今後の活動や最新情報をお届けしていく予定ですので、合わせてチェックお願いします。
- [Twitter](https://twitter.com/SilverBulletClb)
- [Facebookページ](https://www.facebook.com/SilverBulletClubdeJapan/)
質問、やってほしいことなどありましたら上記からお気軽にご連絡ください！もちろん各個人に直接ご連絡いただいてもかまいません。
## SILVER BULLET CLUB
SILVER BULLET CLUBというのはユニット…チーム名です。ソフトウェア業界でよく使われる比喩として「銀の弾丸はない」というものがありますが、「自分たちチームが銀の弾丸になろう」という想いを込めてこのユニット…チーム名をつけました。
チーム名大事です！
## なぜやるのか
これらの活動は、チームの活動や経験知を発信していくことでチームのファンを増やすためにはじめてみます。
[](https://speakerdeck.com/takaking22/for-engineer-life?slide=63)[エンジニアであり続けるために ーアジャイル時代の「個」と「チーム」ー](https://speakerdeck.com/takaking22/for-engineer-life) より
チームにとっていろんなイベントがあった2019年のふりかえりを実施した時に、今年のアクションとしてこれらを掲げていました。
個人や企業で運営しているメディアはあれど、実際に現場で働いているチームで配信しているものは見かけたことがありません（知っている限り）。チームだからこそできるような番組にしていきたいと考えているのでお楽しみに！
## どんなことをやっていくのか
とりあえずミニマムスタートではじめたので、これから企画をしていきます。
- チームのふりかえり動画（定期）
- モブプログラミング動画
などはあったらおもしろいだろうなーと思うので、やっていき。その他いいアイデアがあればぜひ教えて下さい。
2020年もSILVER BULLET CLUBの活躍をお楽しみに！！
---
# #RSGT2020 で「Team-Based TEAM - 会社を越えるチーム -」を話してきました
URL: https://agile-monster.com/blog/team-based-team/
Published: 2020-01-12
---
Regional Scrum Gathering Tokyo 2020で公演をしました。
https://2020.scrumgatheringtokyo.org/
https://confengine.com/regional-scrum-gathering-tokyo-2020/proposal/11846/team-based-team-
## Team-Based TEAM - 会社を越えるチーム -
「みなさんのチームはいつ死にますか？」
なかなか考えたことがない問いです。私もそうでした。私たちのチームが解散になるかもしれないという経験を通して、この問いについて真剣に考えるようになりました。
アジャイル開発やスクラムの文脈では、STABLE TEAM（安定したチーム）をつくることが成功のための第一歩とされています。
私たちのチームはチーム解散に向き合い、チームFA宣言をし、結果としてチーム転職という選択をしました。
https://agile-monster.com/blog/teamfa-done/
それらの経験を通して、私たちはProject-Based TeamでもProduct-Based TEAMでもなく、Team-Based TEAMであったことに気づきました。
今回の公演では、私たちのチームが現在進行形でどのような考えのもとでどのように活動しているかについてありのままを伝えました。もしかしたら自分たちからは少し遠いチームに感じてしまった方もいるかもしれませんが、「こういうチームがあるんだ」と知っていただくことでいままでと違う視点でチームをとらえるきっかけになればいいな、と思ってお話しました。
## 資料
当日の資料です。
そして煽りVです。
https://youtu.be/9Z0UzwUi7pE
## 参考図書
[itemlink post_id="2366"]
[itemlink post_id="2314"]
https://leanpub.com/dynamicreteaming
## 今回の想い
今回はいままでと少し違うスタイルでプレゼンテーションをつくりました。
今回の公演は「thoughts：新しい提案」というセッションカテゴリです。「やってみた」「こんな工夫をした」「苦労を乗り越えた」という事例セッションは、聞いている人に勇気を与えて明日からの現場で活かせるヒントを得られるため尊いです。これまでは自分もそこを意識してお話することが多かったです。
ところが、私たちのチームは数年活動をしてきて、どんどん進化・深化をしています。「やってみた」あとにもチームの活動は続いていくわけなので、先に進んでいくチームがどのようにもがいているのかを伝える必要があるのではと考えるようになりました。なによりチームのすばらしさを全力で伝えたいという想いもありました。
伝えたいことが変わると、伝え方も変わります。「親近感」による共感を得にくい分、問いやストーリーの力を使って聞いている人を惹き込む必要があります。こういう考え方ができるようになったのも、Scrum Fest Osaka2019で @kyon_mm と基調公演をつくりあげる経験をしたからです。
Regional Scrum Gathering Tokyo 2020にはたくさんの友人がスピーカーとして登壇していたため、登壇前後の彼らとたくさん話す機会がありました。みんな悩んで、不安を抱え、話し始める直前まで全力でプレゼンテーションと向き合っていました。もしかしたら登壇している彼らしか知らない方からするとスーパーマンのように感じるかも知れませんが、みんなただの素晴らしい人間でした。
自分も彼らと肩を並べられるように、一生懸命プレゼンテーションに向き合ったつもりです。
## Silver Bullet Club
2020年は本業はもちろん、個人事業主としても、チームとしても活動を広げていきます。ぜひ楽しみにしていてください！
---
# 家族はあなたと私ではなく、私たちでできている
URL: https://agile-monster.com/blog/we-are-kazoku/
Published: 2019-12-25
---
これは自戒である。
この記事は子育てエンジニアAdvent Calendar 25日目の記事です。今年も子育てエンジニアAdvent Calendarにたくさんの方が参加してくれました。ステキな記事が集まっているのでぜひご一読ください。参加してくださった皆さん、ありがとうございました。
https://adventar.org/calendars/4199
2018年の子育てエンジニアAdvent Calendarではこんな記事を書いた。
https://agile-monster.com/blog/my-paternity-leave/
この記事のあと育児休暇を終えて職場に復帰し、妻は現時点では引き続き育児休暇中である。子供が生まれると生活が変わると聞いていたが、まさしくその通りだなと実感している。
## 子供が生まれる前
これは子供が生まれる前の頭の中のイメージ図だ。
私たちは共働き夫婦なので、
- それぞれの円：それぞれの生活（仕事や人間関係）
- 重なる部分：2人で共有する時間や価値
のように考えていた。もちろんそれぞれに家族や友人などのステークホルダーは存在するものの、基本的には「あなたと私」という構図である。いろいろな夫婦の形があると思うが、共有する部分の違いがあるだけで大枠は変わらない。
例えば、仕事の急用が入ってきたとしてもパートナーとコミュニケーションをして折り合いがつけばそれでよかった。
## 子供が生まれた後
子供が生まれると、もう1つの円があらわれる。
先程の「あなたと私」という構図に子供が加わる。子供は生まれたばかりの人間なので、優先的にサポートする必要があるし、喜んでそれをしたい。「あなたと私」だけでなく、子供も含めた関係性の中でものごとを考える必要が出てくる。簡単な話、優先順位のつけ方が変わるのである。
例えば、先ほどと同じく仕事の急用が入ってきた場合でも、パートナーと折り合いをつけるだけでなく、子供のことを考えて判断しなくてはならない。
## プロダクトチーム
ここでプロダクトチームの話に逸れてみる。
チームというのは1人が増減しただけで、以前とは全く違うチームになる。なぜならば、それまでと大半のメンバーが同じだとしても1人が増減するだけでコミュニケーションのとり方や関係性が変わってしまうからだ。
そんなナマモノであるチームづくりについて、自分の理想とするチームやそのために取り組んできたことについていろんな場で話してきた。
[心理的安全性について本気出して考えてみたら普段やってるチーミングの話だった](https://speakerdeck.com/takaking22/xin-li-de-an-quan-xing-nituiteben-qi-chu-sitekao-etemitarapu-duan-yatuterutimingufalsehua-datuta-number-devlove) より
[心理的安全性について本気出して考えてみたら普段やってるチーミングの話だった](https://speakerdeck.com/takaking22/xin-li-de-an-quan-xing-nituiteben-qi-chu-sitekao-etemitarapu-duan-yatuterutimingufalsehua-datuta-number-devlove) より
[アジャイルで目指した坂の上の雲](https://speakerdeck.com/takaking22/clouds-above-the-hill) より
これらをチームを家族に置き換えて考えてみると、家族は1人増えると関係性が変わるし、
- 家族 vs 問題の構図
- 心理的に安全な家族
- 個を成長させる家族、家族を成長させる家族
こんな家族を目指したいなって思う。
## 理想とするチーム
少し前に野中先生と平鍋さんの記事を読んだ。
https://dcross.impress.co.jp/docs/talk/001157.html
この中で触れられている「共感」の話がとてもおもしろかった。
>
>
> そこで重要になるのが「エンパシー（共感）」であり、それを共有する場としてのチームです。エンパシーとは、ストレートな感情移入のことですが、その基本単位は“ペア”、すなわち、「私とあなた」の2人です。異なる存在であり、それぞれの主観をもつ「私とあなた」が真摯に向き合って妥協なき対話をして「われわれの主観」をつくりあげる2人称の関係なしに、新たな知識は生まれてきません。
>
> [スクラムは知識創造プロセスそのもの、すべては“エンパシー（共感）”から始まる](https://dcross.impress.co.jp/docs/talk/001157-2.html) より
これを読んだときに、自分は「生物的組織」のことを思い浮かべた。
自分は理想のチームについて聞かれたときに、「生物的組織」という言葉を使う。これは元サッカー日本代表監督の岡田武史さんの言葉だ。
人間の細胞は、古い細胞が死に、新しい細胞が生まれ、日々入れ替わっている。にもかかわらず、「その人」は「その人」としての形を保っている。そのときに脳みそはいちいちすべての細胞に細かく命令を出しているわけではなく、自然と近くの細胞と折り合いをなして形をつくっている。
これをチームとして見るとものすごく自己組織的なチームだと思うし、自分のチームもそういうチームでありたいと思い、この言葉を使わせていただいている。
[itemlink post_id="2314"]
ちなみに、とある友人は理想のチームを語るときに「超個体」という言葉を使っているが考えていることはだいたい同じだと思う。
すべてに共通しているのは、「あなたと私」から「私たち」を目指しているという点だ。もちろんこれは没個性という意味ではなく、チームとしてのあり方の話である。
## 家族はあなたと私ではなく、私たちでできている
再び家族の話に戻る。
育児休暇から明けて、妻と子供と3人で家族の暮らしを楽しんでいる。自分の中では2人はペアであり3人がチームの最小構成なので、家族というチームができて1年半が経過した。
しかし、時に妻と「あなたと私」になってぶつかってしまう時がある。ペアのときはそれでよかったのかもしれないが、これからは「私たち」を目指して家族ビルディングをしていきたい。まずは「あなた」「私」ではなく、「私たち」という言葉を意図的に使うことからはじめようと思う。
**家族というチームは「あなたと私」ではなく、「私たち」でできているのだ。**
---
# インセプションデッキを現場でどう活用しているか
URL: https://agile-monster.com/blog/how-to-use-inceptiondeck/
Published: 2019-12-08
---
この記事は、インセプションデッキAdvent Calendar 9日目の記事です。
[XP祭り2019](https://xpjug.com/xp2019/) に参加した際に、角谷さんとこんなやりとりをしました（遅くなってすみません）
https://twitter.com/kakutani/status/1175398049188700160
https://twitter.com/TAKAKING22/status/1177126441844015104
体感としてインセプションデッキをやっている現場はそこそこ多いにも関わらず、検索結果にはあまり事例が出てきません。いろんな人のインセプションデッキに対する考え方や、各現場での使い方やコツが集まったら面白いなーという動機からAdvent Calendarを立ててみました。
## インセプションデッキとは
インセプションデッキを説明するのに良い資料があったので貼っておきます。ご自由にお使いください。
## インセプションデッキの好きなところ
インセプションデッキをつくることで「チームの共通の言葉」ができるところが好きです。むしろ自分はそのためだけにやっているようなものです。
チームにはエンジニアだけではなく、デザインやテストやビジネスなど様々なバックグラウンドを持った人がいます。インセプションデッキをつくるという共通体験を通して、バラバラだった人たちに共通の言葉ができます。
これまでいろんな現場でインセプションデッキをつくってきましたが、そのあと仕事を進めているとこんな言葉が飛び交うようになりました。
- 「これってインセプションデッキで話してたあれだよね？」
- 「あれ？いまの状況って夜も眠れない問題に出てなかった？」
- 「これはやらないことリストにあったやつだから今は考えないようにしましょう」
- 「スコープよりもスケジュールの方が優先順位が高いのでこれは削っていいです」
バラバラな人たちに共通の言葉ができることで、チームに一体感が生まれ、コミュニケーションが円滑になります。最高のチームビルディングです。
## インセプションデッキをつくる際に気をつけているポイント
### 成果物よりもつくる過程を
禅問答みたいになってしまいますが、インセプションデッキをつくるとどうしてもデッキを作り上げることを目指してしまいがちです。もちろん成果物であるデッキも大切ですが、それ以上にチームに共通の言葉ができることに価値があると思っています。
だから、
- 「全員」集まる時間につくる
一部のメンバーだけでつくって全員に共有するとかはしない- ※先に埋めておいてもよさそうなスライドはあるので時間短縮でやることはある
- 無理に全部つくろうとしない
議論の時間を大切にする- 時間の中で優先順位をつけてスコープを調整する
ということを意識して場を設計しています。インセプションデッキづくり自体のトレードオフスライダーを書いてみるとよさそうです。
### 言える化
インセプションデッキづくりをファシリテートする際は、
- 個人ワーク（まず自分で書いてみる）
- 共有（お互いに書いたものを見せ合う）
- 議論しながらチームで合意形成する（チームのデッキにする）
という流れを意識して進めていきます。特に 1 と 2 をさぼらないことが大切で、自分の頭で考えて自分の言葉で話す、という機会を強制的につくることで全員に発言する機会をつくります。全員が自分ごととして考えて発言できるチームをつくることを自分は「言える化」と呼んでいるのですが、これはその第一歩です。
### ズレを見つける
プロダクトオーナーだからといってよいエレベーターピッチを書けるわけではありません。仮に書けたとしても、同じようなピッチをチームメンバー全員が書けないのであれば、チームの共通認識にできていないのであまり意味がありません。
いままでいろんなチームでインセプションデッキづくりの場を経験してきましたが、全員一致したエレベーターピッチを書けるチームは1つもありませんでした。でも、それでいいのです。ズレていることがわかることが重要です。
だから、インセプションデッキづくりは「誰かが正解を知っている」「正解を見つける」という意識ではなく、「ズレている部分を見つける」「正解かどうかはわからないけれどいまの自分たちの言葉にまとめる」くらいの意識の方がよいです。
前述の必ず個人ワークを挟む進め方は、このズレを見つけるということも意識しています。ズレていることがわかれば、あとはそれをどうするか考えるだけになります。だからズレてることがわかることはよいことなので、チームで喜びましょう。
## チームインセプションデッキの紹介
オリジナルのインセプションデッキは、「プロジェクト＝ある一定期間の仕事」の初期につくられることを想定して構成されています。コンテキストが合っていればそれでいいですが、例えばプロダクトを長く面倒見ているチームなど「プロジェクト」という単位がマッチしないチームにとっては以下のスライドは必要ありません。
- 初回のリリースに必要なもの
- 期間を見極める
自分も1つのチーム・プロダクトを長く開発・運用していることが多いため、オリジナルのインセプションデッキをそのまま使うことはなくて、状況に合わせてカスタマイズしています。
とはいえ、どうカスタマイズすればよいのか困る場合もあると思うので、自分がよくつくる「チームインセプションデッキ」の構成例を公開します。
★がついているスライドは、全員がいる場で話し合って決めることに大切にしているスライドです。それ以外のスライドは必要に応じて、予め用意しておいて全員で合意するなど、効率よく時間を使えるようにしています。
### チーム名・チームロゴ
名前大事！ロゴ大事！
### 我々はなぜここにいるのか ★
そのままやります。チームとしてのWHYを明確にします。
### チームエレベーターピッチ ★
エレベーターピッチのチーム版です。エレベーターに乗っている間に投資家にチームを売り込むつもりでつくります。自分たちのチームがどういうチームなのか認識を合わせて明文化しておくことは大切です。特に「目標・ライバルとなるチーム」について議論するのは面白いです。
### プロジェクトコミュニティ
そのままやります。
### 俺たちのAチーム
そのままやります。
### 技術的な解決策の概要
そのままやります。
### やらないことリスト・あとで決めることリスト ★
そのままやります。
### 夜も眠れなくなるような問題 ★
そのままやります。
### トレードオフスライダー ★
この前つくったときに、「上記以外で重要なこと」に
- プロセス（HOW）
- プロジェクト（WHY）
- プロダクト（WHAT）
を並べたらとても深い議論になりました。ここでいう「プロジェクト（WHY）」は会社や組織として求められているWHYのことです。チームがいまどういう優先順位のもとで意思決定をしているのかすり合わせることが大切だと感じました。
### OKR ★
インセプションデッキをつくる流れOKRを考えるのが自然な流れだと思って入れました。ここまで話し合ってきた内容をもとにOKRを設定します。
### 個人としての目標 ★
チームに属していても、いるからこそ個人としての目標を大切にしたいのでよく入れます。各自が目標を書いた付箋を、常に見えるところに貼っておいて、ことあるごとに進ちょくを確認します。
## まとめ
繰り返しになりますが、インセプションデッキは成果物よりもつくる過程にこそ価値があります。ですので、同じインセプションデッキという言葉を使っていてもチームによって、進め方によって、得られるものが全く違うものになるでしょう。
タフクエスチョンとタフディスカッションを通して、チームの背骨をつくることができれば、チーミングの基礎になります。
---
# モブプログラミングを導入するときに考えていること
URL: https://agile-monster.com/blog/mobprogramming-advent/
Published: 2019-12-01
---
この記事は、モブプログラミングAdvent Calendar 2019 の1日目の記事です。
https://qiita.com/advent-calendar/2019/mobprogramming
モブプログラミングに関するAdevent Calendarを、[昨年](https://qiita.com/advent-calendar/2018/mobprogramming)に引き続き今年も立ててみました。まだ空いている日があるのでぜひ飛び込んでみてください。アウトプットの年末調整です。
## なぜモブプログラミングの導入についてなのか
今年もモブプログラミングについての講演、ワークショップ、現場相談会などをさせていただく機会がたくさんありました。そうした際に、
- 「どうやってモブプログラミングを導入すればよいですか？」
- 「モブプログラミングのファシリテートについて教えてほしい。」
など導入する側としてのアドバイスを求められることがありました。
モブプログラミング自体はかなり広まってきているものの、いざ自分の現場でやってみようと考えると、自分以外はモブプログラミングを知らない／やったことがないメンバーばかりなのでどうやって導入すればよいのかわからない、という状況が多いようです。
自分のチームでは導入してから（チーム転職も挟んで）2年半くらいモブプログラミングを続けています。それらの経験知を活かして、全員初対面のチームや普段一緒に働いているがモブプロは初体験のチームに対して導入ワークショップを何度もやらせていただきました。
というわけで、今回は **自分自身がモブプログラミングを導入するときに考えていること** をまとめてみます。
## 想定する読者
- モブプログラミングをやったことがある／やったことはないがある程度知っている
- モブプログラミングがなんとなくよさそうなことはわかっている
- 実際に勉強会や現場でモブプログラミングをやってみようと考えている
## モブプログラミングを導入するときに考えていること
自分がモブプログラミングを導入するときに考えていることは、主に、
- ファシリテートしない
- カオスを受け入れる
の2つです。それぞれ項目ごとに見ていきます。
### ファシリテートしない
あくまで自分の考えですが、モブプログラミングを導入する際に外部からファシリテートをする必要はないと思います。むしろしない方がいいです。少なくとも自分がやるときはファシリテートしないようにしています。
現場でチームで働いているときに、常に近くに外部のファシリテーターがいることはありません。困ったときに正しいやり方を教えてくれる先生もいません。仮にいたとしても、その人がいないとうまく仕事ができない状態はチームとして不健全でしょう。だからモブプログラミングを導入するときも同じです。
モブプログラミングは、チームで考えて、チームで行動して、チームで学んで、チームで仕事をするアプローチです。むしろ、その「困ったときにどうするか」こそがモブプログラミングです。その学びの機会を奪うようなことはしたくありません。
もちろん、モブプログラミングに参加する場合は一人のメンバーとしてチームに貢献します。メンバーという立場で、チームの仕事を進めるファシリテートは必要です。必要ないのは、あくまでモブプログラミング自体のファシリテートのことです。
もし、モブプログラミングの外からワークショップを運営している場合は、モブプログラミングの最中は基本的には外部から口を出さないようにしています。何かを聞かれる場合がありますが、ほとんどの質問に対して「チームで考えてみてください」「仕事をしているときと同じですよ」と答えることが多いです。
モブプログラミング自体のやり方について学びを深めたい場合は、モブプログラミングが終わった後にふりかえりなどを行います。そのときであれば、見ているときに気づいたモブプログラミングの進め方についてのアドバイスを行ってもよいでしょう。大切なことは、モブプログラミングの特徴を理解した上でそれを学ぶことができる場を用意することです。
### カオスを受け入れる
導入する立場だと、どうしても「うまくいかせたい」という想いが強くなってしまいがちです。ましてや先に成功体験をもっていたり、本などを読んでよい事例を知っている場合はなおさらです。
しかし、「うまくいかせたい」のは何なのかを考えてみましょう。ほとんどの場合、うまくいかせたいのはその場一回きりのモブプログラミングではなく、チームにモブプログラミングを活かせるかどうかを知ることでしょう。
モブプログラミングをしているときに、
- 全然コードにたどりつかない
- 議論が紛糾して手が止まる
- 声が大きい人がずっと話している
- 特定の人がずっと教えている
などいろんなカオスに出会うことがあります。ですが、モブプログラミングは仕事をしているだけなので当たり前のことです。カオスを受け入れましょう。
そもそもモブプログラミングをしているときに発生する問題のほとんどは、モブプログラミング＝進め方とは関係ないことばかりです。たいていはそのチームが現在抱えている問題が顕在化しただけです。モブプログラミングによってコミュニケーション密度が濃くなるので、問題が顕在化しやすくなりますし、ときには潜在的に眠っていた問題が見つかることもあるでしょう。問題が見つかったのであれば、それをどう対処するかを考えるだけなので焦る必要はありません。
ここで考えるべきなのは、問題が見つかったタイミング、見つかり方、そのときのチームの対応の仕方をどう捉えるかです。「いつもより早く見つかったね」「見つかってよかったね」と前向きに問題解決に向かえるチームであれば、モブプログラミングをうまくチームに取り入れることでよりよいチームになれるかもしれません。一方でもし問題を受け入れられないチームであれば、モブプログラミングをすることでかえって関係が悪化してしまうかもしれません。
うまくいかない状況に陥ると、人は安易に手段に原因を紐付けがちです。導入する側は冷静に、「それは本当にモブプログラミングの問題なのか？」「問題が見つかったことは悪いことなのか？」などの質問をチームに投げ入れてあげるとよいでしょう。
## モブプログラミング導入に関するQ&A
最後によく聞かれることをQ&A形式でいくつか補足しておきます。この記事を読んで載っていない質問がある場合は、 SNSなどでぜひお気軽にご連絡ください。
### いつ、どれくらいやるのがよいのか（初回）
できれば半日〜1日くらいやれるとよいです。参考までに自分が実施するワークショップ（半日Ver.）のアジェンダを置いておきます。
- イントロダクション、準備（30min）
- モブプログラミング 1（60min）
- 中間ふりかえり（15min）
- モブプログラミング 2（60min）
- 成果共有＆ふりかえり（30min）
- 講義：現場でのモブプログラミング、質疑応答（30min）
半日以上時間をとれると、中間ふりかえりをはさむことで自分たちのやり方を改善する機会をつくることができます。メンバーをシャッフルしてみることも出来ます。学びが多い実験ができるでしょう。
ただし、どれくらい時間をとれるかは職場環境やチームの雰囲気などの制約によると思います。たとえば1時間あれば試してみることはできます。1時間であれば、チームMTGの時間を使ったり、会議として時間をとって実験しやすいでしょう。
### いつ、どれくらいやるのがよいのか（導入）
モブプログラミングを現場に導入しているチームは、
- 常にモブプログラミングをする
- 週に○日、○時間など決まった時間枠でモブプログラミングをする
- 必要になったタイミングでモブプログラミングをする
のどれかです。
いずれにしても必要だと思えば機会を増やせばいいし、必要ないと思えば減らせばよいです。モブプログラミング or NOTを選ばなければいけないわけではないので、適切な選択をできるようになるのがいちばんよいでしょう。
特に重点的にモブプログラミングをするとよいのは、
- プロジェクトの初期、切り替わり期
- メンバーの入れ替わり直後
- チームワークが乱れ始めて同期が必要な時期
などです。
### お題はなにを選ぶのがよいのか
現場のメンバーでやる場合は、実際の仕事の中からピックアップして行うのもよいでしょう。
- 時間内にある程度区切りがつきそうなサイズのもの
- 全員が体験しておくとよさそうなもの
- 特定の人に依存しているもの
を意識して選ぶとよいと思います。具体的には、環境構築、初期のコーディング、人依存の運用作業などをモブプログラミングすると効果を感じやすいです。
本当にお試しでやるのであれば、TDDのお題を検索したり、 [Cyber Dojo](https://cyber-dojo.org/) にお題がたくさんあるのでそのあたりから選ぶのもよいでしょう。
### 上長をどうやって説得すればよいか
そもそもモブプログラミングはチームで仕事をするだけなので、少なくとも実験をする段階においては説得は必要ないと思います。仕事をもっとうまくできるようになろうとやっていることなので、堂々と気軽に実験しましょう。こっそりやりたい場合でも、チーム内会議やチーム内レビューとほとんど変わらない構図や時間で試してみることができます。実験がうまくいって、仕事のスタイルを変えたり、必要な備品を購入してほしい場合は、そのときにうまくいった結果を持って上司に話をすればよいでしょう。
どうしても結果が出る前に真正面から説得したい場合は、以下あたりが参考になるかもしれません。
https://agile-monster.com/blog/mob-advent/
https://agile-monster.com/blog/mobpro-bestpractice/
## まとめ
モブプログラミングの導入について、自分が考えていることについてまとめてみました。もちろんあくまで個人の考えなので唯一解ではないですが、参考にしていただければと思います。
複業で個人事業主をはじめました。実際に現場でモブプログラミングの支援をしてほしい、講演をしにきてほしいなどのご相談があればお気軽にお声がけください。
https://agile-monster.com/services/
どんなチームどんな状況においてもモブプログラミングが適しているとは思いませんが、業界や職種を超えてモブプログラミングがチームワークの選択肢としてもっと気軽に選べるようになるとよいな、心の底から思っています。
---
# Product Manager Conference 2019スライドまとめ #pmconfjp
URL: https://agile-monster.com/blog/pmconfjp2019-slides/
Published: 2019-11-13
---
まとめ職人がいそうになかったのでつくりました。随時アップデートしていきますが、あくまで個人によるまとめなのでご容赦ください。
当日のスライド、当日のスライドの一部と思わしきもの、補足として紹介されていたものなどをまとめておきます。
https://2019.pmconf.jp/
## Day1: 2019/11/12 (火)
### [ORDINARY PEOPLE, EXTRAORDINARY RESULTS](https://2019.pmconf.jp/sessions/2019/11/12/S1-001/) / Marty Cagan
https://www.slideshare.net/Productized/empowered-achieving-extraordinary-results-with-ordinary-people-by-marty-cagan?ref=https://cdn.embedly.com/widgets/media.html?src=https%3A%2F%2Fwww.slideshare.net%2Fslideshow%2Fembed_code%2Fkey%2FlX4vLCCjxe2s7W&url=https%3A%2F%2Fwww.slideshare.net%2FProductized%2Fempowered-achieving-extraordinary-results-with-ordinary-people-by-marty-cagan&image=https%3A%2F%2Fcdn.slidesharecdn.com%2Fss_thumbnails%2Fmartycagan-empoweredkeynote-181107164901-thumbnail-4.jpg%3Fcb%3D1541609914&key=a19fcc184b9711e1b4764040d3dc5c07&type=text%2Fhtml&schema=slideshare
https://medium.com/@Productized/empowered-achieving-extraordinary-results-with-ordinary-people-by-marty-cagan-talk-summary-25286d72cbc1
[itemlink post_id="2378"]
[itemlink post_id="2379"]
### [Special Session](https://2019.pmconf.jp/sessions/2019/11/12/S1-002/) / Kaarel Kuddu
### [LINEにおけるお金とユーザーのジレンマ](https://2019.pmconf.jp/sessions/2019/11/12/S1-004/) / 二木 祥平
### [海外の現場を訪問してわかったコード中心ビジネスの時代におけるプロダクトオーナーシップ](https://2019.pmconf.jp/sessions/2019/11/12/S1-005/) / 川口 恭伸
### [作り手の想いとユーザーをつなぐための悪戦苦闘](https://2019.pmconf.jp/sessions/2019/11/12/S1-020/) / 金田 悠希
### [保育現場に寄り添うプロダクト開発](https://2019.pmconf.jp/sessions/2019/11/12/S1-021/) / 赤沼 寛明
https://prezi.com/view/68c0fQgrH3lAMR9WoWs0/
### [PMにおけるストーリーテリング](https://2019.pmconf.jp/sessions/2019/11/12/S1-006/) / 岡田 悠
### [ピクシブのプロダクトマネージャー、自己組織化されたチーム、チームを支える組織](https://2019.pmconf.jp/sessions/2019/11/12/S1-007/) / 佐藤 里佳
※紹介していた発表スライドは現在非公開になっています。
### [ソフトウェア・ファーストで医療業界を変える](https://2019.pmconf.jp/sessions/2019/11/12/S1-022/) / 山崎 聡
### [“失敗事例で学ぶ” 失敗しないプロダクトマネジメント- PMの必須スキルと、自走する組織のつくりかた -](https://2019.pmconf.jp/sessions/2019/11/12/S1-009/) / 岡田 康豊
https://note.mu/diskdusk/n/na74688ed344c
https://note.mu/diskdusk/n/nfbefe8d9e762
### [10xのための逆説](https://2019.pmconf.jp/sessions/2019/11/12/S1-010/) / 矢本 真丈
### [多機能アプリのプロダクトマネジメントにどう向き合うか](https://2019.pmconf.jp/sessions/2019/11/12/S1-023/) / 坂本 和大
### [コミュニティマネジメント: プロダクトの開発と展開をコミュニティが加速させる](https://2019.pmconf.jp/sessions/2019/11/12/S1-012/) / 馬田 隆明
https://www.slideshare.net/takaumada/community-management-for-product-manager
### [教育事業におけるプロダクト・マネジメントとは](https://2019.pmconf.jp/sessions/2019/11/12/S1-013/) / 竹部 陽司
### [プロダクトマネージャになるには](https://2019.pmconf.jp/sessions/2019/11/12/S1-025/) / 小泉 剛
### [企業が求めるプロダクトマネージャーとその人材戦略](https://2019.pmconf.jp/sessions/2019/11/12/S1-015/)
https://twitter.com/satomikko94/status/1194167814065537024
### [データ/AIを活用したプロダクトの作り方と磨き方](https://2019.pmconf.jp/sessions/2019/11/12/S1-016/)
### [ベルフェイスが描く総プロダクトマネージャー構想](https://2019.pmconf.jp/sessions/2019/11/12/S1-026/)
### [発明、ドッグフーディング、プロダクトマネジメント](https://2019.pmconf.jp/sessions/2019/11/12/S1-017/) / 増井 俊之
※増井さんの講演メモのページは現在アクセスできなくなっています。
### [Keynote Session](https://2019.pmconf.jp/sessions/2019/11/12/S1-019/) / Harry D. Moseley
## Day2: 2019/11/13 (水)
### [今からはじめるデザインスプリント](https://2019.pmconf.jp/sessions/2019/11/13/S2-001/) / 佐藤 伸哉
### [変化の激しいプロジェクトを成功に導くには － 会議ドリブンなプロジェクトマネジメントメソッド](https://2019.pmconf.jp/sessions/2019/11/13/S2-002/) / 定金 基
### [PMが学ぶべき、最低限のデータ活用スキルとは](https://2019.pmconf.jp/sessions/2019/11/13/S2-003/) / 小川 晋一郎
### [太平洋をまたいで手をつなごう：日本におけるグローバルプロダクト開発](https://2019.pmconf.jp/sessions/2019/11/13/S2-004/) / Brad Ellis
### [「愛と解釈のコンダクター」](https://2019.pmconf.jp/sessions/2019/11/13/S2-005/) / 広野 萌
### [A day in the life of Silicon Valley PM](https://2019.pmconf.jp/sessions/2019/11/13/S2-006/) / 曽根原 春樹
### [打席に立ち続けられるプロダクトチームを作ろう](https://2019.pmconf.jp/sessions/2019/11/13/S2-007/) / 黒澤 隆由
### [プロダクトアウトな新規事業立ち上げのリアル](https://2019.pmconf.jp/sessions/2019/11/13/S2-009/) / 棚橋 寛文
### [ユーザーの行動に合わせたプロダクトづくり](https://2019.pmconf.jp/sessions/2019/11/13/S2-028/) / 田島 佳穂
### [“圧倒的に売れる価値”を創造する為に](https://2019.pmconf.jp/sessions/2019/11/13/S2-029/) / 戸松 大輔
### [PDMのFlexibilityについて](https://2019.pmconf.jp/sessions/2019/11/13/S2-012/) / 熊谷 亘太郎
### [大企業におけるプロダクトマネージャーのリアル](https://2019.pmconf.jp/sessions/2019/11/13/S2-030/) / 山田 高
### [プロダクトマネージャーが知っておくべき、「OKR」を通じたこれからのチームマネジメント](https://2019.pmconf.jp/sessions/2019/11/13/S2-014/) / ピョートル・フェリクス・グジバチ
### [ともに考え、ともにつくる](https://2019.pmconf.jp/sessions/2019/11/13/S2-015/) / 市谷 聡啓
https://www.slideshare.net/papanda/ss-188798246
### [面白いプロダクトの作り方と魅せ方](https://2019.pmconf.jp/sessions/2019/11/13/S2-016/) / 島澤 甲
### [『突破するプロダクトマネジメント ～ 実践編』](https://2019.pmconf.jp/sessions/2019/11/13/S2-017/) / 坪田 朋
### [プロダクトの強い軸を作るプロダクトマネジメントフレームワーク](https://2019.pmconf.jp/sessions/2019/11/13/S2-018/) / 小城 久美子
https://www.slideshare.net/kumikokoshiro/ss-192896028
https://www.slideshare.net/takoratta/prd-192302662
### [コネクティドカーにおけるプロダクトマネージメント](https://2019.pmconf.jp/sessions/2019/11/13/S2-019/) / 海老澤 雅之
https://www.slideshare.net/MasayukiEbisawa/pmconf2019-nissan-193119829
### [顧客要望と情熱の間- B2B SaaS のプロダクトマネジメント -](https://2019.pmconf.jp/sessions/2019/11/13/S2-034/) / 原口 琢磨
https://www.slideshare.net/takumaharaguchi/b2b-saas-193718915
### [プロダクトマネージャーが陥るカスタマーサポートの盲点](https://2019.pmconf.jp/sessions/2019/11/13/S2-035/) / 豊川 弘樹
### [Rebuild the Industry 〜産業の半自動化を実現するプロダクト開発手法〜](https://2019.pmconf.jp/sessions/2019/11/13/S2-021/) / 水島 壮太
### [ないものをつくるための作法 〜体感からの逆算とデザイン施行〜](https://2019.pmconf.jp/sessions/2019/11/13/S2-022/) / 佐藤 文彦
### [「何をつくらないか」を考えるリーンプロダクトマネジメント ](https://2019.pmconf.jp/sessions/2019/11/13/S2-036/) / 坂田 一倫
### [若者の熱狂を生む「オリジナルヒットコンテンツ」へのこだわり](https://2019.pmconf.jp/sessions/2019/11/13/S2-026/) / 谷口 達彦
### [PMから起業家へ。ゼロイチから40億円の資金調達まで](https://2019.pmconf.jp/sessions/2019/11/13/S2-027/) / 庵原 保文
## その他
https://togetter.com/li/1429367
https://togetter.com/li/1429885
https://satomikko94.hatenablog.com/entry/2019/11/12/234908
---
# #pmconfjp で感じたプロダクトマネージャーの現在
URL: https://agile-monster.com/blog/productmanager-now/
Published: 2019-11-13
---
Product Manager Conference 2019に参加してみたので、個人的に感じたことをさくっとまとめてみる。
https://agile-monster.com/blog/pmconfjp2019-slides/
## プロダクトマネージャーの定義はまだ定まっていない
いくつかのセッションに参加してみたが、プロダクトマネージャーの定義の話がよく出てきた。
- PDM（ProDuct Manager）とPJM（ProJect Manager）
- PDM（ProDuct Manager）とPMM（Product Marketing Manager）
- PDM（ProDuct Manager）とPO（Product Owner）
対比としてこれらの組み合わせが出てきた。それくらい同じ言葉を使っていても認識がズレる言葉だし、登壇者感でも微妙にニュアンスが違う。
https://medium.com/@tumada/product-management-triangle-job-description-d18d1855ef65
それは、カンファレンス内でもよく引用されていたThe Product Manager Triangleに表されるようにプロダクトマネージャーに関連したスキルが多岐に渡るからだろう。
これだけ多岐にわたるので、
- すべてを一人でカバーすることは難しい
- 会社、組織、プロダクト、チームなど様々なコンテキストによって求められるものが変わる
ということが、今回のカンファレンスを通じて改めて実感した。
こういう揺れる言葉はムリに使わないに越したことはないし、やむを得ず使う場合も「唯一無二の正しい定義」を求めることは諦めて（そんなもの存在しない）自分たちに必要なことを見定めて、それを現実に合わせてアップデートしていくことに時間を割いたほうがよさそうだ。
一般的な定義をつくるのは得意な人たちにお任せして、現場はやることやりましょうというお話。
## ソフトな話が多め
イベントの趣旨なのかどうかはわからないが、経営層など組織をつくる側のスピーカーが比較的多めな印象を受けた。また、テーマの性質上現場レベルの事例は出しにくいであろうこともあってソフトな話が多かった。
- プロダクトマネージャーに求められるもの
- 組織づくり
- 採用
- 育成
- キャリア
こういう話は正論なので共感しやすいけれど、その一方で「そうだそうだ！うちの会社はまちがってる！」みたいな謎の正義感が生まれやすく、実際その手の反応をよく見かけたので大変だなって思った。当然ながら話し手が伝えたいメッセージはそこではないので、正義感をこじらせると大変なことになる。
## まとめ
なんとなく感じたことをまとめただけなので、なんの結論もない。
でもあながちそれが間違っているわけでもなくて、
**「答えなんてない！でもやるんだよ！」**
ということを受け止めて、目の前のプロダクトに向き合っていくしかないってことなんだと思う。
先程「テーマの性質上現場レベルの事例は出しにくい」と書いたがきっとそんなことなくて、それを出したくらいでダメになるプロダクトなんてたかが知れていると個人的には思う。なのでどんどん現場の事例が出てきて、経営層ではなく現場レベルで盛り上がっていく世界になると、よいプロダクトがたくさん生まれる楽しい世界になりそうだな、という可能性を感じることができた。
もちろん現実はそんなにうまくはいかない。でも、定義を気にするフェーズからはとっと脱して、プロダクトの話をたくさんできるようになるといいなって個人的には思った。
兎にも角にも素晴らしい機会を作ってくださったイベント運営・登壇者・参加者の皆さんありがとうございました。
---
# 複業でチームや組織の支援をはじめました
URL: https://agile-monster.com/blog/agilemonster-start/
Published: 2019-10-15
---
2019年10月からチームの支援をはじめました。詳細については以下をご参照ください。
https://agile-monster.com/services/
ページ内にもあるメッセージから抜粋。
>
>
> 私は最強のチーム・組織をつくるために現場で活動をしています。自分の経験知をいろんな現場に伝えていくことで、よいチームが増えたらもっと面白い世界になると思って活動を始めます。
>
>
>
>
> ただし、皆さんの現場の主役は私ではなく皆さんです。私は耳障りの良いことは言いませんし、時には厳しい現実を突きつけることもあるでしょう。耳障りの良さを求めているのであれば他の選択肢の方がよいと思います。私は圧倒的当事者意識を持って本気で取り組むので、本気の方はぜひ一緒にお仕事をしましょう。最終的には皆さんの現場に私のサポートが必要なくなることがゴールです。
>
>
>
>
> よろしくお願いします。
>
>
自分にしかできない形で、チーム・組織の支援をしていくつもりです。本気の方はぜひお声がけください。
ちなみに屋号はAGILE MONSTERです。
これで屋号付きのいろんなものは「AGILE MONSTER 及部」となることでしょう。
ご興味あれば、Twitter・Facebookなんでもいいのでお気軽にお問い合わせください。
https://agile-monster.com/contact/
最後に、あれをこっそり置いておきます。いつもありがとうございます。
https://www.amazon.jp/hz/wishlist/ls/1GT7SXTM8BK63?ref_=wl_share
---
# Regional Scrum Gathering Tokyo 2020の個人的に推しているプロポーザル #RSGT2020
URL: https://agile-monster.com/blog/rsgt2020-proposal/
Published: 2019-09-29
---
日本で最も盛り上がるスクラムイベント、Regional Scrum Gathering Tokyo 2020（以下RSGT）のセッション公募と投票は2019年9月30日で締切です。皆さんもざっと眺めて、投票したり、わくわくしたりするのはいかがでしょうか？
https://confengine.com/regional-scrum-gathering-tokyo-2020/proposals
## プロポーザルが集まるということ
RSGT2020には170近くのプロポーザルが集まっています。RSGT2019の時は94だったので、2倍弱のプロポーサルが出ています。それだけRSGTに？スクラムに？注目が集まって盛り上がっていることを実感します。
これだけ集まっても採択されるプロポーザルは限られています。毎年感じるのですが、「落ちた」プロポーザルがあるわけではなくて「採択された」プロポーザルがあるだけです。それぞれのプロポーザルに経験や想いがこもっているわけで、それが何回かイベントが開けそうなくらい集まっていることはすごいことだなーと思います。
http://kawaguti.hateblo.jp/entry/2018/12/03/002216
RSGTに採択されようがされまいが、強い興味があるセッションがあったら声をかけてイベントを開いてしまうのがよさそうです。
## RSGT2020におけるプロポーザルの傾向
今年のプロポーザルの傾向を見てみます。各項目は提案者が入力したものなのであくまで参考レベルですが、最近の日本の現場の雰囲気を感じることができるかもしれません。
テーマは「組織変革とリーダーシップ」「チームの学びと成長」が多く、実践者が集っていそうなことがわかります。「プロダクトオーナーシップと商売」「技術と実装」は提案が少ないため、提案を出す側としてはこのあたりを軸に考えてみると他のセッションと差別化ができるのかもしれません。
レベルはこんな感じ。「Exective」レベルはさすがに0件でした。個人的には「Advanced」や「Exective」のプロポーザルが増えていくと、深さも出て楽しい世界になっていそう。
セッションタイプはこんな感じ。先日の[XP祭り](https://xpjug.com/xp2019/)でも感じましたが、「Workshop」を提案する人が増えているように感じます。
## 個人的な推しプロポーザル
最後に個人的に注目しているプロポーサルをご紹介します。
### Myプロポーザル
自分自身も毎年プロポーザルを出しています。毎年出せるくらいの圧倒的な活動を継続していこうという活力になっています。ご興味があれば、ぜひ投票お願いします。
https://confengine.com/regional-scrum-gathering-tokyo-2020/proposal/11846/-
こちらは最＆高なチームの活動。チームのファンをどんどん増やしていきたい。
https://confengine.com/regional-scrum-gathering-tokyo-2020/proposal/12609/10
こちらは [@daipresents](https://twitter.com/daipresents) との師弟タッグマッチ。最近はアジャイル系のイベントに参加されていなかったので、声をかけてみました。
### 個人に注目しているプロポーザル
https://confengine.com/regional-scrum-gathering-tokyo-2020/proposal/12223/-
きょん君のやつ。毎年RSGTにプロポーザルを出してチームの積み上げの話をしているのは彼と自分くらいなので、いつも刺激を受けています。今年は何が飛び出すんだろう。
https://confengine.com/regional-scrum-gathering-tokyo-2020/proposal/11890
椎葉さんのやつ。椎葉さんは個人的に前職で一緒に仕事をしてみたかったランキング1位な人。たまに会ってお互いの考え方ややっていることを共有していたのがやりづらくなったので、少し残念。またソフトクリーム食べたいなー！
https://confengine.com/regional-scrum-gathering-tokyo-2020/proposal/11774/set-
The Hiroのやつ。The Hiroは自分にはないものを持っていて、地道に努力を続けられる人なので尊敬しています。彼の生き様をこの眼で！注目していきたいと思っています。
### 働き方に注目しているプロポーザル
https://confengine.com/regional-scrum-gathering-tokyo-2020/proposal/11780
アジャイルコーチに縁がなかったので昨年までだったら興味がなかったと思いますが、自分自身がアジャイルコーチを始めようと考えていることもあって他のアジャイルコーチの考え方に興味を持っています。
中でもRyuzeeさんは近くで働く機会ができて、彼の凄さを肌で感じることがあるので楽しみ！
https://confengine.com/regional-scrum-gathering-tokyo-2020/proposal/11974
これはまさに今のタイミングで聞いておきたい。
### 推したいプロポーザル
https://confengine.com/regional-scrum-gathering-tokyo-2020/proposal/12822/sresre
Ryuzeeさんに鍛えられているエース島津さん。地に足ついたスクラムにするためには、こういうチームの下支えが不可欠なのでとても参考になる。泥臭い話をしてくれるはず！
https://confengine.com/regional-scrum-gathering-tokyo-2020/proposal/11918
デンソーに入社して間もなく[Agile Leadership Summit](https://www.agileleadershipsummit.org/)に参加した際に、「及部さんですか？」と話しかけてくれたデンソーの松原さん。愛知県刈谷市の本社に遊びに仕事に行った時に現場見学させてもらいました。制約の多い製造業の本丸で、草の根でスクラムチームを立ち上げて、チームを継続させているのはホントにすごいので、ぜひ皆さんにも話を聞いていただきたいです。
https://confengine.com/regional-scrum-gathering-tokyo-2020/proposal/11795
生々しそうで楽しみです！
https://confengine.com/regional-scrum-gathering-tokyo-2020/proposal/11984
ハイタッチ最高なんだよね。ハイタッチは負けません！
https://confengine.com/regional-scrum-gathering-tokyo-2020/proposal/12310/ui
デザイン要素をチームに取り込みたいのでぜひ聞いてみたい。
https://confengine.com/regional-scrum-gathering-tokyo-2020/proposal/11965/combining-our-powers-mob-programming-made-easier
海外におけるモブプログラミングの現場の話は、ChirisやWoodyしか聞いていない（それも贅沢）ので、ぜひ聞いてみたい。
https://confengine.com/regional-scrum-gathering-tokyo-2020/proposal/12408/bizreachyamoryless
おもしろそう！チーム拡大って思っているよりも大変だよね。
https://confengine.com/regional-scrum-gathering-tokyo-2020/proposal/12580
>
>
> ・POを志していた私が突然他チームでスクラムマスターをやってみた
> ・「全てを"正しいスクラム"に合わせるのではなく私たちにとってのスクラムのやり方を考えよう」としてきた
>
>
>
> そんなこの３か月のTry＆Errorの記録をお伝えします。
>
>
尊い。
https://confengine.com/regional-scrum-gathering-tokyo-2020/proposal/11896/x-x
これは聞きたい。
https://confengine.com/regional-scrum-gathering-tokyo-2020/proposal/12093/product-discovery-team
半谷さんの本気。
https://confengine.com/regional-scrum-gathering-tokyo-2020/proposal/12395/22
前職を辞める寸前に、このチームの話をすこしだけお聞きしました。ものすごい行動力と活力で現場で試行錯誤されていたので、ぜひその後の話を聞いてみたい。
https://confengine.com/regional-scrum-gathering-tokyo-2020/proposal/11878/rsgt-100-oss-gate-
セッション自体も楽しみだけど、RSGTでどうなるのか客観的にも見てみたい！
https://confengine.com/regional-scrum-gathering-tokyo-2020/proposal/12120/noestimates-scrum
陶山さんのチーム面白いんだよなー！
それでは皆さん、RSGT2020でお会いしましょう！アディオス！！
---
# サッカーからチームを学ぶ「チームをモデリングする ープロダクト開発におけるゲームモデルをつくるー」 #5000dai
URL: https://agile-monster.com/blog/gamemodel-product-development/
Published: 2019-09-16
---
[レッツゴーデベロッパーZERO ONE](https://lets-go-developer.connpass.com/event/143173/)で「チームをモデリングする ープロダクト開発におけるゲームモデルをつくるー」という講演をしました。
https://lets-go-developer.connpass.com/event/143173/
## ゲームモデルとは
今回取り上げたゲームモデルとは、サッカー用語であり、共有のためのチームの設計図のことです。
現代サッカーは、戦術化とデータ化が進んでいてとても面白いです。
- サッカーは世界で最も人気のあるスポーツ
- チームに関する知見、研究、理論の宝庫
- プロダクト開発との共通点が多い
という点から学べることがとても多いです。
ゲームモデルをはじめて知った時に、きっとこれはプロダクト開発に活かせるに違いないと思い、いろいろな本や文献を漁って、実際にチームでつくってみて、今回の講演に至りました。
中でもこの本はとても参考になりました。著者である脇さんは、高校のサッカー部の監督であり、未経験からサッカーを学び、ゲームモデルをつくり、それを広める活動をされています。ゲームモデルの作り方の説明だけでなく、どこにポイントがあるのか、どうやって伝えていくのかまで丁寧に書かれています。
[itemlink post_id="2366"]
## 資料
当日の資料です。
今回チームでつくったゲームモデル（主原則まで）は以下です。
プロダクト開発における4局面を、
- 平常
- ネガティブトランジション（平常→カオス）
- カオス
- ポジティブトランジション（カオス→平常）
と置いて考えてみたところ、とても手応えがありました。それぞれのトランジションにおける主原則は、チームごとの特色が表れるような気がします。
せっかくなのでもう少し時間を取ってチームのゲームモデルを作成し、公開したいなーと思っています。乞うご期待！
## おすすめ
資料の中でおすすめしている本のリンクです。
[itemlink post_id="2366"]
https://amzn.to/30ny2Bk
[itemlink post_id="2387"]
---
# OST（Open Space Technology）の説明用資料を公開しました
URL: https://agile-monster.com/blog/ost-introduction/
Published: 2019-08-09
---
OST（Open Space Technology）の説明をするのに使える日本語の資料がないなーと思ったので公開します。
最近オンラインでOSTを開催する機会も増えたので、オンライン版も公開しました。
## 資料（オフライン版）
## 資料（オンライン版）
許可は必要ないので、ご自由にご利用下さい。もし使っていただいた際に、Twitterで「使ったよー」とリンクと共にツイートしてくれたら勝手に喜びます。
## 合わせて読みたい
https://agile-monster.com/blog/ost-guide/
---
# TrelloからSlackに通知する方法
URL: https://agile-monster.com/blog/trello-to-slack/
Published: 2019-07-31
---
**※この記事は2019年8月1日時点での記事です**
Trelloでチケットを作成したりチケットのステータスが変更されたときにSlackに通知したくなることがあります。以前にもやったことがあったので鼻歌交じりに設定しようと思ったところ、実現する方法が変わっていたので記事にしておきます。
## Trelloアラートが無くなった
以前まではSlack上から「Trelloアラート」というアプリをインストールして設定すれば、さくっと実現することができました。
ところが！！
いくらTrelloアラートを探しても存在しません。
ググってみても、同様の方法がたくさん紹介されています。
https://businesschatmaster.com/slack/trello-renkei
比較的新しい記事でも「Trelloアラート」が紹介されているので、最近変更になったのでしょう。
## TrelloからSlackに通知したい場合はTrello上から設定する
TrelloにもPower-Upという様々なアプリケーションと連携する機能拡張の仕組みがあります。
https://trello.com/power-ups
Power-UpはAtlassianやサーとパーティーによって提供されているアドオンです。Slack以外にもGoogleドライブ、Box、Jira、OneDriveなどさまざまな連携を行うことができます。
## Trello Power-UpでSlackと連携させる方法
1. 連携させたいTrelloのボードの画面に行き、ボードメニューから「Power-Upを追加」を選択します
※ボードが未作成の場合は先に作成します
2. レフトナビの検索ボックスで「Slack」を検索し、Slackアプリの追加ボタンを押します
3. 追加が完了すると、追加ボタンが歯車アイコンに変わるので、歯車アイコンを押して、「Power-Upの設定を編集」を選択します
4. 「Slackアラートを追加」から、連携させたいSlackのワークスペースを設定します
5. 付与する権限の確認が表示されるので、問題なければ画面下部の「インストール」を選択します
※「インストール」選択後にLink Accountを聞かれるので設定します
6. 連携が終わったら3と同様の手順で「Power-Upの設定を編集」を選択すると、連携の詳細設定が開くので、通知を飛ばしたいチャンネルと、飛ばしたい通知を選択して、ポップアップ下部の「終了」を選択します。
一度設定したものを変更したい場合は、3と同様の手順で「Power-Upの設定を編集」を選択すると、編集ボタンがあるのでそこから設定変更をします
以上で設定は完了で、Trello上で設定したアクションを行うと、Slackチャンネルに通知が飛びます。
## Trello無料版では利用できるPower-Upでは1つだけ
便利なPower-Upですが、Trello無料版では利用できるPower-Upが1つまでに限定されています。複数使う場合はビジネスクラスにアップデートする必要があります。
よいTrelloライフを！
---
# 5分でわかった気になるインセプションデッキ
URL: https://agile-monster.com/blog/5minutes-inception-deck/
Published: 2019-07-30
---
仕事でインセプションデッキをつくることになったので、久しぶりに説明用資料をリニューアルしたので公開します。
## インセプションデッキ
インセプションデッキはアジャイル開発のプラクティスの1つで、プロジェクトを始める前に明らかにしておくべき大切なことを知るための活動です。アジャイルサムライでも紹介されています。
[itemlink post_id="2391"]
10個のタフクエスチョンが用意されていて、チーム全員で話し合いながらそれに答えていく形式で埋めていきます。最終的にチーム全員で合意したものがインセプションデッキとしてアウトプットされます。
キックオフMTGやPMBOKでいうプロジェクト憲章のように、仕事を進める上で既に似たようなことをやっているかと思います。ですが、やっている目的を達成できているかを再確認してみるとよいでしょう。
一部の人間だけで決めてない？
一方通行に説明して終わっていない？
都合がいいことだけしか話してなくない？
メンバーの不安に思う点は感じることができた？
テンションがズレてない？
ただの根性論になってない？
つくった後に見直したことある？
これらに「YES」と言えるならいまのままでよいでしょう。
インセプションデッキの良いところは、チーム全員でタフクエスチョンに答えるという共通体験を通して真の合意にたどりつくプロセスです。結果（アウトプット）自体はそんなに重要ではなく、過程（共通体験）こそが重要です。タイミングや形式や方法にこだわる必要はありません。
「このプロジェクトなんのためにやるのかわからない」とか
「このプロダクト誰がうれしいんだろう」とか
不満に思っている暇があったらみんなでインセプションデッキをつくってみるのがよいかもしれません。
## 資料
許可は必要ないのでご自由にご利用ください。もし利用した後に、このブログ記事のリンクと共に「使ったよー！」とツイートしてくれたら勝手に喜びます。
---
# チーム転職できました #チームFA宣言 #完結編 #アフターストーリー
URL: https://agile-monster.com/blog/teamfa-done/
Published: 2019-07-03
---
2019年1月末にチームでFA宣言をしました。この度、無事にチーム転職することができたのでここにご報告いたします。
7月1日付けで、[株式会社デンソー](https://www.denso.com/jp/ja/)にチームごと移籍しました。MaaS開発部でクルマの未来を創る予定です。
https://codezine.jp/article/detail/11391
転職先について書きたいことはたくさんありますが、今回はチームFA宣言の完結を中心に書くことにします。
## 御礼
はじめに、お声がけいただいた企業・個人の皆様、前職の皆様、ご心配下さった皆様、本当にありがとうございました。また、なによりすぐ近くで生暖かく見守ってくれた家族に感謝しています。
チームFA宣言後、自分たちの予想を上回るくらいたくさんの企業や個人からお声がけいただきました（思わずカンバンでステータス管理していたくらい）。今回の選択結果もその中の1つでしたが、それ以外にも魅力的なオファーをたくさんいただき、心より感謝しております。
また、その他にもFA宣言後にオンライン・オフラインそれぞれで反応を下さった皆さんもありがとうございました。こうして無事にご報告できて嬉しいです。
## チームFA宣言とは
詳細は以下のブログに書きました。
https://agile-monster.com/blog/team-fa-declaration/
少しだけ補足をしておくと、チームFA宣言をしたのであってチーム転職宣言をしたわけではありません。
>
>
> FA宣言
>
>
>
> 移籍の自由を与えるための制度
> プロ野球において、選手がその所属している球団から離れて、他の球団に移籍したいという意思表示をすること。フリーエージェント宣言。
>
>
>
> …
>
>
>
> いったんＦＡ宣言しても、もとの球団に残留することもできる。
>
> [FA宣言 - weblio辞書](https://www.weblio.jp/content/FA%E5%AE%A3%E8%A8%80) より
最終的に転職をすることにはなりましたが、所属していた会社の他部署などからもお声がけいただきました。
## 我々にとってのチームFA宣言
>
>
> 一方で、 すごい個人・一緒に働いてみたい個人の名前は挙がっても、すごいチーム・一緒に働いてみたいチームの名前はなかなか挙がりません。なぜでしょうか。
>
>
>
> せっかくいいチームができても会社や組織など様々な事情によって壊れてしまい、チームの寿命がそんなに長くないことが大きな要因のような気がしています。もちろんチームが長生きすればいいわけではないですし、チーム至上主義を謳いたいわけではありません。
>
>
>
> 私達はチームで今後について話し合ったときに、純粋に「もう少しこのチームでやりたいことあるよね」という想いが一致したため、チームFA宣言をすることに決めました。
>
>
>
> 全員に当てはまることではないことは知っていますが、「チームで転職する」という選択肢がもっとふつうになれば、もっと楽しい世界になるような気がしています。
>
> [チームでFA宣言します #転職 ](/blog/team-fa-declaration/)より
こんな想いを持ってチームFA宣言をしました。
宣言をする前はどんな反応がくるのかわかりませんでしたが、どんなことでも迷った時は面白そうな方に倒すと決めています。チームメンバーも同じような考えだったので、すぐに合意することができました。
そこからはチームFA宣言をするために、チームで抱えていた仕事の整理や関係者との調整を密かに進め、タイミングを見計らって公にしました。
また、チームでFA宣言をする際に、
- 個人でも転職活動をする
- 最終的には個人で判断して最善の選択をする
- お互いの判断を尊重する
- 結果として同じところに行けたらいいよね
ということを前提にすることをチームで決めました。人生の大きな決断なので当然のことだと思っています。結果としてチーム全員で転職することができてよかったです。
## 今後について
「チームFA宣言」「チーム転職」というものの事例を1つ作ることができてよかったです。
もちろんすべての人に受け入れられるものではないことはわかっていますし、実際に厳しいお言葉をいただくこともありました。でも、これだけチームの大切さが謳われている世の中なので、こういう選択肢があってもよいと思います。
転職はあくまでCommitに過ぎないので、この後どういう実装を積み重ねていくのかが大切です。一番どうなるか予想がつかなくて一番わくわくする選択ができたと思っているので、TAKAKING22先生の次回作にご期待下さい！！
デンソーは製造業の会社ですが、個人的には違う業界に転職したとは思っていなくて、ここからソフトウェアのてっぺんも取りにいこうと思っています（自分は）。エンジニアがハッピーになれる最＆高の場にしていこうと思っていますので、皆さん今後共よろしくお願いいたします。
これからもいろんなイベントにお邪魔したり、デンソーとしてもイベントをしかけていこうと思っているので、興味がある方はぜひお声がけ下さい。
## Q&A
### どのような反応があったのか
ポジティブなフィードバックは、
- 良いエンジニアを雇うことができても会社や組織やチームの中でパフォーマンスが発揮できるかどうかはわからないが、関係性や仕事のスタイルが確立しているいいチームごと採用できるのは効率が良い
- 良い仕事のし方をしているチームはまわりにも良い影響を与えてくれそう
という声が多かったです。一方で、
- チームとして扱わなくてはいけなくなってしまうのではないか
- チームを崩すことが難しくなりそう
- 評価をどうするか考えなくてはいけない
という懸念をいただくこともありました。
### なぜ起業ではなかったのか
自分たちでつくりたいプロダクトやこだわりのドメインがあるのであれば、もっとはやく起業という選択をしていたかもしれません。
現在の自分たちの中の優先順位としては、
>
>
> 誰とつくるか > どのようにつくるか > 何をつくるか
>
>
であったため、起業するのではなく企業に属して働くことを選びました。
### チームごと抜けて大丈夫なのか
まず、チームFA宣言という活動が会社として奨励されていたわけではなく、あくまで自分たちの責任の中で行った活動であることをご理解いただけると幸いです。
前述の通り、自分たちなりに準備をした上でFA宣言をしました。もちろんその上でもご迷惑をおかけした点も多々あったかと思いますが、まわりの方は応援してくださる方がとても多かったです。
本件に限らず、制御不能な自分たちをサポートして下さった会社やまわりの人達に本当に感謝しています。いい会社です！
## 最後に
自由に働きやすい状況になったので、今後は副業・複業という形で会社の垣根を越えて活動していく予定です。なにかお役に立てそうなことがあればお気軽にご相談下さい。
- 得意分野
アジャイル開発- スクラム- モブプログラミング- チームビルディング- 研修／新卒研修- 新規事業
また、前職の退職祝い並びに入社祝いは引き続き受け付けておりますので、お気兼ねなくご利用下さい！
https://www.amazon.jp/hz/wishlist/ls/1GT7SXTM8BK63?ref_=wl_share
---
# アジャイルで目指した坂の上の雲 #devlove #devlovex #devlovexE
URL: https://agile-monster.com/blog/clouds-above-the-hill/
Published: 2019-06-23
---
[DevLOVE X 〜それぞれの10年、これからの10年〜](https://devlove.wixsite.com/devlovex) で「【勝手に基調講演】アジャイルで目指した坂の上の雲」という講演をしました。
https://devlove.wixsite.com/devlovex
## 資料
### 煽りV
https://www.youtube.com/watch?v=VgI3igC0KKI
### プレゼン資料
### タイムライン
https://togetter.com/li/1368729
## タイトルについて
実はこの「アジャイルで目指した坂の上の雲」というタイトルは、2011年のDevLOVEで人生初の登壇をした際と同じタイトルです。
普段は自分たちが実践したことについて話すことが多いので、今回の「それぞれの10年、これからの10年」というテーマで何を話すのかはすごく悩みました。
DevLOVE Xという節目のタイミングは今回しかありません。このタイミングでしか話せないことを話そうと考え、敢えて同じタイトルでお話することにしました。
## 伝えたかったこと
勝手に基調講演と銘打っていたので、DevLOVE Xというイベント、そしてそこから始まるそれぞれの10年につなげられるようにメッセージを考えました。
登壇者だけでなく、1人1人にこれまでの10年のストーリーが存在します。今は別々の道を歩いているかもしれませんが、いつか誰かの道とつながるかもしれません。だからこそ、「誰かの話」をたくさん聞いたというだけで終わるのではなく、たくさんの人とお話してほしいと思ってこのメッセージを最後にお伝えしました。
実際に、今回のDevLOVE Xに参加して、DevLOVEをきっかけに出会った人たちに久しぶりにお会いしてお話することできました。違う道を歩いていても、どこかで会った時に旅の話をできる仲間ってステキですよね。
## 今のチーム感
今だから話せること、ということで今チームについて大切だと思っていることを3つ紹介しました。
### 成長のバランスを保つこと
ソフトウェア開発の現場は、主に、
- チーム
- 技術
- ビジネス（プロダクト）
という3つの要素から成り立っています。
チームを成長させていく時に、どこか1つの要素だけを成長させていってしまうと、歪になって全体としてうまく成果が出なくなってしまいます。
例えば、技術だけに特化して新しい技術や流行りの技術をどんどん導入していったとしても、それを扱うチームが未熟だったり、技術を活用してビジネス成果につなげるアイデアがなければプロダクトは壊れてしまいます。技術をさらに高めたいと思っても、その状態ではそれ以上のチャレンジも望めないでしょう。
チームが全体としてうまく成長していくときは、こっちを上げたらこっちを上げて…の繰り返しをしていくようなイメージを持っています。
うまくっていなかったことがうまくいき出すとボトルネックが移動するので、今度はその新たなボトルネックを解決して…というイメージです。
技術だけ、チームだけ、ビジネスだけではうまくいかないので、バランスを取り続けることが大切です。
### チームと個の関係
チームの話なのに矛盾しているように聞こえるかもしれませんが、最終的には個が大切だと最近感じています。
この式はあくまで私のイメージなので、これが正しいかどうかは重要ではありません。
チーム練度が低い状態でただ人を増やしていっても、全体の成果に対する効果は薄いです。また、極端な話、いくら作れない人の頭数を増やしても何も生まれません。
また、チーム練度は0〜1.5くらいの範囲で推移することが多いような気がします。初期のフェーズにプロセス改善やマネジメントを頑張ることは効果が高いですが、しばらくするとそれだけでは行き詰まってしまいます。結局は個の力、技術力やビジネス力のような生産活動に必要なスキルの向上から目を背けることはできません。
スタート地点がどこにあったとしても、基本的にはチームの練度を上げていきながら、個の成長が促進できるチームにして、右上のエリアを目指していくほうが筋がよさそうです。
大切なことは、チームは個の隠れ蓑ではなく、個を成長させるチームとチームを成長させる個の関係を作っていくことです。
### 安定させないこと
チームの成長のフェーズを表したタックマンモデルというものがあります。
https://www.ryuzee.com/contents/blog/7066
形成期⇒混乱期⇒統一期⇒機能期と進んでいく話はいろんなところで話を聞くことができますが、自分はチーム活動を続けていく中で機能期に入った時が一番注意しなくてはいけないと感じています。
一度うまくいきはじめると、「うまくいってるからいいじゃん」と満足してしまい、成長が鈍化してしまいがちです。ここで停滞してしまうことは、終わりのはじまりだと思っています。
チームの成長を止めないためには、スクラップ＆ビルドを繰り返していくことが必要です。生物の新陳代謝のように、時には意図的に古いものを捨てて新しいものを取り入れていかなければなりません。
これはチームを壊すという意味ではなく、
- 新しい方法を取り入れてみる
- 慣れ親しんだ方法を辞めてみる
のようなやり方でも、実現することができるでしょう。以前お話したUnlearnの話がまさにこの部分です。
https://agile-monster.com/blog/rsgt2019-learning-and-unlearning-team/
## これからの10年
私事ですが、今回の登壇が楽天株式会社に所属しての最後の発表でした。
https://agile-monster.com/blog/leave-rakuten/
チームFA宣言のその後について、もう少ししたらお話できると思いますので乞うご期待！
https://agile-monster.com/blog/team-fa-declaration/
## DevLOVE X
DevLOVE Xという場は、なんというか最＆高の場でした。
もちろん素晴らしいスピーカーが揃ったということもそうですが、1つのコミュニティが10年続いたからこそ生まれたものたちがそこにありました。
- はじめてDevLOVEに来た人
- DevLOVEにお世話になった人
- DevLOVEをつくった人
- DevLOVEを今支えている人
が同時に存在し、
- 出会いと別れ
- 再会
- それぞれの人生
が凝縮した場はDevLOVEだからこそ生まれたものでしょう。
運営の皆さん、参加者の皆さん、登壇者の皆さん、ありがとうございました。
参加できなかった皆さんもスライドやタイムラインを通して、ぜひ刺激を受けてください。
http://kobase16.hatenablog.com/entry/2019/06/23/013048
それでは最後に。
野村さん、写真ありがとうございます！
---
# #devloveX にて「アジャイルで目指した坂の上の雲」というタイトルで勝手に基調講演をします #devlove
URL: https://agile-monster.com/blog/devlovex-pv/
Published: 2019-06-06
---
2019年6月22、23日に「DevLOVE X 〜それぞれの10年、これからの10年〜」という大会が開催されます。
https://devlove.wixsite.com/devlovex
## アジャイルで目指した坂の上の雲
お話させていただくにあたって、プロモーションビデオを作ったのでまずはこちらを御覧ください。
https://youtu.be/VgI3igC0KKI
自分はこの10年間ずっとプロダクト開発の現場の最前線でエンジニアとして戦い続けてきました。その中で、アジャイル開発と出会い、DevLOVEと出会い、モブプログラミングと出会いました。
変わったこともたくさんありますが、ずっと変わらないことは「最強のチームをつくる」ということです。
いつも通りやってきたことや考えていることしかお話できないので、これまでの10年のチームとこれから先の未来のチームの話をしようと思います。
- 現場でチーム開発をするのが好きな方
- 自分のチームこそが最強だと思っている方
- チームで働くことやチームづくりに苦心している方
- まわりでチームを支えたいと思っている方
- お前の話を聞いてやるよ！って方
そんな人たちが聞きに来てくれたら嬉しいです。
ちなみに、今回の講演タイトルである「アジャイルで目指した坂の上の雲」は、2011年のDevLOVEで人生初の登壇をした際のタイトルです。そこから8年経った今、同じタイトルで話してみます。
https://www.slideshare.net/daipresents/devlove-hangarflight-snow-barrage
## DevLOVE Xに向けた意気込み
自分にとって2019年は、
- 社会人歴10年
- 楽天歴10年
- エンジニア歴10年
という節目の年です。
その節目の年にDevLOVE Xという記念すべき大会に出場できることは運命的なものを感じますし、出場するからには頂点を目指して戦います。
トップバッターの枠でお話することになったので、勝手に基調講演をします。DevLOVE Xと、そこから続く皆さんの次の10年の第一歩につながるような講演にしたいと思います。ぜひ皆さんの「それぞれの10年、これからの10年」も聞かせてください！
そして、この度、楽天株式会社を退団することになったので、これが楽天に所属しての最後の講演になります。
https://agile-monster.com/blog/leave-rakuten/
ここでしか見ることができない講演を、ぜひその目で！その耳で！感じにきにくてください。
---
# 楽天株式会社を退団します
URL: https://agile-monster.com/blog/leave-rakuten/
Published: 2019-05-29
---
2019年6月30日をもって楽天株式会社を退団することになりました。楽天には2009年に新卒で入社したので、丸10年間在籍したことになります。ディケイドです。
人事との退職者面談でネガティブな辞める理由をしつこく聞かれてイラッとするくらいには、楽天という会社が大好きです。
辞める人にはネガティブな理由があるって決めつけてはいけないな、カブロン！
様々な機会で注目されることが多く、すべての人に好かれる会社だとは思わないけれど、自分にとっては最＆高の1社目でした。まさか入社した時には、会社が英語化して、楽天イーグルスが優勝して、バルセロナのスポンサーになって、ヴィッセル神戸にイニエスタとビジャが来て、第4の携帯会社になるなんて想像すらしていませんでした。こんなに刺激的で突拍子もない会社は他にないです。制御不能な自分が好き放題できたのも、会社の懐の深さと、まわりの人達に支えられたからに他なりません。
## 楽天での10年間
### 新卒入社
新卒で入社した2009年は、ビジネス職と開発職共に一斉入社だったので同期が約300名います。これだけいると顔も知らない同期もたくさんいますが、同時に今後の人生でも付き合っていくだろう友人たちとも出会うことができました。ちなみにここで妻とも出会いました。
### 仕事
関わったお仕事は、楽天の中でも小さなサービスの開発・運用や、新規事業の立ち上げが多かったです。炎上気味のお隣のプロジェクトに放り込まれることも何度かありました。
自分の場合は社会人になってからプログラミングを始めたようなものだったので、たくさんのサービスに関わって、それぞれのコンテキストで "そうなっている" ビジネス・システム・プロダクトコード・組織・チーム・環境の中で働くことができたことはとても価値ある経験でした。特に、Infoseek News・楽天レシピ・Rakuten Super Englishは、Tech Leadやマネージャーとして、1つのチーム・プロダクトに長く関わらせていただきました。また、最後の約3年間は新規事業の立ち上げ専門の部門に所属し、大きな会社における新規事業の酸いも甘いも経験することができました。
これらの経験は自分の仕事スタイル、レスリングスタイル、エンジニアリング、チーミングの基礎となっています。
### 社外活動
楽天でのたくさんの出会いや経験をきっかけに、勉強会やカンファレンスに参加したりお話する機会を数多くいただきました。
https://agile-monster.com/slides/
これらの活動をきっかけに、社外にたくさん友人や先輩ができました。いろんな方から刺激をいただくことで、今の自分があります。
### 新卒研修
2018年の新卒研修に携わったのですが、結果としてそれが楽天生活での最後の大きな仕事になりました。
この新卒研修はもはやただの新卒研修に留まっておらず、これまで培ってきた現場での経験知を惜しげなく注ぎ込み、会社の垣根を超えた業界屈指の友人たちと全力でコラボレーションできるという最＆高なお仕事でした。
研修を受けてくれた最＆高な新卒の彼ら／彼女らが会社や世の中を変えていくところを見たいですし、いつか一緒にお仕事できたらいいなと思います。研修の最後に話す場で「オヨベチルドレン」という言葉を発しましたが、これからも一方的にそう思い続けています。彼ら／彼女らがスーパーになった時に、「あいつはワシが育てた（わけない）」と言うことが夢の1つです。
自分自身も新卒で入社した時に同じような集合研修を受けていたのですが、数年後にがっつり研修する側になるとは思っていませんでした。自身が新卒の頃にお世話になった人事の方たちと一緒にお仕事することができ、時の流れを感じました。
こうやって書いてみて気づきましたが、これ盛大にフラグ立ってましたね。
## なぜ今退団するのか
入社時には3年もいるだろうかと思っていたけれど、気づいたら10年経っていたというのが正直なところです。
自分ではあまり会社に依存しないように活動し続けてきたつもりなので、いつでも辞めるつもりだったのですが、常に最＆高の選択ができるように走り続けてきた結果、たまたま楽天に10年間在籍したというだけです。
なので、退団する理由はタイミングでしかありません。10年という節目でもあるので、「最強のチーム／組織をつくる」という現在の目標を達成するためにステージを変えて新たな挑戦を続けます。
「楽天の及部」と声をかけていただく機会も多かったので少し寂しい気持ちもありますが、楽天という冠が外れてもお呼びいただけるように精進します。身体一つあれば、どこでもプロレスはできます。
## 今後について
今年のはじめにチームFA宣言をしました。
https://agile-monster.com/blog/team-fa-declaration/
今後については適切な場でご報告させていただきます。なのでもう答えはおわかりですよね？
>
>
> トランキーロ、あっせんなよ！！
>
>
今後は所属する会社の垣根を越えて活動していく予定なので、なにかお役に立てそうなことがあればいつでもお声がけください。
## 謝辞
この10年間本当にたくさんの方にお世話になりましたし、お世話しました。
友人、仲間、同期、先輩、東京の母、師匠、好敵手（とも）、子どもたち、一人ひとりに感謝の言葉を伝えたいところですが、書ききれないのでいとも簡単に諦めます。皆さん、本当にありがとうございました。
今のところ6月28日が最終出社の予定で、まだ会社にいるのでランチでも飲みにでも誘ってください。社外の方も同じく誘ってください！
## 質疑応答
#### −− もう試合を見ることはできないのですか？
6月22、23日にDevLOVE Xという大会（イベント）があります。この大会が楽天での最後の試合になる予定です。はじめて登壇したイベントがDevLOVEで、おまけに偶然なことにこの大会のキーワードが「10年間」なので、これまでの集大成として会場にお集まりの皆様に最＆高の試合をお届けしたいと思います。
https://devlove.wixsite.com/devlovex
また、SAYONARAイベントを絶賛企画中です。ふつうの辞め方はこっ恥ずかしいので、自分たちらしく華々しく散ります。よかったらご参加ください！
#### −− プレゼントは受け取ってくれますか？
もちろんです！
http://amzn.asia/1jMSZnd
#### −− 個人的にメッセージを送りたいんだけど？
こちらからどうぞ！
- [https://twitter.com/TAKAKING22](https://twitter.com/TAKAKING22)
- [https://www.facebook.com/takaking22](https://www.facebook.com/takaking22)
- [https://agile-monster.com/contact/](https://agile-monster.com/contact/)
離職した後に離職した会社のことを語るのは個人的に好きじゃないので、この退職エントリーは在職中に書いています。書き足りないことがあれば在職中にまた書きます。
それでは皆様、またお会いしましょう！アディオス！
---
# 混んでいるエレベーターでドアが開いた時のこと
URL: https://agile-monster.com/blog/crowded-elevator/
Published: 2019-04-26
---
そこそこ混んでいるエレーベーターとか電車に乗っている時のことです。
※当時掲載していた図解イラストは、旧サイトからの移行で失われてしまいました。
そうするとドアが開いた際に、ドア付近にいる人は降りる人のために動いて導線をあける必要があります。せっかく親切心で動いても、このあたりに移動しちゃうと、結局通りにくかったり。
降りる人がイライラしてると、肩でぶつかられたりパワープレーで強引に押されてしまったりします。
せっかく動いてあげるならこのあたりまで移動して、導線をしっかりあけてあげるとみんな幸せなんだろうな。
それだけ！
---
# 1on1から始める、その前に
URL: https://agile-monster.com/blog/before-beginning-one-on-one/
Published: 2019-04-25
---
「BPStudy#140〜IT企画／エンジニアリング組織・マネジメントを語る会」というイベントで1on1についてのLTをしてきました。
https://bpstudy.connpass.com/event/122728/
## 1on1から始める、でよいのか
最近「エンジニアリングマネージャー」という言葉がバズっていて、様々な書籍やスライドやブログ記事を目にするようになりました。その中でマネジメントプラクティスの1つとして、1on1が注目されています。実際に1on1を導入している企業も多く、私が所属している楽天でも数年前に全社的に1on1が導入されました。
[itemlink post_id="2397"]
ところが、自分のまわりにいる社内外のエンジニアと話していると1on1についてネガティブなイメージを持っている人がそこそこいるように感じています。
エンジニアリングマネージャーとしてがんばろうとしている人たちとエンジニアの間で、大きな隔たりがあるように感じました。そんなことをTwitterでつぶやいたりしました。
https://twitter.com/TAKAKING22/status/1111507218506014721
https://twitter.com/TAKAKING22/status/1111510238023151616
エンジニアリングマネジメントをこれからがんばろうとする人が、メンバーとのタッチポイントとしてまず1on1から始めることは本当によいのだろうか。そんな疑問が自分の中で浮かんできました。
## 1on1に関するアンケート
このもやもやをもう少し具体的に実感したかったので、試しに1on1に関するアンケートをとってみました。ご回答下さった皆さん、ありがとうございました。
TwitterやFacebookでアンケートを募ったので、自分とつながりがある人＋その周辺の方にお答えいただいています。したがって、比較的勉強会など社外で活動している人などが多いため結果にバイアスがかかっていると思います。実態は全体的にもう少しネガティブな結果になるんじゃないかな、と想像しています。
実際に1on1をしている人は60%くらい。
4人に1人は1on1に対してネガティブあるいは無関心という結果でした。前述の通り、実態としてはもう少し多いのではないでしょうか。
どんなマネージャーと1on1をしたいかを聞いてみましたが、ワードクラウドだと細かいので大まかにカテゴライズしてみました。
ざっくりいうと、話を聴いてくれる人かつ自分にとってプラスになる人であれば1on1をしたい、という結果になりました。当たり前ですね！
「技術がわかる／話が通じる」という項目がそこそこ多いので、ある程度同じ言葉で話すことができる人と1on1をしたいと思っている方が多いようです。
今度は反対に、どんなマネージャーとは1on1したくないかを聞いてみました。
さっきの逆で、話を聴いてくれる人かつ自分にとってプラスになる人**でなければ**1on1したくない、という結果になりました。そりゃそうだ！
1on1が会社の仕組みとして導入されることが増えている影響なのか、「ただ形だけやっている」人とは1on1をしたくないと思っている人がそこそこいます。
これらのアンケート結果から、
- そこそこの割合の人が、1on1に対してネガティブor無関心である
- 話したい人とであれば1on1をしたいし、自分の話を聴いてほしい
ということが読み取れます。したがって「流行っているからとりあえず1on1から始めよう」という短絡的な発想は危険で、かえって逆効果になってしまうかもしれません。
また、元も子もない事実として、1on1をうまく活用しているマネージャー達は1on1を始める前からメンバーとの信頼関係を構築できているのです。仮にまだメンバーと信頼関係が築けていないマネージャーが、彼らの話を参考に1on1から始めようとするとどうもうまくいきそうにありません。
そもそもメンバーとよい信頼関係を築くことは1on1の目的の1つでもあるので、まずはお互いにポジティブな気持ちで1on1に臨むことができるような関係づくりから始める方がよさそうです。
1on1から始める前に、 雑談から始めよう。そんなことをメッセージに今回はLTをしました。
## 資料
当日の資料はこちらです。
資料の中にもメッセージを入れましたが、マネージャーもメンバーも同じゴールに向かう仲間であるはずです。どちらが上でどちらが下という話ではないはずなので、一緒にうまくいく方法を模索する方がよさそうです。
マネージャーも「マネージャーなんだからしっかりやらなきゃ」などと気負わずに、自分の悩み事や考えていることをメンバーに正直に相談をすればいいのです。一方で、メンバーもマネージャーはただの人間であることを理解し、マネージャーに対してフィードバックをしてあげる姿勢が重要です。
1on1も、雑談も、People Managementも、ただの手段の1つでしかありません。そんな体裁にこだわるよりも、一緒にゴールに迎える仲間が増えたほうが自分は嬉しいかな。
---
# 「スクラムマスターを雇う時に聞いてみるとよい38個の質問」に答えてみた
URL: https://agile-monster.com/blog/scrummaster-test/
Published: 2019-04-19
---
以前、[スクラムマスターを雇う時に聞いてみるとよい38個の質問 ](https://www.ryuzee.com/contents/blog/7064)を読んで面白そうだなと思っていたら、実際にこれに回答をする記事をちら見したので、読みたい衝動を抑えてまず自分で答えてみることにしました。回答したら @Ryuzee さんが点数を付けてくれると聞いて（言ってない）。
回答するにあたって、
- 「コンテキストに依る」は全てにおいてそうなので禁止
- 問題に対するつっこみはなし
を前提に真摯な態度で回答しました。
また、自分はここしばらくキレイなスクラム／スクラムマスターをやっていないので、基本的には「自分だったらどうする？」をベースに回答しているのと、スクラム／スクラムマスター前提の質問に対しては「転生したらスクラムマスターだった件」という気持ちで答えております。
https://www.ryuzee.com/contents/blog/7144
## 答えてみて
スクラムの復習にちょうどいいかもー！！
復習じゃなくても「自分（たち）だったらどうする？」を考えながら回答していくことで、頭の整理ができると思います。採用面接の場でも、こういうケースを問う質問は相手の仕事の仕方が垣間見えるので有効かもしれません。
答えながら感じたことは、自分はスクラムマスターとしては失格なのかもしれないなー。まあ、いいか。
## スクラムマスターの役割について
### 1. アジャイルマニフェストでは「プロセスやツールよりも個人と対話を」といっている。プロセスを守らせるスクラムマスターは、それとは反対のことをしているのではないか？
「よりも」って言ってるだけで、二元論じゃないよね。プロダクトづくりを円滑に進めるためにプロセスやツールをうまく活用していくことが必要なときもあるので、反対のことをしているとは思わないかなー。
（1問目から言ってしまうと）でも「プロセスを守らせる」とか言ってるスクラムマスターはあんまり好きじゃないかも。自分の場合は、「今の状況からして何をするのがよさそうだろう」を大事にするかな。チームの立ち上げてからしばらく（タックマンモデルで言う形成期〜混沌期くらい）はまずは型に合わせた方がうまくいくことが多いけど、チームが自走しはじめたなら自分たちでよりよいやり方を選んでいけばいいだけだし。
もし専任スクラムマスターをやっていたとすると、立ち上げ当初が一番忙しくてだんだん用無しになっていくのが理想だよねー！そしたらコード書けるし！！
### 2. 自分の組織でアジャイルがうまくいっていることを示す兆候は何か？また自分の働きが成功している兆候は何か？
関わっているプロダクトやビジネスがうまくいっていること！
そこからブレイクダウンしていった時に、
- バリューストリームが端から端まで流れるまでのリードタイム
- SLAがどれくらい守れているか
- ハッピーメトリクス
などを計測していったりはするけれど、まずはビジネスメトリクスと同じものを見るのが自然だと思います。
基本的にチームの成果なので「自分の働きが成功している兆候」って難しいけれど、自分が専任スクラムマスターだとしたら…を無理やり考えると、
- やることいっぱい⇒やることを探しつつ見つけたらやる⇒やることがない、に近づいていること
- チームメンバーが評価されていること
- 各関係者からの自身の評価がそこそこよいこと
- 自分自身が楽しめていること
あたりかな。
### 3. 追跡しないといけないメトリクスはあるか？もしそうだとしたら何の目的でどのメトリクスを追跡するか？
2で回答した通りで、少なくともプロダクトやビジネスが追っているメトリクスは追跡しないといけないかな。それが一番外側のIN/OUTだし。
「キレイなスクラムがまわっている」「チームだけ仲がいい」「デプロイ回数だけ増えている」のような部分最適で終わってしまわないように、常に追跡しておくのがよさそう。
### 4. あなたのチームのパフォーマンスは常にコミットメントを達成できておらずベロシティも安定していない。考えられる理由はなにか？そして問題をどのように指摘するか？
- 差し込みが多くて集中できていない
- メンバー入れ替えが多い、兼務者が多いなどチームが固定化されていない
- バックログアイテムがReadyじゃない
- 必要な役割とのコミュニケーションコストが高い
- チームの技術力が低い
いずれにしても短期的な問題解決よりも自分たちで問題を見つけて自浄作用が働くようになることが最も重要なので、直接指摘はしないかな。代わりにチームで考えてチームとしての答えが出せるような場づくりを全力でサポートする。
### 5. 製品のディスカバリープロセスにスクラムチームは参加してよいか？その場合はどのようにするか？
え、ダメなの？よいでしょ。
むしろ参加しなきゃダメだと思ってます。「よいプロダクトつくってるよ！お客さんやユーザーの顔見たことないけど」ってただのオ○ニーだと思うので、最初から参加するのが当たり前って状況にしちゃうかな。
そうしないとただの受発注の関係になっていってしまいがちだし、なによりもつくる人は考えることもできるのだ！
### 6. 設計上プロダクトオーナーの役割はボトルネックになる。価値が最大になるよう、どのようにプロダクトオーナーをサポートするか？
チームがうまくまわりだすと、ボトルネックが移動してプロダクトバックログがジリ貧になる問題は何度も体験してきたなー。
プロダクトオーナーが集中すべきこと／プロダクトオーナーに頑張ってほしいことに集中してもらえるように、それ以外のことはチームでサポートできるように持っていくことが多いかな。ほとんどのことはプロダクトオーナーじゃなくてもできることなので、走り回れる人が走り回ればいいのです。
### 7. どのようにスクラムチームがしかるべきステークホルダーにアクセスできることを保証するか？
必要なステークホルダーには最初から話しておく。
経験上アジャイルやスクラムの話を面と向かってする必要があったことはなくて、「よいプロダクトをつくりたいんだ！だからこういう協力して下さい」って話したときに反対する人には会ったことがない（いたとしたら会社にいちゃダメ）。
あと彼らは仲間に入れなくて寂しがってることが多いので、定期的に「こういうところがうまくいかないんですよねー」「あ、前に教えて下さった通り○○をやってみたうまくいきましたよー」みたいな相談や雑談をムダにしてあげると強力な仲間になってくれることが多いです。
### 8. どのように複数の異なる部門にまたがってアジャイルのマインドセットを広げるか？ITじゃないステークホルダーをコーチするのにどんな戦略をとるか？
何もできていない内から広げようとしてもなかなかうまくいかないので、パイロットチーム1〜2チームでうまくいかせることに集中する。うまくいき始めると、不思議なもので「砂山の法則」でまわりのチームによい影響が流れ出すのでそのあたりではじめてスケールすることを考えてもいいのかも。
近くのチームで結果が出始めるとステークホルダーからの信頼も得やすいし、まわりのチームも主体的に取り組んでくれやすいので、ステークホルダーごとチームごと研修を受けてもらうのがよさそう。
### 9. 上級管理職にどのようにスクラムを紹介するか
（必要なければ）しなーい！！
「どうしても教えてください」って言われたら考えるけど、そんなに興味があるなら研修に行ってもらうことをおすすめするかな。偉くなっても勉強したまえ。
### 10. あなたはすでにステークホルダーにスクラムのトレーニングをしたとする。この考え方を適用しようとする初期フェーズのあと、スクラムの適用を続けることに同僚が激しく抵抗するような障害やハードルにぶつかったとする。このような状況においてどんな戦略を取るか？またどんな経験があるか？
なぜ抵抗するのか話を聴いてみる。それしかない！
自分自身が「手法やフレームワークを導入しよう」という立ち位置でアプローチすることはなくて、「いまよりもっとうまくなろう」というアプローチで進めるので少なくとも同僚から抵抗を受けた経験はないかな。昔アジャイル開発で失敗した経験を持つ上司（外野）から抵抗を受けた経験はあるが、言葉を一切使わずに、前述の相談・雑談をムダにすることを続けたら最高の理解者にってくれた。そしておまけに気づいたらアジャイル嫌いも克服してくれていた。
重要なことは、
- 「よくしたい」「うまくなりたい」という思いは一致している
- 相手の感情に寄り添う
ということを念頭にコミュニケーションしていくことだと思う。人間だもの。
## プロダクトバックログのグルーミングと見積りについて
### 11. プロダクトオーナーはステークホルダーの要求をプロダクトバックログ項目に落とし込んでその見積りをチームに求めることになる。その流れでよいか？
別にいいんじゃない？
でもステークホルダーの要求を本当に優先すべきなのかはわからないので、そこの優先順位づけができているかは気にするかな。もし御用聞きをしてるだけならそのプロダクトオーナーは不要かと。
あとは可能であれば、その場にチームメンバーも同席するようにしたいかも。「見積もりする必要ない」という見積もりが一番ステキだし、それが判断できるのはチームだけ。
### 12. チームに最新情報やマーケット状況を伝えるためにプロダクトオーナーにどんな情報を要求するか？
新しく準備してもらう必要はなくて、プロダクトオーナーがまわりのステークホルダーに伝えたり、自身で追っかけていたり、考える時に使っている情報や資料を見せてー！って感じかな。
それが残念だと、「そもそも自分たちは何のために仕事をしているんだろう」って気になるので危機感を感じることができるよね。
### 13. 誰がユーザーストーリーを書くとよいか？
みんな！
プロダクトバックログの優先順位を決められるのはプロダクトオーナーだけなので、プロダクトオーナーに全容を把握してリードして欲しい感はあるけど、書くのはチーム関係者であれば誰でも良いと思います。
### 14. よいユーザーストーリーとはどんなものか？どんな構造か？
- **I**ndependent 独立している
- **N** egotiable 交渉可能である
- **V** aluable 価値がある
- **E** stimable 見積もり可能である
- **S** ized Right (Small) 適切な大きさである（小さい）
- **T** estable テスト可能である
INVEST（上記の頭文字）であることが教科書的なのかな。
フォーマットはなんでもいいけれど、これまでの経験上作り手目線だと、
- どうなったらできた！って言ってよさそうか
- 誰のためで、どんな価値が、どれくらいありそうか
- （プロダクトオーナーが）どれくらい想いを持っているか
- 作りながら考えてほしいことや決まっていないことなどが明記されている
みたいなことがわかるとすごく嬉しい！
### 15. 「Readyの定義」には何が含まれているべきか？
とりあえず作り始めることができそうであればいいんじゃないかな。
作る前からわかっていることなんてそんなにないので、Readyにするためにがんばろうとしすぎて時間をかけるよりは、まず作り始めることができるラインを目指して、その分作りながらより良い方向に変えていける余地があった方がステキかな。
そういう意味で見積もりができているってことは、チームがそれなりにイメージできているってことなので、それは含まれていてほしいかも。
### 16. ユーザーストーリーを時間で見積もらないのはなぜか？
相対見積もりの話かな。
かかる時間は人によって違うので、絶対値である時間で見積もりをするとズレていってしまう。一方でポイント見積もりやSMLのようなサイズ感であれば全員で共通に扱える。あとは時間見積もりにすることでパーキンソンの法則が働きやすくなってしまうってのもあるある。
ただこれも「未成熟なチームはできれば避けた方がいいよ」って話であって、時間見積もりの弊害を理解した上で問題なく扱えるチームであれば時間見積もりでよいと思う。
### 17. プロダクトオーナーはあとになってから取り組むようないろんな種類のアイデアを追加してくる。結果的にいろんなタイミングで取り組む200個のチケットができたとする。それに対してどのように取り組むか？スクラムチームは200個のチケットに取り組めるか？
バックログに何枚チケットがあろうと、スプリントのタイムボックスに入るチケットの数が変わるわけではなので、特に何も変わらない。
ただ一方で、時間が経つことでプロダクを取り巻く状況が変わって優先順位を入れ替えたり新たにやりたいことが出てくるのが常なので、「チケット作り過ぎのムダ」みたいなものは生まれやすい。
バックログの下の方のチケットって何ヶ月も触られずにゴミになって、あるタイミングでガベージコレクションされることが多いので、それくらいのつもりでチケットを扱った方がよさそう。
## スプリントプランニングについて
### 18. チームがもっとも価値のあるストーリーに取り組めるようにするためにどのようにスプリントプランニングにスクラムマスターとして貢献するか？
プロダクトバックログが（少なくとも）スプリントプランニングの段階で常に新鮮であるように、バックログリファインメントをしたり、事前にバックログを確認して気になることはプロダクトオーナーに確認しておいたりするかな。
また、プロダクトオーナーにスプリントプランニングに必ず同席してもらうようにするかな。プランニングの中で出てくるチームの質問に答えてもらうこともそうだし、プランニングする中で実装目線で読み解いていくと「実は今はやらない方がいい」とか「これと合わせるとすごく簡単に終わるかも」とか「コード書かなくても実現できそうだ」とかそういう優先順位が変わりうる情報が出てきたりするんだよね。
### 19. ユーザーストーリーの価値をどんなメトリクスに基いて判断するか？どんなメトリクスは受け入れがたいものか？
ビジネスメトリクスに沿っていること。沿っていない場合でも、他のストーリーと重要度を比較できる理由がある程度納得できるかどうか。
「お客さんが欲しいと言っている」
「偉い人に言われたから」
「（特定の）ユーザーからのフィードバックにあった」
「この機能があれば売れる」
みたいなものは受け入れがたいというか、メトリクスになっていないのでもう一歩踏み込んで聞いちゃうかな。
### 20. チームのコミットメントの権限を侵犯することなくどのようにもっとも価値のあるユーザーストーリーを選べるようにファシリテーションするか？
プロダクトバックログが適切な優先順位で並んでいるという前提で。
タイムボックスの大きさは決まっているので、基本的にはそこに入る限りはバックログの上からスプリントバックログアイテムにしていく。このアイテムを入れるとあふれるな、って時はそのアイテムは含めない or 優先順位次点以降で入りそうなアイテムをプロダクトオーナーに選んでもらう。
できる限り詰め込まないと損するって考え方は危険なので、
「早く終わったら次のアイテムを着手しておくよー」
「もしかしたらリダクタリングしたり勉強してるかもだけど」
くらいの空気でプランニングできるといいなー。
### 21. どれくらいの時間をリファクタリングや重要なバグの修正や新しい技術やアイデアの調査につかうのが適切と考えるか？
チームの置かれている状況によって変化するものだけれど、
- 0%でないこと
- 50%以上になっていないこと
を気にするかな。
0の時はおそらくチームがパツパツでよくないことが起こりそう／起きていると思うし、割合が高すぎる時はスプリントプランニングが甘かったりプロダクトバックログがジリ貧などの問題が起きている可能性が高い。
### 22. チームの個人にストーリーやタスクを割り当てようとするプロダクトオーナーをどう扱うか？
ああ、いるよねｗ
話しやすい人とかお願いしやすい人にばかり直接お願いしちゃう人。スプリント期間中に「ちょっとお願い」ばっかりする人。
プロダクトオーナーの「どうしたらいいかな？」「ちょっとお願い」を気軽にできる仕組みがなくて特定の個人にばかりお願いしてしまうことが真の問題だと思うので、そこを一緒に作っていくかな。
その際に、まずは状況を正確に把握するために自分が窓口となって困ったら言ってもらうとかはよくやります。タイムボックスや個人アサインしない話や優先順位とかいろいろ正論を言いたくなる気持ちはわかるけれど、ビジネスシーンで「とはいえ」をやりたくなってしまう気持ちも理解できるので、まずは気軽に言ってもらえる仕組みや関係性をつくった上で、1つずつ整理しながらお互いの進め方を理解すり合わせていくことが多いです。
### 23. チームメンバーによるタスクのつまみ食いをどのように扱うか？
一概に問題とは言えないけど、つまみ食いするくらいなら堂々と食べてほしいかな！
余裕ができて先回りしようとしてくれてるならすごく嬉しいけど、次のに着手してくれればいいよね。もしくはまだ終わってない人を助けてくれた方がチームにとっては嬉しいのかも。
いずれにしてもつまみ食いをする理由を聞いた上で、そのままでいいのか、なにか対処したほうがいいのかを考える。
### 24. ユーザーストーリーが最終的に確定していないがスプリントの2日目には確定する状況で、プロダクトオーナーはそれをスプリントバッグログに入れようとしている。どのように行動するか？
「2日目には確定する」がそもそも予測に過ぎないので、次のスプリントに回すことをおすすめして、それで良さそうならそうしてもらう。もしどうしても入れたいということであれば、スプリントプランニングに余裕をもたせて計画をすることと、不確定な状態なので終わらないかもしれないことを同意してもらった上でいったん受け入れる。
あとはそこまでしたいストーリー（＝重要だと思っている）なので、余裕をもたせてもらった分、ストーリーを確定する作業をチームが手伝う、あるいは相談にのることをそもそも計画に入れてしまうかも。
### 25. スクラムチームのメンバーがスプリントプランニングに参加したがらないだけでなく、時間の無駄だと考えている。このような態度をどう扱うか？
1on1で話す場を作って、
- 今のスプリントプランニングをどう思う？
- なぜムダだと思うの？
- どうしたらいいと思う？
を聴きながらどうすればいいかを一緒に考えるかなー。
## スタンドアップやデイリースクラムについて
### 26. チームのサイズや経験度合いに関わらず全部のチームにスタンドアップを薦めるか？
わりと薦めるかも！
別の手段で目的を達成できれば必要ないけど、定期的かつ短時間で顔を合わせる場があることはそこそこ強力だと思ってます。
もちろん制約が強い（サイズが大きい、経験度が低いなど）場合は、スタンドアップの目的を絞ったり期待値はぐっと下げます。
### 27. なにか困っていることの助けが必要なとき次のスタンドアップまで待つことを期待するか？
全然期待していません。相談したいなって思ったタイミングで相談して、適切な対処ができるチームのほうがステキだよね。
待ってでも言おうとしてくれている分「話す場がなくて言えない」状態よりはマシだけど、スタンドアップやふりかえり待ちになってしまっていると気づいたこと自体が改善チャーーーンスですね。
### 28. スタンドアップをリードして単なるメンバーに対する報告セッションにしてしまうような人をどのように扱うか？
スタンドアップの目的をみんなで確認するかな。報告ってそれ自体はそれほど重要じゃないことが多い（カンバンとか見ればいいよね）ので、目的と手段が合っているかを話し合う場をつくるかも。
なかなか報告癖が抜けない場合は、報告自体を一切やらないスタンドアップをしばらくやってみる。それでみんな困らなければそれでいいよねー！
### 29. スタンドアップが無駄だと思っていて遅刻して来たり協力的でなかったりもしくは出席すらしないような人をどのように扱うか？
相手の話（理由）を聴く、目的や意図を理解してもらう。
その上で気持ちが変わらないなら、
「どうしたら参加してくれるか」
「どうしても参加してくれないとしたら、スタンドアップの目的を別の方法でどうやって拾えばいいか」
を一緒に考えてもらうかなー。
で、それをチームに提案しましょうという流れに持っていく。
あとはチームにいたくないということであれば、然るべきポジション（マネージャーなど）に相談して対応を任せたほうがよさそう。
### 30. スクラムチームのスタンドアップにステークホルダーは誰も参加していない。この状況をどのように変えるか？
いなくても大丈夫！
スクラムチームのためのスタンドアップなので、参加したいなら参加してもらっていいけれど邪魔をしたり少しでもチームが余計な気をまわしてしまうなら抜けてもらう（ということを説明して理解してもらう）かなー
### 31. 分散チーム間のスタンドアップをどのように進めるか？
スタンドアップに限った話ではないですが、同じ拠点に複数人いる場合でもリモートメンバーがいる場合は全員オンラインツールにつないで行います。なぜなら参加者全員のコミュニケーション機会が平等であることがとでも重要だからです。
複数人いる○○拠点のメンバーだけで話が盛り上がって、リモートメンバーが置いてけぼりになるような自体を極力避けたいですよねー！
### 32. スクラムチーム用の物理カンバンボードをいま書いてください
こんな感じかなー
チームの手で使いやすいように少しずつカスタマイズしていくのが好きなので、最初は一番オーソドックスなやつからはじめることが多いかな。
## ふりかえりについて
### 33. だれがふりかえりに参加してよいか？チームだけか？プロダクトオーナーも参加してよいか？
なるべくチームメンバー全員（もちろんプロダクトオーナーも含む）でやりたいなー！
別の目的があって違うサイクルで個別にチームだけでふりかえりをするとかは必要あればやるけれど、全体のふりかえりは全員で進めたいかな。
### 34. チームが健全な状態かをふりかえりの中で確認するか？それとも不要か？もし必要だとするとどうやって確認するか？
ふりかえりに限らず常に気にするけれど、特にふりかえりはチームの状態が表れやすいと思います。だから当然確認します。
ふりかえりの内容自体から読み取れることも多いし、雑談や対話の様子、表情や取り組む姿勢、笑いの数などたくさんの情報がそこにはあります。
ハピネスメトリクス・ニコニコカレンダー・Fist to Five（Five Fingers）など、見える化して状態を確認する方法もありますが、よいチームを能動的につくりたい人は日頃から人間観察を習慣化しておくのがよさそう。
### 35. 過去に使ったふりかえりのフォーマットはどんなものか？
覚えている限りで、KPT、YWT、タイムライン、Fun Done Learn、Fun Learn、チームレーダーチャート、6 Thinking Hats、ドラッガー式ふりかえり、ロールプレイングふりかえり、雑談とかかなー！
※オリジナル含む
https://agile-monster.com/blog/fun-done-learn-report/
https://agile-monster.com/blog/role-playing-retrospective/
### 36. どうやってマンネリを防いでいるか？
あんまりマンネリ化したと感じる経験ないのでわかりませんが、自分自身が人よりも飽きっぽい自信があるので飽きるような状態にならないようにしているかも。
- 飽きそうだったらいったん辞めてどうなるか試してみる
- 毎回同じ方法を続けることにこだわらない
- 雑談の時間を増やす
- 楽しくやることを優先する
とかはよくやっていると思います。
### 37. チームはいつも妥当なアクションアイテムを選んではいるものの、実際に行動できていない。この悪しき習慣をどう扱うか？
あるあるだけど、行動できていないってことは「妥当」じゃないんじゃないかな？チームの課題の優先順位としては妥当かもしれないけれど、やることが具体的でないとか、サイズ感が大きいとか、実現可能性が低いとか。
経験上、どんなに小さくてもいいので成功体験を積み上げていくことがなによりチームの自信につながるので、とことんアクションアイテムのハードルを下げてクリアし続ける状態からはじめることが多いです。
あとはそれでもダメな時は、「なぜ実現できなかったのか」を毎回チームでふりかえって原因分析して都度対策を打っていくこともよい習慣ですね。
人間なので忘れてしまうことはあるので、アクションアイテムはスプリントバックログアイテムとして扱うとか、カンバンの近くにアクションアイテムを常に貼り出してスタンドアップで確認する、などそういう工夫はします。
### 38. どうやってアクションアイテムのフォローアップを薦めるか？
37でほとんど書いたかな。
あと、「実現したこと」や「できなかったこと」は記録は残すことが合っても管理したり継続ウォッチはしないようにするかな。また同じ繰り返し課題が出てきたとしても、それ自体がチームの状態を表す情報なのでそれでいいと思っています。どんどん溜まっていくことで、「やらなきゃいけない」「全然できていない」というどんよりした気持ちになってしまうのでイヤだなー。管理したいわけじゃないしね！
---
# 斜に構える・構えないを切り替えるロールプレイングふりかえり
URL: https://agile-monster.com/blog/role-playing-retrospective/
Published: 2019-03-29
---
この記事を見てすごくおもしろいなーと思ったので、さっそく試してみました。
https://dailyportalz.jp/kiji/sya_ni_kamaeru-kamaenai
## FYI : 所謂「斜に構える」は誤用
この記事をきっかけに「斜に構える」の語源について調べてみました。
>
>
> １. 剣道で、刀を斜めに構える。
>
>
>
> ２. 身構える。改まった態度をする。
>
>
>
> ３. 物事に正対しないで、皮肉やからかいなどの態度で臨む。
>
> [斜に構える - コトバンク](https://kotobank.jp/word/%E6%96%9C%E3%81%AB%E6%A7%8B%E3%81%88%E3%82%8B-524336)
>
普段使っている「斜に構える」は 3 のイメージが強いが、実はこれは誤用が定着してしまったもので、本来は 2 の意味らしいです。
※参考記事は現在アクセスできなくなっています（[アーカイブ](https://web.archive.org/web/20190131155842/https://usable-idioms.com/1542)）。
まあでも誤用の方が一般的なので、エイリアスはそのままにしておきます。
## ロールプレイングふりかえり
今回はモブプログラミングのワークショップの後に、その日の学びをふりかえる場で行いました（画像はその時の資料）。
やることはシンプルで、ヒール（斜に構える）とベビーフェイス（斜に構えない）になりきって話し合いをしてもらうだけです。
### 1.斜にかまえて話し合う（5分）
まずは敢えて**斜に構えて**話し合いをします。大事なことは振り切ることです。ロールプレイなので、ヒールになったつもりで最大限にひねくれてみましょう。
話し合った内容のポイントは付箋やホワイトボードに残してもらうと、後で思い出せるのでよいです。
### 2.斜にかまえずに話し合う（5分）
次に今度は敢えて**斜に構えずに**話し合います。先程と真逆で、ベビーフェイスになったつもりで最大限にポジティブになりましょう。
### 3.現場に持ち帰るもの3つ選ぶ（5分）
最後はどんなやり方でもいいですが、ロールプレイをやめてフラットな気持ちで話し合ってもらいます。
## ロールプレイングふりかえりのよいところ
人によって無意識のうちに、
- どちらかというと斜に構えて考えがち
- どちらかというと斜に構えずに考えがち-
という傾向があると思います。どちらがいい・悪いではなく、それぞれよいところ・いまいちなところがあります。
よいところいまいちなところ斜に構える・冷静に判断できる
・現実的に考えられる・排他的／否定的
・行動につながりにくい
・雰囲気が悪くなりやすい
斜に構えない・話が盛り上がる
・前向きな想像ができる
・雰囲気が明るくなる
・軽率な判断をしがち
・悪ノリしやすい
・逆にいらっとされることも
ロールプレイングをふりかえりに取り込むことで、本人の傾向に関係なく多角的な視点でものごとをとらえることができるのが素晴らしいと感じました。個人やチームのバイアスに依存することなく、効果的なふりかえりをしたい時によいプラクティスかもしれません。
実際に「モブプログラミング」を題材にしたときには、
- ヒール（斜に構える）
ケンカになりそう- 効率が悪くてイライラすることがありそう- 自分でやりたくなってしまう
- ベビーフェイス（斜に構えない）
チームの状態が見えることがよい- チームで仕事をする喜びを感じられる- ハマったりうまくいかない時間すら楽しい
というような話し合いが起こり、その後の時間では、
- 人によって感じ方は違いそうだから配慮が必要
- 普段イライラしないのはその問題を見ないようにしてるだけかも
- 効率が悪いって感じるのは思い込みだからまずは現場でやってみたい
- 「自分がやった方が早い」は危険な兆候なのでむしろモブプロで解消していきたい
というどちらの結果からもインスピレーションを受けたような話し合いが起きていました。素晴らしい！！
## Thinking Hats Retrospective
似たようなロールプレイングふりかえりとして、Thinking Hats Retrospectiveというプラクティスがあります。
やることはあまり変わりません。例えば10分ずつなど時間を区切って、それぞれの時間では決まった色の帽子をかぶります（実際にかぶるかどうかは別）。その時間にかぶっている帽子に関する話し合いに集中します。違う帽子をかぶっている人がいたときはファシリテーターが止めます。
- 白…事実と数字
- 黄色…肯定的思想
- 黒…批判的思想
- 緑…問題解決
このプラクティスは「モブプログラミング・ベストプラクティス」でも紹介されています。
[itemlink post_id="2325"]
こちらも英語だけどご参考までに。
http://retrospectivewiki.org/index.php?title=6_Thinking_Hats_Retrospective
## ふりかえりは自由だ
いかなる状況でもこの方法がベストだというふりかえりは存在しません。参加者・対象・タイミング・環境など、いろんな要因でベターなやり方は変わります。同じ方法をとっても、うまくいくときもあればうまくいかないときもあります。
「同じ方法を極めるのがよい」
「状況に応じていろんな方法を使える方がよい」
別にどっちでもいいのでうまくいくならなんでもいいんじゃないでしょうか。
ふりかえりは自由だ！
https://agile-monster.com/blog/fun-done-learn-report/
https://hurikaeri.booth.pm/items/1076615
[itemlink post_id="2399"]
[itemlink post_id="2400"]
---
# Head Firstモブプログラミング #agilesapporo
URL: https://agile-monster.com/blog/head-first-mobprogramming/
Published: 2019-03-18
---
Agile Japan 2018(年度) サテライト<札幌>にて、モブプログラミングワークショップをしました。モブプロ本発売後はじめてのワークショップだったので、モブプロ本に合わせて導入資料をつくりました。
https://agilesapporo.doorkeeper.jp/events/87408
[itemlink post_id="2325"]
## 資料
これからモブプログラミングワークショップを体験する人向けの説明資料として作ったので、皆さんが会社やイベントでやってみるときにお使いいただけるかもしれません。許可は必要ないのでお好きにご使用下さい（感想とか使ったことをTweetしてくださると喜びます）
本の内容に則してワーディングも合わせているので、合わせてご購入いただければ幸いです。
## 理想的なモビング環境
私のチームでは日常的にモビングをしているんですが、今回の資料作成にあたって理想的なモビング環境について話したものを図にまとめてみました。
ワークショップの準備の際の参考にしていただきたいのもそうですが、現場で本格的に導入する際におねだりできるように資料に入れておきました。
こんな環境でモビングできたらすごくいい仕事ができそうですね！
## モブプログラミングはいいぞ！
モブプログラミングワークショップは何度もやってきたんですが、何度やってもこの場が大好きです。
https://twitter.com/nemorine/status/1106778266919006208
現場でコードを書いている人、久しぶりに書く人、ほとんど書いたことない人…いろんな参加者がいます。普段一緒に働いていない人たちで即席チームをつくり、あまり触ったことがない言語を選択しても、しばらくすると仕事が進んでいきます。最初の立ち上がりに苦労するチームはありますが、だいたい30〜60分経つとどのチームも仕事をしています。
https://twitter.com/ytk250/status/1106778728229531648
皆さんマジメなのでワークショップが終わった頃に、
「○○ができなかったー」
「もっとこうしたかったー」
と悔しさを口走っていることが多いのですが、こんな条件下で、
- そこそこ動くプロダクトができていて
- 仕事の進め方を何度か変えていて
- 悔しがれるほど仕事に集中できている
ってスゴくないですか？
https://twitter.com/TAKAKING22/status/1106835879195107328
今回のワークショップのふりかえりで、最＆高のメッセージを見つけました。
**「笑いながらソース（プロダクト）が完成」**
やっぱりプロダクトづくりって最＆高です。
モブプログラミングを現場で導入するかどうかはともかく、モブプログラミングで得た学びを普段の仕事に活かして、笑いながら仕事ができるといいですね。
参加して下さった皆さん、運営の皆さん、本当にありがとうございました！！
講演やワークショップなどのご相談はこちらからどうぞ。
https://agile-monster.com/contact/
---
# わかった気にならずに原典を読む「スクラムガイド」モブリーディング
URL: https://agile-monster.com/blog/scrumguide-mobreading/
Published: 2019-03-07
---
スクラムガイド2017年版
スクラムの原典である「スクラムガイド」。
最近、Unlearn（学びほぐし）のためにチームでスクラムガイドをモブリーディングしています。昔読んだことがあっても、改訂されて内容がアップデートされていたり、経験に合わせて読む度に違う気づきがあるのでけっこう面白いです。
https://scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Japanese.pdf
ちなみにこんなこともやってみました。
https://agile-monster.com/blog/scrumguide-textmining/
## 「スクラムガイド」モブリーディングとは
文字通りチームで「スクラムガイド」を読むだけです。
個々に読むのもいいですが、ふだん働いているチームで雑談しながら読み合わせをしたかったので、モビングスタイルで読みました。全員で同じ画面を見ながら輪読し、気になったところや分かりづらいところは「ああでもない」「こうでもない」と議論をしながら読み進めていきます。
スクラムガイドはとても短くまとまっているところが素晴らしいです。どれだけじっくり読むかによりますが、そこそこ議論をしながらすべて読み合わせをするのに、2回に分けて合計2時間程度で終わりました。見積もりのご参考までに。
モビングについて学びだければ、こんな素晴らしい本が出たそうですよ！
https://agile-monster.com/blog/mobpro-bestpractice/
## 「スクラムガイド」で面白かったところ
今回モブリーディングをして、改めて面白かったところをご紹介します。
### スクラムの定義
>
>
> スクラムとは、以下のようなものである。
> • 軽量
> • 理解が容易
> • 習得は困難
>
> スクラムガイド2017年版 - スクラムの定義
え、ほんとに！？
なんとなく反対の印象だなー。
### スクラムの理論
>
>
> 透明性
>
>
>
> 経験的プロセスで重要なのは、結果責任を持つ者に対して見える化されていることである。
>
>
>
> 透明性とは、こうしたことが標準化され、見ている人が共通理解を持つことである。
>
> スクラムガイド2017年版 - スクラムの理論
結果責任を持つ者＝チームなんだろうな。
改めてスクラムガイドを読むと、透明性についてうるさいくらいに言及されているんだなって気づいた。スクラムガイドの中で「透明」という単語は22回出てくる。
### スクラムチーム
>
>
> プロダクトオーナーは 1 人の人間であり、委員会ではない。委員会の要求をプロダクトバックログに反映することもあるだろうが、プロダクトバックログアイテムの優先順位の変更については、プロダクトオーナーと相談しなければいけない。
>
> スクラムガイド2017年版 - プロダクトオーナー
プロダクトオーナーは1人の人間だって明確に言っているのが面白い。
>
>
> 開発チームには、以下のような特徴がある。
> • 自己組織化されている。プロダクトバックログをリリース判断可能な機能のインクリメントに変える方法は、誰も（スクラムマスターでさえも）教えてくれない。
> • 機能横断的である。インクリメントを作成するスキルをチームとしてすべて備えている。
> • ある人にしかできない作業があったとしても、スクラムにおける開発チームのメンバーに肩書きはない。
> • テスティング、アーキテクチャ、運用、ビジネス分析のような専門領域であっても、スクラムは開発チームのサブチームを認めていない。
> • 開発チームのメンバーに専門能力や専門分野があったとしても、最終的な責任は開発チーム全体が持つ。
>
> スクラムガイド2017年版 - 開発チーム
スクラムでは、肩書きやサブチームは存在しない。そして、インクリメントを作成するスキルをチームとしてすべて備えているということなので、「アプリチーム」「テストチーム」「インフラチーム」みたいな分け方をしないってことが明記されているんだね。
>
>
> • スクラムチームの全員がゴール、スコープ、プロダクトのドメインを可能な限り理解できるようにする。
>
>
> スクラムガイド2017年版 - スクラムマスター
2017年版で追記された項目。スクラムチームの全員（開発チームもPOもSMも）が可能な限り理解している、そうじゃなくても理解しようとしていたいよね。
### デイリースクラム
>
>
> デイリースクラムは開発チームのためのミーティングである。それ以外の人たちが参加する場合、開発チームの邪魔にならないようにスクラムマスターが配慮する。
>
> スクラムガイド2017年版 - デイリースクラム
そうそう、開発チームのための時間なんだよねー。
### スプリントレビュー
>
>
> スプリントレビューには、以下の要素が含まれる。
> • 参加者は、スクラムチームとプロダクトオーナーが招待した重要なステークホルダーである。
> • プロダクトオーナーは、プロダクトバックログアイテムの「完成」したものと「完成」していないものについて説明する。
> • 開発チームは、スプリントでうまくいったこと、直面した問題点、それをどのように解決したかを議論する。
> • 開発チームは、「完成」したものをデモして、インクリメントに対する質問に答える。「完成」の定義にプロダクト機能のリリースが含まれていれば、それらを表示してレビューしてもらう。
> • プロダクトオーナーは、現在のプロダクトバックログの状況を説明する。（必要であれば）現在の進捗から、可能性のある目標とデリバリーの日程を予測する。
> • グループ全体で次に何をするべきかを議論し、次のスプリントプランニングに価値のあるインプットを提供できるようにする。
> • 市場やプロダクトの利用状況によって、次に行うべき最も価値の高いことが変更される可能性をレビューする。
> • 次にリリースするプロダクトの機能や性能のスケジュール・予算・可能性・市場をレビューする。
>
> スクラムガイド2017年版 - スプリントレビュー
スプリントレビューってレビュワーとレビュイーみたいにくっきり分かれている場ではなくて、スクラムチーム全員で自分たちがやった最＆高の仕事を誇る場なんだなー！
### スプリントレトロスペクティブ
>
>
> スクラムマスターは、次のスプリントが効果的で楽しいものになるように、開発チームにスクラムプロセスフレームワークの範囲内で開発プロセスやプラクティスを改善してもらう
>
> スクラムガイド2017年版 - スプリントレトロスペクティブ
ちなみに英語だと「make it more effective and **enjoyable** for the next Sprint」
スクラムガイドに「楽しい」という言葉が入っていることにはじめて気づいた！
### プロダクトバックログ
>
>
> プロダクトが存在する限り、プロダクトバックログも存在し続けるのである
>
> スクラムガイド2017年版 - プロダクトバックログ
なんかかっこいい！！
### スプリントバックログ
>
>
> 継続的改善を確実なものとするために、前回のレトロスペクティブで特定した優先順位の高いプロセスの改善策を少なくとも 1 つは含めておく
>
> スクラムガイド2017年度版 - スプリントバックログ
ここは2017年度版で追記された部分で、スプリントバックログに改善アクションを「少なくとも」1つ入れることが明記されている。
スクラムはプロダクトだけでなくチームや作業環境を継続的に改善していくことを謳っているので、ただプロダクトバックログを消化しているだけにならないように明記したのかな。「スプリントバックログは開発チームのもの」なので、チームが裁量をもって取り組むものだよってメッセージも感じる。
### 作成物の透明性
>
>
> スクラムマスターは、作成物の検査、パターンの察知、言説の傾聴、期待値と実際値の違いを把握することで、不完全な透明性を検知できる。
> スクラムマスターの仕事は、スクラムチームや組織と一緒になって、作成物の透明性を向上させることである。この仕事には、学習・説得・変化を伴うことが多い。
>
> スクラムガイド2017年度版 - 作成物の透明性
ほー！
>
>
> 透明性は一夜にしてならず。透明性とは長い道のりなのである。
>
> スクラムガイド2017年度版 - 作成物の透明性
かっこいい！！
### 最後に
>
>
> スクラムは無料であり、本ガイドで提供されるものである。スクラムの役割・イベント・作成物・ルールは不変である。スクラムの一部だけを導入することも可能だが、それはスクラムとは言えない。すべてをまとめたものがスクラムであり、その他の技法・方法論・プラクティスのコンテナとして機能する。
>
> スクラムガイド2017年度版 - 最後に
そうなんだー。
これに則って考えると、「自分たちはスクラムをやっている」と言える人はかなり少なそう。
### スクラムガイド 2016 年版と 2017 年版の変更点
変更点を見ていると、
- スクラムがどう変化しているのか
- みんなが困りやすい点がどこなのか
とかそういうコンテキストを想像できて楽しいです。
## 感想
スクラムってめんどくさい。
すごくいいこと書いてあるし、たくさん学ばせてもらっているけれど、「こうしないとダメだ」「これがないとスクラムではない」みたいな説明はあんまり好きじゃないなーって個人的には思いました。
## モブリーディングのススメ
個人で読んでいるときは流して読んでいるところも、チームで読むことで新たな気づきをたくさん得られて面白かったです。チームでは、スクラムガイド以外に公開されているスライドや技術要素の公式ドキュメントをモブリーディングしています。
同じものを読んでも、誰と読むかで得られる学びがぜんぜん違うし、少し経験を積んでからまた読んでも視点が変わっているから学びがあると感じました。
スクラムガイドは、実践者や色んな人がモブリーディングをしながら議論をしているのを、遠巻きに眺める場とか面白そうだと思いました。
面白そうだと思ったら、ぜひやってみてください！
---
# スクラムの原典「スクラムガイド」をテキストマイニングにかけてみた
URL: https://agile-monster.com/blog/scrumguide-textmining/
Published: 2019-03-05
---
スクラムガイド2017年版
スクラムの原典である「スクラムガイド」。
最近、Unlearn（学びほぐし）のためにチームでスクラムガイドをモブリーディングしています。昔読んだことがあっても、改訂されて内容がアップデートされていたり、経験に合わせて読む度に違う気づきがあるのでけっこう面白いです。
スライドや本を読むのもステキだけど、原典が無料で公開されていて、おまけに素晴らしい日本語訳で読むことができるので、定期的にスクラムチームで読み合わせするのはものすごくよさそう。
https://scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Japanese.pdf
## スクラムガイドをテキストマイニング
興味本位でテキストマイニングにかけてみました。結果はこんな感じ。
ワードクラウド
二次元マップ
二次元マップは、こんな感じ。
>
>
> 文章中での出現傾向が似た単語ほど近く、似ていない単語ほど遠く配置されています。距離が近い単語は色分けして、グループにまとめています。
>
>
なぜかプロダクトがすごく遠くにあるのが面白いなー！
出現頻度
名詞はもうちょっと辞書登録とかすると結果が変わりそうだけど、動詞や形容詞が面白い。なんとなくポジティブなワードが多い印象。
※以前は結果ページのURLを貼っていたのですが、公開期限が切れてしまったようなのでスクリーンショットで紹介しています。この他にも共起ネットワークなどの結果もあって面白かったです。
今回は楽をさせていただいて、以下のWebツールを使わせていただきました。
http://social.userlocal.jp/document/textmining_faq
データは以下の下処理をしただけです。
- スクラムガイド2017年版（日本語）をテキストに起こす
- 改行を削除（文章の途中で切れてしまっている箇所が複数あるため）
- ページ番号やクレジット情報を削除
心の声：専門用語（スクラムマスター、スプリントバックログなど）を辞書登録したらもうちょっと違う結果になるだろうし、データ分析の練習におもしろそうな題材だなー
結果の精度はともかくとして、内容を真正面から受け取るだけでなく、
「こんな単語がよく使われているんだな」
「こんな傾向があるんだな」
「こんな関連があるんだな」
という違う角度からものごとを見ることはそれはそれで面白いな、と改めて思いました。
ぜひ、ご参考に！
## 追記：英語版の場合の結果も気になったのでやってみました
ワードクラウド
二次元マップ
残念ながら英語対応されていないようで、単語の品詞まで判別されていないので、そこは評価できてなさそう。
---
# 身も蓋もない事実に向き合うこと「でも、やるんだよ」
URL: https://agile-monster.com/blog/demo-yarundayo/
Published: 2019-02-27
---
手強い壁にぶつかることがあります。
- この技術は素晴らしいけれど今の自分達には手に負えなそう
- どう考えてもイケてないプロダクトバックログ
- いいチームだけど生産力が乏しい
- 技術がわからないマネージャー
そんな時にどうすればいいのだろうか。
## やれることをやる
「やれることをやる」は正攻法です。
手強い壁を前にして立ち往生してしまうのではなく、抜け道がないのか、壁を迂回する方法はないのか、自分達にやれることを探してアクションをする。
- この技術は素晴らしいけれど今の自分達には手に負えなそう
⇨実績のない技術を回避して自分達が知っている技術で解決する
- どう考えてもイケてないプロダクトバックログ
⇨とりあえず自分達の仕事を完遂させて信頼貯金を貯める
- いいチームだけど生産力が乏しい
⇨チームのベロシティに合わせて計画をする
- 技術がわからないマネージャー
⇨粘り強くコミュニケーションしてわかってもらう
このようなアプローチは、まわりからの信頼も得られやすいです。
## 真正面からぶつかる
一方で、もし真正面からぶつかって壁を取り除くことができれば最短の道でゴールへ向かうことができます。
- この技術は素晴らしいけれど今の自分達には手に負えなそう
⇨技術を習得して解決する
- どう考えてもイケてないプロダクトバックログ
⇨イケてないプロダクトバックログはやらない
- いいチームだけど生産力が乏しい
⇨チームの技術力を向上する
- 技術がわからないマネージャー
⇨ボトルネックを取り除く
もしこれらが可能であれば、一度解決したら二度と起こらない、あるいは同じような壁が現れても再び最短の道を選択することが可能になります。
## 身も蓋もない事実に向き合うこと
なぜ急にこんなことを書いたのかと言うと、最近は時には「真正面からぶつかる」ことで身も蓋もないものに向き合うことも大切だと感じることが多くなったからです。
「やれることをやる」は一見万能に見えますが、
- 問題の本質から逃げている
- その場しのぎで短期的な問題解決
- とりあえず頑張ることの奨励
と言い換えることもできてしまいます。
自分達の持ち玉だけで開発していたらジリ貧になるし、イケてないプロダクトを真面目に作っていたところでビジネスが潰れたらすべてがムダになるし、どれだけ良いチームを作ったところでコードが書けなければ仕事はまわらないし、技術がわからないマネージャーと粘り強くコミュニケーションしても1円も儲かりません。
目を覆いたくなるようなことばかりですが、こうした身も蓋もない事実から逃げてばかりではいけません。
「やれることをやる」と「真正面からぶつかる」はどちらが正しい／間違っていると割り切れるものではなく、同時に向き合い続けていかなくてはいけないものです。
## でも、やるんだよ
人生の時間にも限りがあるので、投資判断だと思っています。
「まずはやるべきことをやろう」
「やれることをやろう」
「とりあえず頑張ろう」
は素晴らしいと思いますが、同時に自分が取り組むべきイシューの選球眼を磨いていかないと、気付いた時には体力も精神力も衰えてしまっているかもしれません。
身も蓋もない事実かもしれない。
でも、やるんだよ。
[itemlink post_id="2444"]
---
# 子どもの心理的安全性について考える本「ちゃんと泣ける子に育てよう」を読んだ
URL: https://agile-monster.com/blog/nakeruko-ni-sodateyou/
Published: 2019-02-20
---
子供が生まれたこともあって育児書を何冊か読んでみたけれど、この本が圧倒的によかったです。
[itemlink post_id="2318"]
## はじめに
>
>
> 親には子どもの感情を育てる義務があります。
>
>
>
> それは子どもを産んだ以上、義務です。
>
>
>
> 義務は強い言葉ですが、あえてそう言おうと思いました。
>
>
>
> 義務を果たすためには、親が親として覚悟を決める必要があります。
>
>
>
> 親として子どもを愛する、という覚悟です。
>
>
>
> これは当たり前のことのようですが、実はとてもむずかしい。
>
>
>
> 親を癒してくれる存在として、子どもを愛している場合や、親の自尊心を満たすために、子どもを愛している場合には、 義務を果たせないからです。
>
>
という「はじめに」からこの本が始まります。
- 親を癒してくれる存在として子どもを愛している場合
- 親の自尊心を満たすために子どもを愛している場合
ってものすごく胸に残る言葉ですね。
## 「優しい子に育ってほしい」というプレッシャー
どんな親でも持ってしまいがちな「優しい子に育ってほしい」「思いやりのある子に育ってほしい」という想い。そんな親の想いが、子どもにプレッシャーをかけてしまう可能性があるそうです。
親が「優しい子に育ってほしい」「思いやりのある子に育ってほしい」という想いを持つのは、「優しい大人に育ってほしい」「思いやりのある大人に育ってほしい」という意味のはずです。
この時に、そういう大人になるためはまだ心も身体も成長過程の子どもの頃から大人になるまでずっと「やさしい子」「思いやりのある子」でいてもらわなければいけないという誤解を持ってしまいがちです。
子どもは一番近くにいる親の期待に応えたいと思ってくれるもので、このプレッシャーをダイレクトに受けてしまいます。
## 感情を育てる義務
本のタイトルにもなっている、「泣ける子に育てる」「感情を育てる」という言葉。子どもが感情を育んでいくためには、親が子どもの感情を受け入れながら、言葉として教えてあげる必要があります。
嬉しいときや楽しいときだけでなく、ネガティブな感情のときこそ受け入れてあげる必要があります。
悲しいときは「悲しいねえ」と抱きしめてあげる。
悔しいときは「悔しかったねえ」と抱きしめてあげる。
そうすることで、子どもは自分が抱いている感情を言葉として理解することができるようになります。
一方でその時に、「それくらいで泣くんじゃない！」などと親の理想を押し付けてしまうと、感情のエネルギーを発散できずに子どもが溜め込んでしまうことになります。
## 子どもの心理的安全性
この本を読んで、自分自身は「子どもを育てる」という素晴らしい子どもを子どもにさせてもらっているので、彼が安心して感情を育むことができる心理的に安全な家庭を用意してあげたいなと思いました。
親が「良い子に育ってほしい」と思いたくなる気持ちはわかりますが、自分自身も親としてまだまだ新人なので高望みはせずにそこから始めることにします。
子どもの成長はすごいので、彼に負けないように親として成長していこうと思います。
---
# まわりに迷惑をかけない！シャッター音を消せるカメラアプリ【Android／iOS】
URL: https://agile-monster.com/blog/no-more-shutter-sound/
Published: 2019-02-15
---
カンファレンスなどに参加していて、講演中にうつされているスライドを撮影したくなることがあります。
最近は司会者の方が「シャッター音にご注意下さい」などと注意喚起をしたり、講演者が「スライドは公開するので撮影しなくても大丈夫です」なんてアナウンスをしてくれたりするのですが、そんなことおかまいなくスライドが切り替わるたびにシャッター音が会場に鳴り響いています。
知っていて敢えてやっている人はどうでもいいのですが、解決策を知らない人もいるかも知れないと思ったので、シャッター音をさせないで撮影する方法を紹介したいと思います。
## シャッター音無音アプリ
スマホにデフォルトでついているカメラアプリは、たいていの場合シャッター音が鳴るように設定されています。そしてシャッター音を消すことができないようになっていることが多いです（おそらく防犯を考えての仕様）。
そこでシャッター音を消すことができるカメラアプリを使用することをおすすめします。検索すればたくさん選択肢はあるのでお好きなものを使えばいいと思いますが、OSごとにおすすめのアプリをご紹介します。
### 【Android】シャッター音無音アプリ
#### LINE Camera
設定からシャッター音をオフにできます。
https://play.google.com/store/apps/details?id=jp.naver.linecamera.android
### 【iOS】シャッター音無音アプリ
#### Microsoft Pix
デフォルトの設定がシャッター音オフになっている模様（すばらしい）。
https://apps.apple.com/jp/app/microsoft-pix-%E3%82%AB%E3%83%A1%E3%83%A9/id1127910488
#### LINE Camera
iPhoneの場合は設定ではなく、本体の設定をマナーモードにしておけばシャッター音が消えるそう。
https://apps.apple.com/jp/app/id516561342
## さいごに
「これくらいいいだろう」って思ってシャッター音を鳴らしてしまいがちですが、同じようなことを考えている人が会場にいると、スライドが切り替わるたびに「カシャ」音が至るところから鳴り響くことになります。講演に集中したい人がいるとしたらどう思うでしょうか。
自分は気にならないとしても、それが他人に受け入れられるかどうかは別問題です。シャッター音を鳴らすことに強いこだわりがあるのであれば別ですが、これくらいの手間で解決できることであれば迷惑をかけない行動をする大人になりたいと思いました。
---
# Fun Done Learnをしばらく運用してみた #ふりかえり
URL: https://agile-monster.com/blog/fun-done-learn-report/
Published: 2019-01-30
---
Fun Done Learnをしばらくチームで運用してみたのでご紹介します。
## Fun Done Learnとは
Fun Done Learnはふりかえり手法の1つです。詳しくは以下を御覧ください。
https://yattom.hatenablog.com/entries/2018/10/31
やり方に正解はないので各々でやりやすい方法を見出していけばよいですが、
- アウトプットの時間：Fun Done Learnを意識せずにとにかくやったことを付箋に書き出す
- マッピングの時間：付箋をどこに貼るか話し合いながらマッピングする
のように、アウトプットの時間とマッピングの時間を区切ることがコツだな、としばらくやってみて思いました。「マッピングのことを考えながらアウトプットする」など2つのことを同時に進めるのは人間には難しいので、1つのことに集中できるように進めることをおすすめします。
## モブチームのFun Done Learn
### タイミング
自分のチームでは、だいたい以下のようなリズムで働いています。
※「Art」や「Science」が気になると思いますが、それについては後述します
1日の最後のふりかえりの時間として、Fun Done Learnをはじめました。
### 進め方
以下のような流れとタイムスケジュールでFun Done Learnをしています。
#### 1. やったことを付箋に書き出す（5分）
自分のチームでは日常的にモブワーク（全員で一緒に仕事をする）をしているので、個人ワークではなくチーム全員でその日やったことを思い出しながらとにかく付箋に書き出します。
#### 2. Fun Done Learnにマッピングしながら雑談する（5分）
書き出した付箋を、マッピングしながら雑談します。いや、雑談しながらマッピングします。付箋（やったこと）を1枚取って、どんなFunやLearnがあったのかを話しながらマッピングしていくと進めやすいです。
ex. 楽しかったけど学びはなかった場合は、FunとDoneの間に貼る
ex. やったけどFunもLearnもない場合は、Doneに貼る
#### 3. 雑談する（20分）
残りの時間はだいたい雑談しています。Fun Done Learnの結果を見ながら、
「今日はDoneばっかだねー」
「もっとFunとLearnを増やしたいねー」
「これって実はこういう学びがあったんじゃない？」
「いやー、学びしかない！楽しみしかない！」
などの会話が生まれます。
#### 4. 結果をチームチャットに貼る（1分）
最後に結果を写真に撮ってチームチャットのFun Done Learnチャンネルに貼ります。本当は壁にどんどん張り出していきたいのですが、残念ながら場所がないのでチャットで我慢しています。
とある日のチームのFun Done Learn
### きっかけ
前述の通り、自分のチームでは日常的にモブワークをしています。
https://agile-monster.com/blog/mobprogramming-as-work-style-reform/
そのため、
- お互いのやっていることを共有することは不要
- 問題が発生した時点で話し合って適切なタイミングで解決している
という理由から、一般的な「ふりかえり」はやらなくなりました。
ところが先日のRegional Scrum Gathering2019でのkyonmmのプレゼンをきっかけに、Fun Done Learnによるふりかえりを試しにやってみることにしました。
具体的には、Krebs CycleやKPT as Artのところに共感しました。
前述のスケジュールで、Art TimeやScience Sessionという名付けをしたのはここからインスプレーションを受けています。
### Fun Done Learnの目的
自分のチームではArtの時間としてFun Done Learnをしています。
Art = Behavior（ふるまい）をInformation（情報）にするためのふりかえりなので、1日の活動をFun Done Learnという情報にすることを唯一の目的にしています。
したがって、問題発見・問題解決・相互理解など一般的な「ふりかえり」で目的にしがちなところは目的としていません。なぜかというと、自分たちの場合はそれらは日常的に行っていることなので時間軸が合わないからです。
### Fun Done Learnをやってみて
自分たちにはとても合っているように感じました。
チームの活動内のFun（楽しさ）やLearn（学び）について日常的に話すようになりました。同じ体験をしても人によって感じることは違います。共通体験をつくることは重要ですが、共通体験をした結果なにを受け取ったかまで共有できるとさらに強力です。
自分はただDoneしただけだと思っていても、同じ体験をした別のチームメンバーが、
「これって学びじゃない？」
「こう考えると楽しかったよね」
という受け取り方をしていたとしたら、なんか得した気分になりますよね。学び方や楽しみ方のような暗黙知を共有できるきっかけになるような気がしました。
### Fun Done LearnからFun Learnへ
こんな感じで2週間ほどFun Done Learnをやってみた結果、自分たちのチームではDoneに情報量がないことに気づきました。
Fun（楽しさ）Learn（学び）の量を知ることが、自分たちにとっては情報なので、Fun Done LearnからFun Learnの二元軸に変化しました。
きっと今後も変化していくことでしょう。
## Fun Done Learnのすすめ
最後に自分たちでFun Done Learnをしばらく体験してみて感じたことを書きます。
- シンプル
やったことを分析するだけなのでシンプルです- 問題を分析したり解決したりする必要はありません
- ポジティブ
「Fun」や「Learn」などポジティブな話に集中できます
ふりかえりがうまくいかないという相談を受けることがよくありますが、大抵の場合「つめこみすぎ病」や「期待しすぎ病」にかかっている気がします。
コミュニケーション、相互理解、問題発見、問題解決など、ふりかえりの目的がもし2つ以上になっている場合はこうした病にかかっているかもしれません。2つ以上に増やすのは1つができるようになってからです。
極端な話、フレームワークに頼らずとも雑談できればそれでいい気もするし、ふりかえりが自然にチームの活動に溶け込んでいることが個人的には理想だなと思います。
そこまではちょっと遠い気がする場合、気楽にふりかえりをするのにFun Done Learnは非常に有効だと思いました。
[itemlink post_id="2400"]
[itemlink post_id="2399"]
---
# モブプログラミングの必読本「モブプログラミング・ベストプラクティス ソフトウェアの品質と生産性をチームで高める」
URL: https://agile-monster.com/blog/mobpro-bestpractice/
Published: 2019-01-28
---
2/23（土）に「モブプログラミング・ベストプラクティス ソフトウェアの品質と生産性をチームで高める」が発売します。すごく良い本なので良かったらお買い求め下さい。既に予約開始しているようなのでぜひご予約下さい。
[itemlink post_id="2325"]
## 解説しました
なんとありがたいことに、この本の解説文を書かせていただきました。
お話をいただいた時、正直なところ、
「原著者の方の名前は聞いたことないし本当に面白いのかなー」
「心の底からおすすめしたい本じゃないと解説は書けなそうだ」
などと思い、出版社の担当者の方にもその旨を伝えていました。
ところが読んでみて本当に面白かったので、心置きなく解説させていただきました。
今でもモブプログラミングをずっと現場でやっていて、いろんな場所で講演・研修・ワークショップをやってきて、「この本はモブプログラミングの必読本だ」と自信を持っておすすめできます。
## 内容について
章立ては以下です。
- 第1章 なぜモブプログラミングなのか
- 第2章 モビングの始め方
- 第3章 モビングと人
- 第4章 モビングの軌道修正
- 第5章 定期的なモビングのための仕事場の改造
- 第6章 モビングを定着させるためのチームへの働きかけ
- 第7章 フロー重視の考え方
- 第8章 モビング定着後の長期的な展望
本書は翻訳本ですが、現場への適応のさせ方を大事に書かれているので、あまり翻訳本であることを気にせずに読むことができると思います。
モブプログラミングのHow Toはもちろん、始めた後、始めてしばらく経った後、始めてしばらく経ってやらなくなってしまった時など、 様々なコンテキストでチームやその周囲で起こるであろうこととその時の対応について丁寧に書かれています。
自分もいつかモブプログラミングについての本を書いてみたい、と思っていましたが、「本を書くとしたら」を考えた時のほとんどがこの本で触れられていました。
## どんな方におすすめか
はじめての方、興味がある方にはもちろんおすすめです。
やったことのある方や今もやっている方も、「そうだよね」と読み進められるところと「なるほど」と新たな気づきを得られるところが両方共あるのでおすすめです。自分自身も読んでいて実際にパクったプラクティスやノウハウもありました。
一度やったけどやめてしまった・あきらめた方も、改めて読んでみると良いです。この本のステキポイントは、やめてしまった・ダレてしまったケースにも触れられていることです。いろんなところで同様の話を相談されたりするので、現場感がある人が書いてるんだな、と思いました。
そもそもあまりペアプロやモブプロのようなものが好きでない方にもおすすめします。「ペアプロやモブプロこそが正義だ」などと微塵も思っていませんが、やってみたり、本を読んで知ってみてからの皆さんのご意見をぜひお聞きしたいです。
よいモビングを！
（もっとはやく本を書けばよかった）
[itemlink post_id="2325"]
---
# チームでFA宣言します #転職
URL: https://agile-monster.com/blog/team-fa-declaration/
Published: 2019-01-28
---
>
>
> 本FA宣言はCLOSEしました
>
>
>
> たくさんのお声がけありがとうございました
>
>
## チームFA宣言とは
簡単にいうと、チームで転職活動をはじめました。当然プロ野球のFA（フリーエージェント）宣言とかけています。
社内外に関係なく、よいお話をお待ちしております。
## なぜチームFA宣言なのか
昔からチームの重要性はいろんなところで語られてます。
私達のいるソフトウェア開発の世界は、特にチームを大切にしています。その証拠に様々な書籍・開発プロセス・フレームワークなどでチームやチームビルディングについて触れられています。最近では、日本語版が出たGoogleのre:Workなどが有名です。
https://rework.withgoogle.com/jp/
一方で、 すごい個人・一緒に働いてみたい個人の名前は挙がっても、すごいチーム・一緒に働いてみたいチームの名前はなかなか挙がりません。なぜでしょうか。
せっかくいいチームができても会社や組織など様々な事情によって壊れてしまい、チームの寿命がそんなに長くないことが大きな要因のような気がしています。もちろんチームが長生きすればいいわけではないですし、チーム至上主義を謳いたいわけではありません。
私達はチームで今後について話し合ったときに、純粋に「もう少しこのチームでやりたいことあるよね」という想いが一致したため、チームFA宣言をすることに決めました。
全員に当てはまることではないことは知っていますが、「チームで転職する」という選択肢がもっとふつうになれば、もっと楽しい世界になるような気がしています。
## 私たちのチームFA宣言
### 御社のベネフィット
- ビルドされたチームごと採用することができます
- チーム採用をしたという実績をPRすることができます
### こんな会社がいいな
- チームFA宣言に共感して下さっていること
- お互いに一緒に働きたいと思えること
- 新規事業・既存事業や会社の規模はそれほど問いません
- 事業領域も基本的には問いません（が好き嫌いはあります）
### やりたくないこと
- 受託開発
- 公序良俗に反すること
### 希望する労働条件
- 勤務地は東京・神奈川（通えるところ）
- 給料の上限は特にありません
- 副業が可能であること
- フレックスであること
子供がいるメンバーがいるため
### スケジュール
- 4月以降で調整させて下さい
### お願い
- お互いの時間を大切にするために、早めに条件の情報をいただけるとありがたいです
- ご返信までに時間がかかってしまったり、返信できない可能性もありますのでご了承下さい
いただいたご連絡はすべて確認させていただきます- チームの優先順位に合わせてお返事させていただきます
- 「チームでFA宣言」ですが、最終的には各人の判断を優先させていただきます
## 私たちのチームの紹介
### チーム
mya-zakiSatoryuTAKAKING22
[仲介者型(INFP-A/INFP-T)](https://www.16personalities.com/ja/infp%E5%9E%8B%E3%81%AE%E6%80%A7%E6%A0%BC)
[冒険者型(ISFP-A/ISFP-T)](https://www.16personalities.com/ja/isfp%E5%9E%8B%E3%81%AE%E6%80%A7%E6%A0%BC)
[エンターテイナー型(ESFP-A/ESFP-T)](https://www.16personalities.com/ja/esfp%E5%9E%8B%E3%81%AE%E6%80%A7%E6%A0%BC)
### FA宣言をするきっかけ
- たまたま仕事の区切りがつきそう
- 「このチームでもっとやりたい」という想いが一致した
- 現在所属している会社（楽天）の社内外に関わらず可能性を探したい
### チームの強み
- 最強のチーム／組織を目指しています
- 自己組織チームです
- 学習することに自信があります
- インプットをアウトプットにつなげることが得意です
### チームの弱み
- よく話すのでうるさい（かもしれない）
- 腹落ちしないと行動することができない（かもしれない）
- オブラートに包むのが苦手（かもしれない）
### チーム職務経歴書
https://silver-bullet-club.github.io/team-resume/
- [mya-zaki 職務経歴書](https://mya-zaki.github.io/)
- [satoryu 職務経歴書](https://satoryu.github.io/)
- [TAKAKING22 職務経歴書](https://web.archive.org/web/20201028140102/https://takaking22.github.io/)（※当時のアーカイブ）
### アウトプット
このチームでの活動が特に表れているものをご紹介します。
このチームで始めたモブプログラミングの事例公開です。
取り組んでいる新規事業について話しました。
チームでDevelopers Summit 2018に登壇して、公開モブプログラミングをしました。
https://event.shoeisha.jp/devsumi/20180215/session/1666/
チームで新卒研修を担当し、その時の新卒達と一緒にREGIONAL SCRUM GATHERING Tokyo 2019で話しました。
https://confengine.com/regional-scrum-gathering-tokyo-2019/proposal/7856/unlearn
[itemlink post_id="2369"]
モブプログラミングについてのノウハウを寄稿しました。
事業の成長に合わせて変化していったアーキテクチャについて話しました。
## お問い合わせについて
いずれかの手段でお問い合わせ下さい
- [Github Issues](https://github.com/TAKAKING22/team-resume/issues/new/choose)
- [Contact Form (E-MAIL)](/contact/)
- または各種 SNS からご連絡下さい
---
# 「教える」のではなく「場をつくる」 #enPiT
URL: https://agile-monster.com/blog/badukuri-to-growup/
Published: 2019-01-20
---
最近、新卒研修の講師をしたり、学生の成果発表を見に行ったり、そういう機会がたまたま重なりました。
彼らに「教える」どころか彼らから「教えてもらう」ことが多く、自分たちにできるのは「場を作る」ことだけだ、と思ったという話です。
## enPiT成果発表会
縁あって、2018年度のenPiT筑波大ワークショップ成果発表会にお邪魔してきました。
http://enpit.coins.tsukuba.ac.jp/tsukubaws2018
彼らは本当にすごかったです。どのチームもプロダクトづくりを9 Sprint（といっても授業の時間は3.5 hour/sprint）まわして、
- 動くプロダクトをデモすることができた
- 見つけたProblemに対して自分たちのSolutionをぶつけられていた
- インタビューを通してユーザーからのフィードバックを得ていた
- チームや仕事の進め方をハックしていた
これがどれだけすごいことなのか。中にはそのままリリースしても面白い、お金のにおいがするプロダクトがいくつかありました。
プロダクト面では、我々では考えつかない、あるいは考えてもよくないアイデアだと捨ててしまうような発想から素晴らしいプロダクトの卵がいくつもありました。実現可能性やマネタイズはもちろん重要ですが、そのことばかり考えていたらおそらく途中で捨ててしまうものを、「面白い」「作りたい」「欲しい」という純粋な気持ちを昇華させていった結果が彼らの素晴らしいプロダクトです。彼らのプロダクトを見ていて、馬田さんのこのスライドを思い出しました。
via [逆説のスタートアップ思考的「逆張りワークショップ」手順書](https://www.slideshare.net/takaumada/startup-thinking-workshop-v2#6)
もちろん実際にビジネスにするときにはマネタイズを考えることになるのですが、それが得意な人は多いので意外と後からでもどうにかなりそうな気がします。自分自身新規事業をやってきて実感しているのは、「売上を上げる」ことよりも「ファンをつくる」ことのほうが難しいです。
チーム・プロセス面でも、 同様にどのチームも素晴らしかったです。
- スキル差ができてしまったのでモブプログラミングをやるようにした
- プロダクトの方向性に疑問を感じたので、全員で話し合ってゴールを再設定した
- ユーザーにフィードバックをもらって方針を変更した
プロフェッショナルとして仕事をしている開発チームでも、自分たちのやり方に疑問を持ってチームや仕事の進め方をハックしていくことはとても難しいことです。彼らは当然のことのように成果報告をしていました。
## 新卒研修
この発表会を見ていて、昨年担当した弊社の新卒研修を思い出しました。
ビジネス採用の新卒265人にエンジニア研修をすることになり、いろいろあってその研修を担当しました。この研修の中でenPiT同様にチームでプロダクト開発してもらった時も、enPiTと同じような結果になりました。
この新卒研修の話を、新卒たちと一緒に講演した資料が以下です。
## 2つの場に共通していたこと
この2つの場の共通点について考えてみました。enPiTに関しては、自分は成果発表を聞いたり担当講師と少し話をしただけなので、あくまで感じたことです。
### 子供扱いしない
どちらも講師と生徒の関係が、大人と子供のそれではなく、仕事仲間のような関係に見えました。どうしても研修や教育現場では前者のような関係になりがちで、講師が子供扱いをすると子供のように振る舞ってしまいます。
※参考にしていた交流分析の記事は公開終了しています（[アーカイブ](https://web.archive.org/web/20191114220103/https://mirai.doda.jp/theme/essence/transactional-analysis/)）。
裏返すと、プロフェッショナルとして接することで彼らもそう振る舞おうとしていくのかもしれません。
### 「教える」のではなく「場をつくる」
新卒研修を担当した時に、どのような場を作るのか、自分自身どのようにふるまうか考えました。結論として、教育のプロではない自分が「教える」なんておこがましいので、成長できる「場をつくる」ことにフォーカスしようと決めました。研修屋でなく現場で働く自分たちが担当するからには、今の自分たちが知っている最高の現場を体験できる「場をつくる」ことしかできないな、と。
一方でenPiTでも、よくある授業のように一方的に「教える」だけでなく、成長できる「場をつくる」ことを意識されているように見えました。もちろん必要なインプットを行ったり、適切に学びを得られるようにサポートできる体制をつくっているものの、自分が知っている教育現場よりももっと実際の仕事に近い「場」になっていました。
## 自分が一番得してる
こんな記事を書いてみたのは、別に教育がどうのなんて崇高なことを語りたかったわけではありません。結果として、彼らから刺激を受けて、たくさん教えてもらって、一番得しているのは自分だと感じたから書いてみました。
こんなに成長の加速度が凄まじい彼らと一緒に働いたりできるようになったら今よりもっと楽しくなるだろうな、とワクワクしています。
---
# 学習する／Unlearnするチームへ #RSGT2019
URL: https://agile-monster.com/blog/rsgt2019-learning-and-unlearning-team/
Published: 2019-01-10
---
Regional Scrum Gathering Tokyo2019で「学習する／Unlearnするチームへ ―新卒研修とスクラムとモブプログラミング」という講演をしました。
https://2019.scrumgatheringtokyo.org/index.html
## 資料
今回は、新卒研修を受けてくれた新卒の子たちと一緒に登壇することができました。
登壇当日の朝に何度もまわしたフィードバックループの末にできた彼らの発表資料をマージしながらうるっときて、彼らが控室で最後まで練習を繰り返している姿を見てうるっときて、発表中に彼らの発表を聞きながらうるっときていました。
一緒にメンターを務めた彼らはもちろん、
https://twitter.com/kyon_mm/status/1083269044248035328
https://twitter.com/sato_ryu/status/1083268753402486784
会場で発表を聞いて下さった方々から、感動で泣きそうだったという感想をたくさんいただきました。「人を感動させる」ということがどれだけ難しいことか。でもそんなことすら彼らはやってしまう人たちです。
研修をする側も受ける側も学ぶことができた素晴らしい研修、その集大成として彼らと一緒に登壇できたことは一生の思い出です。研修をやっている最中に自分の子供が生まれたんですが、同時期に265人の子供ができたような気分でした。
彼らがどんな道を歩もうと全力で応援したいし、なにか手伝えることがあれば全力でサポートしていきたいと思っています。
研修を受けてくれてありがとう。
一緒に話してくれてありがとう。
最＆高のみんなです！
---
# 男性エンジニアが育児休暇を取ってみたんだけど質問ある？
URL: https://agile-monster.com/blog/my-paternity-leave/
Published: 2018-12-25
---
このブログ記事は 子育てエンジニア Advent Calendar 2018 25日目の記事です。
https://adventar.org/calendars/3178
## 男性エンジニアが育児休暇を取ってみたんだけど質問ある？
私は楽天株式会社でエンジニアをしています。8月末に子供が生まれて、現在（2018年12月25日現在）育児休暇中です。
実はこの「子育てエンジニア Advent Calendar 2018」を立てたのも、育休中だったからです。たくさんの方にご注目いただき、すごく興味深い話をたくさん読むことができてよかったです。ありがとうございます。
ということで、「男性エンジニアが育児休暇を取ってみたんだけど質問ある？」というタイトルで、育児休暇の話や男性目線での子育てについて書いてみます。
## なぜ育児休暇を取ろうと思ったのか
個人的には「育児休暇を取るのに理由がいるのか？」という感じですが、なぜ育児休暇を取ろうと思ったのかについて言語化します。
### 先輩エンジニアが育児休暇を取っているのを近くで見ていた
一緒に働いていた先輩エンジニア（男性）が、2度育児休暇を取りました。その時に話を聞くと、「すごく貴重な時間だった。絶対に取ったほうがいいよ！」ということをしきりに言っていたことを今でも覚えています。
### 夫婦で乗り越える必要があった
我々夫婦は共に同じ会社で働いているのですが（妻は営業職）、2人共地方出身で実家が遠いため、2人で協力して子育てを軌道に乗せる必要がありました。もちろん出産前後は義母や実母に来てもらいサポートしてもらったものの、基本的には夫婦2人で育児しながら生活をしていかなければなりません。
### 取ると決めていた
などと書いてますが、「いつか子供を授かったときは必ず育児休暇は取る」と前々から心に決めていました。もちろんいろいろな制約はあるのでそれらをクリアしていく必要はありますが、まとまった期間を家族で過ごすという機会はとても貴重で、それだけでも取る価値があるものだと考えています。
## 育児休暇中にやった／やっていること
そんなこんなで取り始めた育児休暇をどのように過ごしているのか簡単にまとめます。
### ライフワーク
以下はだいたい自分の担当になっているもの。
- 掃除
- 皿洗い
- 洗濯
- ゴミ出し
- 買い物
- 風呂洗い
- 子供を風呂に入れる
- 寝かしつけ
一番大変な授乳は変われないですが、それ以外の子供の世話（オムツ替え、ミルク、あやすなど）は手が空いている方が対応しています。大人が2人いるとシフトを組めるので、睡眠時間が足りていない時は片方が面倒を見ている間に睡眠時間を確保したりできるのが大きいです。
基本的には子供が寝ている間が自由な時間なので、家事を済ませたり、趣味の時間にしたり、ブログを書いたり、資料を作ったり、本を読んだりしています。筋トレはジムに行く時間がとれないので子供を抱っこしてスクワットをしたりしています。
また、ちょいちょいマラソン走ったり、勉強会に参加したり、出かけさせてもらったりさせてもらっています（ありがとうありがとう）。
### 情報収集
第1子で何もかも初めてなので、子供の成長に合わせてやらなければいけないことや、「これ大丈夫かな？」というのが全然わからないので、都度インターネットなどで調べながら対応しています。
途中で買ったんですが、この本のように月齢に合わせて情報をまとめてくれている本を1冊持っているとすごく心強いです。
[itemlink post_id="2320"]
また、地域の児童館に行くと同じような月齢の子供を持った親御さんと知り合うことができたり、スタッフの方から子育てに関する情報を得られて良いです。
### 職業病
新規事業やエンジニアをやっていて良かったなと思うのは、
- 不確実性との戦い方
- Try & Errorで学びを得ていくこと
- 仕組み化して効率化をはかること
- 変化に柔軟に対応すること
などに慣れていることでした。
そしてそういう状況を楽しむことができるので、
- 抱き方
- 笑わせ方
- 寝かしつけ奥義
などを無限に開発していくことができます。
## 実際に育児休暇を取って感じたこと
実際に育児休暇を取って感じたことについてまとめます。
### 育児休暇より仕事している方が断然楽
育児休暇を取る前は、「大人2人で対応すればどうにかなるだろう。だから空いている時間でやりたいこともやろう」などと考えて、やりたいことをリストアップしていました。正直この考えは甘かったです。
- 授乳＆ミルクのタイミング（週）
- 睡眠時間（週）
これはとある週の「授乳＆ミルクのタイミング」と「睡眠時間」を見える化したもの（PiyoLogというアプリ）です。
https://www.piyolog.com/
他の子供を育てたことが無いので比較は難しいですが、いろんな人の話を聞いていると、まだ我が子は比較的夜はまとめて寝てくれるし、今のところ病院にお世話になるような事態にはなっていないので手がかからない方かもしれません。子によっては、夜も30分おきに起きてしまったり、寝かせるのに時間がかかってしまったりするそうです。
もちろんこのグラフ以外にも、オムツを変えたり、あやしたり、散歩に連れて行ったり、お風呂に入れたり、様々なタスクが発生します。そして、その合間に自分たちの食事や家事などをこなしていかなければいけません。
- まとまった時間が空くことはほとんどない
- どんどん緊急対応が差し込んでくる
- タスクの優先順位が目まぐるしく入れ替わる
常にこんな状態なので、はっきり言って炎上案件やトラブル対応のほうがよっぽどコントーラブルです。この点において、自分の場合は育児休暇よりも仕事をしている方が予想や計画を立てやすく断然楽だと感じています。
### イクメンという言葉に違和感
平日昼間に抱っこ紐をつけて子供を連れていると、たまにおばあちゃんから「パパ、エライね」などと声をかけていただくことがあります。
家に遊びに来てくれた友人の前で、子供にミルクをあげたりオムツを変えていると、「イクメンだね」とよく言ってもらえます。
男性の育児休暇取得率は5％程度（2017年度）なので、まだまだ珍しいのかもしれません。「イクウーメン」は無いのに「イクメン」という言葉があるように、男性はちょっと育児をしただけで褒めてもらえます。
でも正直普通のことをしているだけなので、素直に「ありがとうございます！」と感謝しつつ、（同じくらいお母さんたちも褒めてあげてほしいな）って思うようになりました。
### 育児休暇は子供のため
夫婦で話をしていて、「夫婦2人で育児休暇を取ることで一番恩恵を授かるのは子供だね」という結論に至りました。
ワンオペをしている場合、子供が寝ているときや機嫌がいい時は子供を置いて、その隙に家事や自分の用事を済ませなくてはなりません。状況によっては多少泣いていても「ちょっと待ってー！！」と言いつつ、タスクを消化していかないと何も片付かずに1日が終わってしまいます。
でも本当は、機嫌がいい時には一緒に遊んであげたいし、泣いている時はなるべく早く対応してあげたいものです。2人いることでそれが可能になるんです。
子供は覚えていないかもしれないけれど、我々両親はこの時間をたぶん一生覚えているし、少しでも多く幸せを感じてくれたのであれば嬉しいです。
## 最後に
今のところ育児休暇をとってよかったことしかありません。もしまた子供を授かることがあったら、迷うことなく育児休暇を取るつもりです。
今回育児休暇を取ってみてがっつり育児をしてはじめてわかったこと、言い換えるとがっつり育児をしないとわからないことがたくさんありました。この時間がなかったら、仕事から帰ってきた時に、
「もう少し片付けておいてよ」「なんでこれもやっていないんだろう」
と思っていたかもしれません。土日に数時間子供の面倒を見ただけで、
「俺育児してるなー！」「僕イクメンっ！！」
と満足していたかもしれません。
すべての人に育児休暇を薦めるつもりはありませんが、このブログが少しでも育児の大変さを理解する参考になり、誰かを思いやるきっかけになれば幸いです。
## 謝辞
無事に育児休暇を過ごすことができているのも、楽天が育児休暇をとりやすい仕組みがある素晴らしい会社であることと、仲間や友人や家族がサポートしてくれているからです。ありがとうございます。
また、なにより2人共無事に産んでくれた妻に感謝しています。ありがとう。
---
# 私がアウトプットする理由
URL: https://agile-monster.com/blog/why-output/
Published: 2018-12-23
---
このブログ記事は Regional Scrum Gathering Tokyo Advent Calendar 2018 23日目の記事です。昨日はやっとむさんの「[心理的安全性について](http://d.hatena.ne.jp/yach/20181222)」でした。明日は小野崇之さんです。
https://adventar.org/calendars/3359
## 私がアウトプットする理由
エンジニアがアウトプットする方法はいくつかあるのですが、今回は勉強会やイベントで講演することを対象に書いてみます。
前提として、「アウトプットする方がエライ／正しい」などと言うつもりはありません。あくまで **"自分が"** アウトプットする理由について書きます。書くことでいろんな人と話すきっかけになったり、少しでも誰かの参考になるのであれば嬉しいです。
### 私のアウトプット
数えてみたところ、平均すると1年間に10本程度公の場で講演をしています。公ではないもの（社内勉強会、秘密の勉強会など）や忘れたものはここに載せていないので、それらを含めるともうちょっと多いでしょう。
https://agile-monster.com/slides/
ほとんどすべて、自分が／チームが経験したことやそこから学んだこと考えたことについて話をしてきました。むしろそれ以外話せません。
また自分の発表スタイルとして、同じ発表を二度としない＆できないので、同じテーマで講演をするとしても資料と話す内容をアップデートをして講演にのぞんでいます。
この数が多いのか少ないのかはわかりませんが、自分がなぜアウトプットするかについて考えてみます。
### 人生のスナップショットを撮る
Photo by Marco Bianchetti on Unsplash
一番最初に浮かんだのが、「人生のスナップショップを撮る」です。
学びや経験やスキルは自分自身に蓄積し、日々変わりゆくもの（成長）ですが、
- どんな考えをもっていたのか
- どんな想いをもっていたのか
などその時その場でしか感じられないもの、表現できないことが確かに存在します。これらはどうしても時間と共に風化してしまいますが、その臨場感も含めて形に残しておくことで後から思い出すきっかけができます。もちろん時間軸が後の自分の方が成長しているはずですが、過去の自分から学ぶことも多いです。
また、その時に一緒に働いたメンバーとの想い出を形に残すという意味もあります。自分の仕事に対する心構えとして、「一緒に働いた人たちと、仕事が終わった後でもたまに集まって近況報告をしたり、思い出話ができるような仕事をしたい」というものがあります。
講演をすることで、その時の仲間と成し遂げた仕事の成果や想いを残すことができれば嬉しいですし、今度もそういう仕事を増やしていきたいと思います。
### インプット⇔アウトプット
講演をする＝アウトプットしようとすることで、本を読んだり、情報を調べたり、データを集めたり、人に話を聞きに行ったり、アウトプットのためのインプットをします。
講演をする＝アウトプットすることで、新しい情報やチャンスに巡り合う機会が増えて、次のアウトプットにつながります。
自分の経験上、このループが永遠につながっていくイメージを持っていて、インプットとアウトプットを別々に考えたことがありません。だから、「アウトプットしよう」とか「インプットしよう」と考えたことはなくて、インプットのためのアウトプットとアウトプットのためのインプットを繰り返し続けて今に至っています。
### いろんな人とつながる場
講演をすることで、たくさんの人と出会うことができます。
- 講演を聞いてくれた人
- 同じ場で別の講演をする人
- 場を運営してくれた人
- 資料を後からみてくれた人
自分では大した話をしていないつもりでも、自分の想像以上につながりは拡がっていきます。ふつうに仕事をしていただけではできないようなつながりができます。
会社でも人間関係でもなんでもそうですが何かに依存して生きるのは健康的でない気がしてあまり好きではないので、会社外に自分の考えをぶつけたりできる場や仲間がいることはとても心強いです。
### 恩送りの場
新井さん（[@araratakeshi](https://twitter.com/araratakeshi)）が、よくおっしゃっている「恩送り」という言葉が大好きです。
- [心が折れてもソシキカイゼンを続けられるたった一滴の魔法](https://speakerdeck.com/araitakeshi/xin-gazhe-retemososikikaizenwosok-kerarerutatuta-di-falsemo-fa?slide=86)
自分もこれまでいろんな本を読んで、いろんな人の話を聞いて、刺激を受けて、現場での活動につなげてきました。本人に恩返しするのもよいですが、「受け取った恩は次の人に送る」という文化がコミュニティを育んでいると思うので、ほんの少しだけそんなことを考えながら話しています。
### まとめ
ということで、
- 人生のスナップショットを撮る
- インプット⇔アウトプット
- いろんな人とつながる場
- 恩送りの場
が私がアウトプットする理由でした。
最初に書いた通り、アウトプットすることを薦めたいわけではありません。人によってする理由／しない理由は様々でしょう。そこに正しいも正しくないもないので、己が信じる道を行けばいいだけです。
だから、マサカリなのかナマクラなのかはしりませんが、他人のアウトプットにフィードバックをする目的ではなく、いろんな人をただ不快にさせる行為は個人的にあまり好きではありません。
自分はいろんな人のアウトプットから学びたいので、
**“人のアウトプットを笑うな”**
ですね。
## 私とRSGT
もうちっとだけ続くのじゃ。
ということで、せっかくの Regional Scrum Gathering Tokyo Advent Calendar なので、ここまでの内容を踏まえて「私とRSGT（Regional Scrum Gathering Tokyo）」について最後にふりかえってみます。
#### Scrum Gathering Tokyo 2011
https://www.scrumgatheringtokyo.org/sgt2011/
始めて参加したScrum Gathering Tokyoは2011年でした。
この時のキーノートでHenrik Kniberの講演の中で、
>
>
> 人は変化を嫌う
>
>
>
> だからまずは自分を変えることからはじめよう
>
>
ということを話していて、当時ペーペーだった自分がとても勇気づけられたことを今でも覚えています。それから自分のメンタルモデルが変わってうまくいくようになって、Agile2012 at TexasでHenrikに会った時に御礼を言えたのがとても嬉しかったです。
**[Fearless Change - Agile2012 feedback report -](https://www.slideshare.net/TakaoOyobe/fearless-change-agile2012-feedback-report)** from **[Takao Oyobe](https://www.slideshare.net/TakaoOyobe)**
#### Scrum Regional Gathering Tokyo 2013
https://scrumgatheringtokyo.org/2013/148.html#S2A-3
はじめてScrum Gatheringで講演したのが2013年。
カンバンを通して、いろんな現場・いろんなチームで仕事の範囲を拡げていった話をしました。最＆高の現場ですね。
https://www.slideshare.net/TakaoOyobe/20130116-product-ownership
#### Regional Scrum Gathering Tokyo 2015
[当時のセッションページ（アーカイブ）](https://web.archive.org/web/20210731000917/https://2015.scrumgatheringtokyo.org/event/c46fa73e116569cbaae3d170ab6df9e5)
伝説の一戦ですね。
コミュニティ活動などでお世話になっていた直人さん（[@nawoto](https://twitter.com/nawoto?lang=ja)）や伊藤さん（[@hageyahhoo](https://twitter.com/hageyahhoo)）と最高のセッショn・・・試合ができました。最＆高のライバル達ですね。
#### Regional Scrum Gathering Tokyo 2017
https://confengine.com/regional-scrum-gathering-tokyo-2017/proposal/3318/-
RSGT2017では、当時所属していた組織で未来会議をやった話をしました。最＆高の組織ですね。
組織の話を他人事にするのではなく、自分ごととして実際にアクションをし、おまけにそのネタで講演するようになったところに自身の変化を感じます。
#### Regional Scrum Gathering Tokyo 2018
https://confengine.com/regional-scrum-gathering-tokyo-2018/proposal/5109/teamwork-revolution-
RSGT2018はモブプログラミングです。現在（2018年12月現在）も所属しているチームの話です。最＆高のチームですね。
#### Regional Scrum Gathering Tokyo 2019
https://confengine.com/regional-scrum-gathering-tokyo-2019/proposal/7856/unlearn
そしてRSGT2019でも講演できることになりました！
2018年に取り組んだ最＆高な新卒研修の話を中心に、そこで学んだことを自分たちの仕事にどう活かすかという話をしたいと思います。
ぜひ聞きに来てください。
### 最後に
RSGTは、ここ数年はプロポーザル制（セッション採択制）になったので、毎年自分がやったことをアップデートしてふるいにかける場にしています。アウトプット＆インプットの場として大好きな場です。
RSGT2019は既にチケット完売なので、来年RSGTでお会いできる方はRSGTで、そうでない方もいろんな場で皆さんにお会いできることを楽しみにしています。
え！？まだ参加できる場はないのかって？関西はどうしたんだって？
https://www.scrumosaka.org/
なんとこんな最＆高なイベントがあるみたいです。偶然ですね！ぜひご参加ください。
---
# レビュー再定義
URL: https://agile-monster.com/blog/redefinition-of-review/
Published: 2018-12-17
---
このブログ記事は [モブプログラミング Advent Calendar 2018](https://qiita.com/advent-calendar/2018/mobprogramming) 18日目の記事です。
JaSST Review'18にて、「レビュー再定義」というタイトルで講演しました。モブプログラミングが主役の講演ではないですが、チームでモブプログラミングを続けてきたことで得られた学びが詰まっているのでAdvent Calendarの記事として紹介してみます。
https://jasst.jp/symposium/jasstreview18.html
## 講演資料
- モブプログラミングを始めてレビューが不要になった
- でもやっぱりレビューは必要だった
- 我々にとってのレビューとは
- レビュー再定義
という流れで話をしました。
冒頭は [Mentimeter.com](https://www.mentimeter.com/) を使って当日の聴衆にリアルタイムアンケートをしました（これがリアルタイムフィードバックだ！！というライブデモｗ）。「レビュー」がテーマのカンファレンスなのでほとんどの人が普段からレビューをされているそうです。
レビューの目的について聞いてみたところ、品質に関するワードをあげる方が多かったです。JaSSTという場なので普段テストエンジニアをされている方が多く参加されていたこともありますが、だいたいこのあたりかなというワードが出ていました。
レビューの目的を分類すると、「検査」「学習」「強化」のどれかに分類できるのではないでしょうか。
では次にそのレビューの目的を達成できているかを聞いてみたところ、ほとんどの人はその目的が達成できているのかはわからないという結果でした。
そしてなにより印象的だったのは、レビューが楽しいかどうか聞いてみたところ、JaSST Reviewに集まる人ですら「ツライです」or「どちらでもない」とほとんどの人が答えていました。
レビュワーをしていると忖度をしなければいけなくなってストレスを貯めたり、エンジニアとしてスキルを積んでいくとレビューおじさんになってコードを書く時間がどんどん減ってしまったり、やはりレビューは「やらなければいけない」ネガティブなものになっていることが多いです。
それがイヤだったので、少しでもワクワクするレビューの話をしたくて、自分たちのチームがどうレビューに向き合っていったかという事例の話をしました。
リアルタイム（モブプログラミング）とレビュー（Re-view）では、強みと弱みがあるので、自分たちのチームではおいしいところどりをしています。
そもそもレビューはRe-view（再び見る）のはずなのに、ほとんどの場合はFirst-view（はじめて見る）です。それが悪いわけではないですが、他人の思考プロセスや仕事の過程を想像してフィードバックをするということは自分たちが思っている以上に難しいです。
レビューに限った話ではないですが、「何かをすれば解決する」と単純＆ロジカルに考えて、うまくいった人の話を聞いてそのまま自分たちに当てはめようとしてしまいがちです。
もう少し自分たちが人間であることを理解してプロセスに向き合っていきたいなと思い、今回はその思いを「レビュー再定義」というタイトルに載せて話しました。
当日の雰囲気を知りたければ、まとめてくださったようなのでこちらをどうぞ！
https://togetter.com/li/1298297
その後に行われたパネルディスカッションで答えきれなかった質問への解答もしています。
## 最後に
JaSST Reviewは今回が初開催でした。自分はJaSST自体はじめての参加でしたが、「レビュー」について改めて考えるきっかけになり、自分としてもものすごく学びが多い経験になりました。
参加者の皆さん、登壇者の皆さん、そしてなにより運営の皆さんありがとうございました＆おつかれさまでした！
## 合わせて読みたい
https://agile-monster.com/blog/mob-advent/
https://agile-monster.com/blog/superagile/
---
# エンジニアリングマネージャーはエンジニアリングがわからなくてもよいのか
URL: https://agile-monster.com/blog/engineering-as-em/
Published: 2018-12-05
---
## エンジニアリングマネージャー界隈でよく聞く話
### マネージャーは役割であって上下関係ではない
マネージャー＝エラいという不文律が存在している組織がまだまだ多い。そうではないと言ったところで給与体系が違ったり、組織上ツリー構造の上位に位置していたりする。マネージャーになることを「昇格」と呼んでたりするのは、こういう風習の表れだったりする。
それにしても「部活のマネージャー」と聞いて上下関係を思い浮かぶ人はいないのになんで「組織のマネージャー」になると話が変わるのだろうか。部活のマネージャーは仲間だけど、組織のマネージャーは仲間だと思えないのかもしれない。
ところが少し前からWorks Rulesの影響などもあって、徐々にマネージャーというものが見直され始めてきているように感じる。役職としてのマネージャーから役割としてのマネージャーへと目線が移ってきた。
[itemlink post_id="2472"]
自分もそういう考え方のほうが好きで、メンバーと横並びになって同じ敵を倒しに行くパーティーだって考えたほうがスッキリする（ゲーム脳）し、そういうマネージャーになりたい／そういうマネージャーと一緒に働きたいって思う。
### エンジニアリングとマネジメントは別のスキルセット
前述の組織の不文律が影響していたのかもしれないけれど、エンジニアの経験を積んでいってあるタイミングからマネージャーになるというキャリアパスがなんとなく存在した、あるいは存在している。
でもエンジニアリングとマネジメントは全然違うスキルなので、このキャリアパスって実は転職どころかエンジニアから営業になるのと同じくらいのジョブチェンジだ。いいエンジニアがいいマネージャーになるとは限らない、ってのはその通りだ。
だからマネージャーになるならマネジメントを学ばなきゃいけないし、それくらい新しいことをやるつもりで取り組んでいかなければならない。過去のエンジニア経験の貯金を切り崩してマネージャーやってるんだとしたら、とっとと思い改めないとすぐに借金生活が待っている。
### だからエンジニアリングのスキルがなくてもマネージャーはできる
もちろんエンジニアリングの経験やスキルがあるに越したことはないけれどなくてもマネージャーはできる、って話をよく聞く。その通りだなって思う。
## でもね・・・
だから知らないままでいいなんて誰も言ってないんだよね。
エンジニアリングのスキルがなくてもエンジニアリングマネージャーになれるかもしれないけれど、エンジニアリングマネージャーがエンジニアリングを知ろうとしなくてもいい、学ばなくてもいいなんて誰も言っていない。
### Googleで優れたマネージャーになるための8つの習慣
Work Rulesの中にGoogleで優れたマネージャーになるための8つの習慣が紹介されていた。
>
>
> - **良いコーチであること。**
> - **チームに権限を委譲し、マイクロマネジメントをしないこと。**
> - **チームのメンバーの成功や満足度に関心や気遣いを示すこと。**
> - **生産性／成果志向であること。**
> - **コミュニケーションを円滑に。話を聞き、情報は共有すること。**
> - **チームのメンバーのキャリア開発を支援すること。**
> - **チームに対して明確な構想／戦略を持つこと。**
> - **チームに助言できるだけの重要な技術スキルを持っていること。**
>
>
>
> グーグルのプロジェクト・オキシジェンの8つの属性リスト (via Work Rules)
>
>
「8. チームに助言できるだけの重要な技術スキルを持っていること」が、エンジニアリングに関することに思えるかもしれないが、それだけではないように感じる。
マネージャーがエンジニアリングを知っていれば、
- より良いコーチングができる
- チームへの適切な権限委譲がしやすいし、介入しなくてはいけない敷居が判断しやすい＝そこまでは任せられる
- エンジニアの成功や満足度に関心どころか共感できる
- エンジニアの生産性や成果に対して理解ができる
- 説明を省いてスムーズなコミュニケーションができる
- エンジニアとしてのキャリア開発を支援することができる
- チームに対して明確な構想／戦略をより具体化できる
かもしれない。もちろんエンジニアリングを知っているだけですべてうまくいくわけではないが、これだけの機会損失をするのはもったいない。
言い換えるならば、マネージャーとしてのよいアウトプットをするためにはエンジニアリングを学ぶこと／学び続けることが近道なのだ。
## まとめ
エンジニアリングマネージャーはエンジニアリングのスキルがなくても務められる。でも「エンジニアリング」を知ろうとする気がないマネージャーは、マネージャーをやめた方がみんなが幸せになれるような気がする。
エンジニアリングを知ろうとする気がないマネージャーに対して、
- キャリアの相談をしようと思うだろうか
- 評価されたいと思うだろうか
- 判断を仰ぎたいと思うだろうか
- 仕事の共有をしたいと思うだろうか
ということをエンジニアになったつもりで考えてみるとよいのかもしれない。
もちろんマネージャーだって人間なので、エンジニア経験がなくたってかまわないし、高いエンジニアリングスキルを持っていなくてもいいと思う。でも同時にエンジニアだって人間なので、自分が好きなことに興味を持ってくれる人にマネジメントしてほしいと思うのは至極当然である。
会社を辞める理由の一番の理由は上司の問題である。日本の会社だと、残念ながら上司＝マネージャーになっていることが多いので、マネージャーになること自体にそれなりの責任が発生する。
ということでエンジニアリングマネージャになっても、エンジニアリングの勉強はし続けようと思った。なんでもはできないけれど、せめてメンバーの好きなこと＝エンジニアリングで一緒にキャッキャウフフできるマネージャーではいたい。
[itemlink post_id="2472"]
---
# 意識低いエンジニアリングマネージャーを目指してやったこと
URL: https://agile-monster.com/blog/to-be-em/
Published: 2018-12-03
---
Engineering Manager vol.2 Advent Calendar 2018 3日目の記事です。
https://qiita.com/advent-calendar/2018/em
https://qiita.com/advent-calendar/2018/em2
楽天株式会社で新規事業のエンジニアリングマネージャーをやっている [@TAKAKING22](https://twitter.com/takaking22) です。 最近「エンジニアリングマネージャー」が流行っていますね。弊社にはそんなかっこいい役職名はないんですが、いわゆる開発部のマネージャーをやっているのでエンジニアリングマネージャーがわかりやすいと思って最近使っています。
# 意識低いエンジニアリングマネージャーを目指して
意識低いエンジニアリングマネージャーを目指してやったことについて書いてみます。 なぜ「意識低い」なのかというと、そもそもマネージャーにはなりたくなかったのでできる限り要領よくマネジメント業務を効率化してその分プレイヤーとして仕事をしようと考えたからです。なんと意識が低いのでしょう。 でも「俺がマネージャーだ！（ドンッ）」みたいにマネージャーになっただけで偉そうに振る舞ううざいマネージャーになるよりは意識が低いマネージャーの方がマシだと思うのと、実際になってみてわかったことがたくさんあるので誰かの参考になればと思って書いてみます。 エンジニアリングマネージャーの方はもちろん、エンジニアリングマネージャーに興味が無い方も読んでいただければ。
## エンジニアリングマネージャーになったきっかけ
コンテキストを少しだけ（興味ない方はこの章は読み飛ばしてください）。 私は2年くらい前にプレイングマネージャーになることを決めたんですが、正直なところできるならマネージャーにはなりたくなかったです。なぜかというと、
- 現場もエンジニアリングも大好き
- 現場にいる方が自分のパフォーマンスを発揮できる
- マネジメントは自分よりも得意な人がいるハズなのでその人に任せたい
- **マネジメントなんてかったるい**
という思いがあったからです。以前にも何度かマネージャーになるタイミングはあってもことごとく断ってきたんですが、
- 最高のチームとその仕事を外部から壊されたくない
- やったことがないのに文句を言うのはダサい
- 「自分がマネージャーだったら…」が溜まっていたのでそれをやってみようと思った
- まずはやってみてマネジメント業務を圧縮すればプレイヤーでいられるのでは？
という理由でやってみることに決めました。
## 意識低いエンジニアリングマネージャーが意識したこと
意識したことはたった1つだけ、「チームが仕事に集中できるようにする」ことです。 幸いなことに自分は「チームやメンバーは最高だ」と自信を持って言えるので、彼らが集中して仕事ができればよい結果が生まれるという確信しています。ど素人のエンジニアリングマネージャーにできることは限られているので、まずはそれだけをやろうと思って取り組みました。
## 意識低いエンジニアリングマネージャーになってやったこと
やるからには意識低いエンジニアリングマネージャーを全力でやろうと思ってやったことを少しだけ紹介します。
### 勉強する
エンジニアリングマネージャーだからといって、エンジニアの上位互換なわけではなく、まったく別の役割を担うことになるので勉強が必要です。ドラゴンクエストで例えると、戦士が僧侶に転職したようなものなのでLV1からのスタートです。効率よくレベルアップするには勉強するしかありません。具体的にやったことは以下です。
- 「この人すごい！」って思う社内外のエンジニアリングマネージャーの話を聞きに行く
- マネジメント系の勉強会に参加する
- マネジメント、組織論、教育学、心理学などの本を読む
最近の本だと以下の2冊が面白かったです。
[itemlink post_id="2474"]
[itemlink post_id="2475"]
勉強会だと最近はEngineering Manager Meetupが定期開催されていてアツいです。Slackグループもあって、勉強会の告知やいろんな現場のマネージャーの話を聞けるので良いです。
https://engineering-manager-meetup.connpass.com/
またそれだけでなく、エンジニアリングやビジネスに関する勉強もより積極的になりました。もともと勉強が好きなので、本を読んだり手を動かしたり勉強会に参加するのは趣味のようなものだったんですが、マネージャーになってからはより意識して取り組むようになりました。 プレイングマネージャーだからということもあるのですが、それ以上にマネージャーとして知らないことで自分がボトルネックになることを避けるためです。マネージャーの役割を担うことでプレイヤーとしての時間は減ってしまうので、ボトルネックにならないように必要になりそうな技術要素やドメイン知識に関してはインプットを怠らないように気をつけました。 意識低いエンジニアリングマネージャーは、効率的にレベルアップし、かつ現場のボトルネックにならないようにするためには勉強をするしかなかったのです。
### 情報を筒抜けにする
マネージャーに降りてきた情報はほとんどすべてメンバーに伝わるようにしました。 組織のマネージャーにいると、わざわざピラミッドの上から順々に情報を流していく大きな滝が存在します。そして大して理由もなく「いったんマネージャーまでで」と謎の制限がかかります。 ですがそんなことは関係なく、自分が得た情報は自己判断でリアルタイムにチームに共有するようにしました。「ほとんどすべて」と書いたように、さすがにまずいと思うものは止めておこうと考えていたのですが、役員レベルならいざ知れず自分のような末端のマネージャーに降りてくるものには機密性がある情報などありません。むしろ人の動きや社内のルールの変更などはやく知っておいて損はないことがほとんどなので、マネージャーでワンクッションおいてスピードを落とす必要はないです。
### フィルターになる
やってみるまではマネージャーほど普段何をしているかわからない役職はありませんでした。評価面談などのタッチポイントやわかりやすいものは想像できるものの、正直なところそれ以外の日常の生態が不明でした。 なのでいったんすべて自分で受けるようにして、どのような仕事があるかを把握し、その上でムダだと思ったものは徹底的に排除するようにしました。 例えばレポーティングに関しては、チームの仕事を誰に対してもオープンにすることで、レポーティング自体を極力しなくてもよいようにしました。特に私達のチームではモブプログラミングをしていたので、自分の上司には「いつでも参加してください」と伝えていました。結局来てくれたことはないけど、うまくいっているのでよいということでしょう。幸いなことに自分の上司も協力をしてくれたので、極力めんどくさいことは自分でやったり、自分の上司におしつｋ・・・お任せをして、本当に必要なものだけ現場に協力してもらうように心がけしました。
https://agile-monster.com/blog/tag/mobprogramming/
マネージャーがフィルターになってムダを取り除くことで、現場のメンバーが全力で仕事に取り組めるならばそれが一番だな、と思います。 そして意識低いエンジニアリングマネージャーはムダなことをしたくないので、改善に必死でした。
## 意識低いエンジニアリングマネージャーとして今思うこと
最後に、実際にエンジニアリングマネージャーを経験してみて思ったことを共有します。
### エンジニアリングマネージャーって面白い
やってみてエンジニアリングマネージャーって面白い仕事だな、と思いました。 何が一番面白いかというと、ムダがたくさんあるので改善しがいがあるところです。マネージャーは多くの人や組織と関わることになるので複雑になりやすい仕事なので、その分ムダが生まれやすい仕事です。そのムダのとり方のほとんどは、現場でやってきた改善活動とそれほど変わらないのでいくらでもやりようがあります。マネージャーになる前に感じていた「もやっとしたこと」はあながち間違いではなく、それをマネージャーとして主体性を持って一つずつ潰していけばいいだけでした。 最初に書いた通り、マネジメントなんてかったるいと思っていたのですが、自分が想像しているつまらないマネージャーがかったるいだけでした。組織・チーム・メンバー・プロダクトのためにやれることは無限にあるので、主体性を持って取り組めばやりがいがある仕事です。
### Manage＝うまくする
https://ejje.weblio.jp/content/manage
動詞であるManageを日本語にすると「うまくする」「なんとかする」という訳があって、「管理する」よりもこっちの方が好きです。 どうしてもマネージャー＝管理者というイメージが強く、意識しすぎるとメンバーを子供扱いしたり、不要な上下関係ができてしまいます。マネージャーはエンジニアやスクラムマスターやプロダクトオーナーと同じくロールの1つに過ぎません。マネージャーは親でも先生でもネ申でもなくただの人です。 「この組織・チーム・メンバー・プロダクトを、うまくいかせるためにはどうすればいいだろう？」 と考えて、メンバーを信頼して、メンバーに信頼してもらって、肩肘張らずに、意識だけ高くならずに、自分ができることをやっていけばそれでいいんじゃないかなーと思いました。 『なんでもはできない、できることだけ』ですね。
## 次は
今回はちょっとネタっぽく書きましたが、
- 子供扱いをすると子供として振る舞う
- 主語が僕らになるか彼らになるか
- マネージャーは孤独だ
などなどネタはいろいろあるのでまたどこかで。 次は [@nakahashi](https://qiita.com/nakahashi) さんです。お楽しみに！
---
# モブプログラミングのよくある誤解
URL: https://agile-monster.com/blog/mob-advent/
Published: 2018-12-01
---
モブプログラミング Advent Calendar 2018 1日目の記事です。
https://qiita.com/advent-calendar/2018/mobprogramming
また空いてるので「書いてみようかな」って少しでも思った人はぜひ書いてください！
Advent Calendarはやったことあるかないかや、エキスパートであるかどうかに関係なく、この流れに乗ってアウトプットするぜっていう勢いがすべてだと個人的には思っております。せっかくなのでモブで記事を書いてみてはいかがでしょうか（ネタ提供）？
# モブプログラミングのよくある誤解
この1年半近く、モブプログラミングについていろんな方とお話する機会があったんですが、その中でよく出てくるモブプログラミングのよくある誤解について書いてみようと思います。 前提として、「モブプログラミングはすべてにおいて最＆高だからやるべきだ！」とは全く思っていません。
ですが、SNSなどを見てもネガティブなことを言ってる人のほとんどはやったことがないか中途半端にやって失敗してこじらせてるだけなので、少しでもやってみたいと思う人の助けになればと思って書いてみます。
# よくある誤解1 : モブプログラミングは効率が悪い
モブプログラミングって複数人で1つのPCで仕事をするんでしょ？ ペアプログラミングよりもさらに効率が悪いじゃん。生産性下がっちゃうよ。
モブプログラミングにおいては効率云々の話が一番多いです。 なので様々な現場で講演をするたびに、マイナーチェンジしながらこれに答えてきました。なかなかよい資料だと思うので、ぜひ御覧ください（Speakerdeckの資料をこの機に更新しました）
ポイントだけ解説します。
おそらくこの手の話をする際には、前提として（普段やっている＝自分が知っている）分担作業と比較して効率が悪いというのだと思います。 まずは主観として、実際に1年半近く自分たちでモブプログラミングをしたり、研修やワークショップなど様々な場面でモブプログラミングをやってきて、効率が悪いと思ったことがありません。効率が悪かったらとっくにやめてます。
大きな誤解の一つとして、多くの方が分担作業とモブワークを二者択一のように考えがちです。私達も1日中モブワークをしていますが、正確には仕事の質や状況に合わせて分担作業とモブワークを切り替えながら仕事をしています。
それぞれに強み・弱みがあるので、その場その場で適切な方を自然と選択しています。分担作業しかできないチームよりも、状況に合わせて適切な仕事のスタイルを選ぶことができるチームの方がチームとして強いのは明らかです。
モブプログラミングから得た学びの中で一番衝撃的だったのは、これまでやってきたことのほとんどは「分担作業を前提としていかにそれをうまくやるか」だった＝思考停止していた、というものでした。
ところで、一体「分担＝効率がいい」というのはいつからそう思っていたのでしょうか。
最近新卒研修に関わった際に、余計な社会経験のない彼らを観察していても、自然と分担作業を始めていたので、学校教育なのかもっと根深いところで我々に染み付いているような気がします。
この他にも様々な視点から効率について考察しているので、ご興味のある方はぜひ資料を御覧ください。
# よくある誤解2 : モブプログラミングはエンジニアのプラクティスだ
モブ “プログラミング” だから、エンジニアがやるものですよね。 デザイナーがやる場合はモブ “デザイン” とかになるのかなー？
「チーム」全員で同じ「仕事」をする、なのでエンジニアに限った話ではありません。
どのようなチーム、どのような仕事においてもモブプログラミングの利点を活かすことができます。デザイナーだけのチームでモブデザインをすることもできますし、チームの範囲を広げてエンジニアもデザイナーもビジネスオーナーもいるチームでモブプログラミングをすることもできます。 モブプログラミング発祥の地であるHunter Industriesでモブプログラミングを始め広めた、Woody Zuil氏やChris Lucian氏に話を聞いた際、彼らのチームもデザイナーやプロダクトオーナーがモブに出入りしながら仕事を進めているそうです。 私達のチームでもモブプログラミングをよくしていますが、開発作業だけでなく、お客さん向けの資料をつくったり、カスタマーサポート対応をしたり、様々な仕事をモブで取り組んでいます。モブ “プログラミング” という名前ですが、モブ “ワーク” という名前の方が実態には近いです。 少し話は逸れますが、とあるチームが私達の現場に遊びに来て一緒にモブプログラミングをした時に、そのチームのプロダクトオーナーの方が話していたことがとても印象的でした。 「エンジニアはずっと黒い画面に向かってひたすらタイピング（プログラミング）している仕事だと思ったけれど、こんなに人と話したりググったりしながら仕事をするんだって初めて知りました」 彼女と開発チームは長年一緒に仕事をしている仲ですが、エンジニアが実際に仕事をしているところ見るのは初めてだったそうです。 「モブプログラミング体験によって、**エンジニアが仕事している姿や働き方**を知ることができたので、彼らとのコミュニケーションが変わりそうだ」 という話をしながら彼女は帰っていきました。 このエピソードはチームに限った話ではなく、相手の仕事をわかったふりしているだけで理解していないことがほとんどです。人間の本質としてわからないものにはやさしくできないもので、それは仕事上のコミュニケーションに少なからず影響しているはずです。「一緒に働いてみる」だけでお互いの仕事を少しでも理解できるのであれば安いものだな、と思います。
# よくある誤解3 : スキルが低いメンバーがいるからモブプログラミングは難しい
私達のチームでモブプログラミングをやろうとすると、新人が多いチームだからずっと教えてるだけになりそう。だからモブプログラミングは難しいです。
「ずっと教えてるだけ」になっても、チームにとって必要なことであればそういうモブプログラミングをすればいいと思います。 そのようなチーム構成の場合、モブプログラミングをしていなくても経験豊富なメンバーが新人のサポートやフォローアップをしながら仕事を進めているのではないでしょうか。モブプログラミングをするからといってチームの状況や関係性が変わるわけではありません。 「ずっと教えてるだけ」が億劫になる気持ちはわかりますが、どのような方法をとるにせよメンバーの教育が必要なチーム状況であればやるしかありません。むしろ一緒にモブプログラミングをすることで、
- 効率がいい：個別に教えるのではなく、チーム全員にまとめて教えることができる
- 過程を学べる：結果だけでなく過程を全員で共通体験しながら学ぶことができる
- タイミングがいい：必要になったタイミングで必要なことを学ぶことができる
というメリットがあります。モブプログラミングの強みの一つは学習効果だと思うので、「存分に活かしてとっとと成長してもらおう」くらいのつもりでまずはやってみるのがよいでしょう。メンバーが成長してくれれば教えてるだけの関係性が変わるので、教える側にとってもメリットがあるはずです。 参考になるかどうかはわかりませんが、
- チーム全員未経験の技術要素を
- プロダクトのドメイン知識がいない遊びに来たエンジニアと一緒に
- プログラミング未経験のビジネスオーナーと一緒に
- プログラミング未経験の新卒同士で
などの条件下でモブプログラミングをやった経験はあります。同じモブプログラミングでも主とする目的は変わりますが、私はスキルの高い・低いを理由にモブプログラミングが難しいと感じたことはありません。 （難しいと感じた場合、モブプログラミングではなくその人と働くのが難しいのかも・・・）
# よくある誤解4 : モブプログラミングをすれば心理的安全になる
心理的安全なチームっていいよね！ モブプログラミングをすれば心理的安全になりそう。
なりません。 前述の通り、モブプログラミングをするからといってチームの状況や関係性が変わるわけではありません。ただし、モブプログラミングをすることでコミュニケーション機会が集中するので、チームの状況や関係性がわかりやすく表れます。 チーム内に一緒にいたくない人がいる場合は、モブプログラミングをすることでストレスが一気に貯まります。チーム内に仲が悪い組み合わせがある場合は、モブプログラミングをすることで簡単に喧嘩が始まります。チーム内で声が大きいシニアエンジニアがいる場合は、モブプログラミングをすることでその人ばかり発言してうまく進まなくなります。仲がいいだけで効果的な議論ができないチームの場合は、順調に進んでいるときはいいけれど問題が発生すると立ち止まってしまいます。 チームの関係性や心理的安全はなにかをすればできるものではなく、日々の活動の結果として徐々に蓄積されていくものです。モブプログラミングしたくらいで心理的安全になるくらいなら誰も苦労していないでしょう。そんな甘えは捨てて、チームに向き合いましょう。 というのはバッサリしすぎている気がするので一言だけ。 モブプログラミングをすることで、自分たちが気づいていなかったメンバーやチームの強み・弱みを発見しやすいです。チームビルディングのための情報収集を目的にモブプログラミングを試しにやってみる、というのは手段としてありかなと思います。
# まとめ
いかがでしたでしょうか。 よく話に出てくる代表的な誤解について自分の考えを書いてみました。 最初に書いた通り、モブプログラミングが万能だとは思いませんが、自分はモブプログラミングから多くの学びを得ました。その学びを必要な人には惜しみなく渡していきたいと思っています。 ここに出ている以外にももしわからないことなどあれば、 #モブプログラミング悩み相談 をつけてツイートしてくれれば、たまに拾って答えてみます。それ以外にも何かあればダイレクトにご連絡ください。ベストエフォートで対応します。
そして引き続き [モブプログラミング Advent Calendar 2018](https://qiita.com/advent-calendar/2018/mobprogramming) をお楽しみください！
https://qiita.com/advent-calendar/2018/mobprogramming
次は [@mohirara](https://twitter.com/mohirara) さんです。 @mohirara さんのステキなモブプロ本はこちら。
https://mohira.booth.pm/items/1044746
---
# チーム開発の現場雑談会をやったよ #現場OST
URL: https://agile-monster.com/blog/gembaost/
Published: 2018-11-23
---
2018年11月19日（月）に、チーム開発の現場雑談会を開催しました。
https://connpass.com/event/106068/
しーばさんとTwitterで話してて、 「そのトピック面白そうだから今度話そう」「じゃあイベントにしてみる？」 っていうくらいの軽いノリでイベントを開きました。 これくらい緩いイベントでもいいんだという参考に、ブログにしておきます。
## 当日の流れ
### テーマだし
参加者全員で雑談会のバックログをつくります。 テーマである『チーム開発の現場』に関して話したいことをそれぞれが出しました。 似ているものはまとめてラベルをつけながら、「このテーマについて話したい」と思うもの3つに投票をしてもらいました。
https://twitter.com/sato_ryu/status/1064468730069929984
### あとは時間が許す限り雑談
あとはバックログの優先順位が高いものから順番に、時間が許す限りディスカッションをしていきました。 ファシリテーションは最初はリーンコーヒーっぽい感じで進行しました。
https://www.slideshare.net/araratakeshi/lean-coffee-60156736
バックログの優先順位の高いものをテーマにディスカッションを開始します。
15分1セットで、タイマーが鳴ったら全員でそのトピックを続けて話すか次のトピックに移動するかを投票して決めて、最大でも1トピックに付き2セット（30分）に留めて時間が許す限り話していきました。
### 突如OSTへ
1トピック話し終わったところで、参加者の方から「テーブルを2つに分けて話したほうが、全員話せてよさそう」とご提案いただき、リーンコーヒーからOST形式に自然と変わりました。
「今日は全員主催者です！」と最初に宣言したからなのか、状況に合わせて自分たちでやり方を変化させていくのは良い場だなーと思いました。
## どんな話をしたのか
正直議論がアツすぎておぼえｔ・・・書ききれないですが、
- どうやってチームビルディングしているか
どっちかっていうと状況の捉え方とかメンタルモデルっぽい話だったかな
- モブが遅いって本当！？
- スクラムおじさんは必要か
などなど、生々しい話がたくさん出てました。
https://bufferings.hatenablog.com/entry/2018/11/20/081149
https://twitter.com/TAKAKING22/status/1064523483541991425
「他人のいる恵まれた環境」っていうのはあるかもしれないけれど、たいていはあなたの頭の中の幻想で、その場所で何をするかを突き詰めていった人たちだけが幻想を現実に近づけることができるのかと。 もちろんとっとと脱出したほうがいい場合もあるので要注意です。
https://twitter.com/TAKAKING22/status/1064525353194946570
無意識のうちにそうなってしまっている可能性があるので注意したい。
勉強会などで刺激を受けて「自分も頑張ろう！」とモチベーションが上がるのはすごくよいことだけれど、現場のメンバーはそれを共有していないので、彼らを巻き込みたいなら同じ体験（モチベーションが上がる）をして共感をつくってからですね。
https://twitter.com/TAKAKING22/status/1064526389812948992
これはイベントの後しーばさんたちと飲んでた時の話かな。
https://twitter.com/TAKAKING22/status/1064539316750180352
開催コストも低いし、自分も学びがたくさんだし、やってよかったなーと思いました。
---
# 超アジャイルのすゝめ #TechOn東京
URL: https://agile-monster.com/blog/superagile/
Published: 2018-11-12
---
https://techplay.jp/event/699906
Tech-on MeetUp#03「Agile for Developers ～やってみよう！お作法だけじゃないアジャイルレシピ～」で、「超アジャイルのすゝめ」というお話をしてきました。
# 資料
久しぶりに、モブプログラミングではなくアジャイルの話をしました。話したいことを話せたので楽しかったです。
資料だけ見ると煽り気味に見えてしまうかもしれませんが、LTのノリで作ってしまったのでいつもどおり現場での臨場感重視です。メッセージ・内容はいたって真面目です。
イベントではいろいろな人とお話できて嬉しかったです。
「デブサミや過去の資料を見てモブプログラミングや現場改善に取り組み始めた」や「明日から始めてみようと思います」というお声がけをいただけて、Outputer冥利につきるなーと思いました。
今日の話の中で触れたUnlearnや研修のお話は、2019年1月開催のRegional Scrum Gathering Tokyo2019でじっくりお話させて頂く予定です。
https://2019.scrumgatheringtokyo.org/index.html
その翌月、2019年2月開催の[Scrum Fest Osaka 2019](https://www.eventbrite.com/e/scrum-fest-osaka-2019-tickets-50902703356)でも暴れてくる予定です。
---
# エンジニアが人の話を聞きながらSNSのタイムラインで盛り上がる理由
URL: https://agile-monster.com/blog/how-to-input-output/
Published: 2018-09-27
---
## エンジニアが勉強会で話を聞きながらタイムラインで騒いでいる理由
### ①インプットしながらアウトプットするため
講演を聞くという行為は、どうしてもインプット一辺倒になってしまいがちです。そして集中して聞こうと思っていても、人間の集中力は脆いので興味がない話が続くと集中力が途切れて眠くなってしまいます。また集中して聞くことに夢中になり、なんかためになったけどよく覚えていないという経験がある人も多いのではないでしょうか。
人の話を聞きながら（インプット）自分の言葉に変換して出力する（アウトプット）という行為は簡単なようで難しいです。機械的な全文書き起こしでもしない限りは、相手の話していることを咀嚼して自分の理解に落とさないと自分の言葉には変換できません。「重要なことだけ書く」ということは、何が重要で何が重要でないかという自分の理解／判断のステップを挟んでいるのです。
インプットとアウトプットは表裏一体であり、アウトプットしようとすることで効率的なインプットにつながることがあります。
エンジニアがプログラミングを勉強する際に、本やサイトを読みながら（インプット）書いてあるサンプルコードをそのまま書き写して実行する（アウトプット）する「写経」をすることがあります。特にエンジニアは手を動かす職業なので、インプットしながらアウトプットすることに慣れている人が多いのかもしれません。
### ②他人と学びを共有しながら学びを深化させるため
「①インプットしながらアウトプットするため」については、話を聞きながらメモをとる方もいるので共感できる人が多いかもしれません。
そのメモをTwitterなどのソーシャルな場に投稿することはどのような理由があるのでしょうか。
ノートやメモなどにアウトプットする場合は自分がわかればいいですが、それをソーシャルな場に投稿する場合は、ある程度他人の目を意識したアウトプットになります。また、学びを残すという視点でも、自分以外の参加者も一緒にメモをしてくれるようなものなので、効率的になることが多いです。
また、話を聞きながら他人の学びと自分の学びを照らし合わせていくことで、自分では理解しきれなかったことが理解できたり、言葉の裏側にある意図や背景を他人のアウトプットから読み解くことができます。
さらに講演者が後からタイムラインを眺めて、参加者のツイートに対して反応をしたり、自分の講演のフィードバックとして自らの学びにつなげることもできます。
このように他人と学びを共有することは、自分の学びを深化することにつながる可能性があるのです。
エンジニアは仕事の中で、自分が書いたコードやドキュメントを他人にレビューしてもらうというスタイルをとることが多く、自分のアウトプットを他人の目にさらすことに慣れている人が多いのかもしれません。また、勉強会だけでなく会議などで議事録をとる際にも、チームチャットなどを使って同様の学びの共有をすることも多いです。
## まとめ
もちろんこれはエンジニア全員がこういう行動をとっているわけではないですし、同じ行動をとっている人たちの中でも全く違う目的で行動している人たちもいるでしょう。あくまで自分自身と自分のまわりにいる人達とこのテーマで話したことを書いてみました。
学び方の1例として参考になれば幸いです。
## 蛇足：人の学び方を笑うな
最近とある勉強をする場で、講演を聞きながらタイムラインで盛り上がっていたところ、
「人の話を聞きながらタイムラインで騒いでいるなんで失礼だ」
という意見を耳にすることがありました。
- 人の話を聞く時は前を見て聞いていることが大切だ
- 他人の話は黙って聞いているものだ
という価値観をお持ちの方はなるほどその通りなのでそれで良いと思います。
一方で、勉強会や研修という場は学びの場で、相手の話を聞きながら学びを最大化させようとアクションをとっていることは本当に失礼なのでしょうか？
答えは、わかりません。
自分も勉強会などで講演者や講師として登壇することがあるのですが、講演する目的の1つとして、聞いてくれている皆さんに何かを学びや気づきを持ち帰って欲しいという思いがあります。なので、参加者が学びを最大化させようとしてくれているのであれば最＆高に嬉しいです。また、自分自身も講演することを通して学びを得たいと思っているので、ポジティブ・ネガティブに限らずフィードバックをもらえることも最＆高に嬉しいです。
ところで、人の学び方に口を出すことは失礼ではないのでしょうか？
といったように、失礼合戦を始めるとキリがありません。どちらも自分がそうするべきだと思っている行為をとっているのであれば、お互いの「正義」がぶつかるだけです。ましてや講演者にとって失礼かどうかの話をしているのであれば、勝手に他人のふんどしで相撲とるなよって感じですね。
そんなことしている暇があったら、いろいろな考え方を持った人を受け入れて**自分自身がどういう行動をとるか**を考えていきたいなと思いました。
---
# モブプログラミングスタートアップマニュアルを更新しました！
URL: https://agile-monster.com/blog/mobpro_manual/
Published: 2018-09-03
---
# 更新した内容
- 全体のデザイン・言葉遣いの調整
- 最近のスライド内容から学びの部分のスライドを追加
- 「モブプログラミングについて知る」の情報を最新化
# 資料
---
# 「スクラム、モブプロ、アジャイルエンタープライズ -小さなチームと大きな組織-」という講演をしてきた #CEDEC2018
URL: https://agile-monster.com/blog/cedec2018-mobpro/
Published: 2018-08-24
---
CEDEC2018で、 [@kawaguti](https://twitter.com/kawaguti) と「スクラム、モブプロ、アジャイルエンタープライズ -小さなチームと大きな組織-」というお話をしてきました。
https://2018.cedec.cesa.or.jp/session/detail/s5ac0b0ab97326
# CEDECという場
まさかゲーム業界にいない自分がCEDECという場でお話できるなんて思っていませんでした。なので今回参加＆講演できることになってとても嬉しかったです。 参加してなにより驚いたのはCEDECという場の熱量です。業界は違えど、負けていられないなーと思いました。来年はちゃんと公募出して参加しよう！
# 資料
モブプログラミングのお話はたくさんさせてもらってきましたが、今回はいつもと違う場でお話するということで、かなり準備に苦労しました。
- 具体的な事例よりもそこから抽出した学びを中心にする
- プロダクトづくりを生業にしている人であれば業界が違っても伝わる言葉で話す
- 「生産性」について本気で考える
- チームで仕事をするということについて本気で考える
ということを意識して構成してみました。うまく話せたかどうかはわかりませんが、良いフィードバックをいただけたのでよかったです。
* CEDEC用に自己紹介スライドをデザインしております
---
# 明日からできる働き方改革「モブプログラミング」 WHOLE TEAM APPROACH
URL: https://agile-monster.com/blog/mobprogramming-as-work-style-reform/
Published: 2018-07-31
---
明日からできる働き方改革モブプログラミング WHOLE TEAM APPROACH」と銘打った。でも、個人的にはモブプログラミングによって働き方やチーム活動のアプローチについてかなりの衝撃を受けたので盛っているつもりは毛頭ない。
## ハイライト
モブプログラミングの事例とその学びはもちろんですが、「モブプログラミングは生産性が低いのでは？」というよくある問いに真正面から答えてみた。
自分自身もウォーターフォールのような開発をしていた頃からアジャイル開発に取り組んできたこれまでの期間を振り返ってみても、作業を分担するが当たり前になってしまっていて、それをいかに効率的にやるかということが中心になってしまっていた。
モブプログラミングの経験を受けてこのことに気づいた時に、 **作業を分担すること＝効率が良い** という一種の思考停止をしてしまっていた自分達に気がついた。
先程の「モブプログラミングは生産性が低いのでは？」という問いはかなり多く聞かれてきたが、同じような疑問を持った方は一度資料を読んでいただくことをオススメする。
## 資料
モブプログラミングをはじめてから1年3ヶ月。これまで経験してきたこと、いろんなところで講演してフィードバックをもらったこと、モブプロの生みの親であるHunter IndustriesのWoodyやChrisと話したことで、かなり伝える言葉が精査されてきた。 おそらく日本一有名なモブプロチームの事例と学びです。モブプログラミングに興味がある方はもちろん、そうでなくてもチームやプロセスの改善に興味がある方はぜひご一読下さい！
---
# Agile Japan2018基調講演「モブプログラミングと”フロー”の力（Woody Zuill）」を聞いてきた #agilejapan
URL: https://agile-monster.com/blog/agilejapan2018-mobprogramming/
Published: 2018-07-19
---
Agile Japan 2018に参加してきました。Agile Japanは2013年に講演した時ぶりに参加させてもらいました。 今回は基調講演の「[モブプログラミングと”フロー”の力（Woody Zuill）](https://2018.agilejapan.jp/session.html#session00)」についてレポートします。
## レポート：モブプログラミングと”フロー”の力
https://www.slideshare.net/hiranabe/mob-programming-and-the-power-of-flow-agilejapan2018keynote
### モブプログラミング
>
>
>
>
> **セッション概要**
>
>
> 5人で1台のコンピュータを使ってプログラミングをする？そんなことをして生産性は高まる？そんな疑問はもっともだと思います。その疑問に回答するのは簡単ではありません。我々が”フロー”の力を理解し始めるまでは - モブプログラミングはどうすれば一つのチームが一緒に効率よく働くことができるかということを探求する過程で発展してきました。一旦始めてみると、我々はモブプログラミングが次のような様々な面でより良い効果を生み出すことにすぐに気づきました。 ・今までよりも多くの作業を終えることができた ・より多くの重要な作業を終えることができた ・作業の品質が劇的に向上した ・チームのナレッジ、スキル、遂行能力が急速に進歩した ・そしてチーム全員がとても楽しんで仕事をしていた 1日を通してみんなで一緒に働くことがこれらの良い効果をもたらす主な要因であることは明らかでしたが、それでもこの働き方がなぜこんなにうまくいくのかをまだ理解できていませんでした。 これを理解するためのヒントが"1個流し”の実践にあることは早い段階で気付いていましたが、この重要性を本当に理解したのは”フロー”の力を探求し始めた時でした。 皆さん、私と一緒にこの探求の結果を考察してみて、モブプログラミングと”フロー”の力の理解をより深めてみましょう!
>
Woody Zuillさんはモブプログラミングの生みの親である。 WoodyさんがHunter Industriesに参加する時に、
- チームの邪魔をしないでください
- 見積りはしません
- 延期をする権利をチームが持ちます
という条件を出した。そこから現場改善に取り組んでいく中で生まれたのがモブプログラミングである。 「A day of Mob Programming」という動画を見たことがある方も多いのでないでしょうか？
https://www.youtube.com/watch?v=p_pvslS4gEI
この動画はHunter Industriesの現場でモブプログラミングをしている1日を早送りでまとめたものである。そして今ではHunter Industriesはモブプログラミング発祥の場として有名である。
モブプログラミングは、同じ仕事を同じ時間に同じ場所で同じコンピューターですること。Woodyはモブプログラミングは本当にアジャイルだと思っているそう。
モブプログラミングは、ドライバー（PCを操作する人）とナビゲーター（それ以外の人）という2つの役割が存在する。 よく勘違いされるが、1人が作業をしているのをまわりで見ていることがモブプログラミングではない。モブプログラミングはチームからのインプットを受けてチームでプログラミングをすることである。考えている人がまわりにいて、ドライバーはチームの考えをキーボードで打つだけなのである。 そして、今では世界中でモブプログラミングをしている。 （チームの写真を使ってくれてありがとうございます） モブプログラミングの話をしていると、いつも聞かれる質問がある。 **「モブプログラミングは生産性があがるのか？」** この答えは私もわからない！ ただし、モブプログラミングによって仕事がうまくいくことはわかった。
1つ1つの仕事を組み合わせることでシステムができるのではなく、1つ1つの仕事の相互作用が重要でそれによってシステムができあがっていく。
以下の3つの視点がよく出てくる。
- 効率＝ものごとを正しくする
- 生産性＝アウトプット／インプット
- 効果＝正しいことをする
ただし、それぞれについて考えるとこうなってしまうことが多い。
- 効率＝仕事を忙しくする
- 生産性＝間違う
- 効果＝正しい
たいてい最初に浮かぶ問いは正しい問いではない。正しい問いは何なのかを考えることが最初の1歩である。正しくない問いにたいして頑張って答えることにあまり意味はない。問いの答えを探しても答えは存在しないので、それよりは正しい問いを見つけることが重要だ。 **「モブプログラミングは生産性があがるのか？」** ではなく、 **「モブプログラミングは効果的なのか？」** という問いに変えてみよう。そしてその問いを少し反対から考えてみて、 **「本来一緒に仕事をするべき人達がバラバラに仕事をする場合にどうやってうまくいかせるためにはどうすればいいか？」** ということを考えてみる。バラバラに仕事をすることで効果的ではなくなってしまう要因は何なのだろうか？
以前、効果的ではなくなってしまう要因を考えるワークショップをやったときは50個見つかった。 これらの問題はモブプログラミングを始めるとすべてなくなってしまう。モブプログラミングは、効果的にするためにはどうすればいいかを学ぶことにフォーカスしたことから生まれたのである。
例えば質問をして答えが返ってくるまでのキューのことを考えてみよう。 1時間ごとに質問が1つ発生するとする。 質問に対して答えが返ってくるまでの待ち時間が2分の場合、1日に16分ムダになる。 質問に対して答えが返ってくるまでの待ち時間が10分の場合、1日に70分ムダになる。 質問に対して答えが返ってくるまでの待ち時間が1時間の場合、1日に4時間ムダになる。 質問に対して答えが返ってくるまでの待ち時間が1日の場合、1日中ムダになる。 この待ち時間をより効果的にするためにはどうすればいよいのだろうか。それは待ち時間の間に別の仕事をすることだ。しかし、このやり方は「在庫を抱える」という別の問題を生んでいる。 別の仕事をすることで忙しくなるので、一見効率がよくなっているように見えるが答えが返ってこないことが真の問題なのである。在庫はできるだけ少なくしないといけない。別の仕事をすることで症状を小さくできているかもしれないけれど、「在庫を抱える」という問題は一切解決していない。
この「在庫を抱える」という問題は、チームで一緒に働くだけで消えるのだ。答えを待つ必要がない。その場に答える人がいるのだから、自動的に1個流しになる。
### フロー
今日のテーマである「フロー」について考えてみよう。2つのフロー（心理的なフローとリーンフロー）について考えてみたい。
#### 心理的なフロー
心理的なフローとは、ゾーンに入っている状態のことだ。没入感が生まれ、時間の感覚がなくなる。チームで働くことで心理的なフローの状態をつくれるのだろうか。 他の産業で同じようなことをしている例を探してみた。
- バンド
- 手術室
必要な奏者がいないバンドの音楽を聞きたいだろうか？ 必要な人がいない手術室に運ばれたいだろうか？ 彼らはチームのゴールを持っていて、その上で個人のゴールも持っている。個人のフローとチームのフローは＆でつなぐことができるのである。モブプログラミングも同じだ。
#### リーンフロー
リーンフローとは製造業のフローのことである。製造業ではキューイング（在庫）が最も重要な問題だ。グリーンを増やしてレッド（待ち時間）を減らさなければいけない。
ではソフトウェア開発ではどうなのだろうか。やはり同様に、キューイングがない、待ち時間がない、割り込みがない、マルチタスクがない状態を目指す必要がある。
そしてそこに近づけるために、ソフトウェアのすべての工程で学ぶのである。 モブプログラミングは個人の仕事ではなく仕事のフローを最適化している。チーム全員で一番いい状態に持っていくのである。 結局、すべての問題の根幹はキューイングである。モブプログラミングはキューイングをなくすことである。
### モブプログラミングは効果的なのか？
ここで、 **「モブプログラミングは効果的なのか？」** という最初の質問に戻る。 モブプログラミングでは、フローとフローを組み合わせることで効果的にする。
- 個人のフロー
- チームのフロー
- リーンフロー
モブプログラミングはいつでも自由に出入りしていいので個人のフローが存在する。もちろんチームで一緒に仕事をするのでチームのフローも存在する。モブプログラミングはみんなの頭の中のContinuous Integrationなのだ。 そしてリーンフローもある。1個流しをすることでキューイングをなくし、常にフィードバックを受け続ける。 1つのことに集中すればいろんな問題が消えていくのである。
### 最後に
Woodyは26〜27歳の時に、Robert Henriという芸術家に会いに行った。Robertはどうやって芸術を作っているかを見せることはできるけどもっと重要なことがあるといってこの言葉を送ってくれた。
>
>
> 芸術をつくることが大事なのではなく、芸術をつくることができる素晴らしい状態にいることが大事なのである。
>
>
モブプログラミングも同じである。要するに環境を整えることが重要なのだ。環境が自然になると良い結果が生まれるのである。 ちなみに、Woodyのスライドのイラストはすべて彼の奥さんが書いたものだそうだ。
## まとめ
Woodyが生んだモブプログラミングを知って、チームでモブプログラミング＝モブワークを続けてきてたくさんの学びを得ることができた。
昨年作ったこのスライドが少しだけ世の中に広まって、この後から日本でもモブプログラミングの場が一気に増えていったように思う。 自分達のチームでは「効果的じゃないと感じたらやめよう」というたった一つのルールのもとでモブプログラミングを始めたが、現在に至るまでずっとモブプログラミングを続けている。Woodyの話は自分達が体験していることがすべてつまっているように感じた。 自分もいろいろなところで話しているが、モブプログラミングはやってみないとわからないことが多いので、もしよかったら一度でいいので試してみてほしい。 もちろんなにかお手伝いできることがあればいつでもご連絡ください。
## Thanks Woody!!
To Woody Thank you for great presentation and talk! We learned a lot from you.
---
# 「どれくらい○○したらよいですか？」っていう問い
URL: https://agile-monster.com/blog/how-to-ask/
Published: 2018-07-18
---
プロダクトをつくる仕事をしていると、
「どれくらいテストしたらよいですか？」
「どこまで考慮したらよいですか？」
「（とあるルール）の範囲ってどこまででしょうか？」
といった問いと遭遇することがある。
ソースコードやデザインのように形として存在するものが成果物である仕事をしている場合、詳細を明らかにしないとできあがらないのでこういう問いをしたくなる気持ちはわかる。
ところが、自分の経験上こういう問いに対して的確な答えが返ってきたことはほとんどない。
## プロダクトづくりの世界は曖昧なことだらけ
「問いAに対する答えはBだ！！」のように答えが自明なものであればたいてい最初に教えてくれるし、そうでなくても聞けばすぐに答えが返ってくるので困らない。
ところが、プロダクトをつくるプロセスの中で生まれる問いの半分くらいは決まった正解が見えない曖昧なものであるように感じる。
実際にあった問いの例（脚色あり）を2つ紹介する。
##### 問いの実例①
プロジェクトの後半で、開発がようやく終わりテストフェーズに入ることになった。当初の計画よりもスケジュールが遅れていたため、チームで話し合いリリーススケジュールを優先させることになった。
テストを実施するにあたり、新人エンジニアがプロジェクトマネージャーに、
「どれくらいテストしたらよいですか？」
と問いかけた。
##### 問いの実例②
ハッカソンを実施する時に、情報の取り扱いに関するルールを定めて参加者に予めアナウンスされていた。いざハッカソンが始まってそれぞれのプロダクトづくりが本格化すると、とある参加者が運営に
「（情報の取り扱い関するルール）の範囲ってどこまでがOKなんでしょうか？」
と問いかけた。
## すり合わせて合意していく
こうした問いには明確な答えというものが存在しない。人によって、状況によって、あるいは結果によって答えが変化する。プロダクトオーナー、エンジニアリーダー、マネージャー、ハッカソン運営のような判断をする人にとっても、答えが曖昧であることは同じである。
ではどうすればいいのかというと、お互いに歩み寄ってすり合わせて「これでいこう！」と合意するしかないのである。作り手側も判断する側も経験した身として、それぞれの視点でのアプローチを考えてみる。
##### 作り手側から
「はっきりしてくれ」「決めてくれないと作れないよ」と言いたくなる気持ちはわかるが、そんなことを嘆いたところで何も解決しない。仮に強引に決めてもらったところで、実際に作っていく中で辻褄が合わなくなったりして、結局同じ問いにぶつかることも多い。
自分の場合は、そんな雰囲気を感じた時はとりあえず今ある情報の中で作り始めてしまう。作り始めることで、最低限決めなければいけないことやおとしどころがより具体的になってくる。
そうしてできたプロダクトのプロトタイプと溜まった情報を持って行き、ステークホルダーと話す。そうすると、
「どれくらい○○すればよいのか」
という曖昧だった問いが、
「これとこれならどっちですか？」
「これなら実現できますがこれでよいですか？」
と少しだけ具体的な問いに変わる。
結局のところ、曖昧であるということは曖昧である理由が存在するので、見えないものを相手に議論したところで時間がかかる上に建設的な議論になりにくい。それならばたたきをつくることで情報を集め、そこから足し引きをして自分達の答えをすり合わせていく方が早い。
問題 vs 私達の構図を作るのだ。
##### 判断する側から
「そんなこと言われてもわからない」「それくらい考えてよ」と言いたくなる気持ちはわかるが、具現化する最前線にいる人達は最終的にはつくるものを明らかにしないと仕事を終えることができない。
- 彼らが一番情報を持っている
- 彼らがつくることができないと何も生まれない
という事実を真摯に受け止めて、彼らから情報を引き出して、彼らがつくることができる状況を整えることに全力を注ぐという姿勢が必要だ。
とはいうものの、当然ながら決められないものは決められないし、判断できないものは判断できない。であれば、それを素直に伝えた上で、どうすればいいかを一緒に考えて自分ができることからやっていけばよい。
彼らはあなたの妄想を実現する奴隷ではなく、一緒に問題解決をする仲間なのだ。
## まとめ
答えが明確な問いは、調べたり知っている人に聞いたり試すことで答えを見つければよいだけなので簡単だ。一方で答えが曖昧な問いは、手も時間もかかってしまう。
しかし、プロダクトづくりは曖昧な問いとの戦いである。曖昧な問いに答えていくことこそがプロダクトを形作っていくのである。なのでどのような立ち場であっても、曖昧な問いを楽しむ気持ちって大事だなって思った。めんどくさいけどね！
---
# 組織づくりや場づくりのための「OST実践ガイド」がすごくよかった
URL: https://agile-monster.com/blog/ost-guide/
Published: 2018-07-17
---
「OST実践ガイド」がすごくよかった。 個人的にOSTを運営した経験があったことのでジャケ買いをしたが、「OST実践ガイド」はOSTのHOW TO本に留まらず、OSTを通して人と人の関係性や組織のマネジメントなどにも触れられていて、組織づくりや場づくりに興味ある方にもおすすめの内容だった。
[itemlink post_id="2327"]
## Open Space Technology
ちょっとだけ前提知識の補足をしておくと、OSTはOpen Space Technologyの略である。
>
>
> 1985年にハリソン・オーウェンによって提唱された。 5人から2000人といった小人数から大人数にまで一堂に会して行えるのが特徴である。参加者が課題を提案してミーティングを行う仲間を募り、課題を解決するプロジェクトを創出することができる。参加者の当事者意識や自発性を喚起するとともに、参加者の主体的な発案、対話を促す。 via [オープン・スペース・テクノロジー - wikipedia](https://ja.wikipedia.org/wiki/%E3%82%AA%E3%83%BC%E3%83%97%E3%83%B3%E3%83%BB%E3%82%B9%E3%83%9A%E3%83%BC%E3%82%B9%E3%83%BB%E3%83%86%E3%82%AF%E3%83%8E%E3%83%AD%E3%82%B8%E3%83%BC)
>
>
テクノロジーという名前がついているので技術的なことのように思いがちですが、実際はそうではなく簡単に言うと、OSTとは会議スタイルの1つである。 オープン・スペース・テクノロジーのユーザーガイド（英語）があって、オープンスペースの定義や基本構造から簡単な場づくりの方法も記載されているので、英語が苦手でない方はぜひオリジナルソースとして見ておいていただきたい。
[OPEN SPACE TECHNOLOGY A User's Guide（アーカイブ）](https://web.archive.org/web/20200613211606/https://www.openspaceworld.com/users_guide.htm)
## OST実践ガイド
まずなにより「OST実践ガイド」は翻訳本ではなく、実際にOSTによる場づくりを何度も経験されている著者のお二人による書き下ろしなのでとても読みやすかった。 本書は7章から構成されており、
- 序章「今なぜオープン・スペース・テクノロジーなのか」
- 第1章「リーダーが生まれてくる土壌をつくるOST」
- 第2章「OSTを実践しよう」
- 第3章「OSTのファシリテーションと組織マネジメントへの示唆」
- 第4章「OSTを柔軟かつ創造的に活用する」
- 第5章「OSTの実践事例」
- 終章「OSTが育むリーダーシップがもたらす個人、組織、社会のあり方」
- 付録（OSTの台本、よくあるQ&A、他ワークショップの進め方）
という構成である。 目次の通り、単なるHOW TO本の内容に留まらずOSTが組織や場に対してどのように機能するかやケーススタディまで載っていて、OSTに関するWHY-HOW-WHATが一冊に収まっている。OSTについて知りたければ間違いなくこの1冊である。 第5章の実践事例（ケーススタディ）はすべて日本の事例であり、実際の組織でどのような目的のもとでどのように準備・運営が進められてどのような成果が得られていたか紹介されているので、とても参考になった。 個人的には第3章の「OSTのファシリテーションと組織マネジメントへの示唆」が好きだ。OSTをファシリテーションする際にどのようなことを意識すべきが書かれているのだが、ここに書かれている内容はOSTという場に限らずに組織やチームをつくっていく上でも必要なことである。・・・などと読みながら思っていたら、章の中で組織マネジメントについても言及されていたので大変興味深かった。
- 学習する組織
- ファシリテーション
- リーダーシップ
- ダイアログ
- 組織マネジメント
- 成功循環モデル
OSTの実践にはそれほど興味がなくても、このあたりのキーワードにピンと来る人は、まずは「OST実践ガイド」を手にとってパラパラ読んでみることをおすすめする。
## 私にとってのOST
### カンファレンス・勉強会にて
自分がはじめて海外カンファレンスに参加した時にOSTに初めて遭遇して、その盛況ぶりにとても驚いたことを覚えています。最近では日本でもRegional Scrum Gathering Tokyo、Scrum Masters Night!、JJUG CCCなどをはじめ、OSTを取り入れているカンファレンスや勉強会が増えているので、どこかで体験したことがある方も多いかもしれません。 また、[Rakuten Technology Conference 2017](https://tech.rakuten.co.jp/rtc2017/)ではUnconferenceという形で企画・運営を経験しました。
- [楽天テクノロジー【アン】カンファレンス2017 #rakutentech](https://plaza.rakuten.co.jp/rakutentech/diary/201710250000/)
Rakuten Technology Conference 2017 Digest - YouTube この時は「エンジニアの未来会議」と題して、組織・会社・職種の壁を越えてエンジニアの未来について考えてみるということをテーマにOSTを開催しました。 OSTのファシリテーションは初めてだったので、「人が来てくれなかったらどうしよう」「盛り上がらなかったらどうしよう」などの不安を抱えながら場づくりをしました。ところがいざ始まってみると、最初から参加してくださった方、楽しそうな雰囲気につられてなんとなく見に来た方、講義形式のカンファレンスに疲れて休憩がてらふらっと立ち寄った方などどんどん人が集まってきました。参加してくださった方々に話を聞いてみると、OST初体験の方が多かったにも関わらず、場としてとても盛り上がりました。
### ふりかえりにて
また、カンファレンス・勉強会以外にも、組織のふりかえりとして「シン・未来会議」という形でOSTの要素を取り入れて実施したことがある。
https://speakerdeck.com/takaking22/sinwei-lai-hui-yi-sukuramuwozhi-eruzu-zhi-dukuri-number-rsgt2017?slide=8
所属組織の未来を考えるという目的のもとに、ふりかえりとOSTを混ぜた形式で進行をした。話したいトピックのもとに集まり、グループごとにディスカッションをすると形式にし、そのままそのグループで取り上げた問題とその解決策を持ち帰って実施してもらった。 カンファレンス・勉強会でのOSTと違って、参加者は同じ組織のメンバーなので見知った顔同士とはいえ、働いている中で膝を突き合わせて自分達の未来を語る場というものはつくりにいかない限りまず生まれない。OSTの要素を取り入れることで、上下関係などを忘れてフラットに問題 vs 私達の構図でコミュニケーションすることができ、単なる問題解決ではなく語りたい未来について話し合うことで未来志向で話し合えるよい場となった。
## 最後に
OST自体ものすごく強力なツールであると思うが、単なるツールとしてではなく場づくりの話だと考えると世界がものすごく広がる。 カンファフェンスや会議というワンショットを考えてもよい場をつくることは難しいことなので、継続的に存在する組織でよい場をつくることは本当に大変だ。OSTが大事にしている「リーダーシップの創出」、「フラットなコミュニケーション」、「心理的安全性」、「カオスを受け入れる」というポイントは、自分が日々の組織運営の中でテーマにしていることとリンクしている。 同じように組織のマネジメントに奮闘されている人にとっても、「OST実践ガイド」は役に立つような気がしています！
[itemlink post_id="2327"]
---
# 学校では教えてくれないググり方（Google検索）のコツ
URL: https://agile-monster.com/blog/how-to-search/
Published: 2018-07-08
---
## Google検索でできる基本的なこと
ググり方のコツ・・・の前にそもそもGoogle検索でできること＝機能について知っておく必要があります。
ここで紹介する以外にも実はGoogle検索には細かなTipsや隠しコマンドのようなものも存在しますが、ここでは代表的なものを紹介します。
### AND検索
AND検索とは、
**ワード1 ワード2 ワード3**
のように、スペース区切りでワードを足していくことで実行できます。
入力したすべてのワードに当てはまるページが検索対象となります。
上記の例のようにワードを足していくことで、検索結果の件数が絞られていくことがわかります。検索ワード次第では検索結果が大量に出てきてしまうので、欲しい情報を効率的に集めるためにはAND検索をうまく活用して情報を絞っていく必要があります。
### OR検索
OR検索とは、
**ワード1 OR ワード2**
のように、ワードとワードを「（スペース）OR（スペース）」でつなげていくことで実行できます。いずれかのワードに当てはまるページが検索対象となります。
上記の例のように、AND検索とOR検索では、OR検索の方が検索結果の件数が多いことがわかります。AND検索に比べて使う頻度は少ないですが、覚えておくとよいです。
### 特定のワードが含まれる検索結果を除外する
**ワード -除外したいワード**
と入力することで、検索結果から除外したいワードを除外することができます。
一度検索したいワードで検索した際に、不要な情報が多く含まれている場合に除外を使っていくと便利です。
### 特定のサイトのみの検索結果を取得する
**ワード site:検索したいサイトのURL（ドメイン名）**
と入力することで、特定のサイトのみの検索結果を取得できます。
情報が欲しいサイトが決まっている場合は、この方法で指定するのが手っ取り早いです。
## 検索のコツ
使い方としては「Google検索でできる基本的なこと」で紹介したことで事足りるが、それ以外のコツを紹介します。ちなみにここから先はGoogleとは関係なくなっていきます。
### エラーメッセージでググる
パソコンを利用している時、あるいはサービスを利用している時にエラーが起きることがあります。その時は慌てずに「エラーメッセージでググる」ことを試してみましょう。
エラーが出るとビックリしてしまうかもしれませんが、エラーが出ているということは裏返すとそのパソコン／サービスを作っている人間がエラーを予測をして何かしら情報を表示してくれているということでもあります。
そのエラーメッセージで検索すると、同じようなエラーで困った人が解決した方法や状況を解説してくれているサイトが見つかることもよくあります。もちろんどうしようもない場合もありますが、エラーメッセージを見て固まってしまう前にぜひ一度試してみてほしいです。
### 英語でググる
欲しい情報がなかなか見つからない時は英語で検索してみることをオススメします。
[Wikipedia](https://en.wikipedia.org/wiki/Languages_used_on_the_Internet#cite_note-UofCLBWApril2013-1)によると、2018年6月現在でW3Techsが見積もったインターネットにおける情報量の割合は上記の表の通りです。日本語で検索するよりも英語で検索した方が単純計算で30倍程度の情報量があります。
当然コンテンツも英語なので読むのは大変かもしれませんが、欲しい情報を入手したいのであればGoogle翻訳などを利用しながらでも頑張って読んでみると英語の勉強にもなるので一石二鳥です。
特にエンジニアであれば、ほとんどの情報のオリジナルソースは英語です。日本語に翻訳される頃には情報は古くなっていることも多いので、英語で情報を取得できるようになっておくことはとても重要・・・というより死活問題だと個人的には思います。
### リアルタイムなことを検索する
「電車止まってる？」 「今地震来なかった？」 のようなリアルタイムな情報を知りたい時はコツがあります。
それは、TwitterやFacebookなどのSNSから情報を取得することです。 直接それらのサービスで検索をしてもいいですが、
- [Yahoo!のリアルタイム検索](https://search.yahoo.co.jp/realtime)
を利用することができます。もちろんSNSですので、誤情報や偽情報の可能性があるので、あくまで参考程度に見ておくのがよいでしょう。
エンジニアの場合は、 「あれ？AWSが遅い！」 「あれ？Slackがおかしい！」 「あれ？Githubがおかしい！」 のような時にリアルタイム検索をして、自サービスの問題なのか、自社のネットワークの問題なのか、そもそもこれらのサービス自体の障害なのかを切り分けます。
## 【エンジニア編】検索のコツ
最後にエンジニア編の検索のコツを紹介します。
### エラーメッセージ／Logでググる
エラーメッセージについては上記でも書きましたが、エンジニアでも必要なことです。 特にエンジニアの場合はブラウザやサーバーでLogを見て、それらのメッセージで検索することで問題解決のヒントが得られたりします。 エラーメッセージやLogから自分の環境依存の情報（サーバー名やディレクトリ名など）を省いて検索すると見つかりやすいです。
### 公式ドキュメント
基本は公式ドキュメントから情報を探すのが確実であることが多いです。
**ワード site:公式サイトのドメインワード 公式**
などでググって解決できれば正確な情報に素早くアクセスできます。
### Github
[Github](https://github.com/)も情報がたくさん詰まっています。 世の中のエンジニアが書いたソースコードから、問題解決のヒントを得られます。
### Qiita / Stackoverflow
[Qiita](https://qiita.com/)や[Stackoverflow](https://stackoverflow.com/)というサイトはエンジニアのKnowhowがShareされています。
### Slideshare / Speakerdeck
[Slideshare](https://www.slideshare.net/)や[Speakerdeck](https://speakerdeck.com/)はスライドが公開されているサイトです。 How Toものなどはよくスライドで公開されているので、参考にしてみてもよいでしょう。
### SNSで投げかけてみる
上級者向けですが、とても有効な手です。
あらかじめコミュニティ活動などでその道のプロとSNSでつながっておき、その人達向けにSNSなどを通じて投げかけてみると意外と答えてくれます。
もちろん用法用量・相手は考えて使うべきですが、自分なりの情報収集の道を確保しておくことも重要なスキルです。
---
# 「アジャイル開発は計画をしない」について
URL: https://agile-monster.com/blog/planning_for_agile/
Published: 2018-07-04
---
アジャイル開発においてよくある誤解として、「アジャイル開発は計画をしない」というものがある。今回は実際にそういう質問を受けたので、マジメに答えてみる。
## なぜ誤解が生まれるのか
アジャイルソフトウェア開発宣言にある4つの価値の中の1つである、
計画に従うことよりも変化への対応を
から誤解する人が多いように感じる。あるいは間違った解釈でアジャイル開発を騙っている方に巡り合ってしまったのではないだろうか。
でもよく読んでみると（いや、読まなくても）、「計画をしない」なんて一言も書いてない。
## むしろ計画を大事にする
自分はアジャイル開発をするようになってから、むしろものすごく計画を大事にするようになった。
なぜなら変化に対応するためには、
- 変化があったことを知ること
- 変化の度合いを知ること
が必要だからである。
行動する前に計画を立てておくことで、計画とズレたことがわかり、どれくらいズレたのかもわかるのである。
それが「次はこうしよう＝学習」につながり、結果として変化に対応することにつながる。
気づけないことには、対応も何も生まれないのである。
## 計画する目的と投資
特にソフトウェア開発の現場において、ほとんどのケースにおいて不確実性が高い。なので頑張って計画を立てたところで、計画通りにいかないことが多い。ここで考えたいのは、うまくいかなかった計画はムダなのだろうか。
自分の考える計画の目的は、**学習を最大化すること**である。
頑張ってみたところで当たらない計画であれば、当たるかどうかはさして重要ではなく、そこから何を学べるかが重要である。つまるところ、学習効果が高い計画とはなにかを考えて計画をするようになる。
ただし、そこにどれくらい時間をかけるのかという投資判断は必要だ。かける時間（コスト）に対してどれだけのリターン（学習）があるのか、またどれだけ時間（コスト）をかけられるのかは現場の状況によって違うので、ROIを考えながら計画をする。
## 正確な計画とはなんだろう
なんとなく正確な計画をしなければ意味がないだろクラスタがいる気がするので少しだけ。
不確実性の高い状況とは情報がない状態である。情報がない状態で、いくら計画に時間をかけたところでさして正確性はあがらない。
では情報をどうやって集めるかというと、学習するしかないのである。
計画の精度が上がるのは、チームの学習が積み上がり、かつ「前と同じくらい」「前のと比べてこれくらい」という情報（経験）が積み上がった時だけである。
正確な計画云々と言うのであれば、ぜひその具体的なHowを教えていただきたいものだ（一休さん方式）。
## 最後に
考えてみた結果、計画を大切にしたい人も、変化に対応することを大切にしたい人も、結局のところ計画を大切にするしかない。
アジャイル開発とはあまり関係ない内容になってしまったが、得てして本質を考えるということはたいていそんなものだと最近思う。
もちろんこの考えが必ずしも正しいとは思っていないので、奇譚なきフィードバックをいただけると自分の**学習**になるので幸いである。
---
# 学習する自分をつくる
URL: https://agile-monster.com/blog/how-to-learn-2/
Published: 2018-06-21
---
最近プログラミング経験がない新人にプログラミングを教える機会があって、彼らを観察していると様々な気付きを得ることができる。
最初の頃はプログラミングのプの字も知らなかった彼らが、1ヶ月もすると、 ソースコードを書いて、 クラウド上で動かして、 Migration Fileでデータベースを管理して、 Gitを使ってコードを管理している。 スプリントプランニングをして、 デイリースクラムをまわして、 ふりかえりをして、 スクラムオブスクラムで障害リストを運用している。 もちろんすべてがうまくまわっているわけではないが、既に彼らは彼らなりの改善サイクルをまわし始めていて、学習する組織ができているように見える。 そんな彼らの変化を見ていると、「経験がないからできない」なんてことはとてもじゃないが恥ずかしくて言えなくなってしまった。
## 人は学んでいくことで自分の可能性にキャップをする
これは自分の仮説だが、人はふつうに働いてふつうに経験を積んでふつうに学んでいくことで、気づかない内に自分で自分の可能性にキャップをしてしまうのではないだろうか。
- これは難しかったからきっとこれも難しいだろう
- これもダメって言われたからきっとこれもダメだろう
- また忙しくなるかもしれないから新しいことをはじめるのはやめておこう
一方でまだ経験を積んでいない新人の彼らは、キャップをしてしまう理由＝立ち止まる理由すら持っていないのでとりあえずやってみることでなんとなくできてしまう。「境を越えた」という認識すら持たずに新しい可能性を受け入れて成長をしてしまう。 ほとんどの場合において、はじめる・はじめない、できる・できないはこれくらいの差でしかないように思う。 しかし、そんな新人の彼らも学びを積み重ねていくことで境が見えるようになり、いつしか自分の可能性にキャップをしてしまう日が来るのかもしれない。
## 自分のキャップをぶち壊す
きっとこれは避けようと思っても避けられないもので受け入れるしかない。 ではどうしたらよいのか。学びを積み重ねていくことでキャップしてしまうのであれば、定期的に自分のキャップをぶち壊す活動をすればいい。
### 頭のネジが飛んだ人たちに会いに行く
自分は定期的に頭のネジが飛んだ人たちに会いに行くことにしている。 人の話を聞いていて、「おお！」「なるほど！」と頭に刺激を受けた体験が誰にでもあるだろう。この体験こそが自分のキャップをぶち壊す活動だと思う。 意識しているのかどうかはわからないが、自分のキャップをぶち壊し続けて学び続けている人達、頭のネジが飛んだ人達が世の中にはいる。彼らの話はいつも刺激的で、彼らから刺激を受けることで、自分のキャップもぶち壊れていく。
学び続けることでキャップができてしまうのであれば、定期的に壊してしまえばいい。これこそが**学習する自分**をつくるということなのではないだろうか。 会社の中にいればラッキーだが、会社にいなければ勉強会でもカンファレンスでもいい。
自分に刺激を与えてくれる人をいかに見つけて刺激をもらうのかが**学習する自分**をつくる上ではとても重要なことだと思う。
ただし、そういう人たちと会うことは得てしてめんｄ…刺激が強すぎて疲れてしまうこともあるので、自身の体調・心調に合わせて用法用量を守った方がよいかもしれない。
## 終わりに
ここまで書いていてなんだけど、正直言って全部後付けで、最初から意識してやっていたわけではなかった。けれど、ふりかえってみるとたぶんこんな感じだ。
そして気づいたらまわりには刺激をくれる人であふれるようになった。環境は自分でつくっていくものだなあと改めて思う。
自分自身ももし今後、 立ち止まる理由ばかり見つけて歩みを止めてしまったり、 承認欲求ばかり強くなって承認欲求を満たすことばかりを優先してしまったり、 そんな自分に気がついた時はまわりの刺激を与えてくれる人に会いに行ってみようと思う。
---
# 2017年のふりかえり
URL: https://agile-monster.com/blog/retrospective2017/
Published: 2017-12-29
---
今年はなんといってもモブプログラミングな年でした。 おかげさまでたくさんアウトプットする機会をいただいたり、イベントやモブプログラミング現場体験会などを通していろんな人と出会うきっかけができました。
こういった活動が継続できているのも、お仕事がうまくいっている＝価値につながっているからこそです。モブプログラミングを通して、ずっとやりたかった大きな会社でのリーンスタートアップがようやく形になり、役割やしがらみを越えて少しずつ事業を成長させることができてきました。
飽きるまではもう少しこの活動は続けていこうと思いますので、何かあればお気軽にご用命ください。
## インプット
来年はさくっと出せるように読んだ本とかまとめておこうと思った。
## アウトプット
- 社外発表 15回
- ブログ記事 5本
ブログ 2本
- Qiita 3本
- 執筆 1回
### 2017/1/12 Regional Scrum Gathering Tokyo2017【発表】
非常に珍しく体調を崩して高熱が出ていたのであまり覚えていない。 [speakerdeck.com](https://speakerdeck.com/takaking22/sinwei-lai-hui-yi-sukuramuwozhi-eruzu-zhi-dukuri-number-rsgt2017)
### 2017/1/28 DevLOVE 199 越境CON 【発表】
その場でLTをつくるいつもの芸。 [speakerdeck.com](https://speakerdeck.com/takaking22/wo-hanazeyue-jing-surufalseka-yue-jing-maindosetutotoxian-chang-gai-shan-number-devlove) [speakerdeck.com](https://speakerdeck.com/takaking22/rou-ti-gajing-shen-woling-jia-surukai-fa-no-muscle-no-life-number-devlove-1)
### 2017/4/5 モブプログラミングを実際にやってみた【Qiita】
モブプログラミングをはじめるきっかけとなった記事。 [qiita.com](https://qiita.com/TAKAKING22/items/31e027dfb6ea8b1a8d69)
### 2017/4/25 DevOpsDays Tokyo 2017【発表】
ある意味、黒歴史となったワークショップ。
- モブプログラミングワークショップ
- 朝まで生DevOps（パネルディスカッション）
### 2017/4/26 Azure FunctionsでサーバレスにさくっとHipchat通知してみる【Qiita】
サーバレスうはうは。でも今ならFunctionすら書かずにLogic Appでどうにかしそう。 [qiita.com](https://qiita.com/TAKAKING22/items/969c6e25c2147690f2ef)
### 2017/5/25 アジャイルチーム未来会議【運営】
一般社団法人アジャイルチームを支える会の活動。
### 2017/6/18 DevLOVE 200 Bridge【発表】
おかげさまで8万PV（2017/12/29現在）です。 [speakerdeck.com](https://speakerdeck.com/takaking22/mobupuroguramingutoiudong-kifang-number-devlove)
### 2017/7/11 モブプロディスカッション【運営・発表】
楽しかったなー！
### 2017/7/21 DevLOVE関西「心理的安全性」のことに思いを馳せる【発表】
関西すごい！また行きたい。 [speakerdeck.com](https://speakerdeck.com/takaking22/xin-li-de-an-quan-xing-nituiteben-qi-chu-sitekao-etemitarapu-duan-yatuterutimingufalsehua-datuta-number-devlove)
### 2017/8/25 Geeks Who Drink in Tokyo-Agile Team Edition-【発表】
[speakerdeck.com](https://speakerdeck.com/takaking22/shi-meteshi-bai-sitedi-metesimauqian-nili-tizhi-matutekao-etemitehosiikoto-number-gwd-nulab)
### 2017/8/25 追われる開発と追う開発【ブログ】
[road-to-king.hatenablog.com](http://road-to-king.hatenablog.com/entry/2017/08/25/%E8%BF%BD%E3%82%8F%E3%82%8C%E3%82%8B%E9%96%8B%E7%99%BA%E3%81%A8%E8%BF%BD%E3%81%86%E9%96%8B%E7%99%BA)
### 2017/9/10 モブの宮【発表】
[speakerdeck.com](https://speakerdeck.com/takaking22/ji-ye-mobupuroguraminguyarouze-number-mobufalsegong-number-mobnomiya)
### 2017/9/16 XP祭り2017【発表】
[speakerdeck.com](https://speakerdeck.com/takaking22/re-xp-xphanazeekusutorimunafalseka-number-xpjug)
### 2017/10/28 Rakuten Technology Conference2017【運営】
### 2017/11/2 Microsoft Serverless Hackfestにモブで参加してきた！【ブログ】
[road-to-king.hatenablog.com](http://road-to-king.hatenablog.com/entry/20171101_serverlesshackfest)
### 2017/11/8 エンタープライズアジャイル勉強会【発表】
[speakerdeck.com](https://speakerdeck.com/takaking22/ni-falsezhong-falseaziyairu-mogakisok-ketetadorizhao-itapuroguramingutoiuxing)
### 2017/11/12 DevLOVE リンスタ関ヶ原 〜敗軍の将、兵を語る編〜【発表】
[speakerdeck.com](https://speakerdeck.com/takaking22/da-kinahui-she-dexiao-sakushi-meru-shi-bai-karaxue-ndaentapuraizurinsutatoatupufalsehazimefang-number-devlove)
### 2017/11/16 ヴァル研究所ライトニング大会【発表】
[speakerdeck.com](https://speakerdeck.com/takaking22/chuan-yan-gemu-yong-gan-namobufalsebai)
### 2017/11/18 JJUG CCC 2017 FALL【ワークショップ】
[speakerdeck.com](https://speakerdeck.com/takaking22/yatta-mob-programming-number-jjug-ccc-number-mobupuro)
### 2017/12/11 アジャイルひよこクラブ 結局スクラムってなんなの？日本のパイオニアから学ぶアジャイルの歴史【発表】
[speakerdeck.com](https://speakerdeck.com/takaking22/mobupuroguraminguxian-chang-ti-yan-hui-woyatutekitewakatutakoto-umakuikutimufalsementarumoderu-number-agile-hiyoko)
### 2017/12/22 WEB+DB PRESS Vol.102【執筆】
[](https://hb.afl.rakuten.co.jp/hgc/0caafbcc.e661d1d6.0caafbcd.37106065/?pc=https%3A%2F%2Fitem.rakuten.co.jp%2Fbook%2F15231700%2F&m=http%3A%2F%2Fm.rakuten.co.jp%2Fbook%2Fi%2F18871025%2F&link_type=pict&ut=eyJwYWdlIjoiaXRlbSIsInR5cGUiOiJwaWN0Iiwic2l6ZSI6IjMwMHgzMDAiLCJuYW0iOjEsIm5hbXAiOiJkb3duIiwiY29tIjoxLCJjb21wIjoiZG93biIsInByaWNlIjowLCJib3IiOjEsImNvbCI6MH0%3D)
### 2017/12/25 Azure Bot Service ✕ Cognitive Servicesで英語に翻訳するChat Botを作ってみる【Qiita】
[qiita.com](https://qiita.com/TAKAKING22/items/4b23c815d891e142fa19)
# 2018年の抱負
来年はさっそくRegional Scrum Gathering TOKYO 2018とDeveloper Summit2018で登壇させていただきます。 [confengine.com](https://confengine.com/regional-scrum-gathering-tokyo-2018/proposal/5109/teamwork-revolution-)
- [実況パワフルモブプログラミング - Rakuten Super Englishにおけるモブプログラミングという働き方 -](http://event.shoeisha.jp/devsumi/20180215/session/1666/)
あとはこっそり海外イベントでの登壇もやってみようかなーと思っています。 来年はもう少しエンジニアとしてのアウトプットを増やしたいなーと思っているのと、ブログや執筆にもチャレンジしてみようと思います。
ちなみに来年は社会人10年目の年になります。 同じ会社でずっといるのですが、サービスや部署が変われば転職したのと同じくらい変化がある会社なので2〜3年に一度は変化を体験しているのと、常にやりたい挑戦に挑んでいるんで飽きずにここまできました。 ただ、それはそれでリスクかなーと思っているので去年くらいから **転職** は真剣に考えています。
ところが最近重要な問題に気付いたんですが、常に今がピークな自分なのでネガティブな理由でやめることがないことができません。
今も今までで一番いいチームで今まで一番いい仕事をしています。 ということで、引き続きおいしいお肉とおいしいお寿司を募集しております！！
---
# Microsoft Serverless Hackfestにモブで参加してきた！
URL: https://agile-monster.com/blog/serverless_hackfest/
Published: 2017-11-02
---
## Microsoft Serverless Hackfestとは
簡単にまとめると、
- Microsoftさんのオフィスに3日間缶詰で
- 実際のお仕事のチームと
- 国内外のMicrosoftエヴァンジェリスト・技術イケメンの皆様と共に
- 実際のお仕事で抱えている技術的問題を
本気で解決しにかかるというエンジニアにとっては垂涎なお祭りです。 今回は **Serveless** がお題です。 Azureのサービスでいうと、
- [Azure Functions](https://azure.microsoft.com/ja-jp/services/functions/)
- [Logic Apps](https://azure.microsoft.com/ja-jp/services/logic-apps/)
- [Data Factory](https://azure.microsoft.com/ja-jp/services/data-factory/)
- [Event Grid](https://azure.microsoft.com/ja-jp/services/event-grid/)
あたりですね。 ただし、Serverlessは手段（How）の1つに過ぎなく、その場にいる全員で実業務の問題解決に挑むことができるのがMicrosoft Hackfest最大の魅力だと感じました。
## 今回取り組んだ課題
 私達のシステムは、 WebApp⇒CosmosDB という非常にシンプルな構成です。
スタートアップフェーズでは、変化に対応しやすくコストも安い現在のアーキテクチャはとても都合がよかったのですが、フェーズが変わりデータの集計などが必要になってきたためパフォーマンスを改善しようと思って今回のHackfestに参加しました。
CosmosDBはMongo DB APIなど複数のインタフェースを持っているものの、全ての機能が使えるわけではないのと、機能によっては想定するパフォーマンスが出なかったりします。
基本はKey-Value Storeとして使い、集計などは非同期で予めデータを作っておくか、RDBなど集計が得意なデータストアを使ったほうがよさそうです。
## Hackfestの流れ
まず最初に、業務・アーキテクチャ・現状の課題などのコンテキストを共有し、技術的アプローチについてアツい議論をしました。
チームにはりついてくれるエヴァンジェリストの方だけでなく海外から来てくれているスーパーエンジニア達も参加して、我々のシステムについて真剣に考えてくれるというとても貴重な場でした。 ヘタなりに英語でディスカッションしていますが、通訳さんが入ってくれるので英語が苦手な方も安心です。
Hackfest期間中チームごとにMTGルームを貸し切りで使わせてもらえるので、エンジニアリングに集中できました。
私達の普段の仕事のスタイル同様にモブプログラミングを行い、全員で一つの画面を見ながら全員で問題解決に取り組みました。 その時に必要な技術要素に詳しい人を呼んでくださったり、とにかく全員で寄ってたかって問題をフルボッコにしました。
ホントにこんな感じｗ
3日間の最後に成果発表＆ふりかえりをしました。
ちなみに3日間の成果はこんな感じです。
Azure Functionsを使ってデータ分析を非同期に逃してみたんですが、色々ハマりながらも2日間でおおよそできてしまいました。
そこで3日目は別のパターンとして、Data Factoryを使って、CosmosDBからSQL Databaseにデータを同期し、PowerBIでレポートを可視化しました。
同じ問題を解決するアプローチでも前者はコードで解決した一方で、後者はほとんとコードを書かずに実現することができました。
## 参加してみて
### ★エンジニアにとって至福の時
3日間缶詰になって、スペシャリストに囲まれてエンジニアリングに集中できる環境は控えめに言って最高でした。 なにより自分がいちばん下手くそでいられる環境というのは、最高にわくわくするし、改めて「エンジニアってたーのしー！」って思いました。
### ★仕事だから本気
Microsoft Hackfestでは実際の仕事の問題を解決することをターゲットにしてくれます。ワークショップの仮のお題ではなく、普段働いているチームで実際の仕事をターゲットにするからこそ本気になれます。
### ★クラウド時代の問題解決
今回取り組んだ問題について、自分たちのチームだけで取り組んだとしてもそんなに時間はかからずに解決することはできたと思います。
ただし、今回のHackfestでいろんなスペシャリストの知見をもらいながら、たくさんの選択肢の中からBetterなものを選んで解決することができました。 結果だけ見ると同じように見えますが、そこに至る過程で得られた経験値が格段に違い、チームとして成長することができました。
とくにクラウド時代はたくさんの選択肢があり、知っているか知っていないかでかかる手間も結果も大きく変わります。自分たちの手で地道に解決していくことももちろん大切ですが、時間は有限なのでいかに情報を得ていかに効率的に問題を解決するかという視点もこれからのエンジニアリングには必要な要素だと改めて強く感じました。
コードを書いているだけがエンジニアリングではないですね。
#### ★モブプログラミングの真価
Hackfest✕モブプログラミングは最強の組み合わせだと思いました。 前述した通り問題解決は結果だけでなくその過程で何を得るかが非常に重要で、全員で問題を一つずつフルボッコにしていくモブプログラミングで貯まる経験値はメタルキングレベルです。
モブプログラミングについては以下の資料をどうぞ。
- [OUR MOB PROGRAMMING AT RAKUTEN](https://speakerdeck.com/takaking22/our-mob-programming-at-rakuten)
## 最後に
最後になりますが、張り付いてサポートしてくださったKanio・寺田さん・本間さん・畠山さん。声をかけてくださった牛尾さん。様子を見に来てくださった佐藤（神）さん。レポートしてくれたちょまどさん。そしてそれ以外の皆さんも本当にありがとうございました。
---
# 追われる開発と追う開発
URL: https://agile-monster.com/blog/ou-kaihatsu/
Published: 2017-08-25
---
※この物語はフィクションです
## 開発現場A
ビジネスチームが一生懸命アイデアを出して、それを開発チームに依頼する。依頼を受けた開発チームは、要件を確認しながら開発計画を立て、数ヶ月にリリースをするスケジュールを組んで、開発を開始した。
ビジネスチームは、開発期間の間にいろんなことを想像し始める。
競合サービスを研究していると不安になり、「あれがないとダメ！」「これもないとダメ！」という気になって、最初の想定よりもプロダクトはどんどん太っていく。
こういう状況で追加されていく要望は当然ながら検証されていない想像＝妄想なので、実際にリリースしててもユーザーに使われるかどうかはわからない。
 [なぜあなたのチームの プロダクトは太ってしまうのか #postudy // Speaker Deck](https://speakerdeck.com/takaking22/nazeanatafalsetimufalse-purodakutohatai-tutesimaufalseka-number-postudy?slide=13)より
当然ながら開発チームは当初想定していたよりもやることがどんどん増えていく。
- やることが増えても適切に納期が延ばされない
- 既に実装してテストされた後に手を加えることになる
- 影響範囲が正しく理解されないまま変更が加えられる
などの状況が重なると加速度的に開発チームの負荷は上がる。
負荷が上がると仕事の精度はがくっと下がるので、順調にプログラムにバグが仕込まれていく。
度重なる仕様追加を乗り越えて、開発チームはようやくリリースにこぎつけた！
しかし、無理して開発した結果、トラブルが発生する。
苦労して追加した機能は大して使われず、おまけに汚く組まれたプログラムによって変更コストは膨大になり、リリース後の改修スピードもどんどん遅くなる。
そんなことしている間に競合サービスがどんどん出てきて、気付いたらユーザーは誰もいなくなっていた。
**Bad End ..**
## 開発現場B
ビジネスチームが一生懸命アイデアを出して、それを開発チームに依頼する（ここまでは同じ）。
依頼を受けた開発チームは、最初のシンプルなアイデア（その一部）をさくっと作って1週間後に彼らに見せることにした。「きっと後で変わるだろう」と余計なこだわりは捨てて、デザインもコードも最初から完璧を目指さずに、1週間でできる分をシンプルに作っていった。
1週間後に予定通りデモを見せると、「え、もうできたの！？」と依頼をした人達は腰を浮かして喜んだ。実際に動いているプロダクトを見て具体的なイメージができたのか、あーでもないこーでもない議論が盛り上がった。そこで開発チームは、「次はどこを作りましょうか？来週までにできるところまで作ってくるので、またフィードバックを下さいね。」と笑顔で伝えてそのデモMTGは終了した。
それから何週間か同じことを繰り返した。
ビジネスチームは少しずつできていくプロダクトに対するフィードバックをして、次に作ってもらうものを考えて、そのための準備をすることで毎週必死になっている。
一方で開発チームは、開発のリズムができてきたことで、その週に予定している対応分は数日で完了するようになっていた。そこで余った時間で何をするのかをチームで考えることにした。
- 次の機会に使うかもしれない新しい技術検証を行う
- リファクタリングする
- 近くにいる想定ユーザーにプロダクトをさわってフィードバックをもらう
- 環境を整備したり、自動化を行う
毎週何をするかをチームで決めて、プロダクト開発をしながらも改善活動を進めていった。
そしてまた数週間が経った頃、ビジネスチームのリーダーが「もうそこそこ使えるしリリースしてみてもいいんじゃない？」と話したことで、リリースが決まった。
常にリリースを繰り返してきた彼らにとって、リリース作業は自動化されていて、さくっと世の中にサービスが出た。
ビジネスチームや想定ユーザーに何度も触り続けてもらったプロダクトは、致命的なバグなど出るはずもなかった。
また、プロダクト開発を続けながら改善を続けてきたおかげでプログラムもキレイに組まれていて、リリース後もユーザーのフィードバックをすぐに反映してサービスはどんどん成長していった。
**Good End ..**
## 考察
いかがでしたでしょうか？
この2つの現場について考えてみました。
一見すると開発現場Aはとても悪い現場に見えます。でもよく考えてみると、みんなそれぞれの状況の中で精一杯仕事をしているだけであって、誰かが悪意を持ってさぼっていたわけではありません。
それと比べて開発現場Bはとても良い現場に見えます。
しかし彼らは急にチームが成長したわけでも特別なやり方をしたわけでもありません。優先順位を決めて、自分達ができる仕事量だけ毎週アウトプットして、余った時間を有効に使っていっただけなのです。
ではこの2つの現場の違いはなんなのでしょうか？
### 本気を出すタイミング
人は動いているプロダクトを目の前にしない限り、本気になれません。
特にプロダクトをつくれない人たちは想像ができないため、ドキュメントや進捗表でいくら説明をしたところで、マジメに聞いてくれるものの本気にはなれません。
一方で開発チームは作っている間、常に本気です。  [JikkanKudo2016_BPStudy // Speaker Deck](https://speakerdeck.com/kawaguti/jikkankudo2016-bpstudy?slide=9)より
この違いを理解することはとても重要です。
開発チームが本気に仕事を終わらせにかかっている時に、思いつきのアイデアを出していらっとされるなんて話はよく聞きます。
お互いの本気のタイミングを合わせるためには、開発現場Bのように常に動いているプロダクトを中心に仕事を進める方がよいでしょう。
### 追われる開発か追う開発か
プロダクトづくりというのはクリエイティブな特性を持っているため、開発チームが追われている状況ではあまりよい結果になりません。
開発現場Bのように開発チームに余裕がある状態であれば、先回りをしたり、改善活動をしたり、様々なアプローチをとることができます。
一方でビジネスチームに余裕がある状態だと、想像ができないことが多いので効果的な先回りがしづらかったり、余裕が有ることによる不安や焦燥感によって暴走しがちです。
しかし開発現場Bのようにビジネスチームが追われている状態であれば、優先順位を決めてそれに基づいて開発してもらうための準備に勤しみます。優先順位を決められるのはビジネスチームであり、そのための準備をするという一番重要な仕事にのみ集中する状況を作ることができます。
追われる開発ではなく追う開発を目指したいものです。
>
>
> 「進め方がちょっと違うだけでこんなに大きな差が出るんだなー」って最近モブプロをしながら実感してるよ
>
>
なんて話をとある日のランチで社内の若者に話していたので、せっかくなのでブログに書いてみました。
speakerdeck.com 手前味噌ですがこのスライドいいこと言ってるな、って改めて思いました。]]
---
# タスクボードの改善事例がたくさん詰まった「アジャイルコーチの道具箱 – 見える化実例集」を読んだ #見える化実例集
URL: https://agile-monster.com/blog/agilecoach-tools/
Published: 2016-04-16
---
「アジャイルコーチの道具箱 – 見える化実例集」を読んでみました。[leanpub.com](https://leanpub.com/agiletoolbox-visualizationexamples-japanese) この本はタスクボードを中心とした見える化のTipsがひたすら紹介されている本です。 Tips集なので前から読んでいく必要もなく、気になったTipsを辞書感覚で見たり、気軽にパラパラめくって読むことができました。 読みながらツイートしていたので、臨場感あふれる感想を貼っておきます。
>
>
> ボードのリファクタリングってけっこう重要。ずっと同じだと飽きちゃうし、情報量多いと見ないし。ホワイトボード使うと面積という制限があるからいいよね。 "情報がどんどん追加されて、どんどん複雑になっていってしまう" [#見える化実例集](https://twitter.com/hashtag/%E8%A6%8B%E3%81%88%E3%82%8B%E5%8C%96%E5%AE%9F%E4%BE%8B%E9%9B%86?src=hash) [#アジャイルコーチの道具箱](https://twitter.com/hashtag/%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%83%AB%E3%82%B3%E3%83%BC%E3%83%81%E3%81%AE%E9%81%93%E5%85%B7%E7%AE%B1?src=hash)
> — OYB48 (@TAKAKING22) [2016年4月16日](https://twitter.com/TAKAKING22/status/721232787483664384)
>
>
>
>
> カンバンにないタスクが増えるときはすぐに全員で足すかどうかを決めて、足すときは違う色の付箋orシンボルつけてたなー。計測しておくと振り返りに使える。 [#見える化実例集](https://twitter.com/hashtag/%E8%A6%8B%E3%81%88%E3%82%8B%E5%8C%96%E5%AE%9F%E4%BE%8B%E9%9B%86?src=hash) [#アジャイルコーチの道具箱](https://twitter.com/hashtag/%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%83%AB%E3%82%B3%E3%83%BC%E3%83%81%E3%81%AE%E9%81%93%E5%85%B7%E7%AE%B1?src=hash)
> — OYB48 (@TAKAKING22) [2016年4月16日](https://twitter.com/TAKAKING22/status/721234124539715585)
>
>
>
>
> これいいね！チームでSprint毎に完了させていく意識につながりそう。モチベーションは計画しちゃダメだけど、バカにしちゃいけないと思うｗ "デモまで何日は、次のデモの日までのカウントダウンだ。" [#見える化実例集](https://twitter.com/hashtag/%E8%A6%8B%E3%81%88%E3%82%8B%E5%8C%96%E5%AE%9F%E4%BE%8B%E9%9B%86?src=hash) [#アジャイルコーチの道具箱](https://twitter.com/hashtag/%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%83%AB%E3%82%B3%E3%83%BC%E3%83%81%E3%81%AE%E9%81%93%E5%85%B7%E7%AE%B1?src=hash)
> — OYB48 (@TAKAKING22) [2016年4月16日](https://twitter.com/TAKAKING22/status/721235684913078272)
>
>
>
>
> カイゼンボードいいね！ふりかえりで出たTryをカンバンに張り出してるけど、改善活動もステータスを見える化しちゃえばいいよね。 [#見える化実例集](https://twitter.com/hashtag/%E8%A6%8B%E3%81%88%E3%82%8B%E5%8C%96%E5%AE%9F%E4%BE%8B%E9%9B%86?src=hash) [#アジャイルコーチの道具箱](https://twitter.com/hashtag/%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%83%AB%E3%82%B3%E3%83%BC%E3%83%81%E3%81%AE%E9%81%93%E5%85%B7%E7%AE%B1?src=hash)
> — OYB48 (@TAKAKING22) [2016年4月16日](https://twitter.com/TAKAKING22/status/721238645118603264)
>
>
カンバンやタスクボードを使っているチームは、自分の現場でまわりを見渡してもかなり増えてきた印象があります。 僕はデジタルなツールよりもアナログなカンバンが大好きなので、チームのみんなにもチームで使うカンバンを好きになってもらいたくていろんな改造をしてきました。だから、読んでいて「これやってるよ！」というTipsも「これやってみよ！」っていうTipsもたくさんあって楽しく読むことができました。
>
>
> ほんとこれ。やっててもやってなくても変わらないならやらない方がいい。 "見える化ボードは生き物だ。それぞれの要素とデザインの価値を定期的に評価して、改善、調整しよう。必要ないなら使うのをやめよう。" [#見える化実例集](https://twitter.com/hashtag/%E8%A6%8B%E3%81%88%E3%82%8B%E5%8C%96%E5%AE%9F%E4%BE%8B%E9%9B%86?src=hash) [#アジャイルコーチの道具箱](https://twitter.com/hashtag/%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%83%AB%E3%82%B3%E3%83%BC%E3%83%81%E3%81%AE%E9%81%93%E5%85%B7%E7%AE%B1?src=hash)
> — OYB48 (@TAKAKING22) [2016年4月16日](https://twitter.com/TAKAKING22/status/721230503534198784)
>
>
とりあえずタスクボードを導入してみるだけでもいいと思いますが、チームの状況や抱えている問題に合わせてちょっとした工夫をするだけでよりチームにとって効果的な見える化ができます。 カンバンは本当に生き物でありナマモノで、正解はないし、銀の弾丸もないので、チームの数だけカンバンがあっていいと思います。最初からあれこれなんでも導入すると失敗するので、シンプルにはじめてチームの成長にあわせてカンバンを育てていくような意識だといいのかなと思ってます。 この本にはカンバンの育て方のヒントがたくさんつまっているので、自分のチームの課題にあったTipsがきっと見つかると思います。 ※かつてこんな発表をしたこともありました。
**[振り返ればカンバンがある ~チームとカンバンとProduct Ownership~](https://www.slideshare.net/TakaoOyobe/20130116-product-ownership)** from **[Takao Oyobe](http://www.slideshare.net/TakaoOyobe)**
電子書籍のみですが、お手軽な値段で手に入るので、暇つぶし感覚で読んでみるといいと思います。 [leanpub.com](https://leanpub.com/agiletoolbox-visualizationexamples-japanese) 本の最後に自分の例を書くスペースがあるんだけど、この本を読んだ人が自分達のオリジナルTipsを共有する勉強会とかあったら面白そうだねー！！
---
# 我々は本当に越境したいのか？ #devlove
URL: https://agile-monster.com/blog/ekkyo/
Published: 2014-12-20
---
DevLOVE AdventCalendar 2014 「越境」の42日目の記事です。 テーマである「越境」について、考えてみた時に浮かんだ疑問について考えてみたいと思います。
### コンテキスト
本題に入る前に私のコンテキストを簡単にご紹介すると、
- Webサービス
- 自社開発が多い
- 英語化な会社
- エンジニア
- アジャイル開発
- チームファシリテーター
- チェンジエージェント
こんなところです。 そんな私のまわりにある境になりそうなものは、
- 開発とビジネス
- 日本語（母国語）と英語
- 個人と会社
- コミュニティと会社
- スペシャリストとゼネラリスト
あたりでしょうか。
### 越境っていいことなの？
ここから本題です。
越境はすごくいいことであると述べられることが多いが、私はそうとは限らないと思っています。なぜなら蛮族（ヒャッハー）でも越境はできます。
越境はWhy（目的）ではありません。越境はWhy（目的）を達成するためのHow（手段）の1つに過ぎません。新しい技術を導入することがWhy（目的）になってしまい、本来あるべきWhy（適切な導入理由）や一緒に考えるべきHow（運用計画）が存在せず、おまけに導入した張本人がそのチームを去って残ったのは荒れ果てたシステムだけだった・・・などどいう世にも恐ろしい越境の悪例を私は何度も見たことがあります。
未来がない越境などしない方がまだマシです。自分勝手とはいえ明確な目的がある分、蛮族（ヒャッハー）の方がまだマシだとさえ感じます。
“なにを為したいのか”と “どうやって為すのか” はセットで考えないと、不幸な未来が待っているのかもしれません。
### 越境する人たちはすごい人？
とあるプレゼンをした後の質疑応答で、 「チームに変えられる人はスーパースターだと思うのですが、どうやったら私たちもそうなれますか？」 と質問いただき、 「もし自分がスーパースターならアジャイルやチームビルドに興味を持たなかったでしょう。だってなんでも自分でできちゃうじゃないですか。スーパースターじゃないからチームが必要で、サービスにとってチームがアジャイルになることが必要だと思ったからやってるだけです。」 と応えました。
私が知っている越境し続ける人たち（ここではチェンジエージェントと呼びます）だと思う皆さんは、越境しようと思って越境しているわけではない気がします。そもそも境だと認識すらしていないからこそチェンジエージェントで居続けられるのでしょう。
とある施策をチームに取り入れようと考えたときに、反対する上司がいるだろうと思って慎重に変化を進めたらむしろその上司が積極的にサポートしてくれた・・・などという経験が私にもあります。境をつくるのも感じるのもたいていは自分自身の中だけで、本当の境は自分が思っているよりも少ないのだとそのとき気づきました。
もし、なにかやりたいことができない理由を「すごい人」「スーパースター」という言葉に変換しているのであれば、本当にできない理由は自分自身の中にあるのかもしれません。
### 本当に越境したい？
越境がHow（手段）の1つであるということは、越境しなくてもWhy（目的）を達成する手段はあるハズです。
それでも本当に越境したいのでしょうか？ 私は**どうでもいい**と思っています。
「なにを為したいのか」「どうやって為すのか」 を考えたときに必要だと思ったことをやってきただけで、今後もそれを続けます。やってきたことが越境だったとしてもそうでなかったとしても、走り続けなければいけません。
そんな想いをこめたのがこのプレゼンテーションでした。
https://www.slideshare.net/TakaoOyobe/20141108-devlove
境だと思わなければ、越えることすら越えられる。 越境に夢を見るのはもうやめました。越境したとしても、境の向こうには世界の続きがあるだけです。 私には行きたいところ（成し遂げたいこと）があるだけです。
---
# 俺のコードレビュー勉強会を開いてみた #devraku
URL: https://agile-monster.com/blog/ore-no-codereview/
Published: 2014-11-05
---
2014年11月5日に俺のコードレビュー勉強会を開催しました。 オープニング資料はこちら。
https://www.slideshare.net/TakaoOyobe/20141105-opening
ライトニングトーク資料はこちら。
https://www.slideshare.net/TakaoOyobe/20141105-lightning-talk
当日の様子もまとめました。
http://togetter.com/li/741820
### Why
とあるサミットで感銘を受けたプレゼンを社内で勝手に再演した際に、 「こんな活動をやってる人が社内にいるなんて知りませんでした。」 と言われたことが今思い返すときっかけでした。
その再演の際、まったく意図はしていなかったのですが、再演後にチームに共有するついでに声をかけた他部署のメンバーを巻き込んでアツいディスカッションが生まれました。
再演をやってよかったなーと思うと同時に、せっかく同じ社内にいるのにすぐ手をのばせば届く人やノウハウにたどり着いていないことが本当にもったいないと感じました。
そこで起きたアツいディスカッションをもう一度意図的に起こしたい、という想いをこじらせて今回開催に至りました。
### What
聴衆型の勉強会は社内外に多いので、今回は対話型の勉強会にしました。
### Where
テーマ的にセンシティブな内容を含む可能性が強く、そこを気にしてディスカッションをシュリンクさせたくないので今回は社内勉強会として開催しました。
### Who
今回の勉強会でメインターゲットにしたのは、勉強会や本などからインプットしたことを現場で実践する・実践しようとする人たちです。
### How
コードレビューをテーマにしたライトニングトークを募集。 当日なぐりこみOKで特にとりまとめもせず、当日集まったものを順番でLT。
ライトニングトークを媒介に場を盛り上げた後は、Scrum Master's Night形式のディスカッションを採用（この形式の勉強会をやってみたかった）。
テーマであるコードレビューについて話したいトピック・聞いてみたいトピックを付箋に書いてもらい、内容を説明しながらホワイトボードに貼っていってもらう。
出尽くしたところで、「これいいな！」と思ったトピックにドット投票をしてもらい、票の多いトピックから時間の許す限りディスカッションする形式で進行しました。
### ふりかえりKPT
#### Keep
- 「極力楽に運営する」という姿勢をスコープとして固定した
- 各地方拠点（北海道・仙台・大阪）とスムーズにやりとりができてよかった
- 想定よりもディスカッションがかなり白熱した
- 勉強会に出て「持ち帰りがあった」割合が多かった
- Tryにできるコードレビューパターンが多く見つかった
- 運営者が一番楽しんだ
- Tech Talkとのコラボレーションができた
#### Problem
- ライトニングトークに時間制限がなかった
- ちょっと終了時間が押してしまった（盛り上がったからだけど）
- ふりかえりのアウトプットを形として残せなかった
#### Try
- さんま力（トークファシリテーション）に磨きをつける
- ワールドカフェ形式でふりかえりをアウトプットする
### やってみてどうだったか
Learn（学んだこと）をGenba（現場）に活かすことができることが理想です。 基本一方通行なインプットをする機会は多く存在するため、今回はそこで学んだことを実際に現場で実践する部分をターゲットに勉強会を開催しました。 いきなりそんなにうまくはいかないだろうと期待はしていなかったのですが、予想以上に議論は白熱してとてもいい勉強会になったと自負しています（内容自体については別記事で紹介予定）。
ライトニングトーク中は聞いてるだけで大人しかった参加者のみんなも、自分たちの現場のストーリーを話しだすと饒舌になっていました。よくよく考えてみると、そもそもみんな想いを持っているから集まっているのであって、それを出し合う場・仕組みをつくってあげるだけで盛り上がるのは当然でした。たったの2時間あまりの時間で、本当にたくさんの学びがうまれました。
こんなに楽なことはない！ 久しぶりに運営して心からよかったと思える勉強会になりました。
社内外に関わらず得た学びを現場で活かす。 それを現場同士で結びつけて、次の学びにつなげる。
具体的に言うと、Tech Talkや社外の勉強会でみんなが得た学びを現場で実践した頃合いを見計らって、お互いの事例を今回のような場を設けて共有し合う。もっといい現場改善につながり、それを成果としてTech Talkや社外の勉強会で発表してもらう。
この学びのフィードバックループがぐるぐるまわりはじめると、面白いことになるんじゃないかとワクワクしています。 でも期待しません、勝つまでは。
ということでやってよかったので、今回MVPでTryしてみた勉強会をDev楽と銘打って不定期でまわしてみようと思います。
無理をしない・楽をする、そして最高に楽しいがモットーなので、Continuousなペースでの開催になりますが、盛り上げてくれればすぐに調子に乗るタイプなので、取り上げて欲しいテーマがある方はのせてください。
また、無理に社内に閉じようとは考えていません。ぜひ機会があれば一緒に胸ぐらつかみ合って学びましょう。 
---
# レガシーコードについて考えてみた #wewlc_jp
URL: https://agile-monster.com/blog/legacy-code/
Published: 2014-09-27
---
[レガシーコード改善勉強会 in東京 - パスマーケット](http://passmarket.yahoo.co.jp/event/show/detail/01pitgwzj67m.html) に参加しています、なう。
勉強会出ててくる内容（キーワード）や雰囲気はハッシュタグから追えると思いますのでぜひ！
- [Twitter / Search - #wewlc_jp](https://twitter.com/hashtag/wewlc_jp)
参加レポートではなく、せっかくなので勉強会のテーマの “レガシーコード” について個人的な想いをつらつら書いてみます。
### レガシーコードってなあに？
- レガシーコードとはテストのないコードである
というわかりやすい定義もありますが、
- 仕様がわからないコード
- 意図がわからないコード
- 読めないコード
といった主観的なイメージもよく聞きます。 定義としてレガシーコードとはなんなのかはともかく、上記に書いたようなコードはどれも無いほうがうれしいし、あったとしたら減らしていきたいものです。
【余談】このあたり読むと面白い！
- [技術的負債 - Wikipedia](http://ja.wikipedia.org/wiki/%E6%8A%80%E8%A1%93%E7%9A%84%E8%B2%A0%E5%82%B5)
- [技術的負債 - Qiita](http://qiita.com/erukiti/items/9cc7850250268582dde7)
### レガシーコードとの遭遇
今までの自分の経験では、コードが存在するところには（程度の違いはあるけど）必ずレガシーコードが存在していました。
仮にレガシーコードが存在しないステキな環境があったとしても、半年後に自分の書いたコードを覚えてなかったりするので明日レガシーコードが存在している可能性はあるでしょう。
ってことは、スタートアップだろうと保守運用だろうと自社開発だろうと受託開発だろうと、**レガシーコードとどう向き合っていくか**はエンジニアやっている限り切っても切り離せないものなのかなーと思うようになりました。
### よくあるレガシーコード
今までレガシーだなーと思ったコードを思い出してみました。
- メソッドでやりたいことがわからない
- インデントや条件が複雑すぎてどうやったらそこを通るかがイメージしにくい
- メソッドが大きすぎてテストコード書こうにも複雑すぎる
- AメソッドとBメソッドそれぞれでは問題なさそうだけど、設計に統一性がない
- 変更部分にしか注意がまわっていない書き方をしている
- 歴史を感じるくらい人によって書き方がバラバラ
- そもそもシステムやテストの設計方針がない
- とにかくわけがわからない
思い返してみるとこれらの共通点は、
- テストコードが存在しない
でした。 もちろんテストコードがあればいいってわけじゃないけれど統計的に！
### レガシーコードができそうなにおい
今度はコードレビューしていてレガシーコードになりそうだなーと感じた瞬間を思い出してみます。
- メソッドが長い
- インデントが深い
- 条件文が複雑
- メソッドからreturnするパターンが多い
これらを見つけた時に聞いてること。
- メソッドが長い →「このメソッドの目的ってなに？」 →「このメソッドテスト書いててつらくなかった？」
- インデントが深い →「ここ通るときの条件を教えて！」
- 条件文が複雑 →「この条件文を文章で説明してほしいなー」
- メソッドからreturnするパターンが多い →「このメソッドのreturnのパターンを教えて！」
コードを書かない時にもレガシーなにおいを感じるタイミングはあります。
- 説明が不安そう
- 仕様理解があいまい
- タスク自体のDoneの定義があいまい
- （項目・コード問わず）テストが書けてない
- 本人がぱつってる
こんなときはあやしいですよね。
### レガシーコードとどう向き合ってきたか
もちろんこれまでにレガシーコードを見てイラッ☆としたことはたくさんあります。
でも前任者だけでなく自分自身もレガシーコードを生む可能性があることに気づいてからは、それほどネガティブな感情を持たなくなりました。
でも、そこでネガティブな感情をもって立ち止まったら、自分自身も同じようにレガシーコードを生んでしまいます。それはレガシーコードに負けた気がするし、自分自身もまた加害者になってしまいます。
だから、 ***状況次第でなかなかリファクタリングできない・進まないことはあるかもしれないけど、少なくとも増やさないようにして少しずつ減らしていこう*** ってことを考えるようになりました。
### 今後レガシーコードとどう向き合っていくか
今後以下の2つのアプローチを考えてます。
- やってきたことをアウトプットする
- 知識をインプットする
#### 1. やってきたことをアウトプットする
レガシーコードと向き合うようになって、いろんな失敗を経ながらもどうにかレガシーコードを減らしてきました。
自分は本能で動くタイプなので、やってみたあとから、 「あのときやったことに名前・方法論があったんだ」 と知識がついてくることが多いです。 それはそれでいいと思うんですが、やってきたことを[形式](http://d.hatena.ne.jp/keyword/%B7%C1%BC%B0%C3%CE)知としてアウトプットして知識に転換していくことがそろそろ必要だと思っています。
#### 2. 知識をインプットする
アウトプットをする一方で、今なら効率よく知識をインプットできる気がするし、頭でっかちにならずに知識を経験に転換していくサイクルをまわすこともできるので、引き出しを増やせばもっとはやくもっと多くの改善ができるんじゃないかなーとわくわくしています。
考えるきっかけを下さった登壇者の皆様、運営の皆様ありがとうございました。
---
# リリース手順書について本気出して考えてみた #CleanReleaseManual
URL: https://agile-monster.com/blog/release-manual/
Published: 2014-02-17
---
## 手順書書くくらいなら自動化すればいいじゃん
もちろんそうです。
でも、まともなリリース手順書をつくれなければ、自動化されたリリース作業を行うことはできても自ら自動化することはできません。自動化やContinuous Deliveryはもちろん大事ですが、自分と一緒にはたらくエンジニアには自動の前に考えてほしいことがあったのでプレゼンにまとめてみました。
## 新人の頃の教訓
この内容は、すべて自分が新人の頃にリーダーから伝えてもらったことです。
- 「変化前の確認⇒変化⇒変化後の確認」さぼらない
- 上から下までコピペでリリースできることが最低限
- リリース手順書には相手がいる
- 相手の事を思いやって書く
- 意図を持って書く
最初はなかなかうまく書くことができませんでしたが、新人の頃に癖づけることができて本当によかったです。
いろんな人のリリース手順書を見てきましたが、震えるような手順書には出会っていません。
たかがリリース手順書、されどリリース手順書！
## リリース手順書に限らないコツ
このプレゼンのメインはリリース手順書ですが、そのコツは手順書に限るものではありません。仕事と作業を分けることを意識して大事な事に集中したいものです。
https://www.slideshare.net/TakaoOyobe/betaclean-release-manual-31258601
---
# 2013年をふりかえってみました
URL: https://agile-monster.com/blog/retrospective2013/
Published: 2013-12-31
---
### 数値でふりかえり
- カンファレンス・勉強会参加 : 47
- 発表（社外） : 10
- スライド公開数 : 5
- ブログ投稿数 : 10
- KPT総ファシリテート数 : 73
- 読んだ本 : 30
- クリアしたゲーム : 12 ※神々のトライフォース2含む
- 回収したアニメ : 20
- 握手会参加数 : 1
### KPTT
#### Keep
- 新しいチームも自他共認めるいいチームに変われた
- サービス（楽天レシピ）が大好きになった
- 年初に立てたチーム年間計画をクリアすることができた
- 2012年から2013年の1年にかけて個人的4大ドームツアー講演達成した （Scrum Gathering、XP祭り、デブサミ、アジャイルジャパン）
#### Problem
- 業務内でエンジニアリングに携わる時間が減ってきた
- いろいろ計測してみたけど仮説の設定があまくあんまりいい指標ではなかった
- 大きなイベントが重なって継続的でなかった
- Agile2013のセッション通らなかった
- 出世払いが増えてきた
#### Try
- 業務外でエンジニアリングする（内容は決めてあるけど濁します）
- 1年を通してのKPIを設定する
- ブログを月1以上書く
- 発表を依頼されるようになる
#### Thanks
##### To チーム・部署
新しい環境でも遠慮なくやらせていただきました。一緒にやってる仲間から「仕事が楽しくなった」「自慢できるチーム」といってもらえたのがなによりでした。もしかしたら賛否両論ある方もいらっしゃると思いますが、変化が起こっているということなのでそれもまた嬉しいフィードバックです。
サービスとしてもチームとしても今年は準備の期間と計画していたので計画以上に進めることができたので2013年としては優かもしれませんが、サービスとしての価値がうまれないとなんの意味もなさないと思います。遠慮したり安定させるのは大人に任せて、来年以降もこれまで以上に空気を読んで空気を壊して行こうと思いますので引き続きよろしくお願いいたします。
##### To 会社
ありがとうございました。 会社を変えてやりましょう！
##### To 勉強会・コミュニティ
たくさんの出会いと学びをありがとうございました。 現場を変えてやりましょう！
---
# 変わる現場をつくる #devlove
URL: https://agile-monster.com/blog/change-gemba/
Published: 2013-11-11
---
### 自己紹介
[2番バッターを務めさせていただきます@TAKAKING22](https://web.archive.org/web/20131124143242/http://devlove.doorkeeper.jp:80/events/7039)です。2番というと、送りバント・進塁打・ヒッティングなど状況にあわせたバッティングを求められます。
私は、楽天株式会社という会社でエンジニアをしています。楽天には野球団と楽天市場と英語以外にもたくさんのサービスが存在し、私は後者の小さなサービス達を開発・運用する部署に所属しています。肩書きはエンジニアですが、チームビルディング・プロジェクトマネジメント・プロダクトマネジメントなど必要であらば現場を変えるために役割の壁をぶっ壊して日々奮闘しています。
そんな現場での実体験を勉強会やカンファレンスなどで発表させていただいているのですが、はじめての発表は2011年の12月の[DevLOVE HangarFlight - Snow Barrage](https://web.archive.org/web/20171211010912/http://kokucheese.com/event/index/21611/)でした。私のエンジニア人生にとって大きなきっかけになり、そこからの約2年間でたくさん成長ができたと思います。
### 現場と変化
私たちの業界では、ビジネスも技術もプロセスも凄まじいスピードで変化していきます。それに合わせて現場も変化していかないと取り残されてしまいます。
なんていうマクロな視点だけでなく、ミクロな視点（自分たちの現場）でも変化はつきものです。言語のバージョンは数年でサポートが終了するし、メンバーが１人変わればチームの雰囲気はがらっと変わるし、そうした変化に対応する形で現場もまた変化を求められます。
ところが、現場で活動をしていると変化を拒む見えない壁にぶちあたることがあります。そんな時に私たちには3つの選択肢があるそうです。
## 私の現場の変化のストーリー
「●●だからできるんでしょ？」 という声をよく聞きますが、どの現場もはじめからそうであったわけでなく必ず誰かが変化をおこしたストーリーがあります。
私は2012年末に今のチームに異動することが決まった際に、まずメンバーへの個別のヒアリングをしました。その結果をチェンジインセプションデッキにまとめ、面談の際に上司との合意をとりました。
- 何やってるかが見えない
- テストがない
- トラブルが多い
- リリースに時間がかかる
という状態だったチーム。
それから約10ヶ月。 今では、カンバンの前で毎朝朝礼をし、毎週ふりかえりをし、テストコードを書き、トラブルも起きず、リリースは毎回成功しています。 言葉で書くと簡単ですが、一朝一夕に変化したのではなく、小さな成功や失敗を積み重ねた変化の結果が今のチームです。
私がチームに入るという大きな変化にも対応してくれたメンバーに感謝しています。
## 私にとっての現場
先ほどうまくいかないときに3つの選択肢があるといいました。私は常に３つ目の「変える」を選ぶようにしています。
自分の現場が必ずしもいい現場だとは限りません。仮に今いい現場だとしても明日にはどうなるかわかりません。
そんなときに我慢するのもいいでしょう。辞めるのもいいでしょう。しかし、変えることから逃げてそれらを選択をすることは絶対にしたくないです。 いい現場は自分たちでつくらなければいけません。
私がやっていることは、自分では名前を使わずとも、アジャイル・リーンなどさまざまな呼び方で呼ばれます。
しかし現場の最前線で戦う私たちからすると、 **『なんだっていい！やってやる！！』** という思いでしかありません。 明日起こせる変化は小さいかもしれませんが、その１歩を積み重ねない限り行きたい目的地にはたどりつくことができません。
私は、その思いのもと、明日からも現場のために現場にあわせた変化（１歩）を起こし続けていこうと思っています。 そして変化を起こせなくなったとき、第一線から退こうと決めています。
---
# アジャイル開発をはじめたって価値はうまれない #agilejapan
URL: https://agile-monster.com/blog/agile-hajime-kata/
Published: 2013-05-27
---
Agile Japan 2013で登壇させていただきました。
https://2013.agilejapan.jp/2013/program.html#05
「アジャイルサムライ壱の太刀～実践者たちが語るアジャイル導入の型～」というタイトルで、3人のパターンのプレゼン、パネルディスカッション、テーブルディスカッションという盛りだくさんのセッションとなりました。
その中で、私は**説得しない・はじめないアジャイル開発のはじめ形**について話させていただきました。 今回はその内容をご紹介させていただきます。
アジャイル開発関連の勉強会や書籍を見ていると、守破離でいう守、はじめ方にフォーカスした内容がとても多いです。私がアジャイルを知ってから2年半ほどですが、あまり大きく変化はしていないと感じます。 すると、一つの疑問を感じます。 「アジャイル開発をはじめるのは難しいのだろうか？」
なぜ難しいと感じるのかをちょっと掘り下げてみます。
- 上司を説得できないかもしれない
- はじめたいけど一緒にやってくれる仲間がいないかもしれない
他人を変えることは難しい、相手がいるから難しいと感じるのでしょう。 難しいのであればいっそのこと説得もはじめることもやめてしまえばいい！ とかの諸葛亮孔明は言いました（嘘）。
冗談はさておき、そもそもアジャイル開発をはじめようとはじめまいと、もともと目指していた目指すゴールが変わるわけではありません。
もちろん上司を説得したり、「はじめます！」と宣言してはじめた方がいいケースもあります。 しかし、そこにこだわるばかりに立ち止まってしまうくらいなら、**説得しない・はじめないはじめ形**があってもいいのではないでしょうか？
最初は説得しないはじめ形について。
最近、私は新しいチームに異動しました。 異動することを知った後、新しいチームでどんな価値を生み出すのか、そのために私が何をすべきなのか考えました。 そして最初に私がやったことはとにかく“話す”ことでした。各メンバーに1対1でヒアリング、ランチや雑談でコミュニケーションをとりました。
これは、リーダー・Product Owner・ベテランエンジニア・新人エンジニアいろんな人と話をし、それぞれが課題におもっていることをリストアップしたものです。 まとめてみて気付いたことは、**みんな共通して今よりよくしたいと思っている**ということです。
同じ想いを持っているのであれば、説得は必要ありません。 説得や交渉のように相対するコミュニケーションではなく、同じ方向をみて意見を出し合えるコミュニケーションの場をつくるだけでチームは進んでいくと私は確信しました。
よくバスに乗せるという例えを聞きます。しかし今よりよくしたいという想いを共感できない（バスに乗らない）人はいるのでしょうか？ 「サービスをもっとよくして利益を上げたい」 「仕事を終えて早く帰りたい」 「最新の技術を使いたい」 言い方は様々ですが、これらは本当に違う方向を向いているのでしょうか？ 屁理屈かもしれませんが、本当にバスに乗らない人がいるのだとすると、どんな方法をとろうとも一緒に働きたくないでしょう。
次にはじめないはじめ形について。
私は、「はじめます」と宣言して失敗した経験があります。 それからは宣言するのはやめました。
これは実際にいままでのふりかえりででたTryの一部です。 こうやって眺めてみると難しいことはありません。
多くの現場で、意外と当たり前に思えることができていなかったりします。まずそれを当たり前にすることからはじめるのであれば、わざわざ「はじめます！」なんて仰々しいはじめ方をしなくてよいでしょう。 そして、当たり前にするだけなので私でもはじめることができました。
はじめるハードルは調整可能です。高いハードルを感じているのであれば低くしてしまえばよいだけです。
最後に新しいチームに参加して4ヶ月で見えてきた成果についてご紹介します。
振り返りを数値でまとめてみました。 継続は力なり。小さなTryでも積み重ねれば大きな変化となります。
プロジェクトの進み方についても振り返ってみます。赤線は理想線（こう進んだら順調だなー線）、青線は実際の進捗を表してます。 計測しはじめた最初の頃はなかなか順調に進めることができず最後に「えいやっ！」でがんばる学生症候群でしたが、最近では毎週進捗を気にしながら順調に進めることができています。 少しは大人に近づいてきたかもしれません。
まだ大きな成果が出せたわけではないかもしれませんが、新しいチームでも“はじめる”ことはできました。
なによりも、同じチームメンバーの若手の子が「私もやってみたい」と言ってくれ、実際にふりかえりのファシリテートなどに挑戦してくれています。 このスライドはデブサミ2012で[@daipresents](https://twitter.com/daipresents)さんが話されていたものですが、もしかしたら少しだけ気持ちがわかったかもしれません。
アジャイル開発をはじめる・はじめないに関わらず、向かう先があってそこに向かう道があることは変わりません。 その道のりは険しいかもしれませんが、それはおそらくもともと私たちの仕事が難しいからであって何かをはじめたから険しくなったわけではありません。
どんなに道のりが険しかろうと、歩き出すことにハードルはありません。ハードルを感じているとしたらそれは自分自身が作り出しているのかもしれません。 したがって、説得しない・はじめないではじめるアジャイル開発があってもよいと私は思います。
最後に、なぜはじめ**形**という漢字を使っていたのかご説明します。 型・・・パターン 形・・・型に自らの血を注いだもの 本や勉強会を通して、多くの**型**を知ることができます。 しかし、型のままで役に立ちません。型を知り、自らの血を注いで形にしてはじめて価値が生まれます。 Agile Japanでも多くの型を見つけることができたと思います。ぜひ皆さんの熱い血を注いで形にして現場に活かして下さい。
https://www.slideshare.net/TakaoOyobe/ss-21894641
---
# 「スクラムを活用したアジャイルなプロダクト管理」を読んできた #postudy @TAKAKING22
URL: https://agile-monster.com/blog/product-management-with-scrum/
Published: 2012-12-23
---
第1回 読書会in東京 - スクラムを活用したアジャイルなプロダクト管理に参加してきました。
https://agilepmwithscrum.doorkeeper.jp/events/2215
>
>
> ″スクラムを活用したアジャイルなプロダクト管理″エクストリームリーディングSTART [twitpic.com/bnviic](http://t.co/FuVCttdz)[#postudy](https://twitter.com/search/%23postudy) — takao.oyobe (@TAKAKING22) [December 21, 2012](https://twitter.com/TAKAKING22/status/282081338650152961)
>
>
### **なぜ参加したか**
本書内の推薦文の中で、Agile2012で出会ったEllen Gottesdiener（DISCOVER TO DELIVERの著者）が「全ての成功するアジャイルなチームは、全員がプロダクトマネージャーと同じような考え方をする」という一文を寄せているのを見かけて私はこの本を読むことを決意しました。 私は職種的にはエンジニア職ですが、最近はプロダクトオーナーのことをちゃんと知る必要を強く感じています。かのJeff Patton曰く「プロダクトオーナーシップはプロダクトに関わるすべての人が持つべき」で、この言葉は私に深くささっています。 意外とプロダクトオーナーについて深く記述されている本（特に和訳されているもの）は見当たらず、この本がプロダクトオーナーについて理解する一つのきっかけになればと思い今回読書会に参加させていただきました。
[itemlink post_id="2336"]
**えくすとりーむりーでぃんぐ**
今回の読書会はエクストリームリーディングという手法をとりました。 エクストリームリーディングについては、やってみた感想やこうしたらいいのではという想いも持っているので、別途まとめようと思います。 以下の記事の一節でも触れられているので参考に貼っておきます。
- [第2回 対話を促進する学び場の運営ノウハウ［中編］ 勉強会当日の進め方](http://gihyo.jp/lifestyle/serial/01/study-meeting/0002)
ってことで簡単な流れだけ以下にまとめます。
- プロダクトオーナーに対する理解度でチーム分け ※なるべく同じレベルの人達でチームをつくる（効果的な議論のため）
- 1テーブル5人でエクストリームリーディング ※今回の進捗： 推薦文～「1.2.2 リーダーとチームプレイヤー」まで
- それぞれのテーブルごとにまとめた内容を全体に共有
- 読書会の振り返り（KPT＆気づき）
テーブルごとの共有の雰囲気を写真で共有。
発表する側も真剣。
みんな本を片手に聞いてます。
関さんナイスカメラ目線！
同じ読書範囲でもテーブルごとに出るアウトプットは違いました。
最後に自分の参加したテーブルのまとめだけ共有させていただきます。 1章の冒頭はプロダクトオーナーについて端的に書かれている部分でした。 プロダクトオーナーの役割は[スクラムガイド](https://scrumguides.org/)にあるように、以下のとおり。 **“プロダクトバックログを管理し、チームが実施する作業の価値を保証する「唯一の責任者」”** このプロダクトオーナーとして望ましい特性に挙げられているものを抜き出してみると、
- ビジョンを描き続ける
- それを伝え続ける
- チームと協働する
- イノベーションを奨励・変化・曖昧性・議論・衝突・遊び心・実験を理解
- リスクを恐れない
- リーダーとメンバーを両立
- ファシリテーション能力
- 忍耐力
ここだけみると、プロダクトオーナーはスーパーマンであるかのように思えます。 しかし、この一連の説明の最後に「起業家チーム」というタイトルでBill GatesやSteve Jobsなどの有名なリーダーの例について触れているコーナーがあり、その中で、 **“優れたチームなら、与えられたアイデアが平凡でも、それを素晴らしいものに変えてしまうでしょう”** というフレーズが出てきます。このフレーズにこそ作者の意図があると私たちは読みました。 プロダクトオーナーの役割は、とても重要なものであると同時にとても大変です。しかし、それを**一人ですべて実現する必要はありません**。ビジョンを見据えて実行し続けながらも、時には足りないものをさらけだしてチームに埋めてもらう勇気も必要なのかもしれません。 まとめ 冒頭に書いた通り、エクストリームリーディングについては別途まとめます。 よく考えてみたら、「読書会」にまともに参加するのは私にとって初めての経験でした。私は一通りさっと本を読んで参加しましたが、さっと読んだ時と読書会を通して得られた感想はまったく違うものになりました。アウトプットを意識してインプットすることで理解度は深いものになります。 エクストリームリーディングは、事前に読んでこなくても参加できるため、現場のチームや社内読書会のようなものをやるときにも使えるかもしれません。 本の内容については、このエントリーではまだ冒頭にしか触れていませんが、プロダクトオーナーについて理解したいという私と同じ想いを持った方にはおすすめできる一冊です。 もし興味を持たれた方はぜひ次回ご参加下さい！ エキストリームリーディングのおかげ？でページ数としてはあまり進んでいないので、全然追いつけます。
https://agilepmwithscrum.doorkeeper.jp/
**おまけ**
二次会の飲み会の席でも本を取り出して語りあう図。
[itemlink post_id="2336"]
---
# いろんな会社の若手エンジニアを収穫してきた！ #オブラブ収穫祭 #oblove
URL: https://agile-monster.com/blog/oblove-engineer/
Published: 2012-10-14
---
[オブラブ](http://objectclub.jp/)さん主催オブラブ収穫祭〜若手エンジニアの集い、実りの秋〜に参加してきました。
https://esminc.doorkeeper.jp/events/1746
まずはいつもの・・・
>
>
> フライングオラクルなう！ [#oblove](https://twitter.com/search/%23oblove) (@ 日本オラクル株式会社 本社) [4sq.com/Tn9j6q](http://t.co/BQOAZi7D) — takao.oyobeさん (@TAKAKING22) [10月 13, 2012](https://twitter.com/TAKAKING22/status/256976382125563905)
>
>
>
>
> ギリギリ若手枠で参加中！ ： オブラブ 収穫祭 〜若手エンジニア、実りの秋〜 [esminc.doorkeeper.jp/events/1746](http://t.co/KSo546oO) — takao.oyobeさん (@TAKAKING22) [10月 13, 2012](https://twitter.com/TAKAKING22/status/256975221570039808)
>
>
**なぜ参加したか** 主には以下の2つの視点で参加してきました。
- 同年代のエンジニアがどんな経験をしているのか
- 他社の新人教育制度はどんな感じなのか
私自身社会人4年目のエンジニア（ギリギリ若手枠：25歳前後）で、約1年前から勉強会等に参加するようになって他社の方と交流する機会が増えたのですが、自分より年上の方が圧倒的に多い印象でした。そんな時にこの会を知り、他社の同年代の人達がどんなことをしているのかのぞいてみたくなりました。 またこの4年間の間にメンター（新人教育担当）を何度かさせていただいた経験もあるのですが、他社がどのような教育を行っているのか教育側からのお話も聞けるいい機会だと思い参加しました。
参加者は若手エンジニアが過半数、教育担当者10数人、学生数人でした。 **講演レポート** 以下講演のポイントをまとめさせていただきます（ムラはご容赦下さい） **講演概要**
- 各社新卒1〜2年目数名＆教育担当者の方の発表
- COOKPAD、paperboy & co.、DeNA 、GREE、永和システムマネジメントの順
**COOKPAD**
- 井原さん（[@ihara2525](https://twitter.com/ihara2525)）
- 社長室エンジニアの方（教育側）
- 教育制度は基本的には無い
- やりたいことをやってもらうという方針
- 新人に求めることは、会社に何かをしてもらうのではなく**会社を利用して何をするのか**
- **遠慮は悪**
- やりたいこと、得意なこと、やるべきことの重なる部分を見つける
- やる気がある人を集める
- **やらせるのではなく、やりやすい環境をつくってあげること**
- クックパッドオープンソースソフトウェアポリシー
- Githubアカウント
- 書いたソースは公開推奨
- **どんどんプルリク**できる環境
- **車輪の再発明ではなく既に世の中にあるものを調べて見つけてコミットする**
発表スライド：[How to Glow Up in COOKPAD](https://web.archive.org/web/20190823111054/https://speakerdeck.com/r7kamura/how-to-grow-up-in-cookpad) ※スライドは現在非公開になっています。
- 中村さん（[@r7kamura](https://twitter.com/r7kamura)）
- 2012新卒入社エンジニア
- 本人主義の中でどうやって強くなろうとしたのか
- 初日から自走、責任（本番権限）、成果
- **下手なコードを書くと全エンジニアから指摘が飛んでくる**
- **Githubの全てのdiffをチェックしていたらコードを書けるようになった**
- **社内から得たものだけでは社内以上にはたぶんなれない**
- 勉強会などの社外活動やオープンソースを通して社外からも情報を得る
- 自分自身も新しい知識（アジャイルなど）を社内で展開していく
- **PM5:00を過ぎたらリファクタリング**することにしている
**paperboy & co.**
- 中尾さん（[@shikakun](https://twitter.com/shikakun)）
- 2012年新卒入社デザイナー
- 大学時代に映画作り→他人とつきあうのはつらい→Web業界なら1人でも→入社
- デザイナーがいない部署に配属
- 1週間缶詰めで新人だけでサービスづくり（まめぶろ）
- サービス作りは盛り上がり、その後もコピー機の後ろでカンバン
- エンジニアに混ざってRailsを勉強
- shikakunアプリ公開中（shikakunのアカウントでTweetできちゃうアプリ）
- やってみると、**誰かと一緒になにかをつくることは楽しい**
- 黒瀧さん（[@kurotaky](http://twitter.com/kurotaky)）
- 2012年新卒入社エンジニア
- Nexus7を購入した際、宛名がBlack Waterfall（黒瀧）と送られてきた
- 新人研修でカスタマーサービス研修→**人がサービスを使っていることを実感**
- emacsを使わないと教えてくれない研修
- 一ヶ月でRailsをマスターする研修
- 社内のスーパーエンジニア達に箱詰めで教えてもらう（**ドクターペッパー付**）
- **ひどいコードを書くとさらされる**
- **問題が発生したらログを読む／エラーメッセージを読む／テストする**
- サービスリリースしたらくす玉を割る文化
- 社内に意識本棚という意識が高い本が並ぶ本棚が存在
- 損失も負けじと意識本棚（お金がないので平積み）を実施中
- 伊藤さん（[@hiboma](https://twitter.com/hiboma)）
- 新卒エンジニアのOJTのお世話（教育側）
- DevOpsという言葉は垣根を作っているようで好きではない
- **なんでもやってもらってその中から好きなことを見つけてもらえばいい**
- 新人でも場合によっては本番sugo許可
- **責任感やリアル感を持ってもらいとにかくなんでもやってもらう**
- **Puppet + Magilicaでなれれば15〜30分で開発環境作成**
**DeNA**
- 後藤さん（[@go_to_mo](https://twitter.com/go_to_mo)）
- 新卒2年目のエンジニア
- エンジニアを大切にする会社だと実感
- エンジニア研修をクリアしないとエンジニアになれない
- 新卒でもいい意見は採用される
- エンジニアもバリバリ企画にからむ
- 社内にすごい人がたくさんいる
- **自分よりすごい人がいないと成長が止まってしまう**気がするのでいい環境
- 大事にしていることは次の3つ
[itemlink post_id="2458"]
- 武部さん（[@nuichi](https://twitter.com/nuichi)）
- 新人研修設計担当者（教育側）
- **日本でもトップレベルのエンジニア研修**だと自負
- あるある一般的な研修
- 現場の負荷が高い
- **チームやメンターに教育が依存してしまう**
- 現場「**やっぱり受け入れなきゃダメですかね？**」
- DeNAの研修
- **基礎を終えましたではなく一流にする**
- ポテンシャル採用なのでプログラム未経験者も多数
- 現場「**待ってました！よく来てくれました！**」
- 「東京大学に二度入学するよりも難しい（研修）」 via 研修担当者
- 「宇宙飛行士になる訓練よりは、少しマシ」 via 研修責任者
- ↑ざっくりな研修内容
- 研修する側が大事にすべきこと
- **育てることは生半可なことではない**
- **現場がほしがる人材を育てる**
**GREE**
- 吉川さん（[@tsuyoshikawa](https://twitter.com/tsuyoshikawa)）
- 教育側
- **社内テンプレをつかいなさいってアレ・・・orz**
- **メンターをつけて後はよろ！は現場の負担が大きい**
- GREE Bootcamp - 基本的なGREEの開発の流れの習得
- **技術とマインドは切り離せない**
- **教える側のスキルも向上させる（教える側の振り返り）**
- **教育の基本は（自分が）もらったものを（後輩に）返して行くこと**
- 露木さん
- 2012新卒エンジニア
- 今回が勉強会デビュー
- **入社前に思っていた会社像と大きく変化した**
**永和システムマネジメント**
- 馬場さん（@kbaba1001）
- 2012新卒入社エンジニア
- 入社して感じていることはコードを書くスキルの向上
- **Githubのpull requestに対して今週だけで146個のコメント**
- 教えていただけることがありがたい
- **コードを介したコミュニケーション**
- 永和のGit **Masterには変なコードは存在しない！**
- 社内のコードを読むことで本とは別の知識を得られる
- 外部勉強会は正直めんどくさいと思っていた
- が、社内にはスーパースターばかりなので同じレベルの人とも出会えるいい機会
- **同レベルの人とのふれあいの中で教え合うことでレベルアップ**
- 今の**一番の課題は続けること**
- 田垣さん（[@akiinyo](https://twitter.com/akiinyo)）
- 新卒2年目エンジニア
- プログラム未経験で入社
- **自分でWebアプリをつくれたらいいなーというあこがれで入社**
- 入ってみるとそこは**想像以上にわけのわからない世界**だった
- 最初は動きそうなコードをコピペ（結局大量のコードを読むので勉強になった）
- キーワードでひたすらgrep
- おすすめは**自分のPRJのコードをとにかく読むこと**
- 最初は「**テストを先に書くといいらしい**」からスタート
- そうすると・・・実装しやすくなる、意識高いらしい
- やってみてもよくわからない、**でもやる！**
- 最初は仕事ができる気がしなかったけど今は**少しだけ自信がついた**
- pull requestするとはなまるマークや**くじらさん**の絵文字がもらえるようになった
- その世界の住人になりたいと思う気持ちがあれば大丈夫
- みんな受け入れてくれるし、**楽しいことや嬉しいことがたくさんあった**
- 諸橋さん（[@moro](http://twitter.com/moro)）
- 10年目エンジニア（教育側）
- **われわれはどうしてお金をもらっているのか**考えることが重要
- 誰がお金をだしてくれているのか
- お金をもらうには、「ちゃんと仕事を終わらせる」「普通にやる」
- ちゃんと仕事を終わらせるには**アウトプットの意識が重要**
- シンプルに議事録てアウトプット意識してもらう研修
- 報告することは自分の気持ちを伝えること
- 悪いニュースこそ早くいう
- **チームであればたいていのことは解決できる**
- 普通のことをふつうにやる
- 新人の子の発言「テスト書かないでどうやってコード書くんですか？」（純粋）
**まとめ**
大量採用への対応のために大きな仕組みづくりが求められているケースもあったり、会社の状況も様々なので教育に対する取り組みも多種多様でした。 しかしその中でも、
- **どう成長してもらうかを本気で考える**
- **状況によって教育も常に変化させていくこと**
は共通事項のように感じました。 業界動向も最新技術も入ってくる人材も大きな流れの中で大きく変化していくため、教育もそれにあわせて変化していく必要があります。 本勉強会のように、他社のリアルな教育への取り組みとそれによる被教育者の成長を知ることができる機会はとても貴重だったように思います。 という真面目なまとめの後で個人的な感想です。 まずは同年代（よりもちょっと後輩だったかな）のエンジニアの皆さんが活き活きとなにより発表されていることが印象的でした。それを見ながら、
>
>
> やっぱりプレゼンテーションはテクニックや名前じゃなくて、想いやメッセージや臨場感だのぅ。まー単純にそっちの方が好きなだけかもですが… — takao.oyobeさん (@TAKAKING22) [10月 13, 2012](https://twitter.com/TAKAKING22/status/257073100385038337)
>
>
なんて感じたり。 中でも個人的な今日一は、田垣さんのプレゼンでした。
>
>
> プログラミング未経験で永和さんに入った新卒2年目エンジニアの女の子のお話、同じく未経験で入ったのですっげーわかるなあw（4年目だけど） [#oblove](https://twitter.com/search/%23oblove) — takao.oyobeさん (@TAKAKING22) [10月 13, 2012](https://twitter.com/TAKAKING22/status/257019445548036096)
>
>
私自身も未経験からのエンジニアスタートなので共感する点が多かったこともありますが、等身大で全力なプレゼンテーションがとってもすばらしかったです。 それにしても・・・ **プログラム未経験で入った2年目の女の子が普通にTDDで実装してpull requestを送って絵文字のコメントをもらって喜ぶ永和さん恐るべしです！！** また個人的にうれしい出来事もありました。 勉強会に参加しながらまわりの後輩を連れてきたかったなーなんて思っていたのですが、
>
>
> 同じグループの新卒エンジニアの子を勉強会で発見！グループのエンジニアMTGで自分が行く勉強会や面白そうな勉強会をちまちま紹介していたのを見てきてくれたそう。こーゆーの嬉しいなー — takao.oyobeさん (@TAKAKING22) [10月 13, 2012](https://twitter.com/TAKAKING22/status/257028111428898816)
>
>
難しいことだけでなく、**学びってこういう小さなところからつながっていく**こともあるんですね！
---
# DISCOVER TO DELIVER : ユーザーの本質的価値をDISCOVER(発見)しDELIVER(届ける)する新たな方法
URL: https://agile-monster.com/blog/discover-to-deliver/
Published: 2012-09-29
---
Agile2012で参加したセッションの中で、個人的にもヒットだった[The Product Partnership: Using Structured Conversations to Deliver Value](https://web.archive.org/web/20121117100443/http://www.discovertodeliver.com:80/index.php?route=common/home)（直訳：プロダクトとの友好的な協力関係）。セッション内容は、[DISCOVER TO DELIVER](https://web.archive.org/web/20121115005349/http://www.discovertodeliver.com:80/)という発売前の本を題材に著者である[Mary Gorman](https://web.archive.org/web/20130616053110/http://agile2012.sched.org/speaker/submit2011_4533)と[Ellen Gottesdiener](https://web.archive.org/web/20130616054828/http://agile2012.sched.org/speaker/submit2011_60)がWork Shopを行いました。 先日(2012/9/25)、ついにその[DISCOVER TO DELIVER](https://web.archive.org/web/20121115005349/http://www.discovertodeliver.com:80/)が一般発売されたので、ご紹介させていただきます。※もちろん本は全編英語ですw **参考リンク**
- [DISCOVER TO DELIVER](https://web.archive.org/web/20121115005349/http://www.discovertodeliver.com:80/) : Book Web Site ※書籍サイトは公開終了しています（当時のページのアーカイブ）
- [著者であるEllenのBlog ](https://www.ebgconsulting.com/blog/announcing-the-release-of-discover-to-deliver-agile-product-planning-analysis/)
**About "DISCOVER TO DELIVER"**
[DISCOVER TO DELIVER](https://web.archive.org/web/20121115005349/http://www.discovertodeliver.com:80/)では、価値を見つけて届けるまでの過程をステップで説明しています。
ポイントをまとめると、
- **ユーザーを中心**におく
- 会話することが重要
- ストーリーやバックログ
- **Discover (発見) と Deliver (届ける) を繰り返す**
- 繰り返してユーザーにとっての**本質的なプロダクトの価値**を導きだしていく
こんな感じです。
本で紹介されているプロダクトのコンセプトや価値を探求していく各ステップは、フレームワークのような使い方ができると思います。
以下のAgile2012のセッションレポートにもありますが、ちょうどインセプションデッキとストーリーの間をカバーするような内容になっているため、プロダクトオーナーに近い仕事の方にはぜひ読んでいただきたい内容です。
- [インセプションデッキとストーリーの間を埋める7つの要素 – Agile2012 現地レポート(7)](http://www.manaslink.com/articles/4258)
（著者であるMary & Ellen with [@uedayo](https://twitter.com/uedayo)さん） 私はセッションを受けて内容がとても面白かったので、会場内で事前販売していた本を購入しました。本は、写真の壁に貼ってあるようなイラストが多く、英語は得意でない私でもイメージがわくので読み進めることができています。 **Agile2012のセッションの反響や発売後のTwitterを見ている限り、アメリカでも注目の本・手法の一つです。今後名前を聞くようになるかもしれません。**
---
# アジャイルとウォーターフォールについて本気出して考えてみる
URL: https://agile-monster.com/blog/agile-and-waterfall/
Published: 2012-09-25
---
なぜアジャイルなのですか？改めて考察するウォーターフォールとの違いに参加してきました。
ウォーターフォールはよくディスらr・・・アジャイル開発と比較されることが多いです。私もアジャイル開発を経験する前にも何度か開発プロジェクトを経験しました。しかし、それらはウォーターフォールをしていたわけではなく、「ウォーターフォールのようななにか」に過ぎなかったように今では思います。
だから、ウォーターフォールについても勉強したいと考えていたのでとてもよい機会になりました。
株式会社ジャムズを経営されている玉牧 陽一さんのご講演のポイントをまとめます。 詳細については下記リンクをぜひご覧ください。
https://www.slideshare.net/yoichitamamaki/ss-14456822
## ウォーターフォールの原点に関わる流れ
- **1970年** [Managing the Development of Software Systems](https://web.archive.org/web/20100712085706/http://leadinganswers.typepad.com/leading_answers/files/original_waterfall_paper_winston_royce.pdf) via Winston Royce
ウォーターフォールの本質が書かれている論文
- **1985年** 米国防総省の規格書「[DOD-STD-2167](http://en.wikipedia.org/wiki/DOD-STD-2167A)」★
Royceの論文を参考に米国防総省がPRJの進め方をまとめた規格書- これがウォーターフォールの原点と言われている- この中では手戻りは絶対だめ！！と述べている ⇒追記：手戻りがだめと明記されたのは1988年発表の2167A版（原田さんありがとうございます）- 1995年のレポートで、「この方法によるPRJの約75%が失敗もしくはうまく適用できずに終わっている」と報告されている（※参照）
- **1994年** 上記の改訂版「**[MIL-STG-498](http://en.wikipedia.org/wiki/MIL-STD-498)」**
繰り返し型開発
- **2010年** CMU/SEI「**Considerations for Using Agile in DoD Acquisition」**
アジャイルを用いた調達やこれからの導入を促す趣旨のレポート
## ウォーターフォールの本質となった論文の概論
- 1970年 [Managing the Development of Software Systems](https://web.archive.org/web/20100712085706/http://leadinganswers.typepad.com/leading_answers/files/original_waterfall_paper_winston_royce.pdf) via Winston Royce
- 一番シンプルな開発モデル
- 小規模で自らが利用するソフトウェア開発には十分かつ合理的
- しかし大規模なシステム開発ではうまくいかない
- 実際のPRJでは追加工程が要求される（管理コストによるオーバーヘッドなど）
- **一方通行でうまくいくわけがない**
- **手戻りは存在する**があくまで想定内（1つ手前の工程まで）におさめる
- **顧客を巻き込むことの大切さ**
- ソフトウェア開発はシンプルなモデルのような簡単なものではない
**要点まとめ：**
1970年の論文だが今でも多く使われているウォーターフォールの本質が述べられている。ウォーターフォールでは手戻りは絶対だめという風潮があるが、これはウォーターフォールの原点となった「[DOD-STD-2167](http://en.wikipedia.org/wiki/DOD-STD-2167A)」で手戻りはあってはいけないものとされているからである。しかし、Royceの論文では**手戻りがあることを前提**としていて、その手戻りを想定内におさめることが大事だ述べている。当然この論文がそのまま開発に活かせるものではないが、それまで体系的にPRJの進め方をまとめられていなかった中で初の取り組みであった。
## ウォーターフォールとアジャイル
- 問題解決 ＝ 要求、アウトプット
- 問題解決における前提的 ＝ PRJの外で決めるものでPRJの中ではStatic
- 問題解決における前提的 ＝ PRJの外で決めるものでPRJの中ではStatic
- 解決手段 ＝ 要求を満たすための方法
- 解決手段における前提的 ＝ 良い方法は既存でそこに近づける
- 解決手段における前提的 ＝ PRJの中で決めて行く
**ウォーターフォールが難しい点**
- 初期の要求がなかなか**確定しない**場合
- 後の工程になって要求が**変更**になる場合
- 事前に**予見しきれない技術的課題**
- リスク管理とその運用の難しさ
- コミュニケーションの質の悪化
- **官僚的な追加作業**
**アジャイルとウォーターフォールの使い分け**
**要点まとめ：**
アジャイルとウォーターフォールはそれぞれに前提条件・向き／不向きが異なる。そのため、現状やプロジェクトの特性を正しく理解して適正をみる必要がある。
一般的にアジャイルとウォーターフォールの併用はよしとされないことが多いが、先攻してアジャイルで開発をはじめて仕様や設計が固まった時点でウォーターフォールにする併用の形の成功例もある。
どちらがいい／悪いではなく、概念やプロセスを理解してそれを活かせるように**現場現場で適用して行くこと**が重要である。
**我々の仕事（ソフトウェア開発もアジャイル開発もウォーターフォールも）はそんなに簡単なものではない**。
## スパイラルとアジャイルの違い
- スパイラルとは小さなウォーターフォールの連続
- スパイラル→渦を描きながら最終的には真ん中に収束して行くイメージ
- アジャイル→ぐるぐるまわりながら中心ですら適切な場所に移動していくイメージ
- 収束を前提とするかしないかの違い
## まとめ
今回の勉強会を通して感じたことは、
>
>
> "WF（[ウォーターフォール](http://d.hatena.ne.jp/keyword/%A5%A6%A5%A9%A1%BC%A5%BF%A1%BC%A5%D5%A5%A9%A1%BC%A5%EB)）と[Agile](http://d.hatena.ne.jp/keyword/Agile)"とか"WFとWFでないもの"っていうよりも、なんでもないもの大半で一部のWFと[Agile](http://d.hatena.ne.jp/keyword/Agile)って感じのイメージ。 — takao.oyobeさん (@TAKAKING22) [9月 25, 2012](https://twitter.com/TAKAKING22/status/250555500150784001)
>
>
>
>
> やっぱり神懸かり的な[ウォーターフォール](http://d.hatena.ne.jp/keyword/%A5%A6%A5%A9%A1%BC%A5%BF%A1%BC%A5%D5%A5%A9%A1%BC%A5%EB)による成功体験は、プロジェクトマネジメント視点ではしてやったりな気がするなー — takao.oyobeさん (@TAKAKING22) [9月 25, 2012](https://twitter.com/TAKAKING22/status/250555824236290049)
>
>
です。 少しこのあたりの話になると盲信的に、 「アジャイル最高！」 「ウォーターフォールはだめだ！」 「ウォーターフォールでないとだめだ！」 となってしまっているケースをよく見ます。 しかし、アジャイルもウォーターフォールもあくまで目的を達成するための選択肢に過ぎず、どちらがいい／悪いという議論は無意味な気がしています。 それよりも、
- **自分たち（プロジェクト、チーム、環境、状況）を理解して、今何が必要なのかを見極められるようになること**
- **それによって結果を出すこと**
こそが重要であることを忘れてはいけません。
・・・という前提で、きちんとウォーターフォールできる状況を考えてみると、
- ゴールが明確であること
- 状況／環境がコントラブルであること
- プロダクトがコントラブルであること
- 要求の出し手／プロダクトの作り手が機能できること
- 関係者のコミュニケーションが良好であること
- 上記全てがPRJの終了まで継続すること
これらの条件が必要かなと思います。 **うーん難易度が高い！！** **でも一度はキレイに滝を滑り降りたい！！** なんて野望を胸に抱きました。
---
# 達人出版会よりサムライ・エピソードが発売されました
URL: https://agile-monster.com/blog/samurai-episode/
Published: 2012-09-14
---
本日 2012年9月14日、[達人出版会](https://tatsu-zine.com/)さんより[サムライエピソード](https://tatsu-zine.com/books/samurai-episodes)が発売されました。 [サムライエピソード](https://tatsu-zine.com/books/samurai-episodes)とは、日本のアジャイラー総勢26名が現場で経験した成功・失敗を生々しく綴ったライブログとも言える一冊です。 実際の体験をリアルに綴っているので、日本のアジャイルな現場でどんな戦い（？）や修行が繰り広げられているのかを知ることができます。How To本とはまた違った気づきを得ることができるかもしれません。 今まさに現場で挑戦している方や興味を持っている方にはぜひ読んでいただきたい一冊です。
[](https://tatsu-zine.com/books/samurai-episodes)
[](https://tatsu-zine.com/books/samurai-episodes)サムライ・エピソード【[電子書籍](http://d.hatena.ne.jp/keyword/%C5%C5%BB%D2%BD%F1%C0%D2)】
26人のサムライ達 達人出版会 発行日: 2012-09-14 対応フォーマット: [EPUB](http://d.hatena.ne.jp/keyword/EPUB), PDF
[](https://tatsu-zine.com/books/samurai-episodes)詳細を見る
私も一つの章を執筆させていただきました。
- **第7章 邪道アジャイルのススメ ～アジャイルであるために必要なたった一つのこと** **～**
明日のXP祭り2012で発表させていただく内容も一部含んでいますが、私も例にもれなく現場での体験をもとに書かせていただきました。
**※ちなみにSME26は勝手に私が言っているだけで正式なグループ名でもなければ、どこからの劇場で活動しているわけではありません。** とりまとめをしてくださった[@HIROCASTER](https://twitter.com/hirocaster)さんが中心となって、勉強会などで有志を募って集まった26名のサムライ達です。 今回本ができあがるまではGitやFacebookを使ってやりとりをするという面白いプロセスを踏んでいたりします。 [達人出版会](https://tatsu-zine.com/)さんなので[電子書籍](http://d.hatena.ne.jp/keyword/%C5%C5%BB%D2%BD%F1%C0%D2)での販売です。
---
# 学び方を学んできたよ！ #devlove
URL: https://agile-monster.com/blog/how-to-learn/
Published: 2012-09-12
---
毎度お世話になっている[DevLove](https://web.archive.org/web/20100823194701/http://www.devlove.org:80/)主催の[学び方を学ぶ～オブジェクト指向の設計と実装を学ぶ～](https://web.archive.org/web/20120924055318/http://devlove.doorkeeper.jp:80/events/1605)に参加してきました。
"学ぶ"と聞くと学生時代の印象が強いですが、 私は社会人3年目の今が人生で一番学んでいる気がします。
勉強会に参加したり、本を読んだり、実際に体験したり、私たちのまわりにはとにかくたくさんの学ぶ機会があります。特に私たちのような技術職は学ぶことこそが仕事と言っても過言でないほどのInputとそこからくるOutputによって対価を得ています。
それでか学ぶ機会が多いにも関わらず、よく考えると**学んだことはあっても学び方を学んだことはなかった**です。
これはひょっとしたらとってももったいないことをしているのでは？と思い、今回参加してきました。
>
>
> [#devlove](https://twitter.com/search/%23devlove) 学んでもらい方を学びたいなー — takao.oyobeさん (@TAKAKING22) [9月 12, 2012](https://twitter.com/TAKAKING22/status/245850695507529728)
>
>
そして、ついでにせっかくなので自分だけでなくもっとまわりを巻き込んで、 **学んでもらうコツ**も学びたいなーなんて思ったりも。
学習パターン
- [井庭先生のスライド](http://www.slideshare.net/takashiiba)
- [Learning Patterns](https://web.archive.org/web/20210209130720/https://learningpatterns.sfc.keio.ac.jp/index.html)（※公開終了のためアーカイブ）
学習パターンは、一言で言うならば学び方のコツを抽出したものです。 学ぶという行為自体が抽象的でヒトに依存しているように思われがちであるため、他人の効率的な学び方を流用することがされにくかった。しかし、その学び方をパターン化して名前をつけることで他人が認識できるようになりました。
この学習パターンは、始めは学生の学び方の支援を目的として井庭先生と有志の学生によって作られたものが起源です。その後もそのPRJは続いていて、半年に1冊くらいのペースでいろんな学習パターンがまとめられているそうです。
**# 上記のサイトにPDFであがっているものもあるのでぜひご覧下さい!!**
最初は学生向けに配布したものでしたが、Web公開していたところソフトウェア業界を中心に一気に盛り上がったそうです。
とても興味深かったのが実際に学習パターンを作成して行く過程です。 その一連の過程を1000倍速でまとめられた動画があり、様子がとても伝わります。
- [Visual Mapping for Making a New Pattern Language for Creative Collaborations (Collaboration Patterns Project #2)](http://vimeo.com/42780071 )
誰もが使えるパターンにするために、ある特定の経験からパターン化するのではなく、全体からkj法などを利用して細かい部分に落としていく作業を行っているため1つ1つのパターンが作られるまでに多くの時間が使われているそうです。
**学び方を学ぶということ**
学習パターンはマニュアルではありません。マニュアルではないので、その通りにやればうまくいくという単純なものではないのです。 状況に合わせてパターンを選択して組み合わせることが大切です。ゼロベースではないので学びの初心者でも洗練されたやり方を参考に効率的な学びが実現できます。 難しく聞こえますが、自然と誰もがやっていることなのかなと思いました。 最初はやり方がわからなかった仕事も、先輩に教えてもらったり先輩の仕事を見て盗みながら、自分の中のパターンを増やしていってどんどん効率的にしていきます。その自然にやっていることを体系立ててまとめておくことで、どんな状況でも効率的に学ぶ手助けをしてくれるものだと理解しました。 前述のとおり学びの多い私たちは、とりわけ学び方を学ぶといいことが多いですね！ 面白かったことがいくつかあったので簡単にまとめます。 **Writers Workshop** やっぱり井庭先生のブログを読めば一発なのでリンクを貼らせていただきます。
- [パターン・ランゲージのライターズ・ワークショップ ](http://web.sfc.keio.ac.jp/~iba/sb/log/eid154.html)
簡単にまとめると、著者以外のヒトが集まって題材となるコンテンツについてディスカッションするワークショップ。著者の意図やまとめ方についてポジティブにディスカッションする。その間著者は発言してはならない。 書き手も読み手を意識して書くようになるし、読み手も本気で理解しようとするので面白いワークショップだと思いました。
**学習パターン実践編**
また、井庭先生の後に学習パターン実践編として発表された増田さんのお話もとても面白かったのでご紹介させていただきます。
https://www.slideshare.net/masuda220/ss-14263541
**現場に生かす** 今日お話を聞きながら現場ですぐに生かしたいことがちらほら思い浮かびました。
>
>
> [#devlove](https://twitter.com/search/%23devlove) 個人的なTryだけど、ストーリーの書き方のパターンをつくってみよーっと — takao.oyobeさん (@TAKAKING22) [9月 12, 2012](https://twitter.com/TAKAKING22/status/245844674412171264)
>
>
最近の私のチームのホットなトピックがストーリーの書き方についてです。 自分達が書いてきたストーリーやWebや本に転がっている実例がたくさんあるので、パターンにまとめてみたら面白そうな気がしています。
>
>
> [#devlove](https://twitter.com/search/%23devlove) 「Writers Workdshop」同じように他人が書いたコードや要件定義を、他人が説明する（書いた本人は発言禁止）レビューとか面白いんじゃないか — takao.oyobeさん (@TAKAKING22) [9月 12, 2012](https://twitter.com/TAKAKING22/status/245845765145112577)
>
>
上記で説明したWriters Workdshopもコードレビューや要件定義や設計フェーズでやってみたら多くの気づきがあるレビューになると思いました。 このあたりやってみたら別途ブログで紹介させていただこうと思います。 今回題材となった学習パターンを体験的に学ぶことができる「学びの対話ワークショップ」を近々DevLoveで企画して下さるとのこと。そうでなくても自分達でやってみたいと思います。
---
# HOTEL Gaylord TEXANにいたらだめになる！？
URL: https://agile-monster.com/blog/agile2012-gaylord-texan/
Published: 2012-08-14
---
今回はAgile2012の会場でもあるGAYLORD TEXAN HOTELに泊まっています。
印象はを3行で表すと
- とにかく広い
- ディズニーランド！？
- なんでもある
です。
 
中庭は室内なので空調が利いているのですが、見た目はディズニーランドのよう。
大スクリーンを備えたスポーツバーがあり、地元レンジャースの試合がある時は盛り上がるそうです。
この他にもワインバーやステーキハウス、コンビニ、スポーツジムなどホテルの中でだいたいなんでも済んでしまいます。
その中でもお気に入りはやっぱりプールです。幸運にも部屋を出て30秒のところに屋外プールがあり、AM7:00～AM0:00まであいているのでここに入り浸ってます。
こんな感じで。
いろいろ作業もはかどりますが、なんかいろんなものがだめになりそうな気がしました（苦笑）
ホテルについては以下の記事にも書かれているのでぜひ！
- [[8/12] Agile2012の舞台 Gayload Texanホテル – Agile2012 現地レポート(3)](http://www.manaslink.com/article/ac/agile2012/report_03/)
---
# Let’s go Rangers!!
URL: https://agile-monster.com/blog/lets-go-rangers/
Published: 2012-08-14
---
テキサス2日目。 適応能力だけは高い自分はジェットラグも食べ物にも悩まされること無くなく2日目を迎えました。
前乗りしたものだけの特権ということで、テキサスレンジャーズの試合を見に行きました 「きっと運がいいからダルビッシュが投げる日になる！」 なんてほざいていたら、
Oh, god…!!
ホテルから車で30分ほどのアーリントンにレンジャーズ・ボールパークはあります。
いい天気だったので40度近い気温がありましたが、日本と違い湿気は少ないので純粋な暑さを感じました。
球場の中は、エンターテイメントパークのようで、野球を見に来る場所というよりは野球を見ることを楽しむための場所という印象を受けました。売店やグッズショップなどが建ち並び、多くの人が試合中もショッピングを楽しんでいました。
中でも驚いたのは、レンジャーズのTシャツやユニフォームを着た人の多さでした。みんな何かしらのレンジャーズグッズを身につけており、日常的にきている人が多いのだろうと予想できます。
球場は日本の球場よりも収容人数が多いにも関わらず、グランドまでの距離が近く感じます。
いざ試合が始まってみても、ダルビッシュがすぐそこにいるように感じました。 彼はアメリカでも大きく見えました。彼が三振をとると「Yuuuuuuuu!!!!」とスタジアムが大きな声援で包まれます。愛されているんだな、と感じました。
しっかりとレプリカユニフォームを購入して応援した成果か、試合は見事にレンジャーズが８―３でタイガースに勝利。
## マダックス兄弟から金言！新型ダルで１２勝目
ダルビッシュも久しぶりの勝利を収めてくれました。 貴重な大リーグの試合を感染することができ、野球の試合内容よりも野球を見ることを楽しむという現地の人々の空気を肌で感じることができました。どちらがいいというわけではないですが、日本のそれとはやはり異なるものです。おそらく文章で表現しても伝わらないと思いますのでぜひ機会があれば見に行ってみて下さい。野球好きでなくても楽しめる空間だと思います。
最後はなぜか**EAGLES in レンジャーズボールパーク**で！！
---
# Agile2012がはじまりました！
URL: https://agile-monster.com/blog/start-agile2012/
Published: 2012-08-14
---
現地時間8月13日いよいよAgile2012がはじまりました。
ホテル内を移動して行くと・・・
だんだん人が集まってきます。
自分は前日に済ませてしまいましたが、入り口でRegistrationを終えればそこはもう会場です。
朝食も自由に食べることができ、ここでのコミュニケーションも醍醐味の一つになっています。
フリースペースではOpen Jamなど、飛び込み型である程度自由にセッションがひらかれていてにぎやかです。
そんなこんなでAgile2012はスタートしました。
セッション内容などをしっかりとまとめるのは[MANASLINK](http://www.manaslink.com/article/ac/agile2012/)さんの記事や後日紹介させていただくとして、カンファレンス中は個人的な振り返りや感想をお届けしたいと思います。
まずは初日のKPTです。
Keep
- 心は折れなかった ⇒むしろ楽しくてやばい
- 日本人のいないところに行くよう心がけた
- 事前にサマリーだけでも予習しておくと、英語ができなくてもなんとなくの概要をつかめた
- 素直に「I don't know」と言えばけっこうやさしく教えてくれる
- 「May I sit here?」からはたたみかけると話がつながる
- テキサスでの目的の一つ、ロデオ体験Done ⇒日本の暴れん坊将軍の実力をいかんなく発揮
**Problem**
- WSの話し合いにはほとんど参加できない（英語力的な意味で）
- 予習が足りない
**Try**
- 前日に次の日のセッションの予習の時間をつくる
初日はワークショップばかりでした。
やはり言語の壁は厚く、講義形式はまだしもコミュニケーションが必須なワークショップは相当の英語力が無い限りつらいものがあります。毎年その壁に苦しむ方が多いと聞いていました。
自分自身も例外にもれずやはりワークショップ内での会話になかなか参加できませんでしたが、心は折れませんでした。何より悔しい思いでいっぱいでした。来年までに英語をネイティブと話せるレベルにまであげようと誓いました。
そして悔しい以上に、楽しかったです。
よく**プレゼンテーションはインターラクティブなもの**だと聞きますが、海外のカンファレンスでは実体験で知ることができます。プレゼンテーション中もスピーカーとオーディエンスが**コミュニケーション**しながらセッションを作り上げます。単純な話し手／聞き手の関係性を保つのではなく、その場にいる全員がセッションの目的に向かって**参加**します。ワークショップでも彼らは**ガチ**です。本気で意見を出し合い、ゴールに向かいます。
なんていうのか、純粋なんだなーと感じました。何もかもが大きいからなのか、小さなことを気にせずに本来の目的に向かって一番自然な選択をしているように感じました。このあたりはもうちょっとまとめて帰国後に何かのアウトプットにしたいと思います。
とにかく楽しいです。
やれることには何でも首をつっこんで、得られるものは何でも得るつもりで残り期間も突っ走ります。
最後に初日をつっ走った成果を少しだけ。
- [[8/13] Agile Conference恒例のパーティナィ！ICE BREAKER RECEPTION – Agile2012 現地レポート(8)](http://www.manaslink.com/article/ac/agile2012/report_08/)
---
# アジャイル2012に参加してきます！！
URL: https://agile-monster.com/blog/go-to-agile2012/
Published: 2012-08-11
---
Agile2012参加のために来たここテキサスの地にて、満を持してブログを始めさせていただきます。（ブログへの想いやもろもろについてはまた後日書かせて下さい） MANASLINKさんで、Agile2012参加レポートを書かせていただいていますのでそちらもぜひご覧下さい。
https://www.manaslink.com/articles/3750
ブログでは、レポートとは違ってもうちょっと個人色の強い内容を書きたいと思っています。 さて、今回[Agile2012](https://www.agilealliance.org/agile2012/)に参加するにあたって初めて海外旅行のもろもろを自分で行うことになりました。
Expediaを利用して格安チケットを購入し、Uniter航空の飛行機でヒューストン経由でダラスへと向かいます。 ブログでは飛行機内の様子を中心にしましょう。
機内の様子はこんな感じです。
お気づきの通りエコノミーでも各席前方にタッチパネルが存在し、映画・音楽・ドラマ・ゲームを楽しむことができます。種類は洋画中心で多くないですが、まだ見ていなかったテルマエ・ロマエを見ることができました。
音楽もBon JoviやGreen Dayなど洋楽中心のラインナップ。
隣の席のアメリカ人の女の子とチェスで戦って負けました。 （とにかく時間をつぶすことができるってことをアピールするためにいろいろ撮影しておきました。） そんなこんなをしている内に経由地のヒューストンについたのですが・・・
悪天候によるダイヤの乱れもあって着陸までにうずまきを描いてようやく着陸することができました。
ついに邪道アジャイルサムライがアメリカはヒューストンの地に！！
そんなヒューストンで真っ先に買ったものはレッドブル！！
見た目は似ていますが成分が違うのか日本のものと味が違います。 しかも日本ではカロリーゼロなこの色のレッドブルもなぜかちょっとだけカロリーありました。
そんなヒューストンで国内線に乗り継ぎ、
約1時間でダラスへと到着しました。 海外旅行も初心者！ 英語も怪しい！ こんな私でも**やってみれば意外となんとかなる**もんです。 ホテルの様子もご紹介したいのですがそれはまた明日！