Q. 1人でスクラムを始めたいと思いますができますか？

• 「スクラム」はできないですが、スクラムのなかの特定の手法は可能です。たとえば、バックログを作って上から順番にやっていくとか、定期的にふりかえるとか。

Q. 遠隔チームでのスクラムはデジタルツールを使えば可能？

• 「最初のうちは同じ場所で、慣れてきたら離れて」が基本
• チームの成熟度次第なので、最初からうまくできるチームもあります

Q. チームの相乗効果を上げるにはどうすれば？

• チームの数だけやり方がある。
• チームだけの文化や言語を作っていくことが重要かも。「一緒にご飯を食べる」というのは鉄板です。
• 『Team Geek』オススメです！！！！！（宣伝）

Q. 開発チームがステークホルダーに直接アクセスするのはNG？

• あとでPOに情報共有できればOK
• でも、最初からPOが同席したほうがよいです

Q. POとSMは兼任してもいい？

• 兼任できなくもないですが、WHATとHOWは対立することが多いので、役割分担したほうが無難です。スーパーマンが求められます。

Q. スクラムは何がすごいのかわからない

• 普通の人がそれなりに成果をあげられるところ
• 詳細な規定がないので、幅広い分野に適用できるところ（ハードウェア、教育、組織変革）

Q. アジャイル開発とは？

あえて定義するなら

1. 人間重視
2. 適応型計画づくり

Q. アジャイル開発には他になにがあるのか？

• アジャイル開発宣言に集まったのは、XP、スクラム、クリスタル、DSDMだったと思う
• あとから追加されたのは、カンバンとリーン
• 最近だと「モダンアジャイル」というのもあります
• 大規模用のLeSS、NEXUS、SAFeとかも

Q. スクラムちゃんとまわってるかの判断

• 難しい。。。
• 何をKPIにするかは組織次第
• 特になければ、開発速度（ストーリーの消化具合）がスプリントごとに上昇しているかどうか（改善できているかどうか）

Q. ストーリーを分割するポイントは？

• INVEST: 独立、交渉可能、価値、見積り可能、サイズが手頃、テスト可能
• 分割パターン: ワークフロー、ビジネスルール、作業分割、難しい部分と簡単な部分、データの種類、データの入力方法、機能レベル、CRUD、先にテスト的に実装するところとあとで実装するところ
• 部品よりも、利用シーンごとに分割したほうがよい

Q. スクラムができるようになるとSMは暇になる？

• 暇になります。
• 暇なほうが問題発生時に対応しやすい。
• いつまでもどれだけでも改善できると考えると、終わりはない「俺たちの旅はいま始まった（ry」
• 暇であっても、どこかにやることはある。開発チームだけでなく、POや組織の面倒を見ることもSMの役割。特に組織の教育は大変。
• 本当に暇なら複数チームを担当してもよいです。
• 開発チームが持ち回りでSMになってもいいです。

Q. スクラムってどういうときに使うと便利？

• よくわからないことをやるとき（やり方がわからない、やることがわからない）にはスクラムみたいなやり方しかない
• 考えながら行動するので時間がかかる
• 誰か優秀な人がまとめて指示をしたほうがよいときは、そっちのほうが効率的
• スクラムのほうが考える力はつく

Q. 社内のスクラム開発では何でもできるすごいデベロッパーが求められているが、大切なのは技術より、人間性？

• 技術「より」ではなく、技術も人間性も「両方」重要です
• どちらが欠けてもうまくいきません
• スクラムは技術については触れていません（広い分野に適用可能）
• 仕事のなかですごいデベロッパーが生まれるような工夫が必要 → ラグビーチームの特徴「6. 学びの共有」

Q. レゴスクラムはどんな人におすすめ？ 経験者？初心者？

• 基本的には、エンジニアとそれ以外の連携のために作られたものです
  • エンジニアであれば、いきなりアジャイル開発をやればいい
  • エンジニア以外は、アジャイルを「体験」することができない
• 経験者であっても、学びがあるみたいです

Q. 1スプリントに入らないときは？

• スプリントごとに見せることがスクラムなので、どうにか分割してください。
• 仕事によっては、スプリントの区切りが邪魔になる場合もあります。そのときは、スクラムではなくカンバンが便利です。「イテレーションレス開発」と呼びます。

