システム構築外注時には、発注者にも専門用語の最低限の理解はあったほうが良い？
いきなりですが、ジャック・ラカンという精神分析家をご存知でしょうか。ポストモダニズムの中でも構造主義やポスト構造主義に大きな影響を与えた精神科医・哲学者で、20世紀を代表する著名な思想家の一人です。
彼の理論を大雑把にまとめると「人は言語によって世界の象徴的座標を決定する為、そのまま現実を直視する事は出来ない」といったもので、人間は現実を解釈・説明する際には必ず「言語」を用いる必要があるという事に着目しました。
彼は「人間は現実をそのまま理解するのでなく、言語を介してその一側面を切り取り、その断片的な説明によってのみ理解する」という風に解釈しています。
システム構築における意思の疎通をラカン的に説明すると、発注者は「想像界」（漠然とした、誰もが頭に浮かべる概念で作られた世界）における業務遂行の効率上昇や、システムの中で必要と考える大まかな機能等の概念を、「象徴界」（意思の疎通など言語活動を行う場）で言葉を用いて説明し、ベンダーがその言葉を聞いてそれを理解する、という一連のプロセスからなります。
ですが、発注者が頭に思い描いている物事をベンダーに伝えるためには、そのための「言語」、つまりシステム構築の諸プロセスにおいて使われる専門用語を習得している必要があるのです。
なぜなら、我々は言語を介してしかお互いの欲求を伝えることが出来ないからです。多少長いイントロとなってしまいましたが、次章では実際に使われる専門用語を、場面に沿って見ていきましょう。
発注者にも必要な専門用語
システム構築の手順として主に「ウォーターフォール型」という企画・要件定義・設計・開発・テスト・導入と順序立てて行うものと、その順序を柔軟に入れ替える「アジャイル型」（機敏型）があります。
ここではウォーターフォール型のモデルを利用しながら、その中で使われる用語を見ていきましょう
１、開発の規格とRFP
RFPはRequest for Proposal (提案の要請)の略で、数十ページから数千ページに及ぶシステムの使用目的や必要な機能、希望納期をまとめた文書です。これを発注先候補に送り、充分な提案なら契約を結びたいという意向を示します。
２、オリエンテーション
RFPが完成した後は、それを発注先候補に説明する際にはオリエンテーション（説明会）を行います。つまりこの時点からベンダー側とは言語活動を行うことになります。こうする事によってRFP無しの打ち合わせより統一した形で相手にスペックを伝えることが出来ます。
３、相見積もり
提案の一覧から価格並びにRFPに対する回答と、提案された「スペック」が自分の欲求している物事と最も近いと感じたものを選択する作業です。値段だけにとらわれず、実際にコミュニケートされている内容を考慮する事が大切です。４、基本契約の締結
大まかな金額や保守対応（トラブル発生時の対策）の枠組みについての合意を行う作業です。この時には作業の細かな役回りなどは後述の個別契約書にて指定するようにしましょう。
５、要件定義
システム構築時は、ここからが本番といってよいかもしれません。現在の業務プロセスをフローチャートなどで記号化し、システム導入でどういった課題を解決したいのかを発注者に伝えるプロセスです。人員の数や予算、期間含め、この工程で発注者の想像する目的を、ベンダー側と協賛してその目的の達成手段に変換して行きますが、ウォーターフォール型のモデルでは、各段階を独立して行い、後戻りしないことが条件となっているため、しっかりとシステム導入の目的や、それによって改善したい事柄を明確にする必要があります。
６、外部設計
要件定義を基に、UI（ユーザーインターフェース）を決定していきます。UIとはメニューなどの画面の設計やボタンの配置など、操作に関係する外見的な配置等を指し、使い勝手を左右します。この時にはメニュー等の想像図を作成するなど記号化を行い、どういう配置にすれば使い勝手が良いかを考え、ベンダーに鮮明なイメージを伝えることが大切です。７、内部設計
こちらは実際のプログラミングを指します。こちらは基本的にベンダーに委託してしまって構いません。
８、個別契約の締結
作業分担内容、つまりベンダーは構築のどの部分を担い、共同作業の内容は何を行うかや、最終的な請負金額等を明らかにする契約です。この段階で明確な合意がないまま開発を進めてしまうと、大きなトラブルが発生してしまうリスクが生じます。
９、単体テスト
実際作成したプログラムの一つを、単体でテストする作業で、これが完了すれば事項の複合テストを行うことになります。開発者側が請け負う作業です。
１０、結合テスト
複数のプログラムが念頭に置かれた機能通りに作動するかを確認する工程です。こちらも開発者側が基本的に請け負います。
１１、運用テスト
結合テストクリア後、発注者の動作環境にて実際のそれが意図されたように機能するかを確認するプロセスです。実際の運用で不具合が無いかを調べるという点において、実用面に重きを置きます。
１２、システム移行
今までのシステムから、新システムへと移行する事を指します。プログラムの導入
によって業務の形態を急に変える事が難しい場合や、移行に時間を要する場合は順次移行（少しずつ移行する事）を行いましょう
１３、運用・保守
保守とは、運用において不具合が見つかった場合に対する機能の修正や、システムの補正、アップデートなどを指します。思わぬ不具合が生じた場合だけでなく、機能を修正する必要のあった場合にも保守が必要となります。
最低限の理解
システム構築において、プログラミングなど特殊な技術の必要な知識というのは、実はあまり発注者としては必要ではありません。むしろ発注者は思い描いているイメージや、成し遂げたい目的等といった事を考える方が先決で、そのような「ビジョン」を伝達する手段として専門用語が役立つ、という程度の理解で構いません。
実際、先ほど紹介した単語の多くは、プログラミングというよりは企画から納品までのの諸プロセスや、契約の締結、そして自分の意図を簡潔に伝えるという機能の方が大部分を占めています。
ウィトゲンシュタインは言語の事を、数あるゲームの中から、今遊んでいるゲームのルールに従っていくことに例えています。つまり、このシステム構築というゲームにおいては、発注者の専門用語の理解には一定の不文律があるのです。
外部設計において「戻る」ボタン一つをとっても、そのボタンに機能を与える具体的なコード（プログラミングの文法にならった”暗号”のようなもの）の理解でなく、そのボタンがプログラムの操作上成すべき機能（前の画面を表示する事）や、画面上の配置等といったユーザー視点からの理解に乗っ取って考えてゆく方が直観的ですし、ベンダーにも必要な情報を結果として与えられるのです。
相手が知って有用な情報は何か、という視点から自分に必要な理解は何で、円滑なプロジェクトの進行に必要な用語は何かを考えてゆくことが大切なのです。
言語活動と記号の共有という視点からスムーズなシステム構築に必要な用語の理解を考察してみました。難しく考えすぎず、あくまで円滑に契約や企画を振興するための道具として専門用語と上手く付き合っていきましょう。
