ソフトウェア開発工程の区切りが見えない

ソフトウェア開発の場合、開発工程の区切りがよく見えないことがある。例えば、次のような工程（プロセス）の区切りを明確に見分ける方法は存在するだろうか？

1．ソフトウェア開発計画
2. ソフトウェア要求分析
3. ソフトウェアアーキテクチャ設計
4. ソフトウェアユニットの実装と検証
5. ソフトウェア結合
6. ソフトウェアシステム試験
7. ソフトウェアリリース

別にウォーターフローのプロセスじゃなくてもいい、インクリメンタルでも、ユニファイドプロセスでもなんでもいいが、どこが区切りかどうやって内外に示すのか？

電気回路の設計なら、プリント基板の完成や部品の実装という形で明確に一次試作や二次試作の工程のくぎりが見える。部品が実装され一通りのテストが終わったら「じゃあ、飲みに行こうか」と言える。

しかし、ソフトウェア開発の場合、工程の区切りが曖昧なので、「ソフトウェア開発計画が完成したから一区切りついた」とか、「ソフトウェア要求仕様ができあがったので飲みに行こう」という感じにはなかなかならない。ソフトウェア開発の工程で区切りが明確に分かるのはソフトウェアをリリースするときだけなのだろうか。

ソフトウェア開発の上流工程は特に少数の技術者、場合によってはひとりの技術者の作業に集約されてしまうことが多いから達成感や区切りが見えにくい。

ソフトウェア開発の工程の区切りを見るのに一番分かりやすいのが、アウトプットとなるドキュメントの完成だ。ソフトウェア開発計画工程のアウトプットとしてソフトウェア開発計画書、ソフトウェア要求分析工程のアウトプットとしてソフトウェア要求仕様書を作成する。これらのドキュメントが完成したことで工程の区切りを判断することができる。

ところが、これらのドキュメントで明確に分かるのは書類があるかないかであって、その工程内で実施すべきアクティビティがキチンと実施されたのかどうかはドキュメントの中身を精査したり、プロジェクトにインタビューしたりしないとわからない。電気設計のように「回路図がを出図した！」とか「実装されたプリント基板が動いた！」というほど工程が完了したというインパクトがない。

ソフトウェア開発の場合、悲しいかなドキュメントの中身をキチンとレビューできるレビューワーがいないと、各工程でやるべきことが実施されたかどうかも分からない。工程の区切りが明確でなく、工程のアウトプットドキュメントをきちんレビューできないと、結果としてぐだぐだになってしまりのない開発になる。

しまりがないというのは、計画通りにプロジェクトを進めるとか、ここから先は要求仕様の変更はしないとか、アーキテクチャは大幅に変更しないとかいった判断ができず、プロジェクトリーダーやプロジェクトメンバの個人的な判断、個人的な折衝力で、変更要求をはね返したり、プロジェクトの舵取りをしなければいけない状態のことだ。

ソフトウェアプロジェクトの内外から「ソフトウェアはいつでも変更できる」と見られていると、変更がソフトウェアシステムに与える影響を考えずに開発工程の後半であっても、プロジェクトは変更要求を受け入れてしまう。

複雑な仕事を成し遂げるには、当然のごとく最初の段取りをしっかりしておかないといけないが、開発工程の最初の方がぐだぐだのプロジェクトは開発の後工程で相当苦労する。

日本の組込みソフトウェア開発では、20年も30年も前は、もともと明確な「プロセス」を設定して、ひとつずつ前に進む仕事の進め方ではなく、試行錯誤でソフトウェアを作成し、プロトタイプを動かしてみて問題があったらすぐ直すという作り方をしてきてその進め方が体に染みついているので、にわかルールで開発プロセスが定めてもすぐに形骸化してぐだぐだの開発になりがちだ。

メインフレームのソフトウェア開発の世界では、ソフトウェアの規模と複雑性が限界を超えた時点で、試行錯誤的なやり方では開発が完了しないことがわかり、プロセスアプローチの重要性が認識された。

組込みソフトウェア開発の世界では、ソフトウェアの規模と複雑性が限界を超えていない開発が多いので、まだ、試行錯誤的なやり方では開発が完了しないという事態にまでは至っていないのではないだろうか。

そして、日本ではそんなぐだぐだな開発プロジェクトがたくさんあるはずなのになんだかんだいって製品はちゃんとリリースされていく。

おそらく、ギリギリのところで破綻していない理由は開発の前工程がぐだぐだでも、後工程で残業してがんばってなんとかつじつま合わせているのだと思う。表面的には破綻していないように見えて、プロジェクトメンバーの中には倒れている者もいるかもしれない。

このぐだぐだの先の見えない開発スタイルの流れはこのブログでも何度となく言っているように実際に開発に関わっている技術者が幸せになる目がない。毎回、前工程ぐだぐだで後工程でがんばるというやり方を繰り返していると、ソフトウェアの規模が増大し複雑化していくので、後工程でがんばる部分の負担がどんどん増えていく。

開発を重ねるたびに楽になっていくとか、クリエイティブなことを考える時間が増えるとかいった感じがしない。自分が不思議なのはこの悪循環な状況を改善したいと考える、もしくは、改善しなければ自分たちに明日はないと考える組込みソフトエンジニアが驚くほど少ないということだ。

なぜ、少ないのかはいろいろ理由があると思うが一番大きな理由は、このままではダメだと思っても状況を改善するには各方面に働きかけをしないといけない、人間系の壁を動かさないといけない、自分たちはソフトウェアを作るのは好きだけれど、人を動かすのは得意じゃないし面倒だと考えいるからではないだろうか。または、改善をして開発が楽になるというイメージを想像することができないのか。

自分が考える「開発を重ねるたびに楽になっていく開発」「クリエイティブなことを考える時間が増える開発」とは、その製品や製品群の価値が凝縮されているソフトウェア資産を明確にし、その資産の完成度を高めて再利用し、再利用資産を徐々に積み重ねていく開発だ。

これは一回の開発ではうまくいかない。何回か開発を重ねていくたびに徐々に楽になっていく。そして、再利用資産を抽出して隔離するときが一番時間も工数もかかる。だから、約三回の開発を経て効果がでることをプロジェクトの内外に説明して納得してもらう必要がある。

ぐだぐだの開発から抜け出せない理由は、複数の開発という長期レンジの視点を組織上位層もプロジェクトも持てていないのと、「最初は時間がかかるが、次かその次には開発効率とソフトウェア品質は確実に改善する」と宣言する自信とか気迫がないからだと思う。

組込みソフト開発の現状を打開するには、複数回の製品開発のプランとソフトウェア開発の技術の修得と変革を宣言して実行するリーダーシップのすべてが必要となる。