Q. エンジニア以外の人はどの程度エンジニアの知識が必要？

• 隣の人のことが全然わからないと協力できないので、少なくとも会話できる程度には必要です

Q. どんな人がPO、SMに向いてる？

• PO：起業家的な人、意思決定ができる人、KPI分析ができる人
• SM：問題解決ができる人、根回しがうまい人、気配りができる人
• とはいえ、プロジェクトによって違います。

Q. 1日何時間稼働で見積もるのがよい？

• 「全力でやって5時間」というのが多い気がします
• 実際の労働時間は8時間かもしれません

Q. 開発チームのレベルが異なるときの見積もりはどうする？

• スキルに依存しない「規模見積もり」が基本で、チームでの見積り値を求めることになります（とはいえ難しいですね。。。）
  • 1つのストーリーに引きづられないように、できるだけ細かくばらばらにするとか？
  • 長期的にはチームで平坦になるはず！
• 「その人しかできない仕事」があれば、バックログの順番も考慮する必要があります。

Q. （開発手法の）組み合わせを検討・決定するタイミングは？

• 開発手法の決定もComplexな問題なので、フィードバックを繰り返しながら適用することになります。
• 最初は何から始めても構いませんが、改善やフィードバックのタイミングを計画しておく必要があります。

Q. 適正規模は？ 何人でやるのがベスト？

• 10人程度までとされていますが、現実的には5人程度が理想です。

Q. 大きい開発に使えるの？

• 単に「作業量が多い」という意味での「大きい」だと、作業の分割が可能なので、複数のスクラムチームを作ることになります。
• 大規模向けアジャイル手法としてはLeSS、Nexus、SAFeなどがあります

Q. どの業界でも適用できる？

• 業界よりも、プロジェクトごとに適用できる/できないが決まる気がします

Q. 今またアジャイルがなぜ盛り上がってるのか？

• 基本的には「当たり前」の領域になっています
  • 海外からは「まだやってないの？」レベル
• 盛り上がっているとすると、レイトマジョリティにも浸透してきた感じでしょうか？

Q. もう終わった考え方じゃないの？

• 当たり前すぎて言う必要もない、という話だと思います
• 他の手法のベースとなる考え方になっています
  • リーンスタートアップ
  • デザインスプリント

Q. プロダクトの価値と組織の成熟とのバランスのとり方は？

• 組織が成熟するのを待っていては時間がかかるので、まずはやってみる
• 最初はうまくできないので、失敗やフィードバックの頻度を上げるために、イテレーションを短期間に設定する
• 繰り返していけば、プロダクトの価値も上がる……はず

Q. 見積もりの基準は？

• 1pt = 1時間、1日あたり5時間労働（エフォート100%）で5ptというところが多い印象
• 実測値とのズレは適宜解消する必要があります（ポイントのインフレ感）

Q. POはどういう人をアサインすべき？

• 意思決定ができて、予算権限があり、プロダクト（ユーザーや開発）に理解がある人
• プロジェクトマネージャーにプロダクトの知識を植え付けるのが早いかも？
• 役員だと他の仕事が多すぎる気がします

Q. 要件はどの粒度で、いつ、だれがきめるか

• 粒度：最初は粗くてよいが、最終的には開発できるレベル
• いつ：開発直前まで
• だれが：最終的な判断はPO

Q. 絶対値を使わない場合のプロジェクトの予算決めは？

• どこかで「1」を何かに変換することになります。基準は特にありません。できることなら初期フェーズで「提案」と称して実際に開発してみて、実測値で出したほうがいいでしょう。

Q. WF型開発とアジャイル開発では、設計書の作り込み度合いに違いがあるか？

• 作り込み度合いは開発者のレベルによって違う
• 両者の違いは、編集頻度
• アジャイル開発では開発にあわせて更新していくイメージです

Q. 進化的開発だとどんどんフィードバックが大変になるのでは？

• 最後にまとめてドーンとやるか、少しずつ定期的にやるかの違い
• 基本的には差分を中心に

Q. カンバンで作業をDoneにすると、タスクがDoneにならないのか？

