高まる「コードファースト」への期待、そこに落とし穴はないのか：AUTOSARを使いこなす（39）（2/3 ページ）

[櫻井剛，MONOist]

コードファーストアプローチについて考えてみる

　Automotive SPICEや自動車機能安全規格ISO 26262への対応などで、ソフトウェア開発の「手間」がかかるとお感じの方も少なくないでしょう。

　LinkedIn上の投稿などでも、しばしばその不満を見かけますし、「コードファースト／Code First」アプローチへの期待の大きさも感じます。AUTOSAR Common Adaptive Platform Implementation（CAPI）のWebサイトでも「code-first initiative」を取り入れることが明言されています。

　この「コードファースト」という言葉、単なる流行語、バズワードとして捉えるべきなのでしょうか？

　今回は、実際の開発にどのような影響が及ぶのか、具体的には、どんなメリットやリスクがあるのか、少し掘り下げてみたいと思います。

　そもそもコードファーストとはどういうものなのでしょうか。

　「コードを先に書く」と、文字通り解釈しただけでは「ああ、そう」でしかありません。

　このような場合により理解を深めようとするのであれば、一般的に以下のようなアプローチが取られるかと思います（ごく一部の例です）。

• 目的論アプローチ：なぜそうするのか？　何がしたいからそうするのか？
• 対照的アプローチ：対極にあるものとの対比（例えば、「Design First」や「Specification First」など）

　実際にやってみると、少なくとも、こんな要素が見えてきました。

• （1）標準化の議論なんかよりも、さっさと動くコードを作りたい
• （2）動くコードによって、要件とその設計が実現可能であることを、いち早く確認したい
• （3）動くコードによって、要件がその基となった要求を適切かつ効率的にかなえていることを、いち早く確認したい
• （4）ソフトウェア開発者に、コード開発に専念させたい（コード開発以外の「やりたくないこと」をさせない）
• （5）全てをコードの形で表現したい

（1）標準化での議論なんかよりも、さっさと動くコードを作りたい

　標準化活動には合意が不可欠です。そして、合意に行き着くまでには、以下のような理由から時間がかかります。

• 問題／課題を理解するための準備期間：議論に参加できるようになるまでの期間（過去の議論内容の把握も含む）
• さまざまな選択肢からの選択：選択肢を複数開発する上、時には各選択肢が実現可能であるかどうかも定かではなく、実現可能性の検討が必要（その検討自体が議論を通じて行われる場合も）
• 時には、細かな実装レベルの議論にまで発展

　確かに、コードファーストで進めることで、開発スピードが向上し、プロトタイピングによる早期フィードバックが得られるなどの利点もある上、上記のような負担を軽減できる可能性があります。

　しかし、標準化での議論は、実際には「開発活動」の要素も多分に含んでいます。

　先に示した「無駄になり得る点」を省略することで、「開発活動」において重要な何かを見落としてしまう可能性はないでしょうか？

　ということで、次にプロセス観点を検討してみました。

（2）動くコードによって、要件とその設計が実現可能であることを、いち早く確認したい

　動くコードで、いち早く実現可能性について「検証／verification」をやってしまいたい、ということになるかと思います。

　ただ、実現可能性について細かく見ていくと、例えばISO/IEC 25000シリーズ^※2）で示されているような多様な品質特性があります。

　また、Automotive SPICEやISO 26262などで示された論理的な作業の流れの観点（図2および図3）からすると、以下のような弱点が見えてきます。

※2）主なものはJIS化されていますので、JISCのJIS検索サービスで閲覧可能です（JIS X25010など）。

a）以下の成果物の品質の面

• 要件定義：要件が検証可能なのか（合格条件を示せるのかも含めて）、検証しやすいか
• アーキテクチャ設計：後のインテグレーションに無理が生じないか（インテグレーション時の検証が可能なのか）※システムレベル／ソフトウェアレベルともに
• 詳細設計：まちまちの実現方法になってしまい各種リソース面（実行時間なども含む）の効率が悪くなったり、テストケース数の爆発、保守性低下などが起きてしまったりしないか

図1　システムレベルのV字［クリックで拡大］ 出所：長岡技術科学大学大学院で2024〜2025年に筆者が担当した「安全・情報セキュリティ特論2」講義資料より

図2　ソフトウェアレベルのV字［クリックで拡大］ 出所：長岡技術科学大学大学院で2024〜2025年に筆者が担当した「安全・情報セキュリティ特論2」講義資料より

b）以下の活動における品質への影響

• 競合解決（矛盾やトレードオフ解決など）：工学／開発は、競合解決を含む意思決定の連続です。そして、各所で行われる競合解決に一貫性がなかったら、インテグレーション時に新たな競合が生じる可能性があります。結果は「手痛い手戻り」です
• 開発全般での「意図」の表現：コードが意図の全てを表しているのだとしたら、コードからリバースで起こした設計書は「意図通り」ということになります。コードと設計書の突き合わせ検証では、「意図の誤り」については当然検証できませんし、意図の誤りを他の人やツールなどに見つけてもらおうとするなら、その意図（コード表現に全て反映されているとは限りません）を何か別の形で表現／伝達する必要があります
• 開発全般での実現可能性：ボトムアップで開発したものを組み合わせていって、初めて実現可能性がないことが分かることもあります（例：上位要件の達成に必要な下位要件を満たす要素が足りない、下位要件群が矛盾する……etc.）
• 各種バリアントへの対応：まちまちの実現方法になってしまい各種リソース面（実行時間なども含む）の効率が悪くなったり、テストケース数の爆発が起きてしまったりしないか