楽をする体質を作る

TD;TR

開発で楽ができないのはプロジェクト管理とかそういう次元の問題じゃない。 楽をするための知識、技術を身につけようよ。 自分が目指したいのってそこじゃないのかな。

気持ち良く開発をするということ

気持ち良く開発をすることを目指す。 僕にとって気持ち良く開発をするというのは、楽をすること、気持ち悪くない開発。「幸せは不幸でないこと」みたいに逆説的だけど、やっぱりこれがしっくりくる。具体的にいうと理不尽なことに悩まずに開発をすることだと思う。理不尽なことには人間関係とかもあるだろうけど、それについてはここでは扱わない。じゃあ僕にとって気持ち悪い開発ってなんだろうか。

気持ち悪い開発

言語化は難しいのだけれど、僕のイメージは、負のスパイラルが起こること。時間に追われるから最短距離で終わらせることを目標としてしまって結果、より時間に追われること。じゃあ、なんで時間に追われているのだろう。ちゃんと見積もって、仕事量を調整できれば問題ないのだろうか。それだけでは不十分だと思う。開発、さらには運用の両方をやっていると突発的な問題が出てくる。

• 想定していたよりも複雑なコード
• 技術的な課題、バグ
• 手続きが多いリリース作業（マニュアルでの作業が多い）
• 本番環境のトラブル
• 時間のかかる復旧作業
• 分かりづらい仕様に対する問い合わせ

要するに不確定要素、変数が多すぎる。一方でプロジェクトマネージャーからの「いつまでに終わる？」という問いに答え続けなければならない（これはPMの仕事だからしょうがない）。結果、時間に追われ、なるべく変更が少なくて済むように、事なかれな修正、開発をしてしまう。

負のスパイラル

上記のように時間に追われた結果、消極的な開発をして、結果なぜか余計に時間に追われることになる。この矛盾を抱えたままが非常に気持ち悪い。先に羅列したようなものは技術的負債によって引き起こされると思っている。負債のために、時間に追われ、そしてまた負債を残したり増やしたりしてしまう。気持ち悪い開発にストレスもたまる。こうして負のスパイラルが起こる。

スパイラルの原因は開発の優先順位の付け方なのか

この負のスパイラルを止めるためにはどうすれば良いのだろうか。最近までは「ビジネス的な価値、つまりお金になること（例えば新機能の実装とか）ばかりを優先して開発を繰り返した場合にこういうことが起こる。だから負債を返済するフェーズを取らないといけない」と考えていた。要するに開発の優先順位の付け方に問題があると思っていた。

でも考えが変わった（この記事を書いている途中で考えが変わった）。そんなことをしたとして、果たして負のスパイラルは本当に止まるのか、という疑問があったからだ。上記で挙げたことって、変更しやすいコードや運用しやすい設計をする知識や技術がないからそうなっているんだと思う。時間を設けたところで、正しい知識や技術がないと負債はなくならない。どこかの漫画じゃないけど、「開発における不利益は全て当人の能力不足」なんじゃないか。

技術の不足をどう補うか

勉強は大いに歓迎する。でもちゃんとスケジュールを引いたプロジェクトやロードマップの中に組み込むとおかしなことになる。タスクが勉強することに依存してしまうからだ。技術検証なら良いけど、一から学ぶところから始めるというのは良くないと思う。変数の変動が大きくなるし、実際タスクはいつまでも終わらない。だからといって、「プライベートな時間に勉強しろ」って言いたい訳じゃない。それ自体は大いに結構な事だとは思うけれど。業務時間内で勉強をすべきだ。実際それを取り入れてるって話はいろんなところで聞く。

まず学ぶべきは

ただ、とりあえず先端技術に飛びつくのはよくないと思う。「うちはk8s取り入れています」って言いたいだけでやるべきじゃない。そんなのIoTとかAIってバズワードに飛びついてる会社の経営陣と変わらない。それで開発が良くなるならいいけど、会社の金を使って勉強をするなら、有用性は意識して勉強すべきだ。そして個人的にはその時間を負債を作らないための知識、技術をつけるのに使うのが先決だと考える。 そう考える理由はリソース（人）が限定されているからだ。リソースが限定されているならリソースが少なくても回るシステムを開発すべきだ。仮に人を入れたとして、負債が溜まっているプロジェクトなんて誰も長くいたいとは思わない。優秀な人ほどそうだろう。結果、人の入れ替わりは多くなる。人の流動が激しいチームはそれだけ新規メンバーにコスト割く訳だから余計リソースが制限される。

僕が目指すこと：このブログで書きたいこと

僕が目指すのは負債を小さく維持して、楽に開発できる仕組み、技術を学んで導入すること。このブログはその活動や考えを記録して、自分がしたいことを忘れないために使いたい。

裏ミッション

なんで自分がここまで負債にこだわるか。負債があるとそれを引き受けて犠牲になる人がいる。大抵の犠牲者は優しい人で、そういう人は心を病むか、優しくあることを辞めてしまう。あるいは何かに対して鈍感になってしまう。そもそも自分の意思を持てとか断り方を覚えろとか、これには意見が別れるところだと思う。けど、個人的にはそういう状況があること自体を悲しく思う。優しい人が優しいままでも満足に働ける環境を作る事が僕の裏ミッションである。

人は理屈で動かない

三行で

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

こんなシチュエーション

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

やったこと

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

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

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

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

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

期限を設けた

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

個別に話した

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

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

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

やらなかったこと

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

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

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

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

で、結局何が足りなかったの？（結論）

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

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

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

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

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

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