少し前にも日記に書きましたが、１年前から地元企業とあるソフトウェア開発を進めています。工程計画という知的業務をソフトウェア化しようという試みです。断続的にインタビューし、あれこれと打ち合わせをしてきたのですが、なかなか進みませんでした。企業は業務知識に固執、私は知識ソフトの早期実現を。ゴールは同じはずなのになぜかみ合いません。もし、私がソフトウェアメーカーに身を置いていたらとっくの前に赤字プロジェクトになっていたでしょう。そのような状況の中、今日、お互いに１つの光が見えました。
きっかけは企業の社長が導入を決めたあるツールです。名前は出せませんが、知識をフローチャートにして可視化し、現場の知識を共有化しようソフトウェアです。そのツールを数ヶ月前から使い始めて、社長自身が自分の頭の中にある知識を具現化し始めたのです。社長室の壁一面に模造紙を貼り、業務を可視化し始めたのです。それはそれは素晴らしい光景です！
この企業の改善精神は非常に素晴らしいものがあるのですが、「文書化」は苦手でした。作業標準書やそれに類するものを作るようにアドバイスもしてきましたが、なかなかはじめてくれませんでした。それがある方のアドバイスで可視化をし始めたのです。
表現されたフローチャートは単純なのですが、フローチャートに書かれていることがソフトウェア化する対象そのものであることが、それを見てわかりました。
ソフトウェア開発で要件定義するときに、要求分析者がインタビューし要求定義書を書いていきます。餅は餅屋の言葉の通り、ソフトウェアの仕様書はソフト屋が書く、と考えてきましたが、顧客が顧客なりの書き方で描いた成果物がプロジェクトを進める上で非常に重要であることに気づかされました。
顧客が描いた成果物は、形はどうあれ、少なくとも、顧客自身が納得している世界です。ソフト屋が特殊な図法で「あなたの要求はこうですか？」と問うことはもちろん有効であり可能ですが、顧客自身が納得できない以上、どんなに素晴らしい図を描いても合意を得ることはできません。
もちろん、顧客が描いたものが、最終的に実現すべきソフトウェアとはずれていることもあるでしょう。非機能要件が含まれていないことも当然でしょう。それぞれを置いておいたとしても、今日見たフローチャートは確実にプロジェクトを前進する１歩になることを実感しています。
情報技術に不慣れな顧客で、どうしても要求獲得ができない場合、「マンガでも箇条書きでもいいです、とりあえず実現したいことを紙に書いて見せてください。一人で書けなければ一緒に書きましょう」という言葉が有効かも知れませんよ。
