2014年9月27日土曜日

コンピュータシステム開発の昔と今、そして…

私がコンピュータを初めて見たのは、30年以上前の高校1年の時だったと思います。

だいぶ前のことなので、おそらくの話になりますが、工業高校の電機科でしたので、コンピュータについて学ぶことが専門科目の必須授業になっていたと思います。

コンピュータは、NEC製だったので「ACOS」だったと思います。
また、ハードディスクは「磁気ディスク装置」と言われ、専用の大きなカートリッジに収めされていて、非常に重かった記憶があります。また、カートリッジ1基だけで車が買える程の高価なものでした(^^;)


今のパソコンのような環境ではなく、入力装置といえば、タイプライター、紙テープ、カードであり、出力装置は、タイプライターについている印刷装置やラインプリンターと言われるプリンター類しかありませんでした。


紙テープといえば、昔のアニメやウルトラマンなどで、紙テープに空いた穴の位置を見て、そこにある情報を読み取るシーンがありました。
専門的なことですが、紙テープには16進数で表現された穴が開いていてます。その体系は「ASCIIコード」と呼ばれるものがほとんどです。

つまり、彼らは「ASCIIコード」との照らし合せを頭の中で行って、情報を読み取っていたということです。


現在のコンピュータが搭載されたシステムで、紙テープのような入出力装置は使われないと思いますが、あるとすれば、工業機器に組込まれたコンピュータの入出力用や点字などではないかと思います。


最近までは画面モニターとキーボート/マウスとプリンターが定番の入出力装置でしたが、
現在は、画面に触って入力するタッチパネルやデジタイザー、地図や翻訳などで使われる音声入力などがあります。

また、スマートフォンや携帯ゲーム機などの小型コンピュータの性能は、30年以上前のコンピュータと比較してはるかに凌駕しています。


結論は、現在のコンピュータが相互協力していくことができれば、スーパーコンピュータ数台分以上の性能がありますので、もっと人類文明は発達できると思います。

そのためには、肯定することが大切です。

自分を肯定し、相手も肯定する社会になれば、国同士、民族同士、宗教同士で争うことがなくなると思います。

肯定し、相互信頼できれば、相手を滅ぼす武器など必要なくなります。

そのために使われる国家予算規模のお金が軍事行動以外に使われるようになれば、食糧問題や災害の防止・対策や社会福祉、そして先進国の支援が必要な国や地域の発展に貢献できます。


コンピュータシステムが世界平和や人々の幸福のために生まれてきたと信じています。



2014年9月21日日曜日

ウォーターフォールモデルとアジャイル開発のソフトウェア開発の共存

ソフトウェア開発30年以上の経験・実績から伝えること


ウォーターフォールモデル VS アジャイル開発?!



「ウォーターフォールモデル」の場合、お客様(エンドユーザーではなく、組織の情報システム部になることがほとんど)の要望を聴き、それをシステム化し、コンピュータを使用して効率的に業務を進めるようにするまでの一連の開発行程に多くの時間と人員を必要になります。

お客様の要望を聞いた後に行われる開発作業行程の例
  1. 要件定義
  2. 基本設計書
  3. 概要設計書
  4. 詳細設計書
  5. 試験手順書
  6. プログラム開発
  7. 単体・結合試験
  8. 総合・運用試験
  9. マニュアル作成(導入、操作/運用、例外対応)

開発の進め方は、各作業行程途中や終了後に開発組織内のレビューやユーザーレビューを行い、ユーザーが承認してから次の行程に移行するような流れです。

そのため、開発期間が長くなり、開発に必要な人員が必要になるため、開発費用が高くなります。
よって、開発したシステムをリリースしても、業務が変わっていたりするなどシステムの変更が必要になることが多いです。

いわゆる、バックログ(改善。追加要望の積み残し)が多くなり、エンドユーザーコンピューティング(EUC)としてExcelやAccessなどのオフィスソフトや業務支援のためのツールが現場では使用しなくては、業務そのものが成り立たないのではないでしょうか?


「アジャイル開発」の場合は、上記行程を1~3、4~7、8~9のように分割し、1~3と8~9はユーザーに近い組織が担当し、4~7を専門的に行う社内組織か外部委託する様にしてシステム開発を進めます。このような方法で実際の開発期間を短縮する様にしています。

また、3~4の行程は、全機能が確定してから開発をするのではなく、優先度の高い機能から確定して、機能ごとに実装と試験を行いリリースしますので、短期開発とバックログを少なくすることができます。

ただし、コンピュータシステム開発は1~9の行程が必須です。

アジャイル開発は、3~4についての記事が多いですが、その他の行程もアジャイル開発に向けて変化しなくては、本来のアジャイル開発は成功しません。


ウォーターフォール・モデルのみでシステム開発していく場合の短所には、
上記の通り、開発期間の長期化と開発費用の増大にバックログが減らない可能性があります。

