ドリルの穴
ホームセンターで電動ドリルを探している人がいるとします。その人は何を買いに来ているのでしょうか？ 当然のことながら買うのは電動ドリルです。ただし、本当に欲しいのは、本体ではなく「電動ドリルで空く穴」です。鉱山で使うのであれば、岩石に発破を入れる穴が欲しいし、建設現場で使うのであれば、ボルト止めの穴が必要です。いくら高性能・高品質であっても、必要な穴が空かないドリルは不要です。
自動車を購入する場合には、メーカーや車種、型式、予算等でおおよその絞り込みができるので、全メーカーの全車種から選定を始める必要はありません。好きなブランドやスタイルなど要求を特定するとある程度の車種は絞り込めます。検討段階ではグレードや装備の検討はしますが、エンジンが付いているか、ハンドルは有るか、走るのか、曲がるのか、止まるのかという検討は必要ありません。自動車は走って、曲がって、止まるという基本機能を有しています。また、四角いタイヤの自動車が欲しいと思っても、その要求は受け入れられません。どうしても欲しい場合は、自分で作るしかありませんが自動車としての役割を果たせないでしょう。
夕飯のカレーのために必要なものを調達する場合は、必要な食材を買いに行きます。前提として、家にはガスまたは電気があり、コンロがあり、鍋や包丁などの調理器具がある場合は、スーパーに行くだけで足ります。ここで、その前提を変えて、キャンプ場でカレーを作ることにします。まずは火をどうするか考えます。薪や炭にするのか、カセットコンロにするのか、ガス管をどこから引いてくるのかで労力やコストが変わります。調理器具に関してもナイフと鍋だけで作るのか、その他調理器具一式を調達するのかで労力やコスト、さらに後片づけにまで影響を与えます。前提条件を変えることで同じことをするにしても、労力やコストに多大な影響を与えることとなります。
注文住宅を購入する場合は、業者選定→設計→基礎工事→木工事→内装工事→設備工事→外構工事→完成・引き渡しのような工程があります。「5LDKで白い壁の出窓がある家」という要求に対して、でき上がる家のイメージは十人十色で、施工業者によって完成品が異なることは想像できます。設計図面である程度の合意ができたとしても、施工業者の見え方と初めて家を建てる発注者の見え方は異なります。紙のイメージとでき上がった住宅にギャップがあると、当然直しの要求が出るはずです。見えない基礎部分や柱、梁に対する変更要求は無いにしても、建具や浴槽、キッチンなど目に見える部分の変更要求は出てくるようです。内装、設備工事の段階で大幅な変更があった場合に、木工事や基礎工事まで遡って変更しなければならないとすると、誰かがコスト負担して直さなければならなくなります。そのようにならないために要求を明確にして完成型をイメージすることが重要になります。
情報システム調達の際に何を求めるかを明確にする必要があります。パソコンやサーバが必要なのではなく、それらで実現する効果を購入すると考えることが重要です。情報システムが動く環境や範囲が不明確であれば、導入しても不具合が生じます。要求を明確にしないまま情報システムを調達することは、発注者にも受注者にも不幸な結果をもたらします。情報システムの導入に失敗しないよう、調達前に「目的」、「条件」、「要求」を整理してみることが大切です。
日本語が分からない
かれこれ情報業界の末席に25年以上置いてもらっており、仕事において文章を書く機会が多いのですが、非常に不得意なことの一つです。そもそも文章を書く能力は中学校レベルで止まっており、もっと勉強しておけば良かったと思ったのが初老になってからでした。
最近の情報業界のドキュメントを読むと、何となく言わんとしていることは見えますが何を伝えたいのか理解できないものがたくさんあります。「日本語は難しい。」と一言で言ってしまえば終わりですが、難しいなりにどうすれば関係者が理解できるようになるか考えています。
伝わらない文章の代表的なものは、主語がない文章です。当事者が主語を自分の都合で解釈すると異なる解釈が生まれます。最初のボタンを掛け違う始まりです。主語＋述語が文章の最小構成だと思うのですが、述語を説明する文章や形容する文章のみで構成されているものが多数有ります（お前もだろ～っと突っ込まないでください）。
主語がない文章が多数見られる文書では、ページや段落毎に人格がコロコロ変わります。自分たちのリスクを減らす場合は、自分たちに都合良く主語を隠し、発注者の責任を明確にしたい場合は主語を明らかにすることもあります。ドキュメントのレビューの際に作成者に「主語は何ですか？」と質問した回答によってレビューの出席者が意識のギャップに気付き意識のズレを早期に修正するきっかけになります。
日本語は、単語が多く広辞苑第六版では約24万語収録されているようです。それら全ての単語を使うわけではないので24万語を覚える必要はないですが、広辞苑の収録語数の他に情報業界の専門用語と行政の専門用語、ローカルな言葉を含めるとかなりの語数になるはずです。それらを駆使して文章で表現するわけですが、「言葉が異なると意味が異なる。」ことを意識して文章を書くことが大切です。
目的と目標や問題と課題など一般的に使われる言葉ですが、全く同じ意味を持つとした場合は、どちらかの言葉のみで文章を書けばいいのですが、明確に意味を変えて利用していない場合があります。読み手に正しく意図を伝えるために、目的はゴール、目標は中間指標、問題は悪い現象、課題は悪い現象を無くす活動など最初に定義して関係者と合意しておくことが大切です。情報システムに関する文書は技術文書であり文学ではありません。行間を読むことや情景を思い浮かべながら読み手の解釈によって意味が異なれば何ができあがるか分かりません。
文法にもとづいて単語を利用して文章を書くわけですが、書き手によって表現が異なります。文章の表現力も文書を書く上で重要です。ある有名なソフトウェアメーカーでは「悪意のあるソフトウェアの削除ツール」という表現をしています。情報業界では当たり前の表現ですが、「悪意のある削除ツール」という意味に捉えることもできます。「悪意があるソフトウェアを削除するツール」と言ってもらった方が分かりやすいです。違和感がある文書では「の」を多用しているものがあります。その場合は「の」を使わずに表現してくださいとお願いすると主語と述語の関係が明確な文章になって返ってくることが多いです。
「技術文書は一つの意味しか持ってはいけない。」という大原則を守らないと様々な問題を引き起こすことになりかねません。単語を定義し文法に則った一意の文章を書くことを心がけることが大切です。
知っているのにやらないのは知らないのと一緒
情報技術の進歩はめまぐるしいもので、EA、BA、PMBOK、PRINCE2、P2M、SLCP、SQuBOK、ITIL、ITSSなどの新たなフレームワークや知識体系などが次々と生まれ、知識を習得するのに苦労しています。ここでは個々の詳細な説明は割愛させていただきますが、これらは情報システム調達の様々な場面で役に立つものです。これらの知識体系をもとにサービスを提供してくれるITベンダーを望むところですが現実はどうでしょう。
システム調達の現場にいると、情報業界の技術者はフレームワークや知識体系、ソリューションやプログラムの製造まで、何でも知っている人材が多いことを目の当たりにします。さすがは日本の企業であり勤勉さは昔から変わっていないと安心できます。しかし、言葉を知っていることと実践できることは異なるものであり、安心感がすぐに不安になり、不安が的中することが数多くあります。
過去に、外国人のヒッチハイカーを車に乗せたことがあります。「英語は話せないよ」と言ったら「私はフランス人なので英語はわからない」とお互いがつたない英語とジェスチャーで意思の疎通を図りました。道すがら「フランスに来たことはあるか」と聞かれたので「フランス語を話せないので行こうと思わなかった」と答えました。「フランス語で知っている言葉はないのか」と聞かれたので「ボンジュール」「メルシーボクー」「コマンタレブー」「ジュテーム」とカタカナ的な発音をしたら「それだけ知っていたら大丈夫だよ！（たぶんこのような意味）」と言われました。
もし、EAのDFDやPMBOKのWBS、SLCPのV字モデルを知っているという技術者が、私のフランス語と同レベルの状態であったらどういうことになるでしょうか。提案書には、「SLCPのプロセスにもとづいて工程展開します」「PMBOKに準拠したプロジェクトマネジメントを実施します」などの聞こえがよい言葉が並ぶので、当然ながらそれらフレームワークの体系や詳細を理解し実践方法を知っているものだと思います。しかし、実際にサービスとして提供してもらえるとは限りません。
もっと困るのは、情報システムの構築の際にフレームワークの実践手法を適用することを求めても、パッケージソフトウェアの設置・設定作業などの非常に狭い範囲に、フレームワークの実践手法を無理矢理押し込んでくることです。もう何をやろうとしているのか理解できなくなります。実際に様々なフレームワークを理解して実践できる方々を多数知っているので、そういう技術者は少数だと信じたいのですが、現場にいると数多く見かけることも事実です。
内容を理解していない技術者を見分けるコツとして、「○○のフレームワークで最初にやることは何ですか。その具体的な手法はどのようなものですか。」と聞いてみることがあります。しどろもどろな回答や質問に対する論点を変えた回答をしてきた場合には疑ってかかった方が良いかもしれません。「PMBOKやSLCPに書かれている手法を利用して実施します」と言われたときも疑います。私が読み取れないだけかもしれませんが、どちらも具体的な手法は書いていません。知ったかぶりは役に立ちません。「最初は、○○の役割のヒトが□□を作成するために△△を整理します。つぎに～～」とすぐに明確なイメージを持てる回答がくれば一安心です。
そういう私が、何でも知っているかというとそうではありません。知っていることより知らないことの方が遙かに多いです。知らないことを質問されると勇気を持って知らないと言います。しかし、質問されたことに対する回答を持っているヒトは知っています。自分でできないことは、できるヒトの力を借ります。知ったかぶりは関係者を不幸にします。
知っているのにやらないのは知らないのと一緒であることを肝に銘じています。
