SSブログ

フィードバックが欲しくて遺跡を残してしまった事件 [DevOps失敗談]

Fukuiです。
再登場です。

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


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

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


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

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



ユーザーってシャイ

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


わざとかっこ悪く

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



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

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


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


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

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




nice!(0)  コメント(0) 

カナリアの森をサーバーに作ってしまった話 [DevOps失敗談]

Fukuiと申します。
ハードコアパンクと公園遊具をなんとなく愛し続けているおっさんです。

今日はGYOMUハックAdvent Calendarの10日目としての記事です。みなさんの記事が素晴らしすぎるので、ちょっとハードルを落とした話をしてみようと思います!



 仕事は社内情シス


SoRと呼ばれるあのドイツのERPから、SoEの代表のSalesforceまでいろいろなシステム領域を担当しています。いろいろなことをやっていますが、現在はそのなかでAgileとかDevOpsという新しめのアプローチもいくつかのプロジェクトの中で試しています。限られたメンバーの力を最大限に生かしながら、いろんな工夫をしてビジネスの課題を解決してゆくという面ではGYOMUハックとは非常に親和性の高いアプローチだと思っています。特にSaaSの場合は親和性が高いアプローチで、Salesforceの学習コンテンツ「Trailhead」でもAgileアプローチのコースがあったりします。

今回は私のAgile試行チームでやらかしてしまった失敗を解説つきで話します。みなさんはそんな失敗しないでくださいね。でも失敗こそが最大の学びというのがAgileの基本的な考え方なのですので、チャレンジしたからやらかした・・・というのは悪いことではないでしょう。




カナリアリリースとは?

 DevOpsやAgileアプローチの中の技法でカナリアリリースというものがあります。カナリアリリースは新機能や新しいバーションのプロダクトをいきなり本番環境のユーザ全体にリリースするのではなく、一部のユーザにのみ小規模に提供することによって、新バーションによる悪影響のリスクを最小限に抑えながら、できるだけ早いフィードバックを得ようというデリバリーの手法です。一般的なリリース時のリスクとされる悪影響として考えられるのは、システム負荷の急上昇、不具合による業務混乱、新しいバージョンがウケ無かったときに利用者からの批判が炎上してしまうなどの事態で、ちょっと自信が無いとき、利用者の利用頻度や利用行動が読みきれないときにはこのカナリアリリースというアプローチは非常に便利なアプローチです。
 最近はGCPのサービスなどで「アクセスしてきたユーザのうち、10%のユーザーに新バーションを提供する」「カナリアリリースしたプロダクトのモニタリングと承認ワークフローを提供する」みたいなカナリアリリース向けの機能なんかもちらほら見かけるようになってきています。そういえば最近ラスベガスで行われたAWSのイベントでもこのサービスが発表されていたようです。まさにカナリアリリースはこれからが旬のアプローチと呼べます。

 ちなみに何故カナリアと呼ぶかと言うと、むかし炭鉱とかの過酷な環境で作業員の生命をおびやかす有毒ガスを人的被害が出る前にすばやく検知するために、環境変化に弱いカナリアを籠に入れて持ち歩いて作業場所の「有毒ガスセンサー」としたことがはじまりです。センサーにされてしまうカナリアさんはとても気の毒なのですが、ガスのセンサーがない時代には人命を守る大事な手法だったのだと思います。そういえば最近テレビで見ましたが、20年ほど前、地下鉄サリン事件を起こしたオウム真理教の山梨県の施設(サティアンとか言われていた建物群)への警察の一斉捜査で機動隊の人たちもサリンを恐れてカナリアの籠を持って突入したときの映像が記憶にあります。



