この記事は富士通システムズウェブテクノロジー Advent Calendar 2019 23日目の投稿です
（おやくそく）
記事の内容は全て個人の見解であり、執筆内容は執筆者自身の責任です。所属する組織は関係ありません。
ごめんなさい。出落ちです。
さいつよの開発手法でもなんでもないです。ただの基礎的なアジャイル開発の記事です。
たまにはコード書こうかなと思いましたが、時間ない～。頭の中にだいたいあるようなことを記事にしよう！
特にエンタープライズのアジャイルとか新しい事は書いていません。
ばっちりアジャイル開発知っているよ！という方ではなくあまりアジャイルわかりません。という方向けです。
本投稿はアジャイル開発について、思うところ、よくある疑問に対する個人的な見解というような内容です。
#１.はじめに
アジャイル開発は、実は20年以上前から存在していて特に新しくはありません。
しかし、特にここ数年アジャイル開発というワードをよく目にしますし、
弊社もそうですが各大手SIerも組織としてのアジャイル推進に重い腰をあげたようにも見えます。
・NTTデータ6000人で富士通4000人、3年後のアジャイル開発要員
・日立、「アジャイル開発コンサルティングサービス」を提供開始
・KDDIら3社、アジャイル開発を支援する合弁会社「Scrum Inc. Japan」設立
※上記例は全部2019年の記事。その他大手各社でもここ数年でアジャイルの動きは多数。
中堅以降の方は、いやいやアジャイルなんてこれまでも大きな動きがあったでしょ。と思うかもしれません。
でもまた大きな流れを感じるので過去の試みはうまくいかなったのか...、あるいはあなたは人生をループしているのかもしれない
#２.昔話し
私のアジャイルとの出会いは、富士通グループ会社ではなく小さなソフトウェアハウスに在籍していた頃の2000年になります。当時私は、まさにデスマーチ案件に従事しており残業が**100～230h/月**な状況でした。
この案件は医療系の制御システムでウォーターフォール型開発で行っており、以下のような問題がありました。
・お客様もあるべき姿がわからない。システムテスト後の仕様変更多発
・医療系の仕様が複雑
・システム構成が複雑
（サーバーとのSocket通信、ハードの制御、マルチスレッド制御（4プロセス、10数個のスレッド等）
・開発メンバーの約半数が、新人あるいは新人レベルのパートナー
・開発は分担制で、お互い自分の担当以外の機能はあまり知らない。
・可読性の悪いコード（C++だけど非オブジェクト指向、1クラスが1万stepオーバー、同じ処理のコピペ多数等）
などなど
一か月山奥の工場に開発/テストで軟禁されました(30日連続出勤）。今、考えても複雑怪奇なシステムでバグや仕様変更で終わりが見えません。
###「悲しいけどこれ仕事なのよね」
という状況でした。
そこへ、**ケント・ベック (Kent Beck)**らによるエクストリーム・プログラミング（以下XP)という開発手法の提唱です。
（XPはアジャイル開発手法のひとつ）
バグも仕様追加も変更も見たくない！という状況でしたが、そこに
変化ヲ抱擁セヨです。
この開発手法なら、変化も抱擁して解決してしまうらしい！ケント・ベック様！まさに神！！
このデスマーチ案件では、度重なる修正により変更の難易度がとても高くなったり影響箇所が特定できなかったりと対応工数が誇大化していました。バグがバグを呼びまた元に戻したりと図のようにコストが指数関数的にあがっているんじゃないかと思ったほどです。しかしXPのプラクティスによりこの曲線をなだらかにできるというのです。
XPのプラクティスをいくつかあげると
テスティング（テスト駆動）、リファクタリング、ペアプログラミング、共同所有権、継続的インテグレーション、週40時間（週40時間以上働いてはいけない）...
いやいやいや！これ最新の開発手法でしょ？
違います！これらが約20年前にもう提唱されていたのです。凄くないですか？
当時、デスマーチ案件だったこともありますが、XPはとてつもない衝撃でしたよ！もう麻薬レベルです。
そして。。。**私は会社を辞めた** 
って逃げ出したみたいですね。（汗
そうではなくて、XPが良いといってもいきなり適用はできません。
リファクタリングや共同所有権など部分的に取り入れたり、中心人物としてデスマーチを沈めてからの退職です。
バイト時代も含めると5年半ぐらいの在職になります。
当時まだ先進的だったWeb開発と、エクストリームプログラムは今の会社では出来ない。
そしてこの会社は泥船だ。沈む前に逃げだせ！
と判断しての転職になります。こうして私はXPの強烈な印象を胸に刻みこみ別の戦場を求めて旅立ちました。(曲.「ドラゴンクエストⅡ」より 遙かなる旅路)
勇者プログラマー LV5
当時影響を受けた本。共に2000年出版
エクストリーム・プログラミング(ケント・ベック著）※今は2nd Editionがあります
リファクタリング―プログラムの体質改善テクニック(マーティン・ファウラー著）
##３．アジャイルとアジャイル開発手法
アジャイルとアジャイル開発手法の関係ですが、アジャイルは思想、考え方であり、
スクラムやXPがその開発手法です。これらの総称をアジャイル開発といいます。
アジャイルソフトウェア開発宣言(2001年）にアジャイルで重視すべき指針、考え方がまとめられています。
（アジャイル開発手法の分野において名声のある17人（ケント・ベックやマーティン・ファウラー等）が共通して重要であるとした考え方をまとめたもの）
ここではこう謳われています。
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、
価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。
またアジャイル開発手法はXPやスクラムなど複数存在しますが、現在のアジャイル開発の傾向については、
VersionOneが行っている「annual State of Agile Report」(年次レポート)で確認出来ます。
例えば、「13th annual State of Agile Report(2019)」によるとアジャイル開発手法採用の内訳は以下の通りです。
現在はスクラム開発手法が多く採用されていることがわかります。
- SCRUM(54%)
- OTHER/HYBRID/MULTIPLE(14%)
- SCRUM/XP HYBRID(10%)
- SCRUMBAN(8%)
- KANBAN(5%)
しかし、それぞれの開発手法の優劣に意味はないし、それらの開発手法を厳密に真似る必要はありません。
実際にアジャイル開発を行いながら、その案件でそのチームに合うやり方を探っていけばよいのです。
しかし、そこでアジャイルソフトウェア開発宣言を忘れてはいけないしこの価値観こそが、アジャイルだと私は思います。
これらが、現在でも私の開発の考え方の原点です。
また今回知ったのですがIPAがこんなものを出していました。
[アジャイルソフトウェア開発宣言の読みとき方]
(https://www.ipa.go.jp/files/000065601.pdf)
（私もこれはちゃんと読んでない）
なぜ2018年に？とても遅いわけですが、DXレポート等もそうですがIPAみたいなところがこういうものを出すことによって世に広まりやすいので良いことではあります。
##４．ウォータフォール型開発の問題点
ウォータフォール型開発の問題点をおさらいしておきます。
（請負契約、ウォーターフォール型での大規模開発をイメージ）
-
実際に動くアプリを触るまでに時間がかかる
仕様が伝わりきってなかった。思ってたのと違かったー。となる。 -
実際に触る頃には要求が変わっている
-
必要だと思って作成したが実際は使われない機能も多い
使われない機能が3分の2(まったく使われない機能45%、ほとんど使われない機能19%) (The Standish Group "Chaos" report 2002より) -
手戻りが発生した場合に、下流で発生するほど負担が大きい
-
仕様変更、追加は、再契約が必要
-
あまり使わない（あるいは必要がない）ドキュメント作成に多くの時間が割かれる（場合がある）
-
多重請負でムダが多い（場合がある）※富士通は再々委託は禁止
-
仕様通りに作成することがゴールになってしまう（場合がある）
-
お客様<-->ベンダー<-->二次請負の間で相互に、決定した仕様を如何にコストを低く実現するかが重視されてしまう（場合がある）
-
開発者は言われたとおりに作るだけで楽しくない
（なんてのもありますが、こういうのも意外に重要です）
などがあります。
アナログで確立されており効果も仕様も明確な業務をシステム化するにあたっては、ウォーターフォール型開発で良かったのかもしれません。しかし、既にもう１周まわっていて（いや２、３周？）そのような新規に作成するシステムはほとんどありません。
もうウォーターフォール型の良い点は、スケジュールや予算が立てやすい。管理しやすい。ぐらいなのではないでしょうか。しかしその開発には上述のたくさんのムダが含まれているわけです。
アメリカでは、ウォーターフォール型開発なんてまだ日本はしているの？と言われるそうです。
これでもあなたはウォーターフォール型で開発をしますか？
現代のソフトウェア開発で製造業をモデルにするのはふさわしくない部分がある。
日本企業は、ソフトウェア開発をレバレッジの効くビジネスとしてではなく、工業製品のように捉えたため、イノべーティブなソフトウェアを生み出せなかったのはないか？
上記は、書籍「ソフトウェア・ファースト」（及川卓也著）からの引用ですが、
製造業のように手戻りすることが許されない開発にはウォーターフォール型開発は向いていますが一部をソフトウェア開発にそのまま持ってきただけではふさわしくないとあります。
（※誤解のないように書くと書籍では、ウォーターフォール型が絶対ダメとは言っていません）
このあたりにこの20～30年の間に日本がIT後進国になってしまった鍵があるのではと思います。
個人的には私は、マイクロソフトの牛尾さんの書かれているブログとほぼ同じ気持ちです。
(大きな声では言えないがウォーターフォール型開発なんてもう不要!)
(メソッド屋のブログ)私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い
##５．アジャイル開発のよくある質問
- アジャイルって素早く開発できるんでしょ？
「agile」という単語が「すばやい」「俊敏な」という意味から由来する勘違いですが、正しくは、変更に対する対応が「すばやい」です。
開発関係者で知らない人はいないと思いますが、本当に勘違いしてるのではというような記事を見かけるとモヤモヤします。
- アジャイルって仕様変更がいつでも出来るんでしょ？
すぐに可能です。
例えば最重要な変更なら次のスプリントから対応可能です。※1スプリントは通常1～4week
但し何かを追加（変更）すれば、何かが外に追いやられます。例えば次々回移行のスプリントにです。
また無料で出来るんでしょ?。というのは別の問題です。
- アジャイルって安くできるんでしょ？
速いわけでも安いわけでもないです。
最初から間違いのないゴールがわかっていればウォーターフォール型が最短かもしれません。
ただしそのような正しくて明確なゴールは最初からわかったりは普通しないです。
アジャイルは、最初は明後日の方向に進むかもしれませんが短いサイクルで方向修正をしながら進みます(下図)。
- ドキュメントは作らないんでしょ？
アジャイルでもドキュメントは作成します。
但し、アプリケーションを相対的に重視し、本当に必要なドキュメントだけを作成します。
またアジャイル開発なのですぐに変わるかもしれないしいらなくなるかもしれません。
綺麗な凝ったドキュメントは不要です。Web上で簡単に残しておいたり、白板に書いた簡単な設計でも構いません。
※どのようなドキュメントを作成するかについては、誰のためにどれくらいの人数がどれぐらい期間そのドキュメントを参照するか等を考慮して決めると良いと思います。
※変更があってもすぐに反映できるようにドキュメント生成が自動化されていると良いです。
- アジャイルって優れたメンバー集めないと出来ないんでしょ？
私はそうとは思いません。が
アジャイルでは、コミュニケーションを重視するのでコミュニケーションが苦手な人や、ウォーターフォール型で、細かく役割分担し前工程でのドキュメント通りに作ります、指示して下さい。というような開発に慣れきっている方は、合わないかもしれません。
（裏返しな人材が出来るヤツっていうだってばよ？）
- アジャイルって専用のツールを使うんですよね？
Redmine,Jira,Trelloなどの管理ツールを使ったりしますが、これらのツールを使ったからアジャイルなわけでも、アジャイルならこれらのツールを使わないといけないわけではありません。
アジャイルの開発手法の実践が、ツールを使って効率化されるのであれば使うのが好ましいです。
なお「13th annual State of Agile Report(2019)」によると
アジャイルプロジェクトの管理ツールは65%（複数回答あり）がJiraを使っているようです。次にExcel(48%)、Microsoft Project(24%)が続きます。
Excelは意外ですが効率化されるならどんどん使ったほうが良いです。またMicrosoft Projectは推奨されるツールでは25%となっているので使用しているが望ましくはないようです。
- アジャイルって大規模案件には適用できないんでしょ？
大規模な案件にも適用できます。
10人以下のチームを作って複数同時にまわすことになります。
この場合それぞれのチームをどう管理するのかが気になるところです。マイクロサービスでアジャイル開発をバリバリやっているある有名企業さんに、私も質問したことがあるのですが
「定期的にチーム間の問題や課題、変更を共有する会議体を設けている」とのことでした。案外普通です。
また大規模アジャイルを実施するためのフレームワークもあります。
例によって「13th annual State of Agile Report(2019)」によるとSAFe(30%)、**Scrum of Scrums(16%)**となっています。
（※ちなみに、私の所属している組織（のとなりのチーム）ではこのエンタープライズアジャイルのコンサルも行っています）
##６．契約形態
またアジャイル開発で避けて通れないのが、契約形態です。
システム開発では、よくユーザー企業とベンダー企業の間で以下のような契約が適用されます。
（簡易的に書いています）
-
請負契約
仕事を完成させる責任があり、その成果に対して報酬が支払われる
瑕疵担保責任がある -
準委任契約
労働期間に対して報酬が支払われる
瑕疵担保責任がない
アジャイル開発では、ある周期毎にフィードバックを得て計画を見直します。したがってあらかじめ全体作業ボリュームを見積もることが難しく請負契約のような契約が適しません。
もし請負契約でアジャイル開発というような案件があったとするとお互い不幸になるので見直す事が推奨されます。
「DXレポート（経済産業省）」でも、
アジャイル開発における契約の整備が課題であり、現在以下の３パターンが考えられるとしています。
A.内製モデル
B.基本/個別契約モデル（請負/準委任）
C.ジョイント・ベンチャーモデル（共同出資）
富士通としても、以下でアジャイル開発の契約について触れられています。
[アジャイル開発に必須の組織、契約、人に関するあり方]
(https://www.fujitsu.com/jp/services/knowledge-integration/insights/201805-05/index.html)
個人的には準委任契約が良いと思います。今の時代はサブスクリプションなので。
DXレポートでは、ユーザー企業側にリスクがあると書かれていますが、成果が出せなければ開発を途中で打ち切りするかどうかの判断を短い間隔で行うような形にすればリスクも抑えられますし、私が「４．ウォータフォール型開発の問題点）で述べた問題と戦うより、このほうがずっと双方で幸せになれると思うからです。
##７．さいごに
「アジャイル最高だぜ！」という投稿になってしまいましたが、アジャイルだけではなく以下も重要です。
（これらはアジャイルと親和性が高いですし、ある規模以上の開発だと合わせて実施することは必然的です）
・テストやデプロイの自動化（CI/CD）
頻繁に発生する変更のたびに手動でのテストは非現実的です。また変更のハードルを下げるためにも必要です。
・マイクロサービス化
変更を行う際にシステムがモノリシック（一枚岩）な作りになっていると非常に修正が困難になります。
システムを疎な関係で適切に分割を行いAPIで連携する構成にします（マイクロサービス化）これによって個々のサービスの開発（変更、機能追加）が容易になります。
加えて、いわゆるDX案件では世の中の変化に素早く対応することが求められ、最初からゴールがわからない場合が多いです。
このような場合も上記のセットはとても有効かと思います。
###楽しいけどこれ仕事なのよね
私が言いたいことはシステム開発を最適化することによって、発生している（しているかもしれない）ムダに費やす時間をすべてお客様のうれしいこと（すばらしい価値を生み出すアプリケーション）に向けたいだけです。
キレイ事のようですが、これが実現されればお客様もエンジニアもハッピーになるはず！
（エンジニアって良い開発をして、お客様の喜ぶ姿を見れればもうなにもいらないですよね。
楽しければ良いという意味ではなくて、メンタルを最高に保てばその人のパフォーマンスも最大になり会社もハッピーなわけです）
###ぼくのかんがえたさいきょうの開発手法
さいごに、本投稿のタイトルですが
もし、なんの制約もなしにあなたが好きなように開発していいよ。と言われたら、私はアジャイルになると思っています。
それは「２．昔話し」~~(回想編)~~で、身を持って死にそうになりながら開発のあるべき姿を胸に刻み込んだからです。
だからスピリットはアジャイルなんです（無意識でも）
そして既存アジャイル開発手法をそのままでやるのではなくカスタマイズしたり自分の頭で考えて一番良い方法を探して試行錯誤して開発するのがいちばん最強なんだと思います。（＝アジャイルなんだけどね）
ということで本投稿のタイトルは、
「ぼくのかんがえたさいきょうの開発手法」
となったわけです。
ちゃんと書くと、こんなイメージです。
| 内容 | |
|---|---|
| 考え方 | アジャイルソフトウェア開発宣言のポリシーで |
| 開発手法 | スクラム＆XP。案件やメンバーに合わせていいところ取りで |
| 備考 | 新しいプラクティスを試しながら、効果のないものは排除 |
| （「13th annual State of Agile Report」の開発手法採用アンケートでほぼ答え出ていました。皆様考えることは一緒） |
勇者マネージャ LV45歳
※最近はレベルが上がるとステータスが下がります⤵
おまけ
こちらのイベント「DX Japan Meetup 2019/12/16 in Tokyo」でもほぼ同じ内容をLTで話させて頂きました。
（このアドベントカレンダーの投稿を先に書いたので、LTはほぼそれをパワポにしただけですが）
本日はこちらです。#DXJPhttps://t.co/BxBEEdNP7a
— そがとし / Toshiyuki Soga (@soga_toshi) December 16, 2019