フィードバックが欲しくて遺跡を残してしまった事件

Fukuiです。
再登場です。

今日はGYOMUハックAdvent Calendarの１７日目としての記事です。今回もさらに失敗談です。


フィードバックループの大切さ

ＩＴによる業務改善のプロセスで大切なポイントの一つにフィードバックがあります。かつてのトラディッショナルなシステム開発の時にはゴールが「システムのリリース」でしたが、ビジネスの成果が重要であるＧＹＯＭＵハックやアジャイル開発では、機能をリリースする前のプロセスよりも、むしろリリースしたあとにどういった対応をするかのほうが大切になってきています。自分も数年前のあるセミナーで武闘派CIOで有名な当時東急ハンズのＣＩＯ長谷川秀樹さん（現メルカリＣＩＯ）が壇上で言っていた「リリースしたあとのスピードのほうが大事」という言葉に衝撃を受けました。よくＥＲＰパッケージの導入において「リリース前に考えたアドオン機能の４０％は使われない」と言われていますが、最近聞いたセミナーでは「開発した機能の６０％使わない」なんて言われています。確かにまだ使っていない機能に対する非エンジニアの欲望は膨らみがちで「せっかくだから」とか「やっといたほうがいいから」と余計な機能を盛り込みがちです。まずは必要最低限のシンプルな実装を本番にリリースした後に、問題があれば素早く対応するほうが、全体的な効率は良いというのは実体験としても有効でしょう。その時に必要になるのが実際に使ってくれた人たちからの「フィードバック」です。これを素早く的確に集められるかが、プロジェクトの成功を支える重要なポイントです。


社内システムにおけるフィードバック

　よく「アジャイルって外部向けのＷｅｂシステムに使うもので、社内システムに使うものではない」という否定的な話を聞きます。しかしながらフィードバックを得やすいという点では、社外の本当のっ客様を相手にしたサービスよりも社内で使用するサービスのほうが、絶対にアジャイル開発に向いています。お客様は最悪のサービスを提供したら、自分たちのもとを簡単に離れてゆきますが、社員であればそう簡単には離れられません。会社を辞めるか、その業務から離れない限り、社内システムは使うしかないからです。しかも誰がキーマンなのか、だれが知見を持っているのか、そして誰が前向きなのか、そういったことまで社内だったら把握することが可能です。「誰に聞けば良いフィードバックを得られるか」をわかっているのだから当然です。しかも社内の場合はどんなに問題があっても所詮は社内の話です。お客様相手だったら最悪のクレームに発展しかねませんが、社内だったら社内のもめごとにしかなりません。誤っておけばいいだけです。挽回のチャンスもたくさんあるのです。社内のサービスこそフィードバックをベースに改善を進めやすいのです。



ユーザーってシャイ

　とはいえ社内ユーザーからフィードバックを得るのも簡単ではありません。なぜなら社内システムのユーザーはシャイだったりします。特に現場に近ければ近いほどシャイだったりします。営業の現場の人ならば別ですが、工場や倉庫、事務センター当たりの人は基本的に自分の気持ちを表すのが苦手です。だいたいは「間違っていたら恥ずかしい」「反論されたらどうしよう」など他人の仕事に意見をするのはどうしてもおっくうになります。さらに「言ったってしょうがない」「本部の人にたてついたら怖いことになる」とか「反対勢力として目をつけられたらどうしよう」なんて考えていたりもします。しかも物事を整理して論理的に話すのって意外に難しいものです。
だからいつも現場の人からフィードバックをもらうのは非常に苦労します。そのためにいろんな工夫もしています。そのなかのひとつが「わざとダメなものを作る」です。


わざとかっこ悪く

　人間というものは、なかなかスタートをするのはおっくうです。しかしながらいったんスタートを切ったら止まらなくなります。フィードバックも最初の一言さえ現場メンバーから出すことに成功したら、次々に出てきます。シャイな現場の人たちにいかに「最初の一言」を話してもらえるかが大事なのです。そのために自分たちのプロジェクトでは試してみたことがあります。それは「わざと出来の悪い機能を出す」です。誰も目から見てもダメなもの誰ばどんなにシャイで自信がない現場の人たちだってフィードバックの口火を切ることができます。
とはいえ「あまりにもダメな機能」だったら「こりゃあかん」とあきらめられています。しかも少なからず自分たちのプライドも傷つきます。モチベーションも下がるので機能的にダメなのはちょっと厳しいです。だからやるのは「デザイン的にダメ」です。字が小さすぎるとか、色が変すぎるとか、そういったわかりやすい瑕疵を埋め込んで、そこに突っ込みを入れてもらうという作戦をとるようにしていました。たしかにこれであればだれもが自信をもってフィードバックを出せます。業務のことをよく知らない新人でも簡単に指摘できます。



ダサいデザインがそのまま遺跡の様に

　しかし、これがうまく機能しなかったときは極めて悲惨なことになります。エンジニアというのは困ったもので「ちゃんとしたものを作ろうとする」という性質があります。フィードバックの余地を残しておけと言ったのに時間をかけてちゃんと作ろうとします。しかも「色とデザインをダサくしろ」といった言った指示だけはちゃんと聞いたりもします。ついつい微妙な感じに直してしまったりします。微妙に突っ込み出来ないような完成度で機能がリリースされる。そうなると時と場合によっては現場の人から最初のフィードバックが出なかったりします。対面フィードバックだったら、それでもしつこく聞いてフィードバックをもらおうとしますが、これがメールなんかでやったら、本当にフィードバックが戻ってこなかったりします。リリースされた機能が何のフィードバックも得られなかったら直す理由がありません。・・・・その結果、わざと仕込んだダサいデザインを残したまま機能が稼動し続けることになってしまいます。こうなると悲惨です。
残ってしまっただれの目で見てもダサい画面が長期間残ってさらしものになってしまったりします。見る耽美に心が痛む結果になったりもします。


・・・・・まるで遺跡のように残ってしまいます
　　


　　しょうもない話ですみません

　いくらフィードバックがほしいと言っても、やりすぎには注意しましょう