カナリアリリースをやってみた対象

 こういうアプローチは長年のシステム開発の経験から、「プレリリース」とか呼びながら、いろいろ工夫してやってきていました。とはいえ今GoogleやAWSで提供され始めたカナリアリリース向けの機能なんか存在もしていないし、社内システムにおいてはフィードバックをくれそうな特定のユーザーで試したいということもあり、非常に雑ではありますが、独自の方法で我々はこれを実施していました。

 対象としたプロジェクトはERPの基本的に社内向けのシステム開発。各機能を最小単位にサービス化して、そのサービスを使いまわしながら、ユーザーが直接接する機能を提供するという今でいうマイクロサービス的なアプローチで、普通に提供されるような「〇〇検索機能」とかとはちょっと違った観点で機能を提供する事を試みていました。例えば「自分が取って来た受注が後工程で処理が進んでいるかをリアルタイムで追跡する機能」とか「まとめて処理した受注をいっぺんにチェックする機能」みたいに、ユースケースを明確にした尖がった(変な)機能にパッケージングして提供するというかなり実験的な試みを狙っていました。こういった新しいアプローチなので正直現場に受け入れられるかどうかもわからないし、思ったより使いすぎるとサーバの性能を使い切ってしまう心配もあるという「危険」なアプローチなので大胆なんだけど慎重さも必要というプロジェクトでした。
 このちょっと自信のないプロダクトたちをいきなり全国にいる利用者たちに大々的に提供する自信は無く、いろいろ考えた結果といて「一部の尖がったユーザー」にこっそり使ってもらってフィードバックを得たり、性能の問題を確認したりしようと「カナリアリリース」を考え出しました。
やり方はすごく簡単で作った機能をみんなの目につく「メニュー」には一切載せないで、そのかわりに直接URLをフィードバックをもらえそうなユーザー個人に主旨を説明して、こっそり教えるといったもの。今風の自動的なカナリアリリースの仕組みとは程遠い原始的な方法でしたが、確実にターゲットのユーザー層からフィードバックをもらえるので我ながらよい作戦と思っていました。


カナリアの森
 
 この試みは早くから意外とうまくいき、いくつかのプロダクトは安全性を本番環境で確認することができたり、(おかげで厳しいインフラ担当の人たちを納得させられました)そこそこ現場の利用者にウケる事も確認したうえで自信をもって正式リリースをすることができました。やはり実際に使ってもらったフィードバックは的確で必要最低限で効果的な改善が進みました。そのうち「新機能はカナリアで試してから出す」という形がこのプロジェクトではスタンダードになり、若干完成度が低くても素早く提供して素早いフィードバックをもらい、完成度を高めてから本格リリースをするというのが一般的になりました。・・・・・それはそれでいいことだったのですが・・・・・

 このプロジェクトも順調に進み、機能が増えてきたので、あるときメニュー機能をもっと柔軟で使いやすいものに見直そうということになりました。メニューを再構成する作業の中で、サーバーの中のプロダクトを棚卸しすることになったのですが、その時にチームメンバーは気が付いてしまいました。
悲しいことに、カナリアリリースされたプロダクトがちゃんと管理していなかった事が、それがきっかけで発覚してしまいました。恐ろしいことにサーバーの中には「カナリア」だらけ、メニュー化されていないプロダクトであふれていることに気が付きました。まさに「カナリアの森」のようになっていたのでした。ログで調べると、そのカナリアたちはしっかりと試行先での利用実績があり、URL直リンクのまま業務が行われ続けていた事がわかりました。ほかの誰にも気が付かれずにずっと使われていたのです。・・・・もったいない。というか最初はきちんとフィードバックをトレースしていたのですが、量が増えるにつれてその管理が雑になり、忘れ去られたプロダクトがサーバの中に放置されていたのです。

   とほほ・・・

   あほな話ですみません




大事なこと
 
 ここで反省すべきは計画です。計画というよりもフィードバックループの間隔とか、見切りのタイミングとかをあらかじめしっかりと決めておいて、一定のリズムを守って確実に本番リリースまでもっていく事です。
カナリアリリースももっと一般的になってくると、特定のユーザーを狙って新バージョンを提供し、そのレポートや、全体へのリリースまでをしっかり管理する仕組みができてくるかと思います。
この失敗はともかく、カナリアリリースのアプローチはユーザから有効なフィードバックをもらうには非常に有効な手段です。みなさんも意識して使ってみてはどうでしょう。






nice!(1)  コメント(0) 

この広告は前回の更新から一定期間経過したブログに表示されています。更新すると自動で解除されます。