僕がアジャイルに興味を持ったのは10年ほど前でした。
受注後、どんどん変わっていくお客様の要求に何とか対応できる方法が無いかを検討したのが最初です。
しかしながら予め成果物を決める請負契約とは全くマッチせず、
要求詰め放題プランになってしまいました。
今、転職し契約に縛られない働き方ができるようになりました。
改めてアジャイルについて考えてみます。
DXにおいてアジャイルは肝になると考えています。
アジャイル開発の大きな特徴は「アジャイルソフトウェア開発宣言(Manifesto for Agile Software Development)」によく表れています。
この宣言は2001年、ケント・ベック(Kent Beck)らが決起人となって結成したアジャイル同盟です。
有名な宣言ですのでご参考まで。
アジャイルマニフェスト
私たちは、ソフトウェア開発の実践あるいは実践を手助けをする活動を通じて、よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、価値とする。
すなわち、左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。また、アジャイル宣言の背後にある原則がそそります。
私たちは以下の原則に従う:
顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。
要求の変更はたとえ開発の後期であっても歓迎します。
変化を味方につけることによって、お客様の競争力を引き上げます。
動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。
ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。
意欲に満ちた人々を集めてプロジェクトを構成します。
環境と支援を与え仕事が無事終わるまで彼らを信頼します。
情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。
動くソフトウェアこそが進捗の最も重要な尺度です。
アジャイル･プロセスは持続可能な開発を促進します。
一定のペースを継続的に維持できるようにしなければなりません。
技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。
シンプルさ（ムダなく作れる量を最大限にすること）が本質です。
最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。
チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。要求の変更はたとえ開発の後期であっても歓迎します。
しびれますね。
アジャイル開発を名乗りながらこの原則に抵抗を感じた人はご愁傷様です。
おそらくただのウォーターフォールモデルかインクリメンタルモデルです。
ペアプログラミングやテスト駆動開発といった手法をそう呼んでいるのか
Q&Aで細かくお客様の要望を聞くことをそう言っているのか
はたまたとりあえずコーディングから入ることをそう呼んでいるのか。
請負契約は成果物を予め定義し
それに対して見積金額を提示し契約となります。
先に成果物と金額を決めてしまうため
契約した以上はいらなくても作ってもらおうとするでしょうし、
シンプルさ（ムダなく作れる量を最大限にすること）が本質です。
と矛盾します。
追加開発や追加費用を許容する開発スタイルは
費用の総額が発注者側に見えないため契約として成立しにくいです。
何より手戻りを嫌う請負プログラマーや計画が命の意識高い系SEに
計画に従うことよりも変化への対応を、価値とするが受け入れられるのでしょうか。
だいぶ古いネタですが、以下なんて面白いです。
これで笑っちゃう僕はウォーターフォール型の人間です。
要求仕様はプログラム完成後に完結する。
基本仕様は完成品を顧客が見てから決定される。
詳細仕様は使用者がプログラムを動かしてから固まる。
仕様確定がどんなに遅れても納期は変わらない。これを「納期不変の法則」という。
開発スケジュールは小学生でもできる算数を無視して作られる。
顧客は水と仕様追加はタダだと思ってる。
定時に職場を出ると、仕事が増える。
バグは夜更け過ぎに仕様に変わるだろう。方法論で議論し始めたらそれまで信じてきたやり方の否定になりますので収集がつきません。
ただの宗教戦争です。小気味の良い言い争いも先人にお任せします。
「伝統的な方法論者とは、ビジネスのニーズを満たす実際のシステムよりも、非の打ちどころのないドキュメントをつくる、革新ぎらいの連中である」
「軽量または”アジャイル”な方法論者は、おもちゃを拡張して企業で利用するソフトウェアをつくり、驚かせようとしているハッカーたちを、過度にほめる連中だ」
[The Great Methodologies Debbate : Part2]
伝統的な開発モデルが良いか
アジャイルが良いか
そんなことは自分の環境で選べばよいと思います。
内製開発＋DXは、案外アジャイルと相性がよさそうです。
アジャイルについて深く知りたくなるきっかけになれば幸いです。
DXの設計書㉕ – アジャイル方法論
おわり
コメントを残す