{"text_format":"1","workbook":"xlsx","n_sheets":5,"sheets":["レーダーチャート","使い方","知恵袋","参考資料","変更履歴"],"not_rendered":{"charts":1,"images":2,"macros":1,"external_links":0,"defined_names":24,"comments":0,"pivot_tables":0},"unopened":[],"bounds":{"document_bytes":16777216,"sheet_cells":100000,"rows_first":2000,"rows_last":500,"rows_between":2000,"halvings":0,"cell_chars":16384,"cell_head_chars":4096},"cells_cut":0,"cells_raw":0,"read":"whole","date_system":"1900"}

{"sheet":"レーダーチャート","index":0,"n_rows":37,"n_cols":42,"rows_kept":37,"cut":false,"hidden":false,"merged":[[2,18,3,28],[4,19,6,27],[7,19,9,27],[10,19,12,27],[26,15,27,16],[23,18,37,18],[23,19,37,28],[14,19,21,28],[14,18,21,18],[4,18,6,18],[7,18,9,18],[10,18,12,18],[4,28,6,28],[7,28,9,28],[10,28,12,28],[28,15,29,16],[24,15,25,16],[1,14,3,14],[4,14,6,14],[7,14,9,14],[10,14,12,14]]}
[]
[null,null,null,null,null,null,null,null,null,null,null,null,null,null,"マインドセット","開発チーム",10,null,"カテゴリ",null,null,null,1,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,1,"マインドセット"]
[null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,"組織の責任者",10,null,"アジャイルソフトウェア開発の価値観や原則がステークホルダに理解されているか。",null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,"文化"]
[null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,"発注者",10,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,"チーム"]
[null,null,null,null,null,null,null,null,null,null,null,null,null,null,"文化","発注者の支援",10,null,"設問1","開発チームは、アジャイルソフトウェア開発宣言を読み、内容を理解した上で、共感し、実践していく意思をもっているか。\n(1:いいえ~10:はい)",null,null,null,null,null,null,null,null,10,null,null,null,null,null,null,null,null,null,null,null,null,"プロジェクト"]
[null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,"信頼",10]
[null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,"意思決定",10]
[null,null,null,null,null,null,null,null,null,null,null,null,null,null,"チーム","チームサイズ",10,null,"設問2","開発チームが所属する組織の責任者は、アジャイルソフトウェア開発宣言を読み、内容を理解した上で、共感し、実践していく意思をもっているか。\n(1:いいえ～一部～10:はい)",null,null,null,null,null,null,null,null,10]
[null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,"経験",10]
[null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,"アクセス",10]
[null,null,null,null,null,null,null,null,null,null,null,null,null,null,"プロジェクト","変更",10,null,"設問3","発注者（自社製品の場合は事業の責任者）は、アジャイルソフトウェア開発宣言を読み、内容を理解した上で、共感し、実践していく意思をもっているか。\n(1:いいえ～一部～10:はい)",null,null,null,null,null,null,null,null,10]
[null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,"品質レベル(厳格さ)",10]
[null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,"漸進的",10]
[]
[null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,"ヒント"]
[]
[]
[]
[]
[]
[]
[]
[]
[null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,"知恵"]
[]
[]
[]
[null,"注意事項"]
[null,"この「アジャイル開発問診票」の「入力シート」と「レーダーチャート」は、Project Management Institute (PMI）とAgile Alliance "]
[null,"が定めたアジャイル実務ガイドに掲載された「付属文書X3: アジャイル適合性フィルター・ツール」に対して、JASPICアジャイル分科会"]
[null,"の知見を加え、以下の変更を行ったものである。※"]
[null,null,"・カテゴリー（マインドセット）及び質問項目の追加。"]
[null,null,"・質問内容の修正（日本の実状に合わせて文言を見直し）。"]
[null,null,"・複数の問いのある質問を、1つの質問には１つの問いとなるように分割。"]
[null,null,"・直感的な理解を促すため、ギャップの点数が低くなるようにレーダーチャートを工夫。"]
[null,"ご利用にあたっては、上記を踏まえて知的財産侵害とならないよう配付先、転用等に注意するようお願いする。"]
[null,"※英語版：AGILE PRACTICE GUIDE, APPENDIX X3: AGILE SUITABILITY FILTER TOOLS"]