• タスクレベルだとそうなるが、カンバンでは「要求」や「機能」を付箋紙にする
  • ある機能の「分析→設計→実装→テスト」
• スクラムにカンバンを入れる場合、要求ではなく「タスク」レベルでカンバンを作る
• どのレベルにするかは使い方次第

Q. アジャイルはコスト高い？

• それしか使えない領域では、比較対象がないので無意味
• 誰でも出来る簡単なプロジェクトでアジャイル開発をやれば、ムダが発生します → コストにつながります

Q. UIの監修はSM？SMとPO？

• 基本的にはPO
• POは映画監督なので最終意思決定者ではあるが、美術監督みたいな立場がまた別に必要になる

Q. フルスタックの人がスクラムすべき？

• チーム全体で成果物を出せるならフルスタックでなくてもOK
• 完全な役割分担よりも、隣同士の役割のことは知っておくと便利
• 「T型スキル」を複数組み合わせる
  • 縦の専門分野と、横につなげる力

Q. 会社にあったアジャイルをどう見つける？

• 「アジャイルの導入もアジャイル開発のようにやる」が答え
• 様子を見ながら少しずつデプロイしていく。ダメそうならロールバックする。
• 完成形はないので、日々改善する

Q. リモートでのバックログの管理は？

• 24時間ビデオ撮影や定期的にカメラ撮影
• 物理的なバックログは、チームが未熟なときの対応策
• 未熟なときはそもそもリモートにしないほうがよい
• 慣れてきたらデジタル管理でもOK

Q. 開発支援できないSMは大丈夫？

• チームのスキルと期待値とのギャップを埋めるのがSMの役割
• 技術的な問題がギャップとは限らないので、何が問題かを見極めて日々解決していくのがSM
• 仮に技術的な問題が発生したときの対応策は、事前に考えておくべき（誰かに相談するなど）

Q. 開発支援できないSMはチームで勉強したらいい？

• プロジェクトやチームによって答えは異なる。まずはチームと相談してみては？

Q. 開発支援できないSMはテックスキルのあるPOと協力すればいい？

• それが可能ならOK
• 役割が逆転している感もある？

Q. 防火壁のSMと門番のPOの違いは？

• 防火壁はチームの邪魔になるものすべてをSMが排除する
• 門番はプロダクトに関する情報は必ず門番（PO）を経由する

Q. スクラムを導入する単位はプロダクトなのか機能なのか？

• 基本はプロダクト単位
• 機能単位でも問題はない
• フィーチャーチームと呼びます
  • <-> コンポーネントチーム

Q. 他拠点で開発時にチームが成熟していない場合のよい方法は？

• 対面よりも効果的な方法があるならそれを。。。（なさそう）
• プロジェクトに余裕があれば、プロジェクトのなかで成熟度を高めていく工夫を

Q. 最適なメンバー構成

• プロジェクトのなかで成長・学習していくことが前提なので、開始時のスキルはあまり問わない
• 学習できるかのほうが重要
• （余談）女性チームに男性1人のチームのパフォーマンスが高いという論文を読みました

Q. 新人などスキルレベルが異なっても大丈夫？

• 学習できるなら大丈夫です
• ただ、新人ばかりだと難しいと思うので、メンターが入っておいたほうがよさそうです

Q. SMをやっていたときにマネージャっぽいことをやってしまい、スクラムがわからなくなった

• マネジメントスタイルはチームの状況にあわせて変える必要がある
• 最初は「教える」ことも必要

Q. POをやる上で一番大事なことは？

• 圧倒的当事者意識（aka 情熱）
• 起業家みたいに働けと言われます

Q. 長期プロジェクトの場合のスプリントの組み方

• 計画できるなら先に計画を
• 計画できないからこそのスクラムなので、再計画を何度も繰り返し、さまざまな選択肢（撤退プランも含めて）を考えておいたほうがいいのでは？

Q. 複数チームを作るには？

• 大規模スクラム（LeSS、Nexus、SAFe）などがあります。そちらを参照してみてください。
• 基本的には階層構造になります。

Q. スクラムの作法はどこまで守らないといけない？

• スクラムガイドには全部守れ（守らなければスクラムではない）とありますが、自分たちにあわせて調整すればよいです。

