先週の事で思うこと…

はい、急に顧客対応で、火曜日に定時後から着替えもなく３泊４日の旅…
まさに事件は「会議室」でなく「現場」で起こるもの。
運用開始直後なのでしょうがない。
基本的には僕はそういうリリースあとの現地での対応はいままでなかったので、経験にもなる。
着替えは…下着はコンビニで購入するとか、手で洗たくするとかはしましたよ…だって夏だし。

再認識するのは、
『使う側』と『作る側』のギャップていうのをどう埋めていったらよいのだろうか？
ということをほんと考え続けないとダメだってこと。

そういうことを考えると、以前にも参考にさせてもらっている
「プログラミングファースト開発」は１つの有効な手段だと思う。
使ってもらって、問題があれば「運用でカバー」「機能に追加」等の判断をしていく。

他にもこういうギャップがあったりするから、いろんな方法論とかとりあげられる。
設計をうまくしていくとかいうのが主体的なような感じもするけど、
でもやっぱ「動くものがない」とわかりにくいという状況が一番多いんじゃないかな？
契約とかそういうので縛るための「設計でギャップをなくす」方法になって、
打ち合わせをした人たちの意識としてはいいかもしれないけど、
「使う人」への連絡や調整を基本的にできていない事が多いと思う。

もちろん「使う人」の事をを考えて提案だとか、設計だとかするわけだけども、
「使う人」になりきる事は十分にはできない。
運用保守とかをして、あぁ〜とか気づく点は少なくはないと思う。

でも、作りながら触ってもらいながら作っていくというのは、
『予算』を立てにくいものであったりして、受け付けるということも難しい。
また、「検収」の基準を設けるのも難しいと思う。
そういう調整を「要件定義」や「設計」で行うことは必要だと思うけど、
そうなると何かまた少し話がずれてくるような気もする。

システムは構築したら終わりじゃなくて、成長させなければいけないものだと思ってる。
これはＯＳだとかもバージョンアップしていってることが十分な理由になると思う。
使っていけばイロイロ問題や要望が必ずでてくる。それを反映する。

また難しいとこは、システムだけの問題でなく、担当が変われば要件もかわったりする。
作る人が変われば元の意思が薄れていく。
その結果として成長でなく退化してしまうこともある。

難しいですよね…
もちろんそれらすべてを一人で話は無理であって、システム開発の業界だけが集まっても解決は無理。
「使う側」と「作る側」と「それらをつなぐパイプ」が集まった勉強会なり
そういうのが増えていかないといけないと思う。
そういうのをしようと思うと、企業のシステムや業務のオープン化というのも必要になってくるかと…

どうしていったらいいでしょうかね？
いい案とかなんだとかないですかね？（ぉぃ）