{"sheet":"使い方","index":1,"n_rows":7,"n_cols":1,"rows_kept":7,"cut":false,"hidden":false,"merged":[]}
["使用方法"]
["①黄色セルのカテゴリセルの右のボックスの内容を切り替えると各カテゴリの質問が表示されます。"]
["②入力フォームのカテゴリを選択ください"]
["　→マインドセット、文化、チーム、プロジェクト"]
["③それぞれの質問に従い、フォームの右の入力ボックスから1～10の数字を選択します。"]
["④各質問のついてのヒントや現場支援のヒントについては、設問1～設問3のボタンを押下ください"]
["⑤ヒント(青いセル)、知恵（緑のセル）にヒントが表示されます。"]

{"sheet":"知恵袋","index":2,"n_rows":19,"n_cols":8,"rows_kept":19,"cut":false,"hidden":false,"merged":[]}
["No.","分類\n知恵袋参照","項目","質問","回答\n1:ギャップ\n10:適合","意図\nギャップを埋める理由(知恵袋)","知恵袋\n現場支援のヒント","回答のガイド(ヒント)"]
[1,"マインドセット","開発チーム","開発チームは、アジャイルソフトウェア開発宣言を読み、内容を理解した上で、共感し、実践していく意思をもっているか。\n(1:いいえ~10:はい)",{"$f":"レーダーチャート!Q2","v":10},"開発チームが、アジャイル型の価値観を理解し、その実践にコミットすることが非常に重要である。\n誤った解釈は誤った活動につながり、アジャイル開発の恩恵が受けられない、かつアジャイル開発に対する信頼を失う。\n","アジャイルソフトウェア開発宣言の勉強会開催、IPAの資料「アジャイルソフトウェア開発宣言の 読みとき方」の説明会開催、アジャイルトレーニング受講など、アジャイル型の開発が目指すものに対する理解を深めたらどうか。","開発チームが、アジャイルソフトウェア開発の価値観を理解し、その実践にコミットすることが非常に重要です。\nここでは、開発チームがアジャルソフトウェア開発における価値観や原則を理解し、実践していく意思があるかどうかを確認します。\nチームメンバが全員、必ずしも同じ意識ではない場合には、チームとしてどのような状況にあるかを考えてもらって、全員がきちんと理解している＝10点として、相対的に点数を決めるようにしてください。"]
[2,"マインドセット","組織の責任者","開発チームが所属する組織の責任者は、アジャイルソフトウェア開発宣言を読み、内容を理解した上で、共感し、実践していく意思をもっているか。\n(1:いいえ～一部～10:はい)",{"$f":"レーダーチャート!Q3","v":10},"開発チームが所属する組織の責任者が、アジャイルソフトウェア開発の価値観を理解し、開発チームがそれを実践する事に協力することが非常に重要である。\n組織の責任者がアジャイルソフトウェア開発の狙い・本質を理解することで、チャンピオン（開発チームを擁護し支援する立場）になっていただきたい。","アジャイル開発で成果を出している組織の責任者や経営者に、事例紹介や成果報告をしていただいたら、共感が得られるのではないか。","開発チームが所属する組織の責任者が、アジャイルソフトウェア開発の価値観を理解し、開発チームがそれを実践する事に協力することが非常に重要です。\nここでは、開発チームが所属する組織の責任者が、アジャルソフトウェア開発における価値観や原則を理解し、実践していく意思があるかどうかを確認します。\nよくわからない場合には、わからないこと自体をリスクとして3点以下にして、課題の認識につなげましょう。"]
[3,"マインドセット","発注者","発注者（自社製品の場合は事業の責任者）は、アジャイルソフトウェア開発宣言を読み、内容を理解した上で、共感し、実践していく意思をもっているか。\n(1:いいえ～一部～10:はい)",{"$f":"レーダーチャート!Q4","v":10},"発注者もアジャイルソフトウェア開発の価値観への理解とその実践にコミットすることが非常に重要である。\n発注者のアジャイルソフトウェア開発への典型的な誤解は、「いつでも、いくらでも、要件の変更ができる」というものである。さらに、アジャイルソフトウェア開発では、発注側が果たす役割や関与が重要で、相応の負担が求められることを理解していないこともある。","そもそも受注してはいけない案件である。\nここのギャップが大きい場合には、アジャイル型で進むことが本当に良いのか、受注前に考えて欲しい。\nまずは、発注者にアジャイル型を理解していただくことが優先である。","発注者も、アジャイルソフトウェア開発の価値観への理解とその実践にコミットすることが非常に重要です。\nここでは、発注者が、アジャルソフトウェア開発における価値観や原則を理解し、実践していく意思があるかどうかを確認します。\nよくわからない場合には、わからないこと自体をリスクとして3点以下にして、課題の認識につなげましょう。"]
[4,"文化","発注者の支援","発注者（自社製品の場合は事業の責任者）は、開発期間中のいかなるときも開発チームに対して継続的な支援と双方向のフィードバックを行うことを約束しているか。\n(1:おそらく無理～一部～10:おそらくそう)",{"$f":"レーダーチャート!Q5","v":10},"アジャイルソフトウェア開発では、特に発注者がプロダクトオーナーとして、ビジネスの価値やフィーチャの優先順位を判断するなど、継続的にプロジェクトに関わる必要がある。そこの覚悟ができていることが大事である。","発注者がアジャイルを望んでいない以上、受託側はアジャイルで進めることは不可能である。\nアジャイル型で進めることに発注側が合意した上で、具体的に、このプロジェクトにおける発注者の役割と責任、どのイベント（ミーティング）に参画するのか、発注側の理解を確認しておく\n","アジャイルソフトウェア開発では、特に発注者がプロダクトオーナーとして、ビジネスの価値やフィーチャの優先順位を判断するなど、継続的にプロジェクトに関わる必要があります。\n開発期間中、常に発注者として関わることに対して、その覚悟ができているかどうかで評価してください。"]
[5,"文化","信頼","開発チームは、発注者（自社製品の場合は事業の責任者）とビジネスゴールを共有し、その期待を要件に変換して、プロダクトに反映することができると、発注者から信頼されているか。\n(1:おそらく無理～一部～10:おそらくそう)",{"$f":"レーダーチャート!Q6","v":10},"開発チームが、ビジネスの側面も含めて価値を理解して実現してくれるという、発注者からの基本的な信頼が必要である。","信頼されていない場合には、まずは信頼されていない要因が何かを考える。\nゴールをきちんと理解していないのであれば発注者に説明会を開いてもらう。\n特に、ビジネスや製品で心配なことがあれば、優先的に開発し確認するなど、不安解消への取り組みを発注者と共に考える。","開発チームが、ビジネスの側面も含めて価値を理解して実現してくれるという、発注者からの基本的な信頼が必要です。\n発注者の期待する価値の実現という観点で、開発チームが信頼されているかどうかを評価してください。"]
[6,"文化","意思決定","開発チームは、開発と開発チームの運営に関する意思決定に対して、権限をもっているか。\n(1:おそらく無理～一部～10:おそらくそう)",{"$f":"レーダーチャート!Q7","v":10},"チームが自己組織化し、能動的に自身の裁量で意思決定ができる環境が整っているかどうか。\n所属する組織として、開発チームが適切な権限をもつことが認められていて、開発チームの裁量で開発を進められることが必要である。","委譲を求めること＝チームが全責任を負って取り組むことの覚悟が必要。課題や問題を放置せず、チーム全員が自分の責任として能動的に解決にあたる姿勢を示す必要がある。","チームが自己組織化し、能動的に自身の裁量で意思決定ができる環境が整っているかどうかを確認します。\n所属する組織として、開発チームが適切な権限をもつことが認められていて、開発チームの裁量で開発を進められるかどうか、で評価してください。"]
[7,"チーム","チームサイズ","開発チームのサイズは、５～８人程度か。\n(1:4人以下または11人以上～10:5～8人)",{"$f":"レーダーチャート!Q8","v":10},"開発チームは、意思疎通や意思決定ができるサイズか。（２PIZZAチーム：２枚のピザを全員で食べれるくらい：５～８人が適しているといわれている）\n","一番重要なことは、チーム全体でコミュニケーションや意思決定へのコンセンサス形成が円滑に行われること。\n初めてのプロジェクトでまだ初心者なら単純にこの人数に入るかどうかで判断。\n経験のあるチームの場合、適用するプロセスにフィットしたサイズ（人数）かどうかを判断。","開発チームは、意思疎通や意思決定ができるサイズかどうかを確認します。\n5～8人であれば10点、としていますが、ポイントはコミュニケーションをとって、決定に対するコンセンサスが得られるかどうかです。4人以下または11人以上を機械的に１とするよりも、コミュニケーションの観点\nで、点数を付けてください。"]
[8,"チーム","経験","アジャイル開発を進めるにあたり、十分な経験値があるか。\n(1:経験者不在/有識者の支援なし～10:十分/支援いつでも可)",{"$f":"レーダーチャート!Q9","v":10},"アジャイル開発に不慣れなチームは、異常を見つけられないことがしばしばある。\nダメ出しをしてくれる有識者やコーチによる支援が受けられると良い。","経験者の参加を検討、または社内外の有識者からの支援を受けられるようにする。\nただし、単に経験していれば良いと言うわけではなく、アジャイル型への理解が前提である。","単純に経験の有無ではなく、開発チームのアジャイルソフトウェア開発に対する成熟度に照らして評価してください。\n経験値にはメンバ各自の力量だけでなく、アジャイルコーチなどチーム外からの支援を受けられる環境が整っていれば、それも含めて評価してください。"]
[9,"チーム","アクセス","開発チームは、必要な時に発注者（自社製品の場合は事業の責任者）へアクセスし、質問してフィードバックを得ることができるか。\n(1:いいえ～一部～10:はい)",{"$f":"レーダーチャート!Q10","v":10},"開発を成功させるためには、開発チームが必要とするときに、タイムリーに発注者へアクセスできることが重要である。\nそのためには、気軽に聞ける関係作りと、双方向のコミュニケーション手段が必要である。\nチームが自ら行動を起こせる器量や、気軽に発注者へ依頼できる環境（拠点配置やインフラなどの物理的、立場や契約などの論理的双方で）が整っていることが必要である。\n","まずはチームの自己点検をして、チーム側のコンタクトパーソンと発注側のカウンターパートを明確にする。その次に、互いに必要するときの連絡方法、ルールなどを話合う。","開発を成功させるためには、開発チームが必要とするときに、タイムリーに発注者へアクセスできることが重要です。そのためには、気軽に聞ける関係作りと、双方向のコミュニケーション手段が必要です。\nチームに自ら行動を起こせる器量があるかどうか、発注者へ依頼できる環境（拠点配置やインフラなどの物理的、立場や契約などの論理的双方で）が整っているかどうかも合わせて評価してください。"]
[10,"プロジェクト","変更","要求事項が変更されたり追加されたりする可能性はあるか。\n(1:まずない～多少はある～10:大いにある)",{"$f":"レーダーチャート!Q11","v":10},"要件がどのくらい安定（確定）しているかを確認する。\n単に要件だけを評価するのではなく、プロジェクトの適用分野や目標などから、要件の安定性に影響を及ぼす要素（技術・標準・法制など）を合わせて考えると良い。\nプロジェクトの特性を踏まえてアジャイルソフトウェア開発に向いているかどうかを判断する。アジャイルソフトウェア開発は、不確実性（やってみないと分からない、決められない）に対応する一つの方法である。\n","《知恵》アジャイル開発に向けて考慮することは二つ。要求事項が固まっていればウォーターフォールの方が開発の効率が良い。要求事項の変更が見込まれる場合には、「いつでも、いくらでも変更が可能」という発注側の誤解に注意が必要。開発のサイクル（イテレーション）の期間は固定し、その間の変更は受けないのが一般的。","要件がどのくらい安定（確定）しているかを確認します。\n単に要件だけを評価するのではなく、プロジェクトの適用分野や目標などから、要件の安定性に影響を及ぼす要素（技術・標準・法制など）を合わせて考えて評価してください。"]
[11,"プロジェクト","厳格さ","開発するシステムやプロダクト、サービスが、社会に大きな影響を与えないような高い品質レベル(文書の厳格さや追加の検証)を求められそうか。\n(1:厳格～普通～10:寛容)",{"$f":"レーダーチャート!Q12","v":10},"開発の対象としているシステムが、アジャイルソフトウェア開発のやり方に向くかどうかの質問である。\n試行しながら段階的にリリースしてフィードバックを受けるというスタイルが許される内容かどうか。例えば人命にかかわるのであれば単純にやってみる、ということは許されない。","アジャイル型で取り組むのでれば、マニフェストの「シンプルさ（ムダなく作れる量を最大限にすること）が本質です。」を踏まえて、顧客の価値のために本当に必要かどうかを確認し、ムダを排除するという観点での検討も必要である。\n文書の厳格さに関しては、開発チーム、発注者、それぞれの観点で考慮が必要。開発チーム側は、必要な文書まで作成を拒絶していないか、発注側は不必要なものまで要求していないか。\n","開発の対象としているシステムが、アジャイルソフトウェア開発のやり方に向くかどうかの質問です。\n試行しながら段階的にリリースしてフィードバックを受けるというスタイルが許される内容かどうかで、評価してください。例えば人命にかかわるのであれば単純にやってみる、ということは許されません。"]
[12,"プロジェクト","漸進的","プロダクトまたはサービスは部分的に構築および評価できるか。\n(1:おそらくできない～ときどき～10:はい)",{"$f":"レーダーチャート!Q13","v":10},"漸進型デリバリを実施できそうかどうかを確認する。\n価値の高い、優先順位の高いものから、早くリリースして、その利益や恩恵を受ける、これを繰り返し行うことが可能かどうか。可能であればアジャイルソフトウェア開発が目指す価値観と一致し、恩恵が期待できる。\n","リリースを繰り返し行い、フィードバックを受けながら、プロダクトやサービスを成長させつつ、価値が得られるようなプロジェクトなのか、ということを確認する。","漸進型でデリバリを実施できそうかどうかを確認します。\n価値の高い、優先順位の高いものから、早くリリースして、その利益や恩恵を受ける、これを繰り返し行うことが可能かどうかで評価してください。"]
[]
[]
[null,"マインドセット","アジャイルソフトウェア開発の価値観や原則がステークホルダに理解されているか。"]
[null,"文化","アプローチへの賛同とチームへの信頼を基盤とした支援を得られる環境があるか。"]
[null,"チーム","チームはアジャイルの採用に成功するのに適したサイズか。メンバは成功するために必要な経験と、ビジネス担当者へのアクセスを持っているか。"]
[null,"プロジェクト","変更頻度が高いか。漸進的デリバリは可能か。プロジェクトはどの程度重要か。"]

