現在の勤務先に入社してからいつの間にか3年が経過していました。入社当日に入社したことを深く後悔するところから始まった（その後持ち直した）波乱の3年でしたが、振り返れば私はそんな中で勤務先を徐々に自分仕様に変えてきました。

ほとんどが破壊活動ですが、どんな変化があったのかを列挙します。まだ道半ばのものが多く、変化があったというものは意外と少ないですね…

広範囲に変化をもたらしたものもあれば、私だけ、または私の周囲のごく狭い範囲だけの変化もあるのですが、大事なのは前例をつくったことだと思っています。

PMが予算管理することをやめた

結局私がプロダクトマネージャーであってもなくても、組織全体としてはプロジェクトマネジメント至上主義で、そこには漏れなくスケジュールと予算がついて回る世界でした。当然のように予算管理を求められます。

私も最初は予算管理をしていましたが、最終的には他部署に予算管理業務を移管しました。もちろん今でも大まかな予算規模は把握していますが、発注のひとつひとつを管理したり、予算執行の承認をとったりというプロセスから解き放たれ、よりプロダクトに集中できる環境が整いました。これは私だけでなく、他のいくつかのプロダクトについても同様の状況になっています。

機能とスケジュールで話をするのをやめた

機能とスケジュールの話を一切しないというわけではありませんが、機能とスケジュール一辺倒の話をやめました。機能やスケジュールの話は、各機能に深く関わる人達とは引き続きしていますが、そうでない人達とはあまり話さないようにしました。かわりに、何を実現したいのか、どこにチャンスがあるのかという話をするようになりました。

コミュニケーションの密度は変えずに中身を変えたので、現状の課題や、どんなチャンスがあるのか、新たな発見は何なのかという話をする機会が増えました。

外部講演に関する規定に例外を生んだ

社内の規定で、外部講演はある一定の役職以上の者のみ可能ということになっています。

私は役職の規定を満たしませんが、関係者の方々の協力を得ながら広報と協議し、外部講演を特別に許可されました。

講演時や取材対応時にジャケットを着なくてもよくした

基本的にはジャケット着用がルールなのですが、「それは無い」と指摘しました。

ジャケットの着用を否定するものではありませんが、服装というのはいわゆるTPOに合わせて選択するべきもので、どのような媒体の取材を受けるのか、どのようなトーンでの取材になるのか、または講演時のオーディエンス属性などによって当然フレキシブルに変えるべきものです。

最近では逆にこちらから「ジャケット着ます？」と聞いても「いや、着なくていいですよ」と広報から言われることも多く、この柔軟性には感謝したいところです。

緊急時の連絡をPMが皆にするのをやめた

障害などの緊急時、社内の期待は私から各所に連絡をすることでした。しかし、連絡するべき先は経営層からお店のアルバイトスタッフまで多岐にわたり、単一のメッセージを一斉に発信するというわけにはいかないものです。

そもそも何か問題が発生した時、私が本来やるべきことはコミュニケーションではなくて障害からのリカバリのはずです。それを後手にしてでもコミュニケーションをとる人が評価されていたという事実もあったのですが、それは本質的には正しくないものだと私は信じています。

そのため、私は緊急時のコミュニケーションフローを整理し、緊急時のコミュニケーションを担当する人を置きました。私がある所に一報を入れると、コミュニケーション担当者が各所へのコミュニケーションを行い、私はリカバリに集中できるという体制を構築しています。

インシデント発生時のエクセルフォーマットによる社内報告をやめた

インシデントが発生すると、解消後に社内の担当部署にエクセルのフォーマットによるインシデントレポートを提出することになっています。

内容としては、発生した事象や原因、経緯、影響範囲、対策状況と今後の再発防止策などを網羅したものになっています。

システムの障害というのは大きな影響が出ない限り握りつぶすことが可能で、インシデントの規模の大小を問わずこのようなレポートの提出義務があるということは小さいものを握りつぶすモチベーションになり得ます。

私はこれについて訴え、インシデントレポートの簡易化を実現しました。基本的にはインシデント発生時のコミュニケーションはSlack上で発生するので、その流れでSlackからインシデントレポートをテキストベースで発信するという形に変更しています。

他部署の人を強引に巻き込んだ

この規模の会社でテクノロジー部門のメンバーが30人に満たない状況ですので、各個人がやるべき業務はそもそも1人で全部できるわけがないのです。

結果的にコミュニケーションにコストをかけることをやめてただひたすら職人のようにシステム開発に集中するタイプの人、ひたすらロードバランサーに徹して全ての業務をベンダーに丸投げするタイプの人など、タイプは違えど「何かを諦めて重要だと思うところに集中する」というスタイルで働く人が多い状況でした。

私は全部諦めたくないので、「1人でやらない」という選択をしました。他部署の人たちを朝会にも参加させ、「皆でやっていこうね！ズッ友だよ！」のノリで強引に巻き込みました。今のところそちら側の上司からのクレームも出ていないし、各上司への「こんなことしてくれてめちゃくちゃ助かってる！」のアピールもしっかり行っているので、まだ怒られないはず…

情報共有のための大人数の会議をやめた

有意義な会議もあれば、そうでない会議もあります。私が所属する部門で行われるある会議は、残念ながら生産性の低い会議でした。本来コアメンバーのみで議論するべきことも大人数の場で話すことで発散し、事前に各参加者の理解度のレベルも揃っておらず、結果的に議論は深まらず何の結論も出ない。しびれを切らして「この会議何か意味ありますか？」と聞いてしまったほどです。

聞くところによると情報共有のために必要だということだったので、まずは小グループで議論を行い、煮詰まった段階で大人数の場で結論を出すことで全体的な情報共有も意味のある会議運営もできるのでは、ということになりました。

ベンダーへの丸投げをやめた

テクノロジー組織が少数精鋭であるために、外注することが多いのですが、その時に丸投げすることをやめました。

本来は自前で用意するべきことができておらず、人もいないので仕方なく外注しているのであって、開発ベンダーの方々は我々のパートナーだと思っていたのですが、どうも「お客様」の立場としての仕事の出し方をする人が多く、あらあらと思っていました。もしその人達が同じ会社で働く社員だったとして、同じようなコミュニケーションスタイルを続けられますか？と…。

丸投げをやめるのは簡単で、
・who/what/whyを理解していない仕事は出さない
・納得していない仕事は出さない
・失敗したときに責任をとれない仕事は出さない
これだけです。

少なくとも、最終的に出来上がったものを見て落胆したり事後処理に奔走したりというリスクを減らすという意味では入り口の部分で多少の労力をかけたほうがいいのだろうと思います。皆が同じコンテキストを持って働けているに違いない、という思い込みほど危険なものは無いので、できるだけ具体的にwhyを語り、提示されたhowの妥当性をビジネスの観点で厳しく見ていくということが必要になります。

余談ですが、これをやるとベンダー側でも輝きを増す人と輝きを失う人がいるので、そういう産業構造に生きることに幸せを見出す人も一定数いるんだろうなというのは感じました。