歩み寄り

要求を出す側はソフトウェアのなんたるかをあまり詳しく知りません。
要求を受ける側は要求の本質を知りません。

両者が目標を共有するには相互理解するプロセスが欠かせません。
要求を受ける側は多くの場合受注者なので、相手をお客様として扱うのはもちろんのことで、お客様がその気でなければ一方的にでも近寄ります。
しかし、要求仕様書は両者の共同成果物なのですから共同したほうがよりうまくいくわけです。
ソフトウェア技術者があれこれ細かいことを聞いてくると思われるお客様は実はあたりの技術者が担当してくれているのかも知れません。

あれこれ聞くだけで的を外すこともあるので、絶対とは言えませんけど(笑)

ダイアグラム

人間がぱっと見で理解できる範囲などたかが知れたものですが、それが文字や話だけだったりするとさらに狭まります。
できるだけ広い範囲を理解して、しかもそれを協働者と共有しようとすると別の方法を考えるしかありません。
その一つが図を書いてみることで、これはとても効果的です。
まず大切なことは関わる業務を理解すべく図を描く覚悟をすることでしょうか。
一般にしっかり分析して理解した上でなければロクなものは作れませんが、いきなりコードを書いてうまくいっちゃうんじゃないかという誘惑にかられます。
もちろん私もその一人です。（笑）

これは何もソフトウェア開発に限ったことではなく、それ以外の業界でも何らかの図を書いていたりするかもしれませんね。
私もソフトウェアと直接関係ない業務でも、入力と出力とそれを変換するプロセスを示す図を書いたりします。
これで、「こういうことをやれば良いのですか？」と上司に確認すると案外簡単に理解してくれ、しかも的はずれな仕事をしないで済みます。
どういう図が適しているかはそのとき望まれることによって変わります。
ネットを探してみると結構たくさんの種類があるのがわかるでしょう。

自分が苦労していることなどありふれたことで、既に誰かが何かの方法を考えてくれているという謙虚さを持ったほうが得ですね。
まぁ、探しても見つからなければ自分で方法を考えれば良いことです。

あなたの仕事はどんなこと？

こんなことを聞かれたらたいていの人は即答するでしょうね。
ソフトウェア技術者もそうなんですけど、仕事をするうえでは思いっきり自分の仕事の分析をしなければならない場合があるんです。
昔々の時代には神様みたいなプログラマがいてその人がすべてを書いていた時代もありました。
凡人プログラマと神様プログラマの生産性の違いは２０倍とか２００倍などとも言われます。

ですけれど、開発規模が大きくなってきた昨今では神様が一人いるだけではどうにもならないわけです。
そこで普通はプロジェクトをしっかり分析して、ここは誰、ここは誰というように分担します。
この「しっかり分析」の時に自分の持ち分がどこまでで、誰から何を受け取って作業後誰に何を渡すのかというのを徹底的にやる必要があるわけです。
当たり前のことなんですけど、深く綿密にやっておかねばなりません。

情報流出あとたたず

http://slashdot.jp/security/06/03/29/0227200.shtml
あきれました。

パスワードをファイルに書いてあることが驚きだし、それを家に持ち帰り「住基ネット」などというなんともわかりやすいフォルダに入れるとは。
もう何と言ったらいいやら。

http://internet.watch.impress.co.jp/cda/news/2006/03/03/11106.html
こんなのも出てくるわけだし、「安全」などと押し切った政府の気が知れない。
そもそもずっと前にも、建物の外で無線LANに接続してデータ読めちゃいましたなんて話もありました。
暗号化してなかったか、暗号が弱かったんでしょうね。

仮にシステム設計者が神で穴のないシステムを作り上げたとしても、運用側が設計者の意図を理解して使ってくれるという保証はありません。
ソフトウェアに限らない話ですけれど、こんな例はいくらでもあります。

所詮人間のやることですし、システムには設計者だけが関わるわけではありませんからね。

窮鼠猫を噛む

岩波国語辞典では

きゅうそ【窮鼠】
追い詰められて逃げ場を失った、ねずみ。「―猫をかむ」(弱者も追い詰められると死力を出して強者を負かすことのたとえ)

ということです。

現状のソフトウェア技術者の労働環境(というよりマネジメントかな)は良いとも思えません。
要求分析の重要性を理解せず協力的でない発注者がいるのは珍しいことではないですし、場合によっては管理職までわかっていない人だったりすることもあります。
そんなソフトウェア技術者をいじめるとどうなるかといいますと、「そのような要求は聞いておりません」となるわけですね。

結局のところ、要求の分析は発注側も受注側も手を抜かずしっかりやるのがお互いのためなんですね。
だけれど、何度痛い思いをしても懲りない人っているんですよね。
どうしてそうなるのか考えていないのかも知れません。