アジャイル開発について今回は取り上げます。
アジャイル開発のひとつ「リーンソフトウェア開発」はトヨタ生産方式ときっても切りはなせないし、トヨタの問題解決のやりかたに源流をみることができます。
しかし、米国はそのほとんどがアジャイル開発といわれている一方で、日本がまだまだ適用が進まない理由と、その中でも適用するならこの部分という内容を示します。
自分もアジャイルを適用した開発は経験していますが、こうすれば始められるという方法も紹介しています。
日本ではアジャイルがなかなか適用されない理由とプロジェクトマネージャーの対策
日本ではアジャイルが広まらないない理由と適用するならどこか
・ＩＴ投資が米国に比較して少ない
・自社開発ではなく、外部での受託委託での開発が多い
・パッケージにあわすのではなく、オリジナルを開発
・国民性
・母国語が日本語
考えられる理由を５つ掲げましたが、こう書いてみて、どれも一筋縄ではいかない。
というか、プロジェクトマネージャーでどうこうする話ではない、という内容ですね。
実際、日本ではという視点にしたのでこうなってしまいましたが、それでも適用すれば効果があるところはあるのです。
・要件、仕様をユーザと検討するタイミング
・開発（コーディング）にはいって以降
・運用保守の機能改善
そもそもアジャイルそのものは、開発手法というよりは、長いことかけてシステム開発をするのではなくて、必要ないことはしないで効率的に開発をまわしましょう、ということなので、考え方はどんどん適用すればいいわけです。
最後に、「まずアジャイルをやってみるなら、こんな方法」というのも書いておきましたので、途中とばしても、最後の部分をお読みいただければと思います。
アジャイルソフトウェア宣言
アジャイル開発そのものは、2001年に、ウォーターフォールのような重厚な開発プロセスよりも、もっといい開発のやり方がないかと、個々に開発のやり方を試みていたメンバーが17人が集まって議論した結果、アジャイル開発宣言として世の中に出したのが始まりです。
アジャイルソフトウェア開発宣言
私たちは、ソフトウェア開発の実践
あるいは実践を手助けをする活動を通じて、
よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。
プロセスやツールよりも「個人と対話」を、
包括的なドキュメントよりも「動くソフトウェア」を、
契約交渉よりも「顧客との協調」を、
計画に従うことよりも「変化への対応」を、
価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。
アジャイルが広まらない理由
先ほど述べた日本でアジャイルが広まらない理由について詳しく見ていきます。
・ＩＴ投資が米国に比較して少ない
・自社開発ではなく、外部での受託委託での開発が多い
・パッケージにあわすのではなく、オリジナルを開発
まずこの３点については、事実は情報通信白書の数字が示しています（総務省：情報通信白書（令和元年）より引用）
さて、これがどうしてアジャイル適用が進まない理由になるのか？
新しい技術や開発導入にはその転換コストがかかるため、「ＩＴ投資」は関係してきます。
実際は、適用した方が効果があがる、という反論もあるかもしれませんが、予算がないとなかなか踏み切れないものだと思います。
・自社開発ではなく、外部での受託委託での開発が多い
・パッケージにあわすのではなく、オリジナルを開発
この２つは、アジャイルの特性にかかわります。
アジャイル開発は、最初にどれだけ開発するかの範囲は完全には決めきらず、リリースしながら改善点を利用者と調整して決めていきます。
外部委託は、契約で最初に範囲を決めてしまうので、途中で、追加機能が欲しくなったのに作ってくださいとか、いままで作っていたのを直した方が効果的だから対応したい、とかが難しいのです。
日本は自社開発がほとんどないので、契約的に厳しいということです。
さらに、パッケージを利用する場合は、カスタマイズのノウハウがあれば、パッケージという動くものに、徐々に追加機能をのせていくという流れができますが、新規開発の場合はそうもいきません。
最初に動くものができはじめるまでに一定の期間がかかってしまうので、アジャイル開発には向かない傾向があります。
・国民性
・母国語が日本語
最後の２つ。
不確実なものよりも確実にという日本人の国民性がアジャイルには適合しないといわれています。ただ、時代は変化のスピードが速くなっていますので、不確実かどうかは別として、素早く対応していくことは必要になってきますね。
更に、僕はドキュメントは必要なものはきちんと書かないとプロジェクトは失敗すると考えています。
というか、そんなプロジェクトは山のようにみてきたし、実際、アジャイルだ、プロトタイピングアプローチだ、生産性向上だ、とドキュメント削減を狙って失敗したプロジェクトをたくさん見てきました。
じゃぁ、なぜ母国語が日本語が、アジャイルと適合しない？
以下を見てください
――――
利用 印刷
整数 フラグ
フラグ ＝ ０
繰り返し 条件（フラグがゼロ）
・・・・
印刷処理
繰り返しここまで
――――
import print
integer flag
flag = 0
while (flag == 0)
・・・・
end while
――――
プログラミングは言語なのです。
ひとつ、ドキュメントが減りますね（笑）
もちろん、書き方次第だし、プログラミング言語を読み解くスキルが高ければ違いはないのかもしれませんが、平均的なエンジニアでは、差はでてしまいます。
アジャイルを適用することで効果があるもの
以下は実施してみて、アジャイル開発で効果を感じた部分です。
・運用保守の機能改善
・要件、仕様をユーザと検討するタイミング
・開発（コーディング）にはいって以降
まずは、「運用保守の機能改善」ですが、ここはいうまでもなく、そもそも改善を続けるのはアジャイル以外のなにものでもありません。
課題を出して、優先度を決めて改善していく。
お客様と改善の内容が順次調整できるのであれば、普通にアジャイルが適用されているという状態です。
あとは、本格的にアジャイルの開発手法であるスクラム等を導入するかどうかだと思います。
次に、「要件、仕様をユーザと検討するタイミング」です。
ウォーターフォールの問題の一つに、実際に利用者が使えるタイミングがプロジェクトの後半なので、ユーザテストで触りだしたら、思っていたのと違う！となってしまう、というのがあります。
アジャイルで操作性も含めて最初から見せながら進めると、そのあたりの認識の違いは減らすことができます。
この際、操作性まで含めてみてもらうことが大切で、開発のベースとなるツールは何を利用してもいいと思います。
エラー処理とかも必要最低限で問題ありません。
どんどん見せて、ユーザから意見をもらえば、それだけ良いシステムをつくることができます。
「開発（コーディング）にはいって以降」
コーディング以降とかいてますが、ある程度の作り方などのベースが決定して、他と独立している機能であれば、先に出してしまうというのは効果があります。
プロジェクトのオーナーに見せることで安心してもらえるし、ユーザーに確認いただくことで品質向上を狙うこともできます。
１点だけ注意点は、ユーザに見せることで要件がどんどん追加になると、プロジェクトが破綻するリスクになります。
ユーザと合意しながら、変更のルールはしっかり決めてマネジメントしておくことが重要になります。
まず、アジャイルをやってみるなら、こんな方法で
アジャイルをまずやってみるのなら、高価なツールの導入は不要です。
ホワイトボードと、付箋紙。それで十分です。
実際僕も、トヨタの開発で、アジャイルやるときはつかってました。
簡単にアジャイル開発を実施する方法
ホワイトボードを３つに区切って、やるべきこと（バックログ）、仕掛中、完了、にわけて、やることを書いた付箋紙の貼る場所を移動していくだけです。
やるべきことを最初に右にはっておく、空いた人がそれを一枚はがして、真ん中の仕掛中に貼る。完了したら、一番左の完了エリアに貼る。
これでもアジャイル的な開発を進めることができます。
アジャイル開発のニーズがあるなら、一度試してみてください。
今回はここまでです。
最後までお読みいただき、ありがとうございました。
