和アジャイルの誰時 β2　9章　和アジャイルの誰時

# 9．　和アジャイルの誰時

## 9.1 本書をざっと、まとめ直してみる

　再び本書の目次を眺めてみてください。　発注側の経営幹部、ＰＯ、受注側の開発メンバ、受注側の責任者に向けて、それぞれに対するメッセージとしています。　表紙にも開発ステップに関するメッセージを埋め込んでいます。

### ■ 発注側・経営幹部へのメッセージ

  - __アジャイル開発のメリットを受けるのはあなた（経営幹部）です。__ ソフトウェア開発の進め方を、__「大事なことを先にやる」、「フィードバックを早く回す」__ 、そう変えるだけです。変化する状況にスピードディに対応するには、その変化対応力が大切なのです。
  - アジャイル開発を推進するのはあなた自身（経営幹部）の役割です。あなたが自らの組織を変革していかなければいけません。もし、社内でアジャイル開発が未だ上手く実践されていないとしたら、組織風土（価値観、責任・制度、育成）に問題があるはずです。それを __改革するために、先頭に立って汗をかいてリーダシップを見せていかなければいけないのは、あなた自身です。あなたはまずPOの心得を知らなければいけないでしょう。__
  - 開発責任者になれるPOを育成し、支援し、援護しなければいけません。POとは情報処理技術を知り、チーム運営のできるビジネス・リーダです。

### ■ 発注側・POへのメッセージ

  - __アジャイル開発は準委任契約で実施__ しないと、良いソフトウェア作成には至りません。請負開発契約でアジャイル開発を実施した場合には、あなたの期待するアジャイル開発になることはあり得ません。
  - アジャイル開発では __POに完成責任・品質確保責任__ が発生します。責任に見合う権限を持ちましょう。
  - POに必要なのは __ビジネス・リーダシップによるチーム運営力__ です。POが受身だとソフトウェアは完成しません。　主体性が重要です。
  - 良いソフトウェアを作るには開発メンバのモチベーションが重要です。__モチベーションを高く維持するためにPOは努力__ しなければいけません。

### ■ アジャイル開発メンバ（ソフトウェア技術者）へのメッセージ

  - 「アジャイル開発をやりたい」と言うのは発注側です。受注側が言い出し誘導するのは無責任です。なぜなら、発注者側がソフトウェアの完成責任・品質確保責任を負うべきだからです。
  - アジャイル開発に参加したいが契約制度に関わりたくないなら、自社製品の内製プロジェクトや、派遣社員として他社のアジャイル開発プロジェクトに参加するのが、簡単な道です。
  - アジャイル開発では、__コミュニケーション・スキルが重要__ になります。　コミュニケーションをどうしても避けたければ、アジャイル開発からは離脱しましょう。
  - アジャイル開発では、POの優先度判断によってプロジェクトが進みます。__目指すゴールとPOの価値観を正しく理解__ して、あなたの __主体性を発揮__ してPOを支援していきましょう。
  - アジャイル開発に参加したからには、技術的な貢献をしましょう。　プロジェクト以外でも __情報処理分野の最新技術を広く習得し、自分を磨き続ける姿勢__ を持続しましょう。


### ■ 受注側責任者へのメッセージ

  - アジャイル開発を成功に導くためには、__製造請負契約で受注してはいけません__。目先の売り上げに負けて製造請負契約で受注すると、両者が、そして日本の情報処理業界全体が、子供たちが不幸になります。

## 9.2 和アジャイルが目指すべき世界

　日本におけるアジャイル開発、和アジャイルで目指す世界はどこでしょうか？

  - 日本のソフトウェア開発が世界で競争力を持つこと。情報システムの開発能力が米国並みに上がること。発注者が望む良いソフトウェアをリーズナブル（価格、期間、品質）に作りだす世界になること。
  - モチベーションの高い優秀なソフトウェア技術者が活躍して良いソフトウェアを作れる場が普及すること。ソフトウェア技術者が開発で充実感と成長を感じられる世界になること。
　