{"sheet":"参考資料","index":3,"n_rows":30,"n_cols":10,"rows_kept":30,"cut":false,"hidden":false,"merged":[[0,0,0,4],[1,0,1,4],[2,0,2,4],[3,0,3,4],[4,0,4,4]]}
["「参考資料」の内容は、JASPICアジャイル分科会の参加者から寄せられた情報、文献、成果物である。"]
["SEPGの知見として親しんでいただき、現場の支援に役立てていただければ幸いである。"]
["内容には、有償のものや、JASPIC以外の団体の所有する資料、特定企業の事例なども含まれている。"]
["転売、転記、転送などには慎重な判断をお願いすると共に、各自の責任においてご活用いただきたい。"]
["2019年10月　JASPICアジャイル分科会\n"]
[]
["No.","知恵","資料・情報の名称","分類","説明","使う人へのアドバイス","発行元","参照・更新のためのURL","発行年月","媒体"]
[{"$f":"ROW()-7","v":1},"アジャイル開発の価値観","アジャイルソフトウェア開発宣言","■マインドセット\n□文化\n□チーム\n□プロジェクト","アジャイルでソフトウェアを開発する際の価値観（マインドセット）","きちんと解釈するために、「アジャイルソフトウェアの12の原則」（No.2）も読もう","Kent Beck,Mike Beedle,Arie van Bennekum,Alistair Cockburn,Ward Cunningham,Martin Fowler,James Grenning,Jim Highsmith,Andrew Hunt,Ron Jeffries,Jon Kern,Brian Marick,\nRobert C. Martin,Steve Mellor,Ken Schwaber,Jeff Sutherland,Dave Thomas\n","http://agilemanifesto.org/iso/ja/manifesto.html","copyright\n2001","ネットワーク"]
[{"$f":"ROW()-7","v":2},"アジャイル開発の原則","アジャイル宣言の背後にある原則","■マインドセット\n□文化\n□チーム\n□プロジェクト","アジャイルでソフトウェアを開発する人が従うべき原則","IPAの解説（No.3）を読もう","site design and art work © 2001, Ward Cunningham\n Japanese translation by Kenji Hiranabe \n","http://agilemanifesto.org/iso/ja/principles.html","copyright\n2001","ネットワーク"]
[3,"アジャイル開発宣言の解釈","アジャイルソフトウェア開発宣言の 読みとき方","■マインドセット\n□文化\n□チーム\n□プロジェクト","アジャイルソフトウェア開発宣言が示している真意を読者に伝えることができるよう、4つの価値とその価値に由来する明確な12の原則についてそれぞれの解釈を記載","よくある誤解に対して、適切な解釈へ導くことができる\n一つひとつの原則に対して、どのように取り組んだら良いか、アドバイスも記載されている\n","IPA\n独立行政法人\n情報処理推進機構","https://www.ipa.go.jp/files/000065601.pdf","2018-04-01","PDF"]
[4,"スクラム\n（アジャイル開発の進め方の一つ）","スクラムガイド™\nスクラム公式ガイド:\nゲームのルール\n日本語版 | Japanese","□マインドセット\n□文化\n■チーム\n□プロジェクト","スクラムの定義を説明したもの\nスクラムは複雑なプロダクトを開発・提供・保守するためのフレームワークである","スクラムの役割・イベント・作成物と、それらをまとめるルールが含まれており、スクラムのバイブルである","Developed and sustained by Scrum creators: Ken Schwaber and Jeff Sutherland","https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Japanese.pdf","2017-11-01","PDF"]
[5,"アジャイル開発に対する誤解の例","Clarifying Myths with\nProcess Maturity Models vs. Agile\nWhite Paper","■マインドセット\n□文化\n□チーム\n□プロジェクト","“Process Maturity Models”と“Agile Development”を簡単に解説した上で、Myths（誤解）をどのように解決するか、解説したもの","この文献はAutomotiveの世界では有名。\nアジャイルはドキュメント作らないとかCMMIはＷＦだとか。","Intacs.info\nInternational Assessor Certification Scheme","https://www.intacs.info/index.php/download-forms/download-directory/newsletter/465-white-paper-spice-and-agile/file","2014-08-01","PDF"]
[6,"経営者の目線でアジャイル開発、スクラムを解説","アジャイル開発とスクラム\n顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント","□マインドセット\n■文化\n□チーム\n□プロジェクト","アジャイル開発とは何か、スクラムとはどのようなものかを解説","経営者やアジャイルを知らない関係者（顧客を含む）に対する説明のヒントになる","平鍋 健児 (著), 野中 郁次郎  (著)\n翔泳社","https://www.shoeisha.co.jp/book/detail/9784798129709","2013-01-01","書籍"]
[7,"アジャイル開発の基本的な手順","アジャイルサムライ−達人開発者への道−","□マインドセット\n□文化\n■チーム\n□プロジェクト","アジャイル開発の進め方を、企画前の段階から、順を追って一つひとつのステップで解説","古典的であるが、愛読している人の多い本\n内容は親しみやすい","Jonathan Rasmusson  (著), 西村 直人 (監訳), 角谷 信太郎  (監訳)\nオーム社","http://shop.ohmsha.co.jp/shopdetail/000000001901/","2011-07-01","書籍"]
[8,"インセプションデッキ\n（プロジェクトを開始する前に確認しておくべき10の質問）","アジャイルサムライ−達人開発者への道−\npp.46-49","□マインドセット\n□文化\n■チーム\n□プロジェクト","インセプションデッキの内容の説明を、具体例を交えて平易に解説","インセプションデッキを解説している（日本語の）書籍は少ないので貴重","Jonathan Rasmusson  (著), 西村 直人 (監訳), 角谷 信太郎  (監訳)\nオーム社","http://shop.ohmsha.co.jp/shopdetail/000000001901/","2011-07-01","書籍"]
[9,"パッケージデザイン\n（ビジョンBOX）\n（顧客に訴求する要素、そのプロダクトならでは値打ちを簡潔に記載する）","アジャイルサムライ−達人開発者への道−\npp.59-62","□マインドセット\n□文化\n□チーム\n■プロジェクト","パッケージデザインを具体的な事例とイラストで解説","パッケージデザインを解説している（日本語の）書籍は少ないので貴重","Jonathan Rasmusson  (著), 西村 直人 (監訳), 角谷 信太郎  (監訳)\nオーム社","http://shop.ohmsha.co.jp/shopdetail/000000001901/","2011-07-01","書籍"]
[10,"エレベーターピッチ\n（ごく短時間でアイディアの本質を伝える手法）","アジャイルサムライ−達人開発者への道−\npp.56-58","□マインドセット\n■文化\n■チーム\n□プロジェクト","エレベーターピッチとは何か、どのような項目をカバーしたら良いかを解説","エレベーターピッチを解説している（日本語の）書籍は少ないので貴重","Jonathan Rasmusson  (著), 西村 直人 (監訳), 角谷 信太郎  (監訳)\nオーム社","http://shop.ohmsha.co.jp/shopdetail/000000001901/","2011-07-01","書籍"]
[11,"テスト駆動開発（TDD）","アジャイルサムライ−達人開発者への道−\npp.261-272","□マインドセット\n□文化\n■チーム\n□プロジェクト","テスト駆動開発の概説","概念を知るには手軽\nCIやテストの自動化などを含めて学ぶには専門書籍で","Jonathan Rasmusson  (著), 西村 直人 (監訳), 角谷 信太郎  (監訳)\nオーム社","http://shop.ohmsha.co.jp/shopdetail/000000001901/","2011-07-01","書籍"]
[12,"KPTのやり方","これだけKPT","□マインドセット\n■文化\n■チーム\n□プロジェクト","KPTの基本的な説明から実施のプロセスを詳説","KPTで振返りを繰り返し行う際に、付箋の色を変えることで、チームの傾向がわかるところが凄い\n","天野　勝 著\nすばる舎リンケージ\nISBN 9784799102756","http://www.subarusya.jp/book/b167190.html","2013-08-29","書籍"]
[13,"アジャイル開発適用の判断のヒント","アジャイル実務ガイド\np.14\nステーシー複雑性モデルに触発された不確実性と複雑性のモデル\nUncertainty and Complexity Model Inspired by Stacey Complexity Model","□マインドセット\n■文化\n□チーム\n■プロジェクト","不確実性と複雑性のポジションでソフトウェア開発を分類","不確実性と複雑性の程度（レベル）をどのように判断するかは、確率（可能性）が一つの観点になる","アジャイルアライアンス\nPMI","https://www.pmi-japan.org/bookstore/pm_std/agilepg_1.php","2017-11-01","書籍"]
[14,"アジャイル開発適用の判断のヒント","アジャイル実務ガイド\np.19\nライフサイクルの連続性\nThe Continuum of Life Cycles","□マインドセット\n■文化\n□チーム\n■プロジェクト","デリバリーの頻度と変更の度合いのポジションからライフサイクルを適用する","アジャイル、予測型、イタレーティブ（反復型）、インクリメンタルの4択","アジャイルアライアンス\nPMI","https://www.pmi-japan.org/bookstore/pm_std/agilepg_1.php","2017-11-01","書籍"]
[15,"アジャイル適合性フィルター・ツール\n（解説）","アジャイル実務ガイド\npp.125-138\n付属文書X3\nアジャイル適合性フィルター・ツール","□マインドセット\n■文化\n□チーム\n■プロジェクト","アジャイル開発に向き・不向きを判定する質問集","日本語は訳がわかりづらいものもある","アジャイルアライアンス\nPMI","https://www.pmi-japan.org/bookstore/pm_std/agilepg_1.php","2017-11-01","書籍"]
[16,"アジャイルでのメトリクス例","アジャイルメトリクス実践ガイド","□マインドセット\n□文化\n■チーム\n□プロジェクト","アジャイルの世界動向では、メトリクスとアクションの共通化・標準化が進み、プラクティスとして一般化しつつある\n","メトリクスの基礎的な知識から実践での活用まで事例を交えて解説されている","伊藤　宏幸\nヤフー（株）","https://www.slideshare.net/ssuser968fab/ss-70489058","2017-01-12","SlideShare"]
[17,"CMMIを適用してアジャイル開発のパフォーマンスを改善するためのガイド","A Guide to Scrum and CMMI®:\nImproving Agile Performance with CMMI","□マインドセット\n■文化\n□チーム\n■プロジェクト","アジャイル開発のパフォーマンスを改善するためにCMMIに回帰する企業が増えている\n成功する組織は、アジリティ（迅速性）とスティビリティ（安定性）の双方が必要である","アジャイル開発を行う人に向けたCMMIの解説及び活用のガイド\nCMMIのアプレイザ（評定者）に向けたアジャイル開発に対するCMMI適用のガイド","CMMI Institute","http://www.broadswordsolutions.com/wp-content/uploads/2016/12/Scrum_XP_Profile_Final.pdf","2016-12-01","PDF"]
[18,"アジャイル開発の実際を見学して学ぶイベントの事例","『アジャイル開発行動展示』\nSPI Japan 2016\n★本会議（10月12日(水)13:00 ～ 10月14日(金)12:00）","□マインドセット\n■文化\n■チーム\n■プロジェクト","実際にアジャイル開発でソフトウェアを開発する様子を、自由に見学できる環境で実施、短期間で動くソフトウェアを開発","企画書や感想を参考に、イベントとして企画してみるとか、アジャイル分科会から説明を受けるなど、糸口に","JASPICアジャイル分科会","http://www.jaspic.org/event/2016/SPIJapan/agile.pdf","2016-10-12","PDF"]
[19,"アジャイル分科会の活動概要、アジャイル開発の体験ワークショップの概要がわかる","『頭と体で納得「アジャイル開発」！』\nSPI Japan 2017\n◆トーク＆納得セッション（2017年10月12日（木）15:30～17:30）","□マインドセット\n■文化\n□チーム\n■プロジェクト","前半は頭で納得！\n「組織におけるアジャイル開発とSPI」についてのディスカッション \n後半は体で納得！\n複数のアジャイルのプラクティスを手軽に体験できるワークショップ","アジャイル分科会が取り組むテーマは、アジャイル開発を実践する組織のSEPG/SQAにも関係の強いテーマ\nワークショップは、アジャイル開発の理解を助けるもの","JASPICアジャイル分科会","http://www.jaspic.org/event/2017/SPIJapan/talk/agile.zip","2017-10-12","PDF"]
[20,"ビジョンミーティングの議題の例","The Software Project Manager's Bridge to Agility 1st Edition\np.54 Figure 4-1\nVision meeting agenda","□マインドセット\n□文化\n■チーム\n□プロジェクト","ビジョンミーティングで何を議題とすべきかが具体的に示されている","それぞれの議題に対して、役割（スポンサー、チーム、プロジェクトマネージャ）が記載されているところが良い","Addison-Wesley\nMichele Sliger  (Author), Stacia Broderick (Author)","https://www.amazon.com/Software-Project-Managers-Bridge-Agility/dp/0321502752/ref=mt_paperback?_encoding=UTF8&me=&qid=","2008年","書籍"]
[21,"リリースプランのイメージと、リリースプランニングミーティングの議題","The Software Project Manager's Bridge to Agility 1st Edition\np.73 Figure 5-3\nRelease planning meeting agenda\np.73 Figure 5-4\nRelease plan","□マインドセット\n□文化\n■チーム\n□プロジェクト","ビジョンミーティングで何を議題とすべきかが具体的に示されている","それぞれの議題に対して、役割（プロダクトオーナー、プロジェクトマネージャ）が記載されているところが良い","Addison-Wesley\nMichele Sliger  (Author), Stacia Broderick (Author)","https://www.amazon.com/Software-Project-Managers-Bridge-Agility/dp/0321502752/ref=mt_paperback?_encoding=UTF8&me=&qid=","2008年","書籍"]
[22,"イテレーションプランのイメージと、イテレーションプランニングミーティングの議題","The Software Project Manager's Bridge to Agility 1st Edition\np.75 Figure 5-5\nIteration plan\np.75 Figure 5-6\nIteration planning meeting agenda","□マインドセット\n□文化\n■チーム\n□プロジェクト","ビジョンミーティングで何を議題とすべきかが具体的に示されている","それぞれの議題に対して、役割（プロダクトオーナー、プロジェクトマネージャ）が記載されているところが良い","Addison-Wesley\nMichele Sliger  (Author), Stacia Broderick (Author)","https://www.amazon.com/Software-Project-Managers-Bridge-Agility/dp/0321502752/ref=mt_paperback?_encoding=UTF8&me=&qid=","2008年","書籍"]
[23,"リリースプランの例（内部、外部リリースと、イテレーション0とイテレーションH）","The Software Project Manager's Bridge to Agility 1st Edition\np.90 Figure 6-2\nA release plan is a high-level plan for a series of itarations. Release can be internal or external.","□マインドセット\n□文化\n■チーム\n□プロジェクト","ビジョンミーティングで何を議題とすべきかが具体的に示されている","図の説明の趣旨は、中間リリースや外部リリースを含むリリース計画の図示だが、品質保証上必要とされる第三者評価やドキュメント作成のために、イテレーションH（Harder）を設定する例としても使える","Addison-Wesley\nMichele Sliger  (Author), Stacia Broderick (Author)","https://www.amazon.com/Software-Project-Managers-Bridge-Agility/dp/0321502752/ref=mt_paperback?_encoding=UTF8&me=&qid=","2008年","書籍"]

{"sheet":"変更履歴","index":4,"n_rows":5,"n_cols":3,"rows_kept":5,"cut":false,"hidden":false,"merged":[]}
["変更履歴","日時","内容"]
["V1.0","2020-12-11","MacにVBA対応"]
["V1.1","2020-12-17","MAC/WIN共用のコンボボックス、ボタンを導入"]
["V1.2","2020-12-23","スコアのイベント取得とスコアの即時変更への対応"]
["V1.3","2020-12-29","スコア変更のイベント処理の間違いを修正"]