Q. 開発案件と運用案件がかぶったときにスクラムで対応できるのか？

• 運用案件はスクラムに向いていないので、カンバンなどを使うとよいと思います

Q. 大きなプロジェクトの納期をスクラムではどのように考えるか？

• 短期的なプロジェクトに分割して再計画を繰り返すか、納期は固定したままスコープを可変にすることになります

Q. 細分化が難しい開発はどうするか？

• 「細分化できない」は本当？？？
• どうやって作業するんでしょうか？ 一瞬で完成する？？？ 細かい作業の繰り返しで作っているのではないでしょうか？ その単位で分割すればいいのでは？

Q. 小さく分けられないものはどうする？

• たぶん分けられるはず
• 「こんなの見せたら失礼だ、意味がない」というのはだいたい思い込み
• ただ、効果的な分け方はある。フィードバックに何を期待するかをあらかじめ考え、それをできるだけ最小限にするといいのでは？（たとえば正常系だけ見せるなど）

Q. ハード系でスクラムの事例はある？

• 自動車を作る事例（Wikispeed）
• 共通部品を使う、コンポーネント単位で開発する、インターフェイスをあらかじめ決めておくなど（本人たちはオブジェクト指向的と言っている）
• ただ、あらかじめそういう設計ができるという前提なので（自動車はそういうことがやりやすい）、本当の意味での試行錯誤は難しいように思います
• Wikispeedの講演や資料を参照してみてください
• あと、リーンは元々は自動車業界の話なので、自動車製造の話は参考になると思います。実際には、工場の生産の話よりも、上流の製品開発（リーン製品開発）の話のほうが参考になるはずです。

Q. POは客ではないの？

• 受託開発会社であれば、開発会社の「客」がPOということは考えられます
• 実際には、その「客の客」が別に存在するはずです
• ソフトウェアの（開発ではなく）使用するためにお金を払う人が本当の「客」です

Q. アジャイルの本質は人やチームの成長というのは本当？

• プロセスの面では本当。でもそれは手段にすぎない。
• 価値のある（実際に使ってもらえ、役に立つ）ソフトウェアを作ることが最終目標。ただ、そのために開発者が犠牲になるのも違う。
• 「みんなで幸せになろうよ」

Q. デザイナーがスクラムにどうコミットするのか

• スクラムでは肩書を剥奪しているので、誰もがいろんなことができるようになることが理想
• 仮に「画面設計→コーディング」みたいな順番があるとしたら、少しだけ先行させてデザイナーが作業するというのは考えられます（『Lean UX』を参照）
• とはいえ、開発者と一緒になって仕事をすることが「スクラムでは」求められます

Q. 開発スピードが遅くなる？

• 何と比べて？
• わからないものを開発するのはそもそも大変。他にやりようがないはず。

Q. DB設計は先にやるの？少しずつ作るの？

• あとで変えると大惨事になる、みたいなものは先に決めてもOK
• DBであっても進化的に設計することが求められます
  • Railsのマイグレーションなどを体験してみれば、どういうものかわかるかも？

Q. 共通ライブラリは誰が準備するの？

• 先にライブラリが必要になるとわかることはないはず
• わかったときに誰かが作ればいい
• 3回ルールってのがあったような気がする（正確な表現ではないかも……）

Q. アジャイル = はやいというイメージは本当？

• 開発は早く（or 速く）ないです
• 変化が起きたときに反応しやすいという意味での早い・速いです

Q. スクラムとウォーターフォールのどちらが品質が高い？

• プロジェクトの特性によって違うので、比較対象が間違ってます
• ただ、一般的に（俗物的な）ウォーターフォールで品質が高まることはないです。品質を上げるにはうまく開発するしかないので、開発時間が多いほうが有利です。
• 仕様記述言語みたいな方向はアリかも？

Q. アジャイルに向かない長期PJって何人月くらい？

• 期間や規模の問題ではないです
• 将来を予測できるかどうかで決めてください

Q. スクラム教育のやり方、コツ

• レゴスク（ry
• プログラマであれば、すぐに実際にやってみましょう。実践より教育効果の高いものはありません。
• また、プログラマ以外の関係者の理解を得ることも重要です
• そのためにレゴスクラ（ry

