新人技術者のためのロジカル・シンキング入門（5） ―― ソース・コード規約の作り方

【4】「工程」というものの考えかた

　以上，「設計工程での検討もれは規約では救えない」，「規約は設計方針と調和させること」という二つのポイントについて解説しました．

　実のところ，これら二つは独立した方針というよりはむしろ互いに補い合うものです．なぜなら両者は，各工程の成果物をどのように定義し，期日を定めるかという，ソフトウェア開発管理においてもっともかなめとなる事がらに密接にかかわってくるからです．

　工程ごとにその趣旨と成果物をよく検討することはたいせつです（図11）．このことは，いわゆる教科書的なウォータフォール・モデルを採用しないような開発であっても変わることはありません．

図11　工程には調和と独立性が求められる
教科書的なウォータフォール・モデルを採用しない場合であっても，開発チームを率いる人は，各工程の趣旨とその成果物を入念に考えておく必要がある．そのうえで各工程を調和させることもたいせつ．

　ただし，教科書的なウォータフォール・モデルにとらわれると見落としがちになるのが，「工程間の調和」という観点です．

　教科書の中ならいざしらず，実際の組み込みシステムの開発の場面で「いかに実装するか」をまったく考えずに「何を作るか」を考えることはありません．実際にコーディングを始めないと問題点に気づかない，というのでは何のために設計工程があったのかわからなくなってしまいます．

　組み込みシステムはハードウェア・リソースに強い制約があります．したがって，「いかに実装するか」をまったく考えずに「何を作るか」だけ考えてしまえば，実装不可能な仕様を定めてしまったことに後から気づくことにもなりかねません．仕様として定められた機能がいかに魅力的でも，現状のハードウェアで実装できないものであればアウトです．

　したがって，ウォータフォール・モデルの基本的な考えかたとされる「whatを考えてからhowを考える」というのは，机上の空論であると少なくとも筆者は考えます．つねに後工程での作業も視野に入れながら，あらかじめ問題点を先取りし，一つ一つの工程における作業内容を確定できることが管理者に求められる資質といえるでしょう．

● 外部変数は最小限に絞り込んで

　最後に，外部変数の使用について少し補足しておきます．

　外部変数については，連載第2回でなぜそれが必要なのかを検討しました．また，データ構造の例としてはリードのみの外部変数であるテーブル以外を禁止してしまうやりかたを解説しました．

　本稿では逆に，外部変数をとくに禁止しない手法を解説しています．しかしそうはいっても，外部変数がむやみやたらと使われるのはあまり望ましいことではありません．「必要性を吟味して，必要最小限のものに絞り込むことが望ましい」と考えられます．数が少なければ，頭に入れたうえでソース・コードをメンテナンスできるので，弊害が大きくなることはないと思われるからです．

　外部変数の採用方針はコーディング規約の中で定める事がらです．しかし，外部変数を使うかどうか，また使うのであればどの程度なのかという問題は，実のところデータ構造をいかに定めるかという設計工程における検討と密接にかかわってきます．

　繰り返しになりますが，外部変数については，設計工程とよく調和する形で管理方針を定め，必要最小限のものに絞り込むことが望ましいと思います．

さえき・はじめ