読者です 読者をやめる 読者になる 読者になる

太陽がまぶしかったから

C'etait a cause du soleil.

運用と開発の分離と定期的なモード切り替えをボスタイムとして意識する

photo by nmorao

運用と開発のよい関係

 ここのところで危機感を覚えているのは、個別の無茶振りに対して運用的な個別対応をこなせるようになった段階で終わってしまっていて、長期的な観点から機能に落としこむための視点と時間が不足していること。もちろん、個別対応はその場限りで終わることが多いし、すぐに対応しないといけない。暫定機能の継ぎ接ぎで作りこんでいたらプロダクトデザインが壊れてしまうので「運用でカバー」はある側面からは正しい。

 だけど、そもそも機能として実装されていれば、作業者を選ばないし、手順に抜け漏れがないかヒヤヒヤすることもない。個別の運用対応依頼が来るということは、やはり機能としての不足がある。開発者としての視点が強すぎると、こっちで作った機能にビジネス側が合わせろというお門違いに陥ることも多い。物を作るだけでは自己満足に過ぎなくて、提供できるサービス価値に主題がある。

運開分離をしすぎてもしなさすぎてもうまくいかない

 運用開発の分離(運開分離)によって運用と開発を違う人がやると互いに無責任になるというか、問題の対応を相手側に負担してもらおうという意識になりがち。その一方で「運開一体」をし過ぎると、個別対応に時間が取られすぎてプロダクトデザインの意識が希薄になるし、複数のことを同時に達成しようとジャグリングしてミスりがち。

 結局のところで運用と開発を同じ人がやりつつも、明確にモードを切り替えて対応することが必要なのだろう。「何を求められているか? どう対応したか?」の記録を取りつづけて、その一方で定期的な棚卸しをして製品機能として必要な部分をリストアップする。

 どうしてもビジネスサイドからの要望や、あまり活用される根拠のない機能追加に精一杯になりがちなのだけど、個別運用対応が必要になった原因を抽象化して今後のビジネスサイド要求を予測しながら内発的な機能改修に落とし込まないと、運用負荷が際限なく増えてしまう。当たり前の話なのだけど、日々が忙しいと忘れそうになる。

普段の生活でも運用と開発の分離と定期的なモード切り替えが必要

 普段の生活でもライフハック的な視点が強すぎると、その時に影響をうけた外発的な何かによって劇的な生活習慣改善をしようとするのだけど、日々の生活によって「なかったこと」になってしまう。その一方で、毎度面倒に思うようなことは存在しているわけで、それらの対応に時間を取られ続けても仕方がない。どこかのタイミングで棚卸して長期的な改善対応を行うことが「利息」になっていく。

 id:MoneyReport さんが「ボスタイム」として、1ヶ月に1日は着手している仕事だけに没頭するのではなく、今後の経営戦略を練るために1人で考える時間を設ける活動を紹介しているのだけど、これって、結構大事だなと。

 成果ベースの目標設定や「ふりかえり」の時間は設けていたものの、長期的な改善アクションにあまり繋がっていなかったように思う。改善(開発)と日々の暮らし(運用)の「両方」をやらなくっちゃあならないってのがつらいところだけど、人間の能力には限界があるわけで、ジャグリングできないものはできない。開発モードと運用モードを切り分けつつも定期的に切り替える習慣づけが必要になるのだろう。

「守り」から「攻め」に転換する システム運用完全ガイド(日経BP Next ICT選書)

「守り」から「攻め」に転換する システム運用完全ガイド(日経BP Next ICT選書)