怠けて成果を出すシステム開発

エンジニアはもっと楽をしていい、でも確実に成果を出したい。そんな願望を実現するための試行錯誤を書く。人の入れ替わりが激しい業界なんだから、入れ替わっても大丈夫な開発を目指したい

人は理屈で動かない

f:id:foomin_0xee:20200112162947p:plain

三行で

  • 開発してるシステムでユーザによるマイグレーションが必要だった
  • メリットを理解してもらえればユーザはやってくれるだろうと思っていた
  • でもすぐには動いてくれなかった。僕に足りてかなったのは何だろうか

こんなシチュエーション

僕は社内のデータプラットフォームを作っている。社内の様々なチームがユーザで影響も大きい。UXを良くしたくて数年間変わっていなかったUIに大きく手を入れて、ユーザの使い方を大きく変えた。 ただ、色々変更点があったので、ユーザによるマイグレーションが必要だった。

やったこと

以下に試行錯誤したことを書いておく。

ユーザのメリットを説明した

ユーザを集めたミーティングを開催して、新しい使い方に移行すればどんなメリットがあるかを説明した。 これが良い変化だと僕らのチームは信じていて、その良さを理解してもらえれば、ユーザは快く受け入れてくれるだろうと思っていた。僕はメリットを伝えることが一番重要だと考えていた。が、これはあまり効果がなかった。ユーザからしてみれば今までの使い方に慣れていて、新しい使い方に移行したり、最適化する手間を考えるとあまりメリットには感じなかった、というのが本当のところだと思う(実際そういう意見もあったし、こっそり古い使い方を続けたユーザもいた)。 また、メリットを感じても、必要性にまでは至らなかったようだった。

マイグレーションのハードルを下げた

設定画面から一つの設定を切り替えるだけでいいようにした。これはユーザを動かすことにはあまり貢献しなかったけど、移行手順を単純化したことで、後々説明する僕らの手間は減った。

期限を設けた

急に降って湧いたみたいなことをユーザにお願いするので、これはあまりやりたくなかった。けど、目安がないといつまでも伸びてしまうということは避けたかった。2ヶ月移行期間を設けた。他のプロジェクトもあるので、期限については相談に乗るというスタンスをとった。ちなみに実際には、大半は4ヶ月くらい。完全に移行が完了したのは10ヶ月だった。

個別に話した

個別にチームの人と話して、どんな状況か、どんな障害があるかをヒアリングして個別に対応した。これは手間だけど、お互い信頼関係が築ける方法だと思う。また、僕の当初の見通しに穴があったことに気づくきっかけにもなった。

各チームの移行状況を見える化して共有した

最初は移行の進捗状況を管理するために作った表と円グラフがあったんだけど、進捗が芳しくなかったので、ユーザとのミーティングで共有した。まだ移行が終わっていないチームを吊るし上げるみたいな感じになってしまうので、正直やりたくなかったけど、先に期限を提示してるって言い分もあったので、こうするに至った。 ちなみにこれが一番効果があって、大半のチームが動いてくれた。危機感を煽るようなやり方はぶっちゃけ本意ではなかったで、ちょっと悔やまれる。

やらなかったこと

各チームの上司への根回し

有効な手段の一つ。各チームの上司を説得して上からの指示で強制的にやってもらう。 でもこれはやらなかった。このやり方は動機付けが外部からでやらされてる感が半端なく、楽しいものではないから。

今更ながら、移行の方針について

ここまで読むと何となくわかってもらえると思うけど、結構甘々な対応だったと思う。これが移行に時間がかかった根本的な原因だったと考えられる。周りからはもっと強制的にやらせろとかアドバイスをもらったりもしてた。 「気ぃつかいだから」と言われたりもして、それも大いにある気はする。けど一方で、自分が逆の立場だったら「強制的に何かを押し付けられるのはしたくない」って思うだろうから、内的な動機付けをするやり方を模索したかったっていうのが本音だと思う。

で、結局何が足りなかったの?(結論)

結論からいうと、僕が自身が新しい使い方の価値を信じることができていなかったと思う。「自分はもっとUXを良くしたい!これがユーザのためになると信じてる!」的なことはさらっとしか言わなかった(言うには言ったけど事務的な感じで言った気がする。あんまり僕の思いが乗ってなかったと思う)。そして大事なのは自分が信じないと他の人も信じてくれない。 何でこう考えるかに至ったかと言うと、DevOps Tokyoで何回か耳にして『Fearless Change』って本を読んだから。アイデアを組織に広めるための「パターン」が書いてある(GoFデザインパターンみたいに「こういう場合はこのパターンが効果的だ」って感じのもの)。 その本では第1章ですでにこう書いている。

研究の結果、変化を引き起こす要因について、多くの人が共通の誤解をもつことがわかっている。一つ目の誤解は、「いいアイデアであればみんなに受け入れられるというものだ。(中略) 二つ目の誤解は、「新しいアイデアを紹介すれば、あとは何もしなくてよい。」というものだ。

はい。そう思ってました。すみません。試合開始のゴングが鳴ってすぐに顎にアッパーを入れられた気分だった。そして最初にすべきこととして書かれているのが、自分がアイデアエバンジェリストになること。これがパターンの起点とされている

もしあなたが提案書への信仰心を持っていないなら、草の根で普及させるという穴ぼこだらけの道を踏破できるとは到底のぞめない。

僕の場合、ユーザのUXは本当に良くなるのだろうか、という懸念はぶっちゃけあった。開発チーム内で十分に検討はしたものの、ユーザへの予備調査なしで全ユーザに広めてしまったからだ。ちなみに予備調査についても『Fearless Change』で最初の方に使えるパターンとして紹介されている。

ほんとは確信を持ててから広めるべきだった。今振り返ると結構最初の方で失敗していたのかもしれない。次からは自分が確信をもつところから始めようと思う。そして確信を持てれば、次はもっと積極的に人に導入してもらおうと動けるようになるはず。そうすれば、同じ思いを持った人が動き出してくれる。 人というかまずは自分を理屈ではなく、情熱を持って動かすべきだと知った