システムの設計って何？を考える

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

まず最初に実際のプロジェクトの中で、設計を効果的に実践するための
ポイントを押さえておきましょう。

そもそも、「システム」と「ソフトウェア」はまったく異なるものです。…いえ、言い方を変えましょう。

　「システム」とは「ソフトウェア」を内包した、仕組み全ての総称

です。当然、ハードウェアやネットワークインフラ、ミドルウェアやその構成などすべてを組み合わせます。それがシステムです。システムはソフトウェア単品で成立しません。

ソフトウェアエンジニアのみなさんがはじめてのお客さまのシステム開発プロジェクトにアサインされて、仮に設計工程から参加することになったとします。

そしてマネージャーまたは上司に呼ばれ

　「基本設計から頼むよ」

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

　「基本設計（の定義）って、なんですか？」

です。こう言うとたんに設計のことを何も知らないように見えますが、じつはこれが非常に重要なポイントになることがあります。

ソフトウェア開発ではなくシステム開発における設計の場面では、その設計にまつわる用語として、

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

などなど、さまざまな用語が飛び交います。

これらの用語についての認識は企業や人によって様々です。エンドユーザー直請けではなく下請けで開発するならば、こうした用語が元請けの会社によって異なることを経験することでしょう。

ですが、残念なことにソフトウェアエンジニアやソフトウェアエンジニアあがりのリーダーやマネージャーは、ついつい『ソフトウェア開発』だけの設計をすればいいと思いがちです。

ですが「システムの設計」と言うのであれば

「仕組みやモノの流れを含むすべてのシステムが
　目的を果たすためにどのような構成・構造であるべきか」

が設計できていなければ話になりません。いわば開発の機会をくれた

　お客さまの目的を果たすための業務の仕組みそのものを設計する

ことが重要なのです。

要件定義は厳密には「設計」ではありません。あくまで要求を聞き、要件に落とし込むだけの工程です。当然、設計をする以上は設計工程でなくてはならないはずです。

「"モノをつくる"ための設計」ではなく
「"仕組みを編み出す"ための設計」が必要です。

その時にソフトウェアの力を借りる必要があるのであればソフトウェアを使えばいいし、既存のソフトウェアにそういった目的を果たせるものが無ければオーダーメイドと言う手段を用いればいい、と私は考えています。

ですが、多くのＩＴ企業では「オーダーメイドで発注する際には、すでにお客さまのなかで仕組みを編み出すための設計は既に済んでいるものとしてソフトウェア開発だけに焦点をあてようとします。

そこにＩＴトラブルの絶えない１つのポイントがあるのではないでしょうか。

コミュニケーション不足になりやすい環境

また、大規模なシステム開発プロジェクトであればソフトウェア開発チームだけでなく、インフラやハード調達に別チームがいて足並みを揃えつつそれぞれがそれぞれの領分を担当するのでしょうけど、それにしても彼らと情報の連携ができていなければまともなソフトウェアを作成することはできません。

実際、私がそこまでシステムに精通していなかった頃は、結合テストやシステムテストの段階になってインフラチームとのコミュニケーション不足が仇となり、本番環境でのテストが大きく遅れたこともありました。あるいは別のチームでは本番環境にソフトウェアを組み込んだ瞬間、動かなくなったという話を聞いたこともあります。

そして、こうした用語がかみ合わないままにプロジェクトチームを組んでいても、混乱を招くばかりで生産性は上がりません。最悪の場合、システムそのものが水泡に帰すことにもなりかねません。

もしも、

　「今プロジェクトの基本設計（の定義）って、なんですか？」
　「システムの設計は完了しているのですよね？」

と聞いたとき、マネージャーやリーダーが馬鹿馬鹿しい答えしか返してくれなかったとしたら、まず最初に考慮すべきポイントは

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

ということになります。たとえば料理のレシピなどをイメージしてみてください。レシピを書いた本人にしかわからない記述になっていて、それを読んだ人は正しく料理を作ることができるでしょうか？

当然、「マズいものをお客さまに出してしまう」あるいは「マズい料理を食べなければならなくなってしまう」リスクは事前に考慮できることですよね。そんなこともわからない人がマネージャーやリーダーをしている…人事・人選の方がよほど問題なのですが、こうしたトラブルは往々にしてよくあることです。

業界自体が整備されていないことが元凶

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

　「何を設計するか」

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

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

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

開発プロジェクトとして"基本設計"と言う用語を共有した上でも、

ある人は工程としての「基本設計」を指し
ある人はシステムとしての「構造設計」を指し
ある人は対象としてたとえば「画面仕様設計」を指す

と言う状況になっていたりすることも珍しくありません。
　
これらの用語には、それぞれの背景として「開発プロセス」「開発モデル」「開発方法論」と言ったものがあります。大手メーカーやSIer、ベンダーでは各社が自社独自のプロセスや方法論を定義していたりすることも珍しくありません。どうせ似たり寄ったりな方法論なのですが、バカバカしいくらい自社の独自性や差別化にご執心で、業界全体で協力し合おうなんて精神は微塵もありません。これほどまでにＩＴが社会インフラに根付いていると言うのにもかかわらず、他の業界…たとえば建築や医療、機械製造の業界ほど法的に整備がなされておらず、各企業、各エンジニアが好き勝手に開発しているのが現状です。

既に自ら開発は行わず、マネジメントしか行っていない大手SIerなどは

　「ちゃんとモノができてればそれでいいから」

みたいな姿勢の企業もあります。その"ちゃんと"が何を指しているかは、本人たちもわかっていないのかもしれませんが。

また、ＩＰＡや書籍などで公開されている方法論や開発プロセス上の様々な作業をサポートするツールなどを提供するベンダーが、ツールとセットで提供する商用の方法論などもあったりします。

これらの方法論では、たとえば

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

と言ったように、工程とそこで設計される必要のある事項について明確に定義しています。このため、設計にプロジェクトで採用している方法論を共有することがまず初めに大事となってきます。

これができなければプロジェクトチームは正しく機能せず、しばらくの間は様子見の段階となってただの烏合の衆でしかなくなってしまいます。決して教育の類は行いません。なぜなら受注開発のプロジェクトにおいて「予算」や「スケジュール」には開発のためのリソースしか設けられておらず、教育や育成に割く余裕を最初から用意していないからです。

しばらくすると徐々に慣れてくるのか、個々人が情報を整理して"なんとなく"・"経験則に従って"プロジェクトを回していくことになるのですが、この『しばらく』の間の作業効率は低く、その歪みをプロジェクトの後半で一気に消化しなければならなくなります。

また方法論があらかじめ用意されていたとしても、それがプロジェクトにとって最適解であるかどうかは分かりません。

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

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

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

機会が多く、３Ｋや７Ｋと言われる根本的な要因です。

具体的には、目的や意味に対する説明責任を持っているリーダーやマネージャー、あるいはリーダーやマネージャーを経て管理職や経営層になりあがった上司たちが自らの責務を怠って、一方的に

　「そういうもんだから」
　「今までこれでやってきたから」

だから『お前も言われたとおりにやれ』と押し付け、意味や目的について考えること／考えさせることを停止させてしまうことで蔓延します。一度こうしたやり方を強制され、環境に慣れてしまった開発メンバーは、"考えること"を続ける癖をつけなおすのは至難となってしまい、中長期的にみると組織は疲弊していくことになります。