　著者は、これらを目指します。そのためにはウォーターフォール開発ではダメです。アジャイル開発を日本における受発注型ソフトウェア開発の現場でも普通に使える状況が必要です。2020年度からはプログラミング教育が小学校に導入されます。彼ら・彼女らが就職する前に日本の現状を変えなければいけません。

### ■ 日本の現状の不都合を正しく認識する発注者が主流になることが望まれます。

　まずは、日米格差とその問題点を発注者が正しく理解することが大切だと考えます。 

　日本におけるアジャイル開発は、IT系ベンチャー企業などでは既に常識として取り入れられていると思います。しかし、メインフレームの経験等のある企業や、発注でシステムを開発しようとする企業では未だ主流の開発スタイルには至っていないのではないでしょうか。まだまだ、日の出前の状態にあります。　本書名に使った __「誰時」__ とは、__明け方・日の出前__ のことです。既にアジャイル開発を実践できているベンチャー企業の皆さん、内製開発をベースにアジャイル開発を実践している皆さんには、本書の内容は遠い国の笑い話かもしれません。　

### ■ アジャイル開発スタイルを日本の受発注によるソフトウェア開発の実情に合わせて、上手く実施するための工夫とコツを見つけ出すことです。

　漢字は中国で作られました。しかし、日本独自のひらがなを生み出し、漢字の間にそれを挟んで多彩な表現と文化を生み出しました。米国企業が活用するアジャイル開発を日本の受発注関係の中で使っていくためにも、いくつかの工夫とコツの追加が必要です。 本書ではそれをまとめたいと思い書き始めました。

## 9.3 本書籍もβ版

　そして、この書籍自体もアジャイル開発のような継続的な進化を目指します。　

### ■ フィードバックを得て、改善をまわすのが「アジャイル」なスタイルのハズです。

　本書も、「アジャイル」なスタイルで出版します。他の皆さんの意見を聞きながら改善するのがアジャイルスタイルだと信じるからです。まだまだ日本のソフトウェア産業界におけるアジャイル開発スタイルは「誰時」なのです。時代の変化・人々の経験からのフィードバックに対応して、進化させ追従していきたいと思います。

　　・フィードバック先： 　wa.agile.research.group@gmail.com
　　・情報の更新案内：　https://wa-agile.wixsite.com/research-group


### ■ 著者の限界

　著者は、内製経験、アジャイル開発の発注側PO経験・受注側経験、ウォーターフォール開発の発注側経験・受注側経験があります。しかし、□□□□□□□□□□□□□□□□□□□□□□□□はありません。アジャイル開発は大規模になると課題が大きくなると言われています。本書は、その程度の規模までの経験者が執筆した書籍だと理解してください。本書はアジャイル開発スタイルとしてはスクラムとスパイラル開発を想定しています。
　
　本書の記載と各主張は、著者の所属する組織とは一切関係がありません。 　

##### 2022.9.25 改版に向けて

https://qiita.com/wa-agile-research-group/items/dfa3fc86f203140c25a0

https://qiita.com/wa-agile-research-group/items/1a707d5e301eff676a2c

https://qiita.com/wa-agile-research-group/items/1bce0451290bc14881ba

https://qiita.com/wa-agile-research-group/items/51ad9ffa52e8b59fbeeb

https://qiita.com/wa-agile-research-group/items/d45429f03727f8aa7add

https://qiita.com/wa-agile-research-group/items/c9dbc8176adbd7bd27c2

https://qiita.com/wa-agile-research-group/items/4b5a34b214dc18a758ce

https://qiita.com/wa-agile-research-group/items/e8a75dcc1b8fd03d3bf3

https://qiita.com/wa-agile-research-group/items/fa8d3bee2a2a1b97aee0

https://qiita.com/wa-agile-research-group/items/e440631e5b1318e9280f