Q. スクラム未経験者ばかりのチームで成功させるには何が必要？

• 必要なものばかりあっただな……お仕事おまちしています！
• 最初のうちは期間を短く、フィードバックを頻繁にやりましょう。

Q. POの兼任ってあり？

• 専任のほうが理想ではあるが、なかなか難しいので仕方ないところはあります
• 副業でスタートアップやります、みたいなイメージ（本当にやる気あんの？みたいな）

Q. 収支は誰が管理する？

• POです

Q. TDDはどうやるの？ どれくらいテストを書く？

• どうやるの？については、他の参考書やオンラインチュートリアルを見てもらうしか……。言語によっても違います。
• 開発者が自信を持って納品できる程度には書いておくといいでしょう。思ったよりも多めのほうがいいです。あとで修正や機能追加が発生することが多いので。

Q. スクラムチームの評価はどうあるべきか？

• 基本的にはチーム評価にすべきだが、社会的手抜きが発生する恐れもある
• これは本当に難しい問題だし、経営の話でもあるので、正解はないです

Q. リリース日が決定している状態で、途中からスクラム対応してもよい？

• よい/悪いは別にないです
• スクラムのやり方はスコープを可変にすることなので、リリース日が決定しているのであれば、できない機能がいくらかでてきます

Q. ウォーターフォールを細かくするよりも効果的なのでしょうか？

• ウォーターフォールだと「実装しながら設計」することができない、というところが違います。そして、それをやったほうが効果的な場合が多いです。

Q. スクラム開発を行なうことのビジネス的なメリット

• うまくいかないときに途中で損切りができるところ
• 計画を上回る成果を期待できること
• 早めのリリースにより、回収が早くなること

Q. SMとDevを兼任すると難しい

• もしものために、開発チームの稼働率を上げないようにするために、SMは存在します
• 兼任よりも持ち回りを推奨します

Q. スプリントバックログはどう作るの？

• タスク分解するだけで、明確な規定がないです
• なので、タスクカンバンを作ることが多いです

Q. スクラムのメリットは？特に毎日の15分間のミーティング

• よくわからないものや変化の激しいものを作っていくことができる
• デイリースクラムは再計画会議。毎日、計画を見直します。

Q. スクラムは何に使うといいの？

• 新製品開発がよいと思います
• あるいは、新技術を使うパイロットプロジェクト
• Complexなやつ

Q. スクラムの本質を理解したい

• 変化の激しい環境下における、プロセスの継続的改善およびチームの成長と、プロダクトの価値の最大化

Q. スクラムのメリット/デメリット

• メリットはアジャイル開発の話と同じ（Complexな問題にチームで対応する）
• デメリットは組織変革を必要とすること（→ カンバンがよいかも）

Q. 開発はどういう工程？

• 大前提：プロジェクトによって異なる
• 「構想、設計、実装、テスト」みたいな教科書に書かれていることはあるが、順番通りに進まないことが多い
• それを自分たちで決めることが「アジャイル開発」の本質
• 開発を担当するエンジニアにまずは相談してみては？

Q. どういう要望だと開発しやすい？

• 大きな目的が明確であること
• 目的に応じて手段を変更できること（機能自体が作る目的ではダメ）
• フィードバックを与えるにしても、その時々で判断基準が違っていると萎える

Q. エンジニア以外に開発手法をどう学んでもらうとよい？

• レゴスクラムというのがありまして……。
• 実際にやってみないとわからないので、ものづくりのワークショップをやってみるとよいと思います

Q. 開発がわかるとどんなメリットがある？

• 開発の大きな問題は、作業工程で人間が分離していること。すべてを理解する必要はないが、隣同士の作業の境界線をあいまいにすることが、プロジェクトの成功につながる

Q. 開発が遅れる理由は？

• 遅れない理由の反対？
  • 要求が明確である
  • 作り方が把握できている（以前やった）
  • 予想外のことが起きない（体調不良など）
• → 複雑や未知のものは遅れるものとして計画を立てる必要がある

Q. 遅れるのはどうやってわかる？

• あらかじめわかるのであれば、遅れないように計画を立てられる
• あらかじめわからないからこそ、期間を区切りながら再計画を立てる（→ アジャイル開発の反復）

