コミュニケーションの大切さと難しさ。
僕らの仕事の大半を占める物造りにおいて、担当する方々には、その大切さをご理解されていることと思います。
システム開発を例に挙げると、そのプロセスは以下のようになります。
１．要件定義 … 現状の業務をヒアリングし、分析結果をドキュメントとして作成し提示する。
２．基本設計 … 要件定義の内容から機能別の画面、帳票等のイメージとして資料作成し提示、説明を行なう。
３．詳細設計 … 基本設計の内容を機能別に、プログラマへ伝える資料として作成する。
４．プログラム作成 … 詳細設計書を元にプログラムの作成を行い、作成者は動作確認を行なう。
５．結合テスト … 実際の運用に見立てて、作成したプログラム群の連携確認を行なう。
６．操作説明書作成 … 各機能毎に操作の方法やポイントを資料として作成する。
７．納入 … 出来上がったシステム一式を納入し、操作説明書を元にお客様へ使い方をレクチャーする。
８．フォロー … 運用がスムーズに行なえるよう、また不具合等の改修や問合せへの対応を行なう。
箇条書きでまとめましたが、以上のようなフェーズを踏むのが一般的ではないでしょうか。
一般的に１～８のうちシステムエンジニア（ＳＥ）の領域は１～３、５、６、７、８でプログラマー（ＰＧ）の領域は４～６、８と思います。
お互いにダブっているところがあるのは夫々なりの対応が必要だからです。
ではお題のコミュニケーションはどの時点で重要となるのか？
経験されている方はご理解されていると思いますが、１～８の全てのフェーズで重要です。
よく、「彼はプログラマーとしてはまずまずだけど、システムエンジニアとしては…」というコメントを聞きます。
でも僕としては？で、正直言えば「その人将来難しいし、今も実際はどうなの？」です。
プログラム作成だけに注目しても、仕様を忠実に再現しようとすれば、当然のようにＳＥへの質問攻めがあるはずです。
もっともＳＥが作成した詳細設計書が、それこそプログラムソース（プログラムの記述そのもの）に限りなく近い精度であれば問題無いのかも知れませんが、実際のところそこまで書くのは時間的にもコスト的にも難しいでしょう。
そうすると必然的にＰＧには「こう捉えたけど、間違ってないか？」という不安感があるはずで、それを解決しようと思えばＳＥに聞くしかないのです。
仮にコミュニケーション能力に問題があるＰＧであれば、ＳＥから「君、何が聞きたいの？」とか、ＳＥが間違った捉え方をしてしまい、本来とは違う答えを出したりということが発生します。
こうなると、本来必要とされた機能と違うプログラムが出来上がってしまうのです。
実はシステムの中にこのようなプログラムが一本でも混ざってしまうことは悲劇です。
通常、販売管理を行なうシステムでも、１００本以上のプログラムが存在することは当たり前ですから、そのまずい一本のまずい箇所を、結合テストで見極めることは意外や困難だったりします。
結果的にはＳＥが単体テストを行なうことがベストなのでしょうが、実際には難しい話です。
もっとも怖いのは、ＳＥなのにコミュニケーション能力に問題がある場合。
実際のところ、僕が見渡す限り「年齢的にＳＥと名乗ってるだけであって、スキル的には？」な方が相当いらっしゃいます。
顕著なのは日常会話で現れます。
ＳＥと名乗る方とお話してみてください。
「確かに言おうとすることは何となく分かるけど、具体的にはイメージし難い」って思われますよ。
それでも何となくＳＥらしくして居られるのは、実はお客様が優れていらっしゃるから。
システム屋の作る慣れない資料を必死でご理解されて、何を言おうとしているのかを察していただける。
そんな寛大なお客様だから、それなりに成功したように見えてるだけのことです。
「自分はそんなことは無い！ＳＥとして成立している！」と自負されるあなた。
本当にそうであれば、試しにスナックのママさんを口説いてみてください。
きっと軽くあしらわれますから(^^)
システム屋の本当に必要なスキルは、資料を作れることや説明をすることでは無く、「上手く伝えてご理解いただけること」ではないでしょうか？
※スナックのママさん、ボキャブラリーの無いＳＥが飲みに行ったら、ごめんなさいm(__)m
