サマリ
想定読者：初学者の方、業務に興味がある方 / 想定時間：20分～25分程度
第13回目のテーマは、ガラッと変わり設計業務について取り上げます。
#1 V字モデルに沿って検討
皆さんは製品を試作してほしいと言われた際に、どのように考え、どのように作っていきますでしょうか。例えば、言われた内容（要件）が漏れていたり、この実装したボタン何に使うんだっけ？といった困りごとはないでしょうか？
開発する際の体系は各種整備されている中でも、特に私はV字モデルと言われる開発プロセスを利用して、上記のようなミスをできる限り軽減させるよう努めていましたので、今回はV字モデルからのご紹介になります。
さっそくですが、V字モデルとは、要求～要件～基本設計～詳細設計～実装～テストの順に、トレーサビリティを担保しつつ検討・確認する開発プロセスのことです。簡単な図を以下に載せます。（折角ですので、IPA（Information technology Promotion Agency, Japan）の図を拝借します）
ソフトウェア開発の標準プロセス、IPA/SEC、第二部（３）より、https://www.ipa.go.jp/archive/files/000004771.pdf
元々はソフトウェアの開発プロセスなのですが、考え方が汎用的でありソフトウェアに限らずどの開発にも適用できるため、活用しています。
まず図内の縦軸として、Ｖの字で上から下まで繋がっています。これは、上流からの結果は必ず下流に紐づいていることを意味しており、具体的には成果物（検討結果）は必ずトレーサビリティが担保されている状態になります。（実際の現場では、変更・修正した際の更新漏れで、途切れているケースが散見しますが…）
次に図内の横軸として、要求/要件/基本設計/詳細設計の検討に対して、１対1関係を持つテスト工程があると思います。（例：要件定義⇔運用テスト）これは、各設計プロセスで検討した結果（例えば動作）が、その要求をクリアしているかを、対比しているテストで確認することで、確認漏れはもちろんのこと、検討漏れを無くすプロセスになっています。
この両側面がしっかりと結びつくことで、一定の品質を担保した開発が実施できるようになります。
ソフトウェアに限定せず一般化した単語でのフェーズとそれぞれの業務概要に加え、実際に基板設計の場合にはどのようなことを実施しているかの具体例を以下にまとめますので参考にしてみてください。（※設計プロセス順に記載、かつ、確認・検証プロセスのテストフェーズをイタリックで表現しています）
| フェーズ | 業務概要 | 実例（基板設計時） |
|---|---|---|
| 要求分析 | 顧客の要求は何か、言語化していない（できていない）ところで何を欲しているかをヒアリングなどを通じて表面化させる | この装置はどのような動作をしてほしいのか、全体のサイズはどの程度が理想かなどのヒアリングを実施 |
| 要件定義 | ヒアリングを通じて得た要求や顧客が提示している要件定義書から、設計のベースとなる要件を定義して顧客と合意する。 もし、この時点で定まらない内容があれば、別途検討か別スコープにすることを顧客と合意する | この装置は①XX機能を有し、②電源投入後の立ち上がりはX秒以内、③サイズはXX以下など具体的な内容に落とし込む |
| 基本設計 | 要件を元に社内で検討し、一段階具体的な仕様として落とし込む。開発チームが複数いる場合には、この前に”システム設計”という複合的な検討フェーズを設けることもある | ①XX機能はXXのチップで実現、②電源はXXの構成で実現、③は筐体設計のチームに連携依頼 |
| 詳細設計 | 具体的な仕様を元に、周辺回路も含めた詳細な検討を実施する | ①XXチップの周辺回路としては、XXのクロック周波数を元にノイズ除去としては、、、など詳細に検討。その後、回路図やパターン設計などに落とし込む |
| 実装 | 実際に構築する | 基板製造会社に依頼して基板を作成（ソフトウェアならばコードを実装する業務に相当） |
| 単体テスト | 詳細設計で定めた仕様通りに動作するかを確認する | ショートしていないかの導通チェック後、電源回路から仕様通りに動くかを段階的に確認。問題なければ徐々に基板内部に電源を供給して確認 |
| 結合テスト | 基本設計で定めた仕様通りに動作するかを確認する | チップ間で情報連携している箇所について、I/Fの動作が正しいか、仕様通りにチップ間で情報連携できているかを確認 （なお、これ以降チップにソフトウェア書き込みが必要なため、ソフトウェア部隊と連携して確認となる） |
| 総合テスト | 要件定義で定めた要件通りに動作するかを確認する | 全体の基板として所望の要件通りに動作しているかを確認 |
| 顧客前レビュー | 要求に対する妥当性の検証を顧客の前で実施する。この合格を以って納品となる | 顧客前で実際に触ってもらい、操作感含めて問題ないか確認 |
#2 都度レビューを実施することで品質を高める
実はV字モデルの通りに検討を進めているだけでは品質が十分担保されるとは言い難いです。そこで、ISO9001では、各フェーズゲートを通過する際にDR（デザインレビュー）を設け、そこで有識者からのレビューを受けることで、客観的な立場からの意見を反映させることが品質を高める手段として挙げられています。
このDRはフェーズ（プロセス）を進めるためのフェーズゲートであり、実施しなければ次のプロセスには進行できないほどの効力を持たせることで、品質を一定のレベルまで担保させる仕組みになっています。
そのDRでは実際に何をしているかというと、設計者が設計結果（＋エビデンス）を提示し、それに対し有識者が様々な視点から質問することで、質問に耐えうる設計になっているかを確認されます。例えば、要件に合致しているか、なぜその設計にしたのか、制約はなにか、規格に準拠しているかなどの質問を浴びます。
これが結構きつく、右も左もわからない新人時代には、毎回尋問のように問い詰められ、このDRを受けることが怖くなり、疲弊しながらも指摘事項を修正するといった内容を経て、徐々に一人前になっていきます。事実、しっかりと指摘事項を反芻して学んでいくと、徐々に指摘事項も少なくなり、結果的に品質の高い成果物を最初からアウトプットできるようになりますので、振り返ればよかったと思っています。（ただし、あの状況には戻りたくないですね…）
上記より、組織としてもレビューできる人材をそろえることが品質の面でも育成の面でも重要になります。顧客の背景を熟知している方や、規格に強い方、品質に責任を持つ方、技術を知り尽くす化け物などなど、個性的なメンツが集まった方がよりよいレビューの場を設定できます。
こうして組織としての好循環を生み出すサイクルを作る点では良いのですが、注意点としては、上記のレビュー人材が少ないと、その方がレビューに出ずっぱりになり、元々の業務に負担が生じることがあるため、そこは組織としてサポートが必要な部分になります。
そうこうして、DR時もそうですが、通常の検討途中でも設計修正の必要を感じた際には、都度上流にフィードバックを重ねて検討の方向性を修正。そして再度手元に反映させるといったプロセスを何度も回すことで品質を高めていくことが重要になります。
#3 どの開発PJでも共通に利用可能
ここまで記載したプロセスと考え方は、どの開発プロジェクトでも応用可能なほど汎用性の高いものになっています。この進め方を念頭に置き、実際にスタートする際には、設計の難易度やレビュー時間などを加味してタスク設計を実施し、スケジュールに落とし込んでいきます。この際の難易度や、各フェーズをV字モデルに当てはめる粒度がプロジェクトごとに変化があるだけで、基本的な考え方は変わりません。
ここで重要なのは、必ずIPO（Input/Process/Output）を意識することです。各タスクにおいて、どんな目的があり、どんなインプットが必要か（前段から何を受け取る必要があるか）、そのタスクはどんなプロセス（検討作業）を経て、どんなアウトプットを出すのか（後段に渡すのか）。ここが曖昧だと予定していた日程よりも遅延するリスクが高くなります。また、事前にタスクをしっかりと設計できていれば、何かの拍子にタスクの遅延が発生した際に、影響分析による判断が早くなり、損害を軽微で抑えることが可能になります。
開発フェーズの詳細や、実際の進行に当たるプロジェクトマネジメントは様々な視点から実施されるのですが、細かくなるのでまた別の機会に触れられればと思います。