システム開発は長年、計画された一定の期間を上流工程から下流工程へ不可逆的に進んでいくウォーターフォール型での開発が主流でしたし、今も主流だと思います。しかし、”不可逆的に進んでいく” というウォーターフォール型モデルは、途中変更が容易でないという問題点を抱えており、変化の早い昨今のビジネス環境では何かと「古臭くて使えないモデル」というレッテル張りがされてるようですね。
そこでウォーターフォールに代わる新しいモデルとして提唱されてきたのが、変化に強い（といわれている）アジャイル型であります。
アジャイルソフトウェア開発宣言
アジャイル型開発のベースとなる考え方に「アジャイルソフトウェア開発宣言」がありそれはます。（出典：https://www.ipa.go.jp/files/000065601.pdf）
-<アジャイルソフトウェア開発宣言>———
私たちは、ソフトウェア開発の実践あるいは実践を手助けをする活動を通じて、よりよい開発方法を見つけだそうとしている。この活動を通して、私たちは以下の価値に至った。
・プロセスやツールよりも個人と対話を、
・包括的なドキュメントよりも動くソフトウェアを、
・契約交渉よりも顧客との協調を、
・計画に従うことよりも変化への対応を、
価値とする。すなわち、左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。
—————————————————
また、当宣言の背後にある原則として以下の12項目が挙げされています。（出典：同上）
原則01:顧客の満足を求め続ける
原則02:要求の本質を見抜き、変更を前向きに
原則03:成果物を2-3週間で、リリースし続ける
原則04:全員で共通の目標に向かおう
原則05:人の意欲は信頼から
原則06:ミュニケーションは直接対話で
原則07:進捗も品質も現物で
原則08:一定のペースでプロジェクトにリズムを
原則09:よい技術、よい設計、よい品質の追求
原則10:ムダ＝価値を生まない、を探してヤメる
原則11:よいモノはよいチームから
原則12:自分たちのやり方を毎週、調整する
アジャイルの実体
私が最初にこの内容を見た時の感想は「全部あたりまえの事だし、特に真新しい事なんかないじゃん」ということでした。
そもそも自社オリジナルの大規模システムを素早く、しかも柔軟に開発できるなんて魔法の方法はこの世に存在しません。もし素早くシステムを構築したいなら可能な限り「出来合い」のシステムを活用する方が安全かつ確実です。どうしても出来合いのシステムでは自社のビジネスモデルに合わないのであれば、とりあえず最低限の機能をウォーターフォール型で開発/リリースした後、システム保守を行うチームを構築して優先順位に応じたシステム更改を継続的にやっていくという方法を採るべきです。（ほーら、アジャイルっぽくなってきたでしょ？(笑)
効率的にシステム保守を行うために必要な物は、お客様のビジネスおよび対象システムに精通したメンバーを継続的に確保し続けるという対応です。具体的には保守チームのメンバー全員が年間を通して適度な仕事量となるように、システムに対する改善要望を上手くスケジューリングするといった、チーム保持に必要なアクションを実施する必要があります。また、この実現にはこれら「保守チームの適切な運営に必要なことを」をお客様にもご理解／ご納得いただく必要がありますし、逆に ”できる” お客様ご担当者は、保守チームの長期的な運営に配慮しており、保守チームマネジャと「長期的な計画を常に共有する」ことを常に意識しています。
少なくとも、欲しいシステム/やってほしい改善が顕在化したタイミングで、急遽集めた開発チームに「アジャイルでやって」といっても上手くいくはずなど絶対にないのです。
コメント