ソフト開発と人間の思考

いろいろな人と仕事をすると、ドキュメントを書くのが苦手な人がいたり、作業をうまく進められない人がいたり、何かしら苦手な分野を持っている人が多い。得てして私もいたるところに欠点があってよく失敗もするわけだか、欠点はある程度は、物事の進め方でカバーできることが多い。

ちょっと、ソフト開発の工程に目を向けてみる。ソフト開発には大きく７つの工程がある。ソフト開発を行う者にとって基本中の基本ともいえる考え方だ。

非常に簡単だが、ちょっと図を書いてみた。

ご存じのように、ソフト開発では定番の流れで、これはソフト開発だけでなく、多くの分野でも行われる工程だ。

全体設計または概要設計で、開発するシステムの全体的な方向性、目的、収容すべき機能的要件等を網羅する。これによって、開発物が何であるかが明確になる。

機能設計では、全体設計で行った設計書に基づき、それらを機能的に分割したり、システム的に必要な機能を洗い出すなどして、複数の機能に分割し、それらを結びつける。この結果は全体設計書に書かれている内容に沿っていなくてはならない。

機能が洗い出されれば、それぞれの機能の実装方法等を洗い出し、機能の詳細について定義し、ソフトウエアや処理の流れを定義する。

コーディングは、機能設計に基づき実装する。

ここまでくれば、システムは動くはずであるが、職業としてソフト開発をするものは、ここで完成とはできない。開発したものが正しく動くかどうかを確認する試験工程へと突入する。

試験工程は、おおむね設計工程と対となっている。詳細設計にあることを確認するのが詳細試験、機能設計書にあることを確認することが機能試験、そして全体設計書にあることを試験するのが全体試験である。ここで重要なのは、全体試験だけ行っての試験にならないということだ。設計工程を見てわかるように、ソフトウエアというのは、いくつかの工程によって開発され、それぞれ見ているところが異なる。つまり、その視点にたった試験をそれぞれお行わなくては、間違いの訂正・正しさの確認はできないということになる。

この工程にそってソフトウエアを開発すれば、少なくとも全体設計書に則ったシステムは完成するはずだが、そうもいかない。うまくいかないシステム開発の現場を見ると大体以下のことが行われている。

1. 設計書がない、または、設計工程を省略している。
2. 試験を十分にしていない、または試験工程を省略している。
3. 設計書・試験計画書がメンテナンスされていない。

設計書がないのは、そもそもシステム開発を放棄しているように思えるが、省略しているケースはよくある。一番多いのが詳細設計の工程だ。開発に使用する開発言語が高級化し、PerlやRuby、Java等の開発が増えているのは皆さんもご存じだと思うが、これらの言語を使用した場合、可読性が高いため、詳細設計書をプログラムコードとして代用するからだ。悪いことではないが、多くの場合、プログラムコードに処理の解説を記載したコメントがほとんどないことが多い。プログラムコードを詳細設計書の代用にするのであれば、プログラムコードの各モジュールには、コメントでInput/Output、そして処理概要位の説明があってもよいはずだが、これがない。幾ら可読性が高いといっても、これはいただけない。

なぜこのようになったのか、これはエンジニアの手抜き以外の何物でもない。私も詳細設計を端折る人種の一人であるので、なかなか下記ずらいが思いきって書くと、やはり「手抜き」である。可読性の方い言語の場合、詳細設計をしなくても、少々の経験があれば、処理ロジックは直接プログラムコードとして記載できる。つまり、何も考えずにプログラムをいきなりかけてしまうのである。小さなプログラムならこれでよい。しかし、ある程度開発規模のあるものになると、他との協調動作もあるため、これをやってしまうと矛盾が矛盾を呼びシステムとして動作しなくなる可能性がある。結果、解析が難しいバグを生み、システムとして十分動作しないものを作ってしまうのである。結果だけ聞けば当たり前だが、よくあるケースでもある。

試験の工程をみても同じだ。機能試験だけをして、システム試験をしなければ、システム全体としての整合性のとれた動作の確認ができていない。つまり、不穏な動作を見過ごすことになる。結果甚大なバグを埋め込んだシステムを提供することになる。

結局、工程を端折ることは、全体として悪い結果しか生まない。

さて、視点を変えて、うまく仕事ができない人の様子を見てみよう。最近よく見かけるのは、「何がわからないかが分からずに悩む人」である。なぜこうなるのか・・・。常に頭を悩ませる。本人はやる気満々なのだから無碍にもできない。多くの場合、「目的を見失っている」ケースが多い。つまり、やるべきことが定義できていないのである。これをソフトウエアの工程に合わせれば、全体設計ができてないのである。全体設計ができていないのだから、何をすべきか（機能としてどういうことをすればよいか）、そして、どうすべきか（それぞれの機能をどうこなすべきか）という機能設計、そして詳細設計に進めないのは当然である。

試験工程も同様だ。やるべきことが分かっていて、作業は進むが、どうも手戻りがおおい。これは、十差に行った作業に間違いが多いからである。つまり、せっかく「どうすべきか」という詳細設計まで行っても、その作業の確認、つまり詳細試験を行わなくては作業として終了していないということになる。

世の中には「PDCAサイクル」という言葉がある。これは経営学などでマネージメントを行う場合に使われる言葉だが、要は、企画、実行、確認、改善という工程を回すことで、業務改善を適宜行おうというものだ。これも見てわかるように、企画⇒実行⇒確認というように設計から試験までの工程と同じ考えが導入されている。

つまり、何を行うにも、計画と実行、そして確認がなければ成立しないということだ。仕事が十分にできない人は、このどこかをおろそかにしている。これは、仕事全体というわけでもない。たとえば「ドキュメントを書く」という、細かい作業に至っても言えることだ。

ドキュメントを書く場合には、まず、どういうものを書くかということを練る「全体設計」が必要だ、次に、どういう流れで、どういう章立てにするのかを考える「機能設計」が次に来る。そして、各章や節をどういう論調で書くかという「詳細設計」を行う。これができて初めて「文書を書く」という「コーディング」の作業が始められるのだ。試験工程も同じだ。各章の誤植などをチェックする「詳細試験」、文書の全体的な整合性を確認する「機能試験」、そして、文書全体として目的からずれていないかを確認する「全体試験」だ。

ともあれ、ソフト開発は人間が作業をうまく運ばせる時にひつうような工程を正しく網羅してくれている。おそらく、仕事がうまく運べない人は、どこかをはしょっているに違いない。中には、こんなまどろっこしい工程を踏まなくても、綺麗な文書を書いたり、素晴らしいシステムを構築する人がいる。外から見れば彼らはこれらの工程を完全に端折っているケースが見受けられる。しかし、話をすれば彼らは彼らの思考の中で、これらの工程をきちんと行っているのである。だから、それぞれに理由を聞いても正しくこたえられる。いいわけではなく、計画的に実行した結果を話してくれるのである。このような、思考を持つには、長い訓練と経験が必要なのは言うまでもなく、新人まがいができるはずは等ていない。だが、端折る・・・。

小難しい話になったが、かくいう私もうまいほうではない。当然だが、このblogはそんな工程を経てはいない。多分、読まれている人にとっては意味不明なことが多いだろう。そこはblogということでお許しいただきたい。

最後に・・・。こういうblogが思考を停止させているのではないかという疑念もある。誰かそうではないと言ってほしい・・・。