ふたたびITのお話 「システムを作る基本」

BOSSのつぶやき 2013年6月
~ ふたたびITのお話 「システムを作る基本」 ~

今月のつぶやきは、ふたたび情報技術(IT)関連のお話をしよう。
システムに関わる仕事で、上流とか下流、という言葉が使われる。まあ、上流とはシステムの計画やら要件定義とか基本設計というあたりの仕事のことで、下流とはプログラムの設計からコーディング、テストといった仕事を言うようである。この言葉だが、ちょっと待てよ、と思うことがある。日本語で言う「上流」と「下流」ってなんとなく上に対して下の方、という雰囲気があるのだ。つまり、「上流」の方が「優れている」という感じで、「下流」はまあブルーな雰囲気という感じを受ける。

私がこの世界に入った頃には、上流、下流、というような言葉は、あまり聞くことはなかった。私自身は、業務アプリケーションを開発するという仕事からこの世界に入ったわけだが、自分でプログラムを書くことは仕事に必要なことで、プログラムが書ける(だけでなくちゃんと動くように書ける)ことが自分たちの基本的なスキルだった。
また、システム開発の仕事としてプログラムを書く以上、何を作るのか、とか何のためにこのプログラム(のアウトプット)が使われるのか、という話は君自身が利用者からちゃんと聞いてプログラムを作るのはあたりまえでしょ、と言われたものだ。私の担当は、ほとんどがバッチ処理のプログラムだったが、こんな仕事で使いたいので何か作って欲しい、という話が来れば、自分で出向いて説明を聞き、システムの利用方法や出力の絵を書いて了解を取り、プログラムを書いてテストして納品をする、それを直す、というものだった。。
もっとも、規模感で言えば、COBOLのプログラム4〜5本を自分で書くという程度で、プログラムだけではなくデータの作成や切り替えから、ライブラリーの管理、本番運用のJCLも作るのは当然で時にはリリース後しばらくは運用もした。

こういうことをやったおかげで、少しはコンピュータって何ができるか、みたいな勘は1〜2年でできた。そういう私から見ると、システム開発って工程ごとに分業するということが可能な仕事ではないと思えることもある。
なので、「上流工程」とか「下流工程」とかいう言葉はあるとは思えるが、上流だけやる人が居るとか下流だけを外部に依頼するなどと言うことなどは、しっくりこない。プログラムを作る人が、「このシステムがこの仕事に必要な理由」を知らないでプログラムが作れるのか、疑問なのだ。

プログラムを作るということを考えてみよう。プログラミングでは、コンピュータに同じことをやらせるにしても、何通りもの実現方法があるのだ。楽な作り方、ちょっと凝った作り方、多量のデータを処理する場合と多少実行時間は犠牲にしても変更がやりやすい作り方、等々いろいろあって、最終的にはプログラマが限られた時間の中で作業を完成させるためにどんな作り方をするのか、といったことを自分で考えることになる。
この判断を分業体制で実施することを考えると、選択を限定する内容を詳細設計書とかいう文書に書いて「この通り作って」という指示をすることになるのだろうが、結局はそこまでの詳細設計を書くなら設計書を書く人がコードを書いてしまった方が早いし、確かだろう。要は、プログラム書きはコーダーが詳細設計を見てやればいいのよ、テストも単体ベースで詳細設計書に書いてある条件どおり動くか確かめてね、ということで、分業になるようなものじゃない、と言いたい。

さらに、今どきのシステムは、自分が書いたプログラムがOSだけを使って実行する、という単純なものではなく、様々な他人が書いたプログラムを使って何かを実現する、という仕組みになっている。
となるとコードの書き方の選択、だけでなく、じゃあ、どういったプログラムを使って目的のプログラムを動かしてもらおうか、を考えておく必要もある。これは当然、一つのプログラムだけに限らずアプリケーションシステムのために作るプログラムすべてに共通することなので、プログラムを作る前に考えておくべきことだ。こういった共通するプログラムのことを、いつのまにか、基盤ソフトとかミドルウエアと言っているのだ。
したがって、昨今はこのあたりの共通ソフトの利用についての設計が必要になる。じゃあ、やっぱり「工程」があるのだよね、ということになるかと言うと、そうでもないのだ。これらの一連の作業が工場の「工程」のように整然といわゆる「ウオーターフォール」になるかというとそんなことはない。実現したいことは同じとしても、どのような共通の基盤プログラムを使うかは、その規模、必要性、スピードなど様々な要素によって変化していく。それは、完成までにも起こるし、完成してからも発生することだ。
なので、共通に使うプログラムを選ぶということができる人は、そもそも、作ろうとしているシステムの目的にあったプログラムの作り方を知っていて、さらに、その使われ方を想像して「近未来」の判断ができなければならない。
すなわち、将来のメンテナンスも考えて、どういうようなプログラムの作り方をするのが良いのか自分で決めなければ、この「判断」は出来ないのだ。この作業を方式設計と呼ぶとして、方式設計者はこの方式の上でどのようなプログラムが書かれるべきなのかが分からなければ、方式設計は最適なものにはならない。

言いたいのは、システムを作ることの基本はどういうプログラム書くのか、ということに落ち着くのだ。
いわゆる「上流工程」だけしか経験がない人や「下流」に徹するような作業者はシステム作りには不要だ。要件定義からプログラミング、テスト、運用やメンテナンスまで一人でやり切る意思がある人だけがシステムを作る資格があるのだ、ということである。そういう人たちの集まりであれば、チームやプロジェクトのマネジメントも難しいものではなくなる。手足も必要では、という話もあるが、手足からいきなり一人の開発者は生まれない。
どの作業にアサインされても、最終的には今そこで作っているか使おうとしているプログラムの目的を意識することが重要だと考える次第である。

(i^c^i)


Comments are closed.