ユーザに知っておいてもらいたいシステム開発のルール。
前提として、中小の事業会社なので、ほどほどのところを目指しています。やりすぎると引かれちゃうもので。
話しただけではシステムはできない
結構あるのが「打ち合わせで話した！」ってやつですね。
・打ち合わせでこんなことを話した
・こんなアイディアがあるという話をもらった
→要求としては出さなかったけど実装されると思ってた
話してもそれが勝手に実装されるわけじゃない。それをきちんと精査して要求にまとめて要件化して見積の合意をもらって、そこまでが仕事。
なのでこんな話があったら「で、どうします？」とやるわけですが、いったん持ち帰りになることが多い。
ここで大事なのは
「要求を待つのではなく、相談されたことは案件化して納期を決める」ことであります。
とくにサービス業なんかだと「直前まで大丈夫」なんていう感覚の人たちも多いので、ずっと時間が経ってから大きな追加案件を「以前言ったよね？」なんていわれると真っ青になるので、上がってきた内容はリスト化して納期を決める。これ大事。
ロジカルに説明できることしかできません
次にこれ。結構相反することを言ってくる部分あるわけですよ。
なので、疑問は徹底的に追及して明快なものにしているわけですが、ユーザ内で対立構造があって相反する要求をかなえようとしたりしていると、難しくなってくる。
こういった場合は、下記のようなことをします。
・オウム返しして本人の要求を整理させていく
・ホワイトボードに箇条書きして相反するものをつぶしていく
・相反する話は、本人同士の話に切り出して、解決したものを持ってこさせる（解決しなければやらない）
まあ、「ロジカルに整理する」ってやつですね。システム開発と直結しないものも関係するものであれば、これをロジカルにすることもコーポレートSEとしては必要だと思ってるもんで、やりますよ。
面白いのは、整理していると勝手に話を進展させていく人が出ること。「〇〇なんだったら××しかないじゃん」とか、「あ、これ、自分で言ってましたけど無理ですね」なんていう話になってくれるのが理想であります。
不具合が＝バグになるわけではありません
よくあるのは「ここまで話してきたんだから、この機能がないと困るだろう！」とか「これは困りますよね？そう思いませんか？」とか、こちらの「共感」を求めてくるやつですね。
「〇〇（自部門）で話したところ、これは絶対におかしいという話になりました！」なんていうパターンもある。
気持ちはわかるけど、どこでも合意してないし、そんな仕様どこで話したの？
こういうときには、「（彼らにとって）不都合がある」という部分に共感しつつ問題を整理して、要件とあわせていきます。
そこまでのところで「システム開発ってこういうもの」みたいなところをある程度説明していて理解しているようなら、あまりこちらから一方的に話さないほうがよいです。相手に話させる。
「困っているところを整理すると、どの仕様の部分になりますかね？」
「この仕様のこの箇所に書いて…ないね」
「ないですね」
「困ったな」
「困りましたね」
「やっぱり追加になる？」
「なるんじゃないでしょうか」
「なんとかならない？」
「今の仕様で、こういった操作で回避できません？」
「…ちょっと考えるわ」
システムですべて解決できるわけじゃない
以前こんな記事でも書きましたが、仕事には、システムで解決すべきものと、仕事やビジネスとして解決すべきものがあります。
すべてをごちゃまぜにシステムに持ち込むから、もめるんです。
しかし、DX案件なんかですと、当然一緒に考えるから、もめるのあたりまえなんですよね。この理屈を知っていると冷静に対応できます。
システムのもめやすいポイントって決まっているので、こんな本を読んでおくと参考になります。
これも良書。
ビジネスの要件をシステムにつなぐのって、難しいですよね。
おしまい。