システム開発がわかる人材の育成
2012 年 55 巻 7 号 p. 502-510
詳細
2012 年 55 巻 7 号 p. 502-510
システム開発の経験と大学でシステム開発に関係する講義を30年行ってきた経験を基に，「システム開発がわかる」人材の重要性と，その人材育成のための科目構成を述べた。講義の内容から次の4つの要点を説明した。基本用語とその用語の背景に存在する概念，情報システムの構成要素と機能，ソフトウェア開発の難しさとその理由，その難しさの解決策としてのライフサイクルモデルである。そのモデルの中で，特に要求分析と要求分析における利用者の協力の重要性を指摘した。
本誌『情報管理』の編集委員会から「先生がどのようにしてシステムのわかる図書館職員，（情報センターの）情報担当者を育てたか，育てようとしたかを書いてほしい」との趣旨のお話があり，筆者の長年の経験がお役に立てばと思い，お引き受けした。
「システム開発ができる」ではなく「システム開発がわかる」であることが本解説の特徴である。なお，タイトル中の文言「システム開発」は正確には「情報システム開発」だが，タイトルとしては歯切れの良さを重視した。
一方，筆者がシステム開発に関する解説を書くほど経験があるか？という疑問をお持ちの読者もあろう。大学院修了後の筆者の経歴は文部教官，最後は国立大学教授だからである。筆者は，日本で最初のオンライン情報検索システム（TOOL-IR）を研究開発したチームの一員1)であった。次いで，国文学研究資料館に異動して，図書館関係のシステムの分析，設計を6年半行った。その経験から，システム開発がわかる人材を大学で育成する必要を痛感して，開学3年後の図書館情報大学に1982年に異動した。そして，筑波大学との大学統合を経て，2012年3月末に定年退職するまで，30年間の講義を介して人材育成に努めた。なお，図書館情報大学でも最初の数年間は教員3人，図書館職員，日立製作所との連携チームで統合型図書館システム（LIAISON）を開発した。また，学術雑誌の電子出版システムでは，凸版印刷との共同開発で1990年に日本最初のSGML（XMLの前身）による電子出版を情報知識学会誌第1巻で実現した2),3)。さらに1993年には日本化学会の欧文月刊誌の電子出版を実現するとともに，そのHTML版のWebページの実験公開も行った。
従って，本解説では筆者の経験を基に，2章では「システム開発がわかる」人材の重要性と育成を，3章では重要語の概念を，4章では情報システムの構成要素と機能を，5章ではソフトウェア開発の難しさを述べる。6章ではその難しさを軽減するライフサイクルモデルを述べ，その中で要求分析の重要性と「システム開発がわかる」利用者の協力が有効であることを述べる。7章はまとめである。
「システム開発ができる」人がいれば「システム開発がわかる」人は不要と思うかもしれないが，そうではない。仕事で情報システムを使用する人が「システム開発がわかる」人であれば，要求分析の際にシステムの機能について適切な要求を出すことができ，その結果，仕事に役立つ良い情報システムが導入できるためである。要求分析については6章で詳しく述べる。
どの組織においても，業務改善，新しい業務の展開は必要である。それを実現するには情報システムを改良する必要がある。その際に，現場のリーダーと担当者がシステム開発がわかる人であれば，適切な要求を出すことができるから，情報システムの改良も効率的に進めることができる。
2.2 「システム開発がわかる」人材の育成システム開発がわかる人材を育成するには大学での教育が良いと筆者は考える。1日，2日の講習会では「良い勉強になったが，実はよくわからなかった」で終わる。その理由は，システム開発を理解するには，さまざまな科目を履修する必要があるためである。図書館情報大学が学部学生用に開講していた情報システム関連科目を表1に示す。1学部1学科であるが，図書館系の学生と情報処理系の学生がいるため（後者の方が数が多い），1，2年次に必修科目（後年，図書館系と情報処理系の2コースに分けるコース制を導入した際に共通科目と改称）を置いた。従って，図書館系の学生でも情報システム，システム開発がわかるようになっている。例えば，情報システムの講義で「図書館では図書のID（identification, 同定，識別）番号として，「書誌ID」，「book ID」がある。書誌IDは内容が同じ図書かを識別するIDで，蔵書検索システムのデータベース（DB）の主キーである。book IDは個々の図書を区別するIDで，貸出管理システムの貸出記録DBで使用する」というと，学生は「なるほど」とわかってくれる。
プログラミングで苦労した図書館系の学生はシステム開発，ソフトウェア開発がいかに大変な仕事かを理解し，その仕事は専門家に委ね，自分は機能を要求するのが良いとわかる。一方，情報処理系の学生は選択科目を履修し，卒業研究でシステム開発を経験することによって自信をつけて卒業する。
表1に示した講義の担当者は，単にテクニックを教えるのではなく，その背後に存在する概念とその長所，短所を含めて教えている。コンピューター関連学問の進歩は速いため，単にテクニックを覚えているのではすぐに役立たなくなるが，概念と長所，短所を理解していれば，新しい技術が出現しても，その必要性と価値が理解でき，少し勉強すれば新技術を理解できるからである。
以下，筆者が行ってきた情報システムとシステム開発に関する講義内容の要点を紹介する。
筆者は1，2年次の学生への講義で最初に基本用語の意味と概念を説明してきた。
「システム開発」とは正確には「情報システムの開発」であり，情報とはinformation，システムはsystem，開発はdevelopmentである。なぜ，英語で言うのかと不思議に思われるかもしれないが，本来の用語の意味が日本語の訳語が持つ意味と若干異なるため，概念を誤解している学生がいるからである。
3.1 用語informationの意味と概念図1にinformationの語源と意味を示す。ここでは英語を挙げているが，informationはラテン語由来の言葉であるため，西欧の言語では同じスペルであり，語源，すなわち基の概念も同じである。日本語で情報というと「大事な情報なのだから隠そう」とか「特別にあなただけに教えるけれど，他人には言わないように」とかいうことがあるが，本来の意味から見ると誤りであることがわかる。また，語源からいうとinformationとはきちんとした形式で記述されるものであることがわかる。以前，消えた年金記録というニュースがあり，情報システムのデータベースの中に姓は記入されているが，名が記入されていないものがあるため，その分は個人が特定できないことが原因と報道された。これが事実ならば，知らせるべき相手（この場合は当事者本人）を不明にしたままシステムを運用していたことになるから，情報システムの管理者，運用者がinformationの概念を理解していなかったことが真の原因と言えよう。
日本で情報公開と言われている用語があるが，それは訳語であって，元の英語はdisclosureである。この語は，disは否定を表す接頭辞，閉じるを表す動詞close，動作・状態・結果を示す接尾辞ureで構成され，閉じることを止めることを表す。本来，informationは知らせることであるため，知らせる対象者を限定する必要がある場合は，closeする必要がある。その限定を外すからdisclosureである。一方，情報公開では，情報とは本来隠しておくものだが，それを特別に公開するという印象を与える。これでは，本来の概念を誤解させてしまう。
3.2 用語systemの意味と概念システムの英語はsystemである。その語源と意味を図2に示す。語源から見て，さまざまな構成要素を組み合わせて作ったものがsystemであること，この用語が使用されている分野が多様であるため，分野や用途に適合する構成要素を組み合わせて作る考え方が広く受け入れられていることがわかる。これもラテン語由来の言葉であるため，西欧では共通の用語であり，その意味，概念も共通である。西欧人にはsystemは基本的な用語であり，基本的な概念であると言えよう。一方，日本では分野によって訳語が異なり，コンピューター分野ではカタカナになっている。このことはsystemに相当する概念を持つ日本語が見当たらないことを示している。従って，日本では誤解されやすい用語と言える。
systemは機能を持っていることが重要である。例えば，人の身体は歩く機能，ボールを投げる機能などを持つ。前者の機能は足の骨，関節，筋肉などの構成要素を使って，また後者の機能は肩の関節や筋肉，腕や手の骨と関節と筋肉などの構成要素を使って実現している。制度は機能を実現するために人間が考案した仕組みと言える。
情報システム（information system）はinformationを扱うsystemである。informationは人間の活動によって生まれ，それを必要とするさまざまな人間に使われるため，用途に適合する機能を情報システムの構成要素で実現することによって，人間の活動，生活を支援できる。そのため，情報システムは情報分野や銀行だけでなく，町のコンビニの商品販売管理，Amazonと個人の電子商取引，企業間の電子商取引に至るさまざまな所で広く使われるようになった。これは皆様ご存知のとおりである。
3.3 用語developmentの意味と概念図3にdevelopmentの語源と意味を示す。システムを作る場合はdevelopmentという用語が使われることは，単に構成要素を組み立てるといった簡単な仕事ではなく，今までには無い新しいものを作り出す仕事であって，その意味で作り手の能力を高める仕事であることを示している。
情報システムの多くは情報や機能を提供するサーバー（serviceするからserver），それを受け取って仕事をするクライアント（serverから見れば顧客（client））とその間を接続するネットワーク，それに人間（システム管理者，システム運用者，データベース管理者，一般ユーザー）で構成される。人間がシステムを管理・運用・利用して結果を得る。人間以外の構成要素はその機能をもって人間を支援するのであって，主体と責任は人間にある。
サーバーの構成要素は用途によって異なる点があるが，一般的には次の5つであり，これらが連携して機能を実現している。
情報システムの利用者からシステムに対する処理依頼を受け取り，必要に応じてデータベース管理システムに処理依頼を出して，その処理結果を受け取って，利用者のクライアント コンピューターで表示できるように加工し，ネットワークを介してクライアントに送る。
なお，特殊な機能を提供するシステムでは，例えば，Googleの高速Webページ検索機能のためのバックエンドシステム，Amazonの顧客への商品推薦機能のシステムがバックエンドシステムや関連システムとしてシステムの構成要素に加わり，b)のソフトウェアを介して使用できるようになっている。
クライアントでは次の3つの構成要素が機能を分担している。
良い情報システムを開発することは容易ではない。特にソフトウェアの開発に困難がある。そのため初期はアメリカでも開発時のトラブルとそれに起因する納期の遅れ，開発予算オーバーが起きた。
表2にソフトウェア製品の規模とコストを示す。Lotus 1-2-3はMicrosoftがExcelを発売する前に成功していた表計算ソフトウェアである。コード行数は400Kすなわち40万行であり，これを開発する工数は263人年，すなわち1人で行えば263年，100人で行えば2年7か月掛かる。開発コストは2,200万ドル，その多くは人件費である。納期が遅れて工数が2割増えれば，開発に要する金額も2割増えることになる。開発は難しい仕事なのである。
そこで，プログラミングが主体であった仕事の段取り（進め方）を根本から考え直すことになり，次に述べるモデルが考案された。
ソフトウェアの開発の困難を軽減するため，新しい学問分野：ソフトウェア工学4)が生まれ，開発の失敗事例に学んで，多数の人間が働くと，互いのコミュニケーションに時間を取られるため，仕事の遅れが生じることがわかった。その問題を解決するため，コードを書く前に必要な準備をし，その情報を文書化して共有してからコードを書いて，ソフトウェアを開発する「ソフトウェアのライフサイクルモデル」が考案され，成功した。この考え方は「情報システムのライフサイクルモデル」に適用できる。life cycleとは生命の一生（生まれ，育って一人前になって，大いに活躍し，歳をとって衰えて，死ぬ）が次世代によってサイクリックに繰り返されることである。これをソフトウェアや情報システムに当てはめ，もしも前の世代の製品に欠点があっても，それを改善したものを次の世代の製品にすることを繰り返せば，すばらしい製品ができるはずという考え方を採用した。逆に言えば，人間は神ではないから最初は不十分なものしか作れないが，失敗に学んで改善を繰り返せばよいという考え方と言える。
図4に典型的かつ伝統的なライフサイクルモデルであり，広く知られているウォータフォール（waterfall, 滝）モデルを示す。作業の順が上から下であり，遡ることが困難なことがモデル名の由来である。例えば，試験で誤りが見つかり，その原因が要求分析や設計の根幹にあることがわかっても設計の根幹を訂正することは現実には著しく困難である。
要求分析は，アナリストと言われる専門職が実施する。アナリストは当該の情報システムの使用予定者（管理者，運用者を含む），からシステムの目的，システムへの機能要求と適用条件，通常処理と例外処理，性能要求を理由も含めて聴取する。また，既存の関連システムがあればそれとのインターフェースの情報も得る。それらを分析して，実現可能な機能，性能として設定する。もちろん，所定の開発予算の範囲でしか実現できないため，予算超過する場合は，機能の優先順位も聴取した上で，他の要求との関係を考慮して決める必要がある。
要求分析の成果は要求仕様書である。specificationであるから，詳しく，具体的に記述してあることが求められる。アメリカの著名な学会IEEEのソフトウェア工学部会がソフトウェア要求仕様書は次の性質を満たすべきと勧告している5)。
どのように動作するではなく，機能を書くこと。
記述は簡潔で明確であること。
要求内容はシステムの使用予定者の要求を正しく反映していること。
要求，適用条件に漏れがないこと。漏れがあると，実行不備になる点が生じる。
要求仕様書には互いに矛盾した項目があってはならない。
要求の重要性や安定性による優先順位の付加。
システムが要求を満たすことを検証可能なこと。
機能が設計書やソフトウェアのコード（プログラムの命令記述）で追跡可能なこと。
ソフトウェアの保守（修正）が可能であること。
アナリストはさまざまな情報を聞き，その中から要求仕様書として本質的なことは何かを見つけ出そうとする。その過程でまだ聞いていない情報が存在する可能性があれば，聞き取りを追加して分析する。要求分析はこのように行われる。
たとえ話をすると，見えていないものを見つけ出して本質をつかむことに似ている。図5の左の円柱は直径40cm，高さは1mまでしか見えないとする。木の幹かもしれない。右の方を見ると，円柱2本で上がつながっている。中央の細い棒が尻尾だとすると，動物の後ろ姿かもしれない。これが何かは奥から，あるいは横からに視点を変えると見える。長い鼻が見えれば，象であることがわかる。
要求仕様書はアナリストが作成するが，情報システムの使用予定者の協力が欠かせない。特に，上述の完全性，一貫性は業務現場の実態を確認する必要があるため，それを熟知している使用予定者への期待は大きい。一貫性が疑われる事例は，筆者の経験では，現場の実務者にとっては周知の適用条件であるからこそ，逆に言い忘れたためであることが多いように思う。その意味では，現場の実務者が要求分析の要点を理解していると短い時間でより良い要求仕様書ができると考えられる。
要求仕様書に記述される機能要求，性能要求は上述のシステムの使用予定者が同意したものである必要がある。UML6)（Unified Modeling Language）はオブジェクト指向の概念に基づく要求分析と設計の手法であること，文章だけでなく，非専門家にもわかりやすい独特の図を用いて要求仕様書を書くことが特徴のため，広く使われている。
要求仕様書は開発中だけでなく，終了後も保存され，保守や次のサイクルの際にも利用される。
6.2 設計要求仕様書に基づいて専門家である設計者が設計を行う。設計では機能をどのように実現するかを考案する。その成果が設計書である。
情報システムの設計はソフトウェアの設計，データベースの設計，情報リソースの設計に分かれ，それぞれの専門家が設計する。
6.3 構築設計書に基づいて，ソフトウェアの構築，データベースの構築，情報リソースの構築を行う。この3つの中ではソフトウェアの構築が難しい。コードに不調箇所があれば，見つけ出して修正する。プログラマーは専門家だが神様ではないので，多少は不調箇所が生じるが，早く見つけて修正すれば問題ない。不調箇所を業界用語でbug（虫）という。悪さをする小さくて見つけにくいものを虫に例えたわけである。この見つけ出しと修正の作業をdebugという。
6.4 試験構築したソフトウェアが要求仕様書に記述されている機能を持っていることを試験により確認する。試験項目と試験データは要求仕様書の記述に基づいて作成して，試験を行う。試験の結果，不備が発見されれば，その原因を究明してコードを修正し，もしも設計書も修正する必要があれば修正する。同じように，データベースや情報リソースについても試験を行い，不備があれば修正する。
大学の期末試験であれば60点以上で合格だが，この試験は100％すべて所定の機能を発揮することを確認するまで合格にならない厳しい試験である。この厳しさがソフトウェアと情報システムの品質を保証するのである。
6.5 納品情報システム一式を納品する。一式には要求仕様書，設計書，それに利用者のための操作マニュアルも含まれる。納品とともに情報システムの利用者教育も行われる。
6.6 システムの管理，運用この時期がライフサイクルの最盛期であり，ライフサイクルの中で最も期間が長い。
6.7 評価長期間のシステム管理，運用の後に，利用者が情報システムを評価する。評価は客観的な事実と論理に基づく考察に基づいて行う必要がある。
6.8 今後の方針の決定評価結果に基づいて今後の方針を決定する。そのまま使い続ける場合は追加費用は発生しないが，保守が必要な場合はその費用を誰が負担するかは情報システム開発者・提供者との契約によるので検討が必要である。改造または他の製品を選択する場合は，内部で要求分析を行う必要があり，また予算を用意する必要もある。
開発コストは販売収入によって回収する。表2のスペースシャトルの場合はNASA特注品であるからNASAが全額を負担した。表2の表計算ソフトの場合は，22個しか売れなければ1個の販売価格は100万ドルになるが，100万個売れれば1個当たり22ドルと安くなる。
情報システムのソフトウェアの場合も特注品ならば全額を負担することになる。特注品ではなく，パッケージ製品にして多数の顧客に売れれば，その分，販売価格は安くなる。開発して販売する側から見れば，パッケージ化することによって販売価格を下げ，さらに売れるようにしたいだろうし，購入する側から見れば，予算上の制約があるからパッケージ製品の方が購入しやすいだろう。
前章で述べたライフサイクルモデルは主に特注品の場合を説明した。しかし，購入者がパッケージ製品を購入する場合にも有用で，特に要求仕様と試験の部分は役立つ。要求仕様はどの製品を購入するかを決定する条件になるし，試験は現場の仕事に役立つかを確認する方法だからである。
以上，紹介した科目，講義を履修して学生は卒業した。図書館系の学生はシステム，システム開発がわかる人材として図書館に就職し，活躍している。情報処理系の学生は情報・通信系，製造業の一流企業に就職し，情報システム，システム開発，知的財産権の分野で活躍している。日本で最小の国立大学であった図書館情報大学に企業の人事担当者が来学され，「科目一覧表を見せてください」と言われてお見せしたところ，「これらの科目を教えてらっしゃるなら，求人票を出しましょう」と言われた時はうれしかった。また，就職して1年の卒業生に「あの科目，もっと勉強しておけば良かった」と言われた時はもっとうれしかった。