また、アジャイル開発のみでシステム構築をしていく場合の短所には、
全体のことが見えなくなり、バランス悪いシステムに変化していく可能性があります。


これからは


ウォーターフォールモデル と アジャイル開発 の共存

です。



ビジネスの骨格・エンジン開発は「ウォーターフォールモデル」で開発せよ!!

ビジネスの骨格・エンジンとは、ビル建築くする場合の基礎部分です。
基礎がしっかりできてなければ、ビルは長期間立つことができません。また、長期視点に立ってシステム開発をするには、じっくり練った設計をする必要性がありますます。

ただし、重装備にする必要はありません。
シンプルで、操作性とスケーラビティのあるシステムにします。



機能拡張はアジャイル開発で開発せよ!!

現場業務や経営分析は日々変化します。それにシステムが合わなくなると、業務効率が低下します。何故ならば、システム化していないところは、必ず人が1から作らないとならなくなるからです。
それによって、内部統制ができなくなり、情報漏えいにつながるリスクが増大します。

そのため、変化への許容範囲が広い拡張システム(周辺システム)を作る必要性がありますが、この場合は、短期開発する必要があります。つまり、アジャイル開発が向いています。

この時注意することは、現場を混乱させないことです。
新しいソフトを導入し、今までの操作方法が全く異なるようなシステムは混乱するため、現場では使わなくなります。


現場のニーズのポイントは、改善です。

業務を効率的に行うことと、上司の要望・要求に応えられるようにするんことです。

組織としては、内部統制や情報漏えい防止は不可欠です。

使い慣れた操作性を更に良くし、さらに内部統制や情報漏えいの防止になるシステム開発が望まれています。


組織においても、個人や家庭においても必要不可欠なソフトはオフィスソフトです。
その中で、Excelを必ず使用する人が多いと思いますし、Excelなしでは業務ができない組織は多いと思います。

内部統制、情報漏えい対策のポイントは性善説に立った運用はしないことです。
①情報管理を個人に任せない
②正しい権限と操作ログをとることで、必要な場合はトレースなどの監査が行えることです。
③②のために情報トレーサビリティーが行えることです。


それらの組織と現場の要望に応え、社内のデータベースと連携でき、さらに普段使っているExcelブックを有効活用できるツールとしてdbSheetClientを使用した社内システムを開発・構築しています。

dbSheetClientは150社以上の企業などで導入されています。

2014年9月18日木曜日

コンピュータは頭がいい?!

私は、30年以上システム開発に携わっています。

今回は少し持論を書かせていただきます。


未だに「コンピュータは頭がいい!」と思っている方がいると思います。


コンピュータシステムは、単純なことを超高速に行うためのシステムですので、確かに短時間で、答えを出すことができますので、優秀と思います。



現在のソフトウェアで処理する方式のコンピュータが商用として開発されたのは、

1951年にレミントンランド社(現Unisys)の「UNIVAC I」

からです。(※Wikipedia 「UNIVAC I」参照)

この世に誕生してから60年しかたっていません。


コンピュータのハードウェアは急速に発達し、名刺サイズのコンピュータシステムでも、「UNIVAC Ⅰ」の性能をはるかに上回る性能を持っています。


現在のコンピュータは処理命令を順次実行して一連の処理を実行する方式です。(逐次実行型)
コンピュータの頭脳であるCPUは、1つのCPUに複数のコア(頭脳)を搭載するなどして、並列処理することも可能になりつつありますが、CPU(コア)の基本的な作りは逐次実行型と言えます。


コンピュータシステムは、作り手、使い手の通りに動作します。その作り手、使い手が正しければ正しい答えを出しますが、間違っていれば、間違った答えを出すか、止まったり(フリーズ)、異常終了(Windowsのブルースクリーン)します。

企業内のコンピュータシステムがそのパフォーマンスを発揮するには、企業の仕組みが単純化していることが重要です。


  • 職務・権限の明確化
  • 特例が少ない
  • 仕事人が着く

職務・権限の明確化は、データベースの階層構造と正規化に係わってきます。
あいまいになっていることは、システム作りに向きません。


特例が少ないではなく多い場合は、判断することが増えますので、業務する手間がかかります。

実は、コンピュータも判断が苦手なんです。

判断するということは、分岐することが多くなりますので、処理が複雑になってしまいます。


仕事に人が着くではなく、人に仕事が着くとは、本題と少し違うかもしれませんが、その人でないと仕事ができないことになりますので、チェック体制がないことになります。よって不正の温床になりかねます。誰でも仕事ができる体制にすることは事業の継続に不可欠な要素であり、コンピュータシステムを長期に使用するためにも重要なことです。


これからの企業は、コンピュータとコンピュータシステムに投資しますので、その投資が回収できるような組織とシステムが作られることを願っています。