【ソフトウェア開発】システムの設計って何？

ひと口に「設計」と言っても､それが意味するところはさまざまです。

エンジニアのみなさんが、はじめてのお客さまの開発プロジェクトにアサインされて、設計工程から参加することになったとしましょう。上司に呼ばれ、たとえば

　「基本設計から軸むよ」

と言われたとき、はじめに確認すべきことは、

　「このプロジェクトの基本設計（の定義）って、なんですか？」

と言ってみることではないでしょうか。

言葉尻だけを見てしまうと、たんに「設計のことを何も知らない人」のように見えてしまいますが、じつはこれが非常に重要なポイントになることがあります。事実、私は若かりし頃、『私の中にある常識』とのギャップに混乱させられたことがあります。

ソフトウェア設計の場面では、「設計」とひとくちに言っても、その設計にまつわる用語として、企業やエンジニアによって

　「基本設計」「詳細設計」
　「外部哉計」「内部設計」
　「仕様設計」「方式設計」「アーキテクチャ設計」
　「概要設計」「機能設計」
　「概念設計」「論理設計」「物理設計」

などなど、さまざまな用語が飛び交うことがあります。これらの用語についての認識は、担当するプロジェクトによって様々です。業界として、国として、企業として、明確に定義づけしているものはありません。あっても形骸化しています。ひょっとすると、同じ企業内でも呼び方の違う人たちがたくさんいらっしゃるのではないでしょうか。

そしてその理由（言い訳）は「プロジェクトの特性によって、個々に変化するものだから」です。設計内容の具体的な部分が変化することはあっても、各工程の定義が個々のプロジェクトによって根底から覆されることなんてないはずなんですけどね。そんなことしたら、多重下請け構造は成立しなくなってしまいます。だって、下請けで活躍する人たちは、色んなSIerの現場に行くので、現場ごと、エンジニアごとに各工程、各設計の意味や意義が大きく異なっていると、行く先々で大きなスイッチングコストを費やしてしまい、期待されたパフォーマンスをあげることが困難になってしまいます。

そんなことをしていい現場があるとしたら、全く異なるアーキテクチャを導入する時だけです。

エンドユーザー直請けではなく、ベンダーからの下請けで開発するならば、こうした用語やその用語が示すスコープ、内容などが、元請けの会社によって異なる…といったことを経験することがあるでしょう。ですが、こうした基本的部分の定義がかみ合わないままにプロジェクトチームを組んでいても、混乱を招くばかりでエンジニア一人ひとりの生産性はなかなか向上しません。

もしも、「このプロジェクトにおける基本設計（の定義）って、なんですか？」と聞いたときに、マネージャーやリーダーから馬鹿馬鹿しい答えしか返してくれなかったとしたら、まず最初に考慮すべきポイントは

　この先に予想される混乱にどう対処するか

ということになるのではないでしょうか。このリスクを予測し、そして対処できなければ、人生において多くの時間を無駄に費やす（つまり、残業過多になって、ワークライフバランスを崩してしまう）ことになってしまいます。

これらの用語や意味（基準やルール）は、開発現場では

　「何を設計するか」

と言う"目的／対象についての意味"と、

　「プロジェクトのスケジュール上、いつ実施する作業か」

と言う"工程についての意味"の２つが混在して使われていることが多くありますので、なおさら関係者間の混迷の度合いは深まります。

プロジェクトとして"基本設計"と言う用語を共有した上でも、ある人は工程としての「基本設計」を指し、ある人は対象成果物として、たとえば「画面仕様設計」を指すと言う状況になっていたりすることも珍しくありません。

これらの用語の確定には、それぞれの背景として「開発プロセス」「開発モデル」「開発方法論」と言ったものがあります。大手メーカーやSIerでは、各社が自社独自のプロセスや方法論を定義します。わかりやすいところで、

　日立：HIPACE
　富士通：SDEM
　NTTデータ：TERASOLUNA