Q. 開発が作って楽しいものは？

• 実際に使ってもらえるもの
• 自分の成長につながるもの
• 自分で決定できること
• 再利用可能にすること

Q. 開発が作りたくないものは？

• 使われないもの
• 以前と同じもの（単調な繰り返しはモチベーション落ちる）
• 「楽しいもの」の反対

Q. 開発って何をどうやってるの？

• 「開発」といってもいろいろあるので…エンジニアに聞いてみてください
• 基本的には、事前に調査して、見通しを立てて、コードを書きながら試行錯誤して、少しずつ完成に近づけていく感じです

Q. 別の職種のスムーズなコミュニケーションは？

• 完全に「別の職種」と思わずに、共通点を広げていく（勉強する）
• タイプが違うのは仕方ないので、違うことを前提として付き合い（「ハーマンモデル」などで検索しよう）
• タイプが違うといっても、あらかじめ約束事（グラウンドルール）を決めておくと便利

Q. エンジニアとのコミュニケーション開発とのコミュニケーションの勘所

• 「エンジニア」といってもいろいろいるので、一緒に働き始めるたびに「こういうコミュニケーションスタイルにする」を決めておくとよいのでは？
• ハーマンモデルだと左脳系に属することが多いです

Q. なにが終わればDONE？

• POが決定する
• 「期限を問わずに機能をココまで開発する」こともあれば「機能ができてなくても◯月で終了する」こともある。

Q. 優先順位を決めるときに何を考えてる？

• 工数が少なく、あると嬉しい度が高いものが上位にくることが多い
  • WSJFというキーワードがあります
• 重要度が高くても、他の事項で制約を受けることもある（ex. 7月は不要だけど、8月には超必要）

Q. 仕様設計にどこまでディレクターが突っ込んで良いのか？

• 場合によるとしか……。
• チームとして成果を出したいのであれば、必要なときに必要な人が突っ込めばよいと思われます。
• 開発チームとも相談しましょう。

Q. ムダ・ムラのない開発をするには

• ムダ・ムラを計測するところから
• 何が「ムダ・ムラ」なのかは組織や人によって異なるので、チームでコンセンサスをとる必要がある
• 流れの管理はWIP制限オンリー

Q. スクラム開発ができないものは？

• 高度に専門化されている仕事
  • たとえば、ゲーム開発。サウンド、グラフィック、プログラミングと別れていて、お互いの仕事を手伝うことが難しい。
  • それでもエッセンスを導入することは可能。
• 組織が硬直化しているところ
  • 「スクラム」を組めないのはどうしようもない

Q. スクラムを成功させているチームとそうでないチームの違い

• プロダクトオーナーに「所有者」の意識があるかどうかが大部分
• 自分たちが成長しているかどうかを感じられているか（成長こそがモチベーションの鍵）

Q. スクラムは大規模プロジェクトで使える？

• 人数が多い場合 → スクラムチームを階層化する
• 作業量が多い場合 → 複数チームで対応するが、その場合にコンポーネント単位で分割するよりも機能単位で分割する
• Nexus、LeSS、SAFeといった方法論も

Q. スプリントに分けられない長い作業はどうする？

• 分割する
• 分割できないのであれば「うまく分割できるだけの情報がまだない」と考え、あとまわしにする

Q. スプリントで作り終えられない機能の進め方

• やったけど終わらなかった機能については、見積もり値を変更して、未完成品（仕掛品）として処理する。
• 数スプリントかけても完成できないようなら、何らかの問題があるので見直す。完成の基準や準備完了の基準が不十分なことが多い。

Q. ストーリーや作業の粒度

• ストーリーは「スプリントで完成できるかどうか」で切ります
• 「完成」は基準次第です
• タスクは1日以下にします

Q. フィードバックのタイミングは？

• スプリント終了時に2つのイベントを開催します
  • スプリントレビュー（→プロダクト）
  • スプリントレトロスペクティブ（→プロセス）

Q. 見積もりのタイミング

• スプリント開始時のスプリントプランニングで行います

Q. ストーリーポイントと時間の関係

• たとえば、2週間のスプリントで10ポイント消化できたら、1週間で5ポイントという具合です

