世界では、アジャイル開発で開発が進められています。
今でも日本で主流なのが、ウオーターフォール型の開発です。
ですから、日本のITのサービスで世界中で使われているものがほとんど無いのです。
あらかじめ、すべて決めた上で開発をすすめていても、１年後には古くなっている、
トレンドが変わっている、競合が出てきているということはよくあることです。
ウオーターフォール型だと、一度決めた要件定義は変更が効かないことが多いです。
契約して企画して、要件定義をして、外部設計、内部設計、実装、テスト、納品の流れをとります。
ここの最大の問題は、依頼主は、業務には通じているけれど、ソフトウエア開発において素人だと言うことです。
そして要件定義書という書面を見せられても、実際にどんなものが動くのかイメージできないことにあります。
できたものは、イメージしたものとは違います。これでは業務に支障がある。
といっても、しかし、契約書があり、要件定義書があります。
それを見た上で契約されましたよねと、開発会社は言います。
それで、トラブルになります。
それに対して、アジャイル開発は、予測できない変更がからなずある！とうところから入っています。
では、変更があるなら、どうすればいいか？
なるべく早めに、動くものを依頼主に見せるということです。
そのため、動くものを早く作る。そこで仕様変更が入ることを想定して、柔軟に作るということをします。
DB設計などは、変更によってはすべてやり直しになるので、注意が必要ですね。
そのため私達は、NoSQlのDBを利用を進めています。
DB設計の変更が容易だからです。
そのアジャイル開発の中でもスクラムという開発方法があります。
これはラグビーのスクラムのように、みんなが密になって働くということです。
チーム内コミニケーションを密に取ります。
毎日必ず、15分程度のミーティングをします。
依頼主とは2週間に1回からなず、面談の時間をとります。
スクラムには3つの役割があります。
製品の総責任者、クライアントがなります。
毎週打ち合わせをして、その時点までで動いているものをみてもらいます。
動作の確認をします。
業務に支障がないか?何のためにその機能が必要か？
最後に完成したものを見るのではなく、その作る過程において見ていますので、
まるで開発に参加しているかのようです。
チームをまとめ、組織間のまとめをします。けれども一緒に開発もします。
ここは日本人が入りますので、プロダクトオーナーとも日本語で会議します。
ご安心ください。
開発チームはラグビーのスポーツのように常に一緒に動いています。
主に英語でやり取りします。
今ではツールもあり、何よりもソースコードをみれば何をしたいのかがわかります。
メンバーは協力して同じゴールを目指します。
俺はフロントだから、バックサイドは知らないではいけません。
必要な変更は、互いに譲りながら目的を目指します。
ウオーターフォール型で開発しているとこうは行きません。
辞書のような、分厚い書類があり、要件定義書にあらかじめ決められた仕様が記載してあるので、間違っていたとしても
そのとおりに作らないといけません。
非効率この上ないと思います。
また要望があれば、御社のスタッフを開発メンバーに加えることも可能です。
OJT(on the job training)で、確実に力をつけることが可能です。
ただ、アジャイル開発にもドキュメントがあります。
そして、仕様書というのはとても大切です。
しかし、ウオーターフォール型とは違い、柔軟性を持つものとなっています。
最低限の大枠しか決めていないからです。
環境、画面設計等です。
それにすら変更が入ることもありますが、、
それについては次回説明いたします。
次回は、アジャイル開発の工程について説明したいと思います。
