最近の開発はアジャイルが流行ってるんだよね？
組み込みではアジャイル開発ってやるの？
こうした悩みを解決します。
※筆者はウォーターフォール開発しかやってきたことないので、アジャイルの進め方を理解できぬまま取り組んだ可能性もあるので、参考意見として読んでいただければと思います
アジャイル開発、ただただきつかった…
業務委託で組み込みの案件を受けた時に、 アジャイル開発で進めるプロジェクトがありました。
・突然の仕様の追加修正によってソースコードは汚い
・とりあえず動くだけでどこにバグが潜んでてもおかしくない…
こういう開発の進め方をするといつか破綻すると感じました。
一言で言うと品質が担保できない手法ではないかと…。
プログラムを作るにあたっては初期の設計が非常に大事で、できる限り汎用的な形で柔軟に対応できる状態を保って開発を進めるべきだと思います。
けどアジャイル開発では これは難しいですね、本記事では アジャイルで組込開発をやって感じたことを話していきます。
組み込み現場のイメージが分からないからアジャイルって言われてもなあ…
という方はこちらをどうぞ⇒現場がわかる組込みソフトウェア開発
アジャイルで進めざるを得ない現実
アジャイルきつい！ウォーターフォール開発（←後述します）にして！と言うのは簡単です。
実際、皆ウォーターフォールを望んでいるでしょう、その方が皆ハッピーだし。
けどお客様都合や使用シーンに合わせこみたい場合、小さく区切ってアウトプットを出すアジャイル開発にならざるを得ない現実も分かります。
現物がないと何かと判断しづらいんですよ、組み込みって。
だからどうしても一発目の開発はアジャイルになっちゃうんですよね。
開発アプローチ方法
アジャイル開発とウォーターフォール開発があり、いずれもソフトウェア開発プロセスのアプローチです。
ウォーターフォール開発は予め作る物を決めた上で一つずつ順番に作業を進める手法で、アジャイル開発は柔軟に進めながら、顧客とのコミュニケーションや改善を重視する手法と言えます。
ウォーターフォール開発
ウォーターフォール開発は、ソフトウェアを作るときに手順を踏んで進める方法です。
まず作るものがあって、それを実現するためのハードウェア・ソフトウェアの要件を決めて、それから設計に取り掛かります。
設計着手の時点で全体スケジュールは決まっていて、要所要所で有識者レビューや評価試験を行って、スケジュールの進捗に遅れが出てないか、確認して進めていきます。
だから、設計途中の仕様変更はありません。これが許されると開発だけでなくスケジュールや製品の販売見込みに影響が出ます。
組み込み開発はウォーターフォール型で進めていくのが一般的です。
アジャイル開発
一方、アジャイル開発は小さな部分から作り始めて徐々に改善していく方法です。
作業は短い期間で区切られており、その期間ごとに小さな成果物を作って進めます。この成果物を使って、次の作業を進めるか、改善するかを都度決めていきます。
柔軟性が高いのが特長で、作業の進捗や要望に合わせて改善できるのが利点です。
とりあえずスタートして考えたい場合や、全く新規の試作品作りとかには向いています。
もっと深堀して、アジャイル開発は何が良いのか、こちらで理解しましょう。
組織を芯からアジャイルにする
仕様が未確定という恐怖
アジャイル開発はその時々で柔軟に対応するという進め方なので仕様がいつまでたっても確定しないです
仕様が変わるということは、それに伴ってソフトウェアも影響を受けるということを意味しています。
全く想定していない機能の実装を求められて、 既存のコードに影響を及ぼすこともあります。
できる限り汎用的な形でプログラムを作ることを意識してはいますけど、完成品が見えてる状態とそうでない場合とでは考慮できる点が変わってくるのは事実です。
都度追加・変更分をコードに反映していくのでどこにバグがあってもおかしくないなっていうのが正直なところです。
最終的には動くものの、ちゃんとバグ取りをして高品質な設計になることは少ないのではないでしょうか。
組み込みはウォーターフォールで
組み込みの開発は、試作品でない限りウォーターフォールがよいかなと思います。
例えばこれから メーカーで組み込みエンジニアやりたいという人は、面接や起業説明のときに
どういう開発プロセスで進めてますか、アジャイルですか？
と聞いてみてもよいでしょう。
業務委託で組み込みを引き受けようとしている人も、 先方に対してアジャイルかどうかは確認しておいた方が良いと思います。
本当にアジャイルで開発すると仕様が見えないので時間が経つにつれ中の動作が複雑化してきますし、 バグを作り込む匂いがプンプンします。
まとめ
アジャイル開発よりウォーターフォールの進め方をする開発に携わった方が精神の健康を保てます
あわせて読みたい：
システム開発をより速く確実に 本当に使える開発プロセス
コメント