Q. スプリントの期間を決定するポイントは？

• 最初は短め（3日〜1週間）がよいでしょう。慣れてくれば、2週間が一般的です
• いちど決めたらあまり変更したくはないので（リズムが崩れるので）、最初のうちは適切な長さが決まるまでいろいろ実験してみましょう

Q. スプリントと短いワークフローの違いは？

• 完成させるために必要なことであれば、工程を順番にやる必要はないという点
• たとえば、特徴的なのはTDDで、テストを先に書いてから実装する

Q. できたきりにならない？

• 報告時期の違い
• 見通しを立てるところをアジャイル開発で代用すれば、早く報告できる
• スコープと時間の2つが固定されているとつらいので、いずれかを可変にするように働きかける

Q. 年間達成目標との結びつけ方

• 難しいですね。。。

Q. 上流工程でのスクラムの適応性

• 上流工程とは。。。

Q. ソフトウェア開発以外でスクラムに適する業務にはどのようなものがありますか？

• 「繰り返す」部分はどこにでも適用可能（いわゆるPDCAも一緒）。スクラムの導入をスクラムでやる、みたいなことも可能です。
• ただ、開発の話が大部分を占めるので、開発以外にアジャイル開発を適用するのはあまりオススメしないです
• 「アジャイルコンサル」みたいな人は、どこにでも適用しようとするので注意が必要！
• カンバンであれば、ヴァル研究所さんが全社的（総務など）に導入しているので、見学されるとよいと思います

Q. なぜアナログで情報共有？

• デジタルだと「見に行く」という行為が必要になりますが（「情報冷蔵庫」とも呼ばれる）、壁に貼ってあると自然に「目に入る」ので、好ましいとされています

Q. スクラムマスターの雑用があふれたら？

• 本来はチームの問題なので、チームで解決するものです。
• スクラムマスターが忙しい場合は、複数人で改善するとよいでしょう（アジャイルコーチみたいなのを採用する）
• でも、忙しいのはだいたい最初だけです

Q. 会社のマネジメントを説得する方法 → スクラムの売り込み方

• 「スクラムを導入したい」だとうまくいかないので、それによってどういうメリットがあるかを伝えるとよさそうです
• スクラムもスクラムの方法で導入するとよさそうです（少しずつ入れていく）

Q. POとSMが休んでいるときは？

• 自己組織化されているはずなので、突発的な休みでない限りは、ある程度の期間は動けるはずです
• 事前に休暇がわかっているときは、リカバリ策を考えておきましょう

Q. 集まれない環境だと導入することが難しい？

• 比較的難しいですが、不可能ではないです。テクノロジーで解決しましょう（リモート会議など）。

Q. リリースの短いWFとスクラムの違いは？

• いわゆる（俗説的な）WFは前工程に戻りませんが、スクラムは複数の工程を同時並行でやります（ex. 実装しながら設計する）
• あらかじめ決めたものをリリースできない場合、スクラムでは納期を延ばしたりはしません。次回の開発期間に回すだけです。

Q. 複雑でなければアジャイル開発をしてはいけない？

• いけないわけではないですが、アジャイル開発ではコミュニケーションや探索を重視しますので、それらが不要な場合は効率や効果が低下します（試行錯誤せずに専門家がそれぞれの仕事をすればOK）

Q. POとSMは兼任可能？

• 可能（チーフエンジニア！）だが、推奨されていません
• 作るものを決めることと、実際に作ることは対立することが多いので、別人がやったほうがよい

Q. 機能横断的なチームづくりは学習コストが高く生産性が落ちそうだが、どうフォローしたらいいか？

• 無理に導入する必要はない
• 学習は導入コストだと割り切るしかない
• 「学習」を正式にプロジェクトに含める
  • できる人がいるなら、一緒にやらせてもらうなど
• 最終的には生産性が高まるはず
• 不安なら四半期程度のパイロットプロジェクトで効果を試してみては？

Q. スクラムのメリットを理解してもらうには？

• 頭で理解してからやる、というのはあまりうまくいかない
• 行動が伴っていないとマインドセットは変わらない
• まずは小さく何かをやってもらう
• スクラムの導入もスクラムのやり方で