などが有名ですね。国内ＩＴサービス市場TOP3のSIer企業ですから、この業界に関わった人なら、どれか１つくらいは経験したことがあるかも知れません。メガベンチャーや外資系であれば、また違った方法、違った呼び方をとっているでしょう。もちろん、TOP3内でもプロジェクトやマネージャーによって、全く異なる方法をとっていたり、中には無法地帯のような進め方になっているプロジェクトも存在します。

ＩＰＡでは共通フレーム2013なんかも公開していますので、そちらを活用している企業もあるかもしれません。私もたまに参考にしています。

SEC BOOKS 共通フレーム2013：IPA 独立行政法人 情報処理推進機構

車載系の組込み開発なら、A-SPICE（Automotive SPICE）の規格をベースにした開発手法が取られていたりするのでしょうか。機能安全を含むなら、ISO 26262なんかの規格にも準拠していたりするかもしれませんね。

また、開発プロセス上の様々な作業をサポートするツールやフレームワークなどを提供するSIerが、ツールとセットで提供する商用の方法論などもあったりします。これらの提供する方法論では、たとえば

「"要件定義"完了後、最初の設計工程を"基本設計"工程と呼ぶ。
　"基本設計"工程で実施されるべき設計は、
　　・ハードウェア構成設計
　　・ミドルウェア構成設計
　　・ネットワーク方式設計
　　・サブシステム分割
　　・インターフェース定義
　である。ハードウェア設計では…」

と言ったように、工程とそこで設計される必要のある事項について、明確に定義していたりもします。ツールやフレームワークありきのものとなっているため、既存の考え方が通用しないケースも多々あり、こうした現場では一時的な混乱や品質低下を招くことも珍しくありません（パフォーマンス向上や品質向上が売り文句のはずなのに）。

このような背景から、プロジェクトに参画すると決まって、まず初めに取り掛かる際には、プロジェクトで採用している方法論を共有する（させてもらう）ことが、最重要となってきます。これができなければ、プロジェクトチームは各工程、各作業に対して同じ価値意識、同じ目標意識を共有できずに、正しく活動することができず、しばらくの間はただの烏合の衆でしかなくなってしまいます。

ある程度経過すると、徐々に慣れてくるのか、個々人が情報を整理して"なんとなく"・"経験則に従って"プロジェクトを回していくことになるのですが、この『ある程度』の期間の作業効率は非常に低く、そして長く、その歪みをプロジェクトの後半で一気に消化しなければならなくなるケースも珍しくありません（パーキンソンの第一法則的な）。

また、開発方法論やモデルがあらかじめ用意されていたとしても、それがプロジェクトにとって最適解であるかどうかは分かりません。大手SIerなどは盲目的に開発手法が固定化されてしまっていることが多く、プロジェクト特性ごとの見極めをしていないケースが散見されますので、逆にパフォーマンスが劣化したり、品質を損なう危険性をはらんでいる場合もあります。

　「なぜ、その方法論でよいのか？」

についても意味や意義を見出せなければ、やはり同じような問題が発生してしまうのです。これが、システム開発において

　常に稼働が高く、
　ワークライフバランスを維持できない

機会に多く出逢ってしまう根本的な要因です。具体的には、目的や意味に対して説明責任を持っているはずのリーダーやマネージャーがその責務を怠って、一方的に

　「そういうものだから」
　「今までこれでやってきたから」
　「上からの指示だから」

と他責化し、考えることを止め、『だからお前も言われたとおりにやれ』と押し付け、同じようにメンバーたちにも意味や目的について考えることを停止させることで、蔓延していってるのかもしれません。

一度、こうしたやり方を強制され、環境に慣れてしまった開発メンバーは、"考える"ことを続ける癖をもう一度身につけなおすのは至難となってしまい、中長期的にみると組織は停滞、退化し、その組織に属しているメンバーは徐々に疲弊していくことになります。よく言われる『派遣根性』の完成です。