ぼくのかんがえたさいきょうの開発手法

この記事は[富士通システムズウェブテクノロジー Advent Calendar 2019](https://qiita.com/advent-calendar/2019/fsweb) 23日目の投稿です
（おやくそく）
記事の内容は全て個人の見解であり、執筆内容は執筆者自身の責任です。所属する組織は関係ありません。

![syazai_men.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/528122/67602119-362d-203b-f8c3-109c550800a7.png)
ごめんなさい。**出落ち**です。
<font color="red">**さいつよの開発手法**</font>でもなんでもないです。ただの<font color="red">**基礎的なアジャイル開発**</font>の記事です。

~~たまにはコード書こうかなと思いましたが、時間ない～。頭の中にだいたいあるようなことを記事にしよう！~~
特にエンタープライズのアジャイルとか**新しい事は書いていません**。
ばっちりアジャイル開発知っているよ！という方ではなく**あまりアジャイルわかりません。という方向け**です。

本投稿はアジャイル開発について、思うところ、よくある疑問に対する**個人的な見解**というような内容です。


#１.はじめに

アジャイル開発は、実は**20年以上**前から存在していて特に新しくはありません。
しかし、特にここ数年アジャイル開発というワードをよく目にしますし、
弊社もそうですが各大手SIerも組織としてのアジャイル推進に重い腰をあげたようにも見えます。

・[NTTデータ6000人で富士通4000人、3年後のアジャイル開発要員](https://tech.nikkeibp.co.jp/atcl/nxt/mag/nc/18/013000094/013100008/)
・[日立、「アジャイル開発コンサルティングサービス」を提供開始](https://japan.zdnet.com/article/35132321/)
・[KDDIら3社、アジャイル開発を支援する合弁会社「Scrum Inc. Japan」設立](https://cloud.watch.impress.co.jp/docs/news/1173870.html)
　※上記例は全部2019年の記事。その他大手各社でもここ数年でアジャイルの動きは多数。

中堅以降の方は、いやいやアジャイルなんてこれまでも大きな動きがあったでしょ。と思うかもしれません。
でもまた**大きな流れ**を感じるので過去の試みはうまくいかなったのか...、~~あるいはあなたは人生をループしているのかもしれない~~
![time_machine.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/528122/09731c5a-31c4-8b82-b776-cc49489e2ce3.png)

#２.昔話し
私の**アジャイルとの出会い**は、富士通グループ会社ではなく小さなソフトウェアハウスに在籍していた頃の**2000年**になります。当時私は、まさに**デスマーチ案件**に従事しており**残業**が**<font color="red">100～230h<font>/月**な状況でした。
![business_karoushi.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/528122/0d428679-536b-3f8b-dfaa-88ee346624b0.png)

この案件は医療系の制御システムで**ウォーターフォール型開発**で行っており、以下のような問題がありました。

・お客様も**あるべき姿がわからない**。システムテスト後の**仕様変更多発**
・**医療系の仕様が複雑**
・**システム構成が複雑**
　（サーバーとのSocket通信、ハードの制御、マルチスレッド制御（4プロセス、10数個のスレッド等）
・開発メンバーの約半数が、**新人あるいは新人レベルのパートナー**
・開発は分担制で、お互い自分の**担当以外の機能はあまり知らない**。
・**可読性の悪い**コード（C++だけど非オブジェクト指向、1クラスが<font color="red">**1万stepオーバー**</font>、同じ処理のコピペ多数等）
などなど

一か月山奥の工場に開発/テストで軟禁されました(30日連続出勤）。今、考えても複雑怪奇なシステムでバグや仕様変更で終わりが見えません。
###「悲しいけどこれ仕事なのよね」
<img width="150" alt="war_sentouki_man2.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/528122/cba02d53-b423-8f8e-6207-c8fb265aa7d6.png">
という状況でした。

そこへ、**ケント・ベック (Kent Beck)**らによる<font color="red">**エクストリーム・プログラミング**</font>（以下XP)という開発手法の提唱です。
（XPはアジャイル開発手法のひとつ）
バグも仕様追加も変更も見たくない！という状況でしたが、そこに
<font color="red">**変化ヲ抱擁セヨ**</font>です。![sleep_dakimakura.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/528122/a4c0ad36-fdbb-cccc-2610-af5b2a9be8fb.png)

この開発手法なら、変化も抱擁して解決してしまうらしい！**ケント・ベック様**！まさに<font color="red">**神**</font>！！
![kentbeck.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/528122/0621dc27-9ca4-41c4-56c9-2140dd9c6949.png)
このデスマーチ案件では、度重なる修正により変更の難易度がとても高くなったり影響箇所が特定できなかったりと対応工数が**誇大化**していました。バグがバグを呼びまた元に戻したりと図のように**コストが指数関数的**にあがっているんじゃないかと思ったほどです。しかし**XPのプラクティス**によりこの曲線をなだらかにできるというのです。
![henka.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/528122/dfbfcc1e-deb8-a45e-c68a-b46188079f30.png)


XPのプラクティスをいくつかあげると
**テスティング（テスト駆動）、リファクタリング、ペアプログラミング、共同所有権、継続的インテグレーション、週40時間（週40時間以上働いてはいけない）**...

いやいやいや！これ**最新の開発手法でしょ**？
違います！これらが<font color="red">**約20年前**</font>にもう提唱されていたのです。<font color="red">**凄くないですか**</font>？
当時、デスマーチ案件だったこともありますが、XPはとてつもない**衝撃**でしたよ！もう**麻薬レベル**です。![hakken_boy_girl.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/528122/5ded403f-668f-e635-895f-7ffe6ffbc6a5.png)

<br>
そして。。。<font color="red">**私は会社を辞めた**</font>
![banzai_boy.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/528122/a9f6196e-5beb-09ba-ec9c-1ff89c4bbb84.png)

って逃げ出したみたいですね。（汗
そうではなくて、XPが良いといってもいきなり適用はできません。
**リファクタリング**や**共同所有権**など部分的に取り入れたり、中心人物として**デスマーチを沈めて**からの**退職**です。
バイト時代も含めると5年半ぐらいの在職になります。

当時**まだ先進的だったWeb開発**と、**エクストリームプログラム**は**今の会社では出来ない**。
~~そしてこの会社は泥船だ。沈む前に逃げだせ！~~
と判断しての**転職**になります。こうして私は**XP**の**強烈な印象**を胸に刻みこみ別の戦場を求めて旅立ちました。(曲.[「ドラゴンクエストⅡ」より 遙かなる旅路](https://www.youtube.com/watch?v=awILbegS3CE))
![yuusya_game.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/528122/0f595f41-ba5b-8994-dffd-67ac28e59a5f.png) 勇者~~プログラマー~~ LV5

当時影響を受けた本。共に2000年出版
[エクストリーム・プログラミング](https://www.amazon.co.jp/XP%E3%82%A8%E3%82%AF%E3%82%B9%E3%83%88%E3%83%AA%E3%83%BC%E3%83%A0%E3%83%BB%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0%E5%85%A5%E9%96%80%E2%80%95%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E9%96%8B%E7%99%BA%E3%81%AE%E7%A9%B6%E6%A5%B5%E3%81%AE%E6%89%8B%E6%B3%95-%E3%82%B1%E3%83%B3%E3%83%88-%E3%83%99%E3%83%83%E3%82%AF/dp/489471275X)(ケント・ベック著）※今は2nd Editionがあります
[リファクタリング―プログラムの体質改善テクニック](https://www.amazon.co.jp/%E3%83%AA%E3%83%95%E3%82%A1%E3%82%AF%E3%82%BF%E3%83%AA%E3%83%B3%E3%82%B0%E2%80%95%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%A0%E3%81%AE%E4%BD%93%E8%B3%AA%E6%94%B9%E5%96%84%E3%83%86%E3%82%AF%E3%83%8B%E3%83%83%E3%82%AF-Object-Technology-%E3%83%9E%E3%83%BC%E3%83%81%E3%83%B3-%E3%83%95%E3%82%A1%E3%82%A6%E3%83%A9%E3%83%BC/dp/4894712288/)(マーティン・ファウラー著）

##３．アジャイルとアジャイル開発手法

**アジャイルとアジャイル開発手法の関係ですが、アジャイルは思想、考え方**であり、
**スクラムやXPがその開発手法**です。**これらの総称をアジャイル開発**といいます。
[**アジャイルソフトウェア開発宣言**(2001年）](https://agilemanifesto.org/iso/ja/manifesto.html)にアジャイルで重視すべき指針、考え方がまとめられています。
（アジャイル開発手法の分野において名声のある17人（ケント・ベックやマーティン・ファウラー等）が共通して重要であるとした考え方をまとめたもの）

ここではこう謳われています。

>
**プロセスやツール**よりも**個人と対話**を、
**包括的なドキュメント**よりも**動くソフトウェア**を、
**契約交渉**よりも**顧客との協調**を、
**計画に従うこと**よりも**変化への対応**を、
>
価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。

また**アジャイル開発手法はXPやスクラムなど複数存在**しますが、現在のアジャイル開発の傾向については、
[VersionOne](https://www.stateofagile.com/)が行っている「**annual State of Agile Report**」(年次レポート)で確認出来ます。
![document_report.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/528122/eb383f60-6d3f-80d8-efb4-97c0f76709f7.png)
例えば、「[13th annual State of Agile Report(2019)」](https://www.stateofagile.com/#ufh-i-521251909-13th-annual-state-of-agile-report/473508)によるとアジャイル開発手法採用の内訳は以下の通りです。
現在は**スクラム開発手法**が多く採用されていることがわかります。

1. **SCRUM**(54%)
1. OTHER/HYBRID/MULTIPLE(14%)
1. **SCRUM**/**XP** HYBRID(10%)
1. **SCRUM**BAN(8%)
1. KANBAN(5%)

しかし、それぞれの**開発手法の優劣に意味はない**し、それらの**開発手法を厳密に真似る必要はありません**。
実際にアジャイル開発を行いながら、その案件でそのチームに合うやり方を探っていけばよいのです。
しかし、そこで**アジャイルソフトウェア開発宣言**を忘れてはいけないしこの**価値観こそが、アジャイル**だと私は思います。

これらが、<font color="red">**現在でも私の開発の考え方の原点**</font>です。

また今回知ったのですがIPAがこんなものを出していました。
[アジャイルソフトウェア開発宣言の読みとき方]
(https://www.ipa.go.jp/files/000065601.pdf)
（私もこれはちゃんと読んでない）

なぜ2018年に？とても遅いわけですが、DXレポート等もそうですがIPAみたいなところがこういうものを出すことによって世に広まりやすいので良いことではあります。

##４．ウォータフォール型開発の問題点
![kawa_taki.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/528122/2f1c5065-e6fe-cea3-e293-696e19e6872c.png)

**ウォータフォール型開発の問題点**をおさらいしておきます。
（請負契約、ウォーターフォール型での大規模開発をイメージ）

* **実際に動くアプリを触るまでに時間がかかる**
　仕様が伝わりきってなかった。思ってたのと違かったー。となる。

* **実際に触る頃には要求が変わっている**
* **必要だと思って作成したが実際は使われない機能も多い**
　**使われない機能が3分の2**(まったく使われない機能45%、ほとんど使われない機能19%)　(The Standish Group "Chaos" report 2002より)
* **手戻りが発生した場合に、下流で発生するほど負担が大きい**
* **仕様変更、追加は、再契約が必要**
* **あまり使わない（あるいは必要がない）ドキュメント作成に多くの時間が割かれる**（場合がある）
* **多重請負でムダが多い**（場合がある）※富士通は再々委託は禁止
* **仕様通りに作成することがゴールになってしまう**（場合がある）
* **お客様<-->ベンダー<-->二次請負の間で相互に、決定した仕様を如何にコストを低く実現するかが重視されてしまう**（場合がある）

* **開発者は言われたとおりに作るだけで楽しくない**
（なんてのもありますが、こういうのも意外に**重要**です）
などがあります。

アナログで確立されており効果も仕様も明確な業務をシステム化するにあたっては、ウォーターフォール型開発で良かったのかもしれません。しかし、既にもう１周まわっていて（いや２、３周？）そのような**新規に作成するシステムはほとんどありません**。

もう**ウォーターフォール型の良い点**は、**スケジュールや予算が立てやすい。管理しやすい。ぐらい**なのではないでしょうか。しかしその開発には上述のたくさんのムダが含まれているわけです。
アメリカでは、ウォーターフォール型開発なんてまだ日本はしているの？と言われるそうです。
<font color="red">**これでもあなたはウォーターフォール型で開発をしますか？**</font>

>
現代のソフトウェア開発で製造業をモデルにするのはふさわしくない部分がある。
日本企業は、ソフトウェア開発をレバレッジの効くビジネスとしてではなく、工業製品のように捉えたため、イノべーティブなソフトウェアを生み出せなかったのはないか？

上記は、書籍「[ソフトウェア・ファースト](https://www.amazon.co.jp/%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E3%83%BB%E3%83%95%E3%82%A1%E3%83%BC%E3%82%B9%E3%83%88-%E3%81%82%E3%82%89%E3%82%86%E3%82%8B%E3%83%93%E3%82%B8%E3%83%8D%E3%82%B9%E3%82%92%E4%B8%80%E5%A4%89%E3%81%95%E3%81%9B%E3%82%8B%E6%9C%80%E5%BC%B7%E6%88%A6%E7%95%A5-%E5%8F%8A%E5%B7%9D-%E5%8D%93%E4%B9%9F/dp/4822289915)」（及川卓也著）からの引用ですが、
製造業のように手戻りすることが許されない開発にはウォーターフォール型開発は向いていますが一部をソフトウェア開発にそのまま持ってきただけではふさわしくないとあります。
（※誤解のないように書くと書籍では、ウォーターフォール型が絶対ダメとは言っていません）
このあたりにこの20～30年の間に日本がIT後進国になってしまった鍵があるのではと思います。

<font color="red">**個人的には**</font>私は、マイクロソフトの牛尾さんの書かれているブログとほぼ同じ気持ちです。
(~~大きな声では言えないがウォーターフォール型開発なんてもう不要!~~)
[(メソッド屋のブログ)私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い](http://simplearchitect.hatenablog.com/entry/2016/06/20/080807)

##５．アジャイル開発のよくある質問
![question_head_boy.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/528122/3f65e39e-112d-ff06-8614-5980a7409084.png)

* **アジャイルって素早く開発できるんでしょ？**

![character_program_fast.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/528122/d6d6a6a0-a3f7-1646-aca5-95e93f46b009.png) 
　「agile」という単語が「すばやい」「俊敏な」という意味から由来する勘違いですが、正しくは、<font color="red">**変更に対する対応が「すばやい」**</font>です。
　開発関係者で知らない人はいないと思いますが、本当に勘違いしてるのではというような記事を見かけるとモヤモヤします。

* **アジャイルって仕様変更がいつでも出来るんでしょ？**

![mark_24jikan_eigyou.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/528122/dd9d0661-0fe1-b8a0-c12e-b1055016bb1a.png)
　すぐに可能です。
　例えば最重要な変更なら次のスプリントから対応可能です。※1スプリントは通常1～4week
　**但し何かを追加（変更）すれば、何かが外に追いやられます**。例えば次々回移行のスプリントにです。
　<font color="red">**また無料で出来るんでしょ?**</font>。というのは**別の問題**です。

* **アジャイルって安くできるんでしょ？**

![business_kaitataku.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/528122/74816d6e-34d3-684b-c56d-23b49c5d2043.png)
　**速いわけでも安いわけでもないです**。
　**最初から間違いのないゴールがわかっていればウォーターフォール型が最短かもしれません**。
　ただしそのような正しくて明確なゴールは最初からわかったりは普通しないです。
　**アジャイルは、最初は明後日の方向に進むかもしれませんが短いサイクルで方向修正をしながら進みます**(下図)。
![agile.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/528122/ae7f0159-1e80-3378-fe35-8265c0197100.png)

* **ドキュメントは作らないんでしょ？**

![pose_necchuu_computer_man.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/528122/43bb522f-ca7f-2f24-56fd-24d155a68fa5.png)
　**アジャイルでもドキュメントは作成します**。
　但し、アプリケーションを相対的に重視し、本当に必要なドキュメントだけを作成します。
　またアジャイル開発なのですぐに変わるかもしれないしいらなくなるかもしれません。
　綺麗な凝ったドキュメントは不要です。Web上で簡単に残しておいたり、白板に書いた簡単な設計でも構いません。

　※どのようなドキュメントを作成するかについては、誰のためにどれくらいの人数がどれぐらい期間そのドキュメントを参照するか等を考慮して決めると良いと思います。

　※変更があってもすぐに反映できるようにドキュメント生成が自動化されていると良いです。

* **アジャイルって優れたメンバー集めないと出来ないんでしょ？**

![tensai_boy.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/528122/836a1ec6-90af-3a4d-3504-9a5c653f0d0d.png)
　**私はそうとは思いません**。が
　アジャイルでは、コミュニケーションを重視するのでコミュニケーションが苦手な人や、ウォーターフォール型で、細かく役割分担し前工程でのドキュメント通りに作ります、指示して下さい。というような開発に慣れきっている方は、合わないかもしれません。
（~~裏返しな人材が出来るヤツっていうだってばよ？~~）

* **アジャイルって専用のツールを使うんですよね？**

![monkey_wrench.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/528122/701ce052-b780-8814-d2fc-11173b610642.png)
　Redmine,Jira,Trelloなどの管理ツールを使ったりしますが、**これらのツールを使ったからアジャイルなわけでも、アジャイルならこれらのツールを使わないといけないわけではありません**。
　アジャイルの開発手法の実践が、**ツールを使って効率化されるのであれば使うのが好ましいです**。

　なお「[13th annual State of Agile Report(2019)」](https://www.stateofagile.com/#ufh-i-521251909-13th-annual-state-of-agile-report/473508)によると
　アジャイルプロジェクトの管理ツールは65%（複数回答あり）が**Jira**を使っているようです。次にExcel(48%)、Microsoft Project(24%)が続きます。
　Excelは意外ですが効率化されるならどんどん使ったほうが良いです。またMicrosoft Projectは推奨されるツールでは25%となっているので使用しているが望ましくはないようです。

* **アジャイルって大規模案件には適用できないんでしょ？**

![kousou_building.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/528122/12c2e13b-0388-f7f5-4cdc-450953e0b194.png)
　**大規模な案件にも適用できます**。
　10人以下のチームを作って複数同時にまわすことになります。

　この場合それぞれのチームをどう管理するのかが気になるところです。マイクロサービスでアジャイル開発をバリバリやっているある有名企業さんに、私も質問したことがあるのですが
　「**定期的にチーム間の問題や課題、変更を共有する会議体を設けている**」とのことでした。**案外普通**です。

　また大規模アジャイルを実施するためのフレームワークもあります。
　例によって「[13th annual State of Agile Report(2019)」](https://www.stateofagile.com/#ufh-i-521251909-13th-annual-state-of-agile-report/473508)によると**SAFe(30%)**、**Scrum of Scrums(16%)**となっています。
　（※ちなみに、私の所属している組織（のとなりのチーム）ではこのエンタープライズアジャイルのコンサルも行っています）

##６．契約形態
![akusyu_businessman.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/528122/1aae8049-95da-ffe4-18ee-3eb81a90a593.png)

また**アジャイル開発で避けて通れないのが、契約形態**です。
システム開発では、よくユーザー企業とベンダー企業の間で以下のような契約が適用されます。
（簡易的に書いています）

* **請負契約**
　仕事を完成させる責任があり、その成果に対して報酬が支払われる
　瑕疵担保責任がある
* **準委任契約**
　労働期間に対して報酬が支払われる
　瑕疵担保責任がない

**アジャイル開発では、ある周期毎にフィードバックを得て計画を見直します。したがってあらかじめ全体作業ボリュームを見積もることが難しく請負契約のような契約が適しません**。
もし請負契約でアジャイル開発というような案件があったとするとお互い不幸になるので見直す事が推奨されます。

「[DXレポート（経済産業省）](https://www.meti.go.jp/shingikai/mono_info_service/digital_transformation/20180907_report.html)」でも、
アジャイル開発における契約の整備が課題であり、現在以下の３パターンが考えられるとしています。
A.内製モデル
B.基本/個別契約モデル（請負/準委任）
C.ジョイント・ベンチャーモデル（共同出資）

富士通としても、以下でアジャイル開発の契約について触れられています。
[アジャイル開発に必須の組織、契約、人に関するあり方]
(https://www.fujitsu.com/jp/services/knowledge-integration/insights/201805-05/index.html)

**個人的には準委任契約が良いと思います**。今の時代はサブスクリプションなので。
![business_kubi.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/528122/aeae4654-7a90-ce72-e063-48da39dccc2c.png)
DXレポートでは、ユーザー企業側にリスクがあると書かれていますが、成果が出せなければ開発を途中で打ち切りするかどうかの判断を短い間隔で行うような形にすればリスクも抑えられますし、私が「４．ウォータフォール型開発の問題点）で述べた問題と戦うより、このほうがずっと双方で幸せになれると思うからです。

##７．さいごに

「<font color="red">**アジャイル最高だぜ！**</font>」という投稿になってしまいましたが、アジャイルだけではなく以下も重要です。
（これらはアジャイルと親和性が高いですし、ある規模以上の開発だと合わせて実施することは必然的です）

・**テストやデプロイの自動化（CI/CD）**
　頻繁に発生する変更のたびに手動でのテストは非現実的です。また変更のハードルを下げるためにも必要です。

・**マイクロサービス化**
　変更を行う際にシステムがモノリシック（一枚岩）な作りになっていると非常に修正が困難になります。
　システムを疎な関係で適切に分割を行いAPIで連携する構成にします（マイクロサービス化）これによって個々のサービスの開発（変更、機能追加）が容易になります。

加えて、いわゆる<font color="red">**DX案件**</font>では世の中の変化に素早く対応することが求められ、最初からゴールがわからない場合が多いです。
このような場合も上記のセットはとても有効かと思います。

###楽しいけどこれ仕事なのよね

<font color="red">**私が言いたいことはシステム開発を最適化することによって、発生している（しているかもしれない）ムダに費やす時間をすべてお客様のうれしいこと（すばらしい価値を生み出すアプリケーション）に向けたいだけです**。</font>

キレイ事のようですが、これが実現されれば**お客様もエンジニアもハッピーになるはず**！

（エンジニアって良い開発をして、お客様の喜ぶ姿を見れればもうなにもいらないですよね。
　楽しければ良いという意味ではなくて、メンタルを最高に保てばその人のパフォーマンスも最大になり会社もハッピーなわけです）
![christmas_dance_tonakai_santa.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/528122/02025a36-3cdc-6755-cde6-fb3af026c961.png)

###ぼくのかんがえたさいきょうの開発手法

さいごに、**本投稿のタイトル**ですが
**もし、なんの制約もなしにあなたが好きなように開発していいよ**。と言われたら、<font color="red">**私はアジャイルになると思っています**</font>。

それは「２．昔話し」~~(回想編)~~で、身を持って死にそうになりながら<font color="red">**開発のあるべき姿**</font>を胸に刻み込んだからです。
![business_karoushi.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/528122/75d13576-9208-04ae-5b42-4575bca8adbd.png)
<font color="red">**だからスピリットはアジャイルなんです（無意識でも）**</font>
そして既存アジャイル開発手法をそのままでやるのではなくカスタマイズしたり自分の頭で考えて一番良い方法を探して試行錯誤して開発するのがいちばん**最強**なんだと思います。（**＝アジャイルなんだけどね**）

ということで本投稿のタイトルは、
「<font color="red">**ぼくのかんがえたさいきょうの開発手法**</font>」
となったわけです。

ちゃんと書くと、こんなイメージです。

||内容|
|:--|:---|
|考え方|アジャイルソフトウェア開発宣言のポリシーで|
|開発手法|スクラム＆XP。案件やメンバーに合わせていいところ取りで|
|備考|新しいプラクティスを試しながら、効果のないものは排除|
（「13th annual State of Agile Report」の開発手法採用アンケートでほぼ答え出ていました。皆様考えることは一緒）

![monogatari_king_arthur.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/528122/25e162da-7fc2-2d8b-55da-8361b2c0eac5.png) 勇者~~マネージャ~~ LV45歳
※最近はレベルが上がるとステータスが下がります⤵

## おまけ
こちらのイベント「[DX Japan Meetup 2019/12/16 in Tokyo](https://dx-japan.connpass.com/event/156204/?utm_campaign=recent_events&utm_medium=atom&utm_source=feed)」でもほぼ同じ内容をLTで話させて頂きました。
~~（このアドベントカレンダーの投稿を先に書いたので、LTはほぼそれをパワポにしただけですが）~~

<blockquote class="twitter-tweet"><p lang="ja" dir="ltr">本日はこちらです。<a href="https://twitter.com/hashtag/DXJP?src=hash&amp;ref_src=twsrc%5Etfw">#DXJP</a><a href="https://t.co/BxBEEdNP7a">https://t.co/BxBEEdNP7a</a></p>&mdash; そがとし / Toshiyuki Soga (@soga_toshi) <a href="https://twitter.com/soga_toshi/status/1206507219354710017?ref_src=twsrc%5Etfw">December 16, 2019</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>