Creative
数年前、あるシステム導入のプロジェクトに関わったことがあります。最近、ふとそのときのことを思い出しました。
長く自分が当たり前だと思っていた仕事の前提を、少し考え直すきっかけになった出来事です。
—
会員制度を決めるという仕事を想像してください。
それは、会員との関係をどう設計するかという仕事でもあります。
どんなルールにするのか、どんな人をどう優遇し、どんな振る舞いを増やすように制度をつくるのか。
正論としては、その関係をいかにつくるかの設計があって、それを支えるための機能が用意されるべきです。
ただ現実というのはそういった姿とは離れていることもしばしばあります。
—
実際のプロジェクトで、どんな条件でポイントをつけるか、解約時の対処はどうするかという論点に入った際
「ここは、御社で決めてください」
と私がお伝えすると、少し困った顔をされたことがあります。
もう少し伺ってみると、制度を自分たちの意思で決めた覚えがない。
いまのポイントの条件も、たまたま入っているシステムでそれしかできないから、そうなっている。
だから今回も、望ましい制度を想定して、それが実現できるシステムを持ってきてほしい、それが期待である、と。
—
正直、ショックを受けたのです。
そこは自分たちで決めるべきではないか、と、そのときの私は強く思いました。
私は青臭いところが多分にあり、
「意図や意思なく、ただ出来合いのシステムを入れるというのは望ましい仕事の在り方ではない」
と考えてきましたし、今もそう思っています。
顧客との関係をどう作りたいかという願いがあって、そこから自然な体験の姿を少しずつ形にして、世に出していくという順番であるべきだと信じています。
ただ、スクラッチで毎回作るほどの時間もお金も労力も割くことはできず、一番近しいものを（妥協があっても）選び、騙し騙し使っていくという現実があります。
そのとき、会員との関係の在り方は誰が決めるのか。
システムを入れる側も、仕様を固めないと開発が進まないので、決めないといけないところをベンダー視点で順番に決めていく。
発注者側としては、受け入れられる仕様という現実がまずあって、それが本当に自分たちにとって望ましいものなのか、十分には判断できないまま進むこともある。
そうせざるを得ない状況で、べき論を振りかざしても役には立ちません。
—
ただ、それでも。
面倒なことを書きますが、大事と小事があるとして、小事はシステムの仕様に決めてもらっても構わない。ただ、大事は手放してはならないとも思うのです。
細部まですべて意思をもって定められれば素晴らしいですし学びも改善も進むと思いますが、それも現実的でないとき、手放さないのは核の部分、例えば会員制度であれば「会員であり続けることが報いられるか」「報いられるとはどういう体験で、それはどういう機能で実現されるか」だと思います。
すべてをスクラッチで作ろうとは言いませんが、何にこだわるのか、何が実現されないと仕組みの核たる部分が骨抜きになるのか、そこはすくなくともシステムの仕様任せにはできない。
仕様に決めてもらってよいことと、いけないことがやはりあると思っています。
—
既に存在しているソリューションのパッケージを使って効率的に実現するのはよいとは思いますが、そこで採用しようとしているのは何なのか。
「制度」の検討まで、知らないうちに委ねているのか。
あくまでやりたいことが見えているうえでの「機能」の手配なのか。
その区別が、選ぶ側も、売る側も、緩い状態だとあまり幸せな結果にはならないと感じています。
—
繰り返しますが、すべてを自分たちで決める時間もコストもないことは全く珍しくありません。
でも、どの線が知らないうちに引かれているのかに、気づくことはできる。
そのうえで、ここだけは自分たちで決めよう、という一本を選び直す。
そうしたシーンで、役に立てられればと思っています。
