「CREって何？」と思っている人に、CREの導入を勧めたいでも書きましたが、開発ディレクターとしてCREチームに配属されて、半年以上が経ちました。

CREに開発ディレクターを投入するというのは、弊社では前例がなく、
ロールモデルがないために「どうすればいいんだ？」と
頭を悩ませながらの半年間でした。

ここでは、私が普段の業務でやっていることや生まれた成果などを挙げながら、「こんなお悩みを抱えているのなら、開発ディレクターをCREに投入するのもありかもよ！」という提案をしていけたらと思います。

最近の私の一日

最近の私の一日は、こんな感じです。
世の中の総合職とそう変わらないように見えますね。
違うところがあるとしたら、お問い合わせへの対応や、法律に対応した新機能を作るための予備調査、お問い合わせで判明した問題を解消する方法の提案などを行っているところ。

出勤
メール/GHE/Slackの確認と返信

午前
新機能のお知らせ作成/法律対応の事前調査/機能改善の要件整理

昼
昼会/寄せられているお問い合わせの確認

午後
PdM定例/CSとの相談会/新機能のお知らせ作成/法律対応の事前調査/お問い合わせ対応

退勤前
メール/GHE/Slackの確認と返信

私はエンジニアでもCSでもないので、お問い合わせ対応は本来私の仕事ではないのですが、
CREにくる問い合わせのなかには、「開発ディレクターが一番詳しく把握していること」に関する問い合わせもあるので、それについては私が対応しています。

CREディレクターの仕事

CREチーム配属から今までの間に、私がやってきたことは以下の３つです。

1. CREがやること・やらないことを判断する（提案する）

2. CREチームが目指す方向を示す

3. 他のチームとの連携ルートを作る

CREがやること・やらないことを判断する（提案する）

これを言うとCREのネガキャンみたいになってしまうのですが、
CREはユーザーからの問い合わせを起点に動くチームなので、
タスクの進行管理が難しいです。

どんな開発チームにもスケジュール遅延はつきものですが、
CREは基本的に「スケジュール？なにそれおいしいの？」という感じになります。
スプリントごとに、「これを終わらせるぞ！」と決めはするものの、
問い合わせや他のチームからの依頼によって、予定通りに終わらないということはよくありました。（最近は、改善傾向にある気がするけれど）

CREには毎日10件くらいの問い合わせが来るし、
その中には、不具合っぽいものもあって「修正しなきゃね」となる。
他のチームから、「これも対応してくれない？」と依頼される（チーム間の依頼は、CREに限らずあるものと思いますが）。
果ては何やら法律改正で、「この機能、このままだと違反した状態で利用する人が出てきてしまうよ」なんてことも。

とにかく、「やらなきゃいけない気がする」ものが山積みになりがち。
どんな開発チームそうでしょうけれど、
実現したい機能の数に対して、割けるリソースは圧倒的に足りない。
そうなると、当然ですが、取り組むことの取捨選択は必須です。

が、私が配属される前からCREチームに在籍していた方々によると、
「とにかく全部やらなきゃいけないと思って、全部やろうとしてきた」と・・・。
まずお問い合わせへの対応を最優先、で、不具合の修正もできるだけやろうとするけれど、お問い合わせも認知した不具合も日々増えていくので、
着手してそのまま放置してしまうものも少なくなかったとか。

ある人に言われたのですが、
「エンジニアには技術があって、その技術があると解決できそうな気がするから、何でもやろうとしてしまう。」
らしいです。

CREのような、日々「やらなきゃいけない気がする」ことが山のように積まれていくチームにおいて、「何でもやろうとする」は、本物のいばらの道への第一歩だと思っています。

というわけで、「やらなきゃいけない気がする」ことたちの仕分けをしていこうよという話を、配属してわりとすぐにしました。

そして、何か「やらなきゃいけない気がする」ことが現れた時は、
さてこれは「本当にやらないといけないこと」なのか、いったん放っておいていいことなのか、をチームで話して仕分けていきました。

こうした動きをすることで、
「今までは『やらなきゃいけないことがたくさんある！』とつらくなっていたけれど、こうしてみてみると、やるべきこと・やらなくてもいいことが分かって、楽になった」
と言ってもらえました。

常にやることがあって忙しくて・・・というのは、誰でもしんどいものだと思うので、
チームが長く機能していくためにも、タスク整理は必須だと思ています。

CREチームが目指す方向を示す

「CREがやること・やらないことを判断する（提案する）」とも関連する話なのですが、そもそもCREチームが何を目指しているのかがはっきしりないと、やらないといけないことと、そうでないことの区別はつきません。

CREチームに配属される前に先輩ディレクターから、
「CREチームのKPIやミッションをはっきりさせたほうがいいよ」
と言われるも、いろいろに忙殺され＆チームの状況把握ができておらず、
「CREチームって、何を実現するために、何をするチームなの？」
が明確になっていませんでした。
「お問い合わせに回答して、お問い合わせが特に起こりやすい箇所の修正ができればいいんですよね・・・？」と思っていたので、
チームの方針があることは大事だけれど、最優先で取り組むべき事項であるとは認識していませんでした。

が、いざ配属されてみると、
お問い合わせは対応できているけれど、機能改善までは手が回っていない状態。
このままでは、ただひたすらお問い合わせの対応をすることになり、それ以上のCRE効果を発揮することはできない！
そう危機感を覚え、そもそもCREが何を目指していくのかをはっきりさせなくてはと考えました。

CREは、寄せられた問い合わせに回答するための情報を提供すればOKというわけではありません。
問い合わせに回答していくだけでは、ユーザーに信頼されるアプリケーションはできません。
名前にもある通り、CREの役割は、ざっくりと言えば、
「あれこれ心配せずに使い続けられるアプリケーションの提供を保証すること」
です。

そのために、CREチームはどういう状態になっているべきか、
その状態に到達するために、やっていくべきことは何か、
ということを考え、整理し、文章化してチームに共有しました。

具体的には、お問い合わせの対応だけで仕事が終わってしまわないように、
お問い合わせ対応の効率化をすることや、
判明した不具合の改善をCREだけで負わずに済むようにすることなど。

また、CREがやること/やらないことの根拠となるように、
「CREは、何のために何をするチームなのか」という定義を作ることも提案しました。
これに関しては、自分でも都合がつかず延び延びになっていたのですが、
チームの状況に危機感を覚えたメンバーから、
「やっぱり決めたほうがいいんじゃない」と後押ししてもらって、
何回かミーティングを設けてチームで相談して決めました。

そうして決まったのが、
「カスタマーサポートと連携し、技術でショップオーナーの不安を払しょくするチーム」
でした。
これは、今年3月時点での定義なので、チームや事業部、サービスの状況を鑑みて変えていく予定です。

他のチームとの連携ルートを作る

「CREチームが目指す方向を示す」でも書いた通り、
現時点でのCREチームの定義は、
「カスタマーサポートと連携し、技術でショップオーナーの不安を払しょくするチーム」
です。

ここからもわかる通り、現在CREチームは、お問い合わせへの対応をメインで行っているカスタマーサポートとの連携を意識しています。
十分に連携できているかと言われれば、そうではないのですが・・・（だから、意識するために定義に入れたという）。
なぜなら、CREにくるお問い合わせは、たいていの場合カスタマーサポートを通って来るからです。
カスタマーサポートの方のほうで対応できるタイプのお問い合わせが増えれば、
CREにエスカレーションするよりも早くユーザーに回答できるし、
カスタマーサポートもCREもやることが減ります。
つまり、CREとカスタマーサポートとユーザの三者の業務効率改善につながるのです。
そのようにするために、カスタマーサポートとの連携を意識しています。

また、お問い合わせによって発見した問題は、CREだけで解決できるものであるとも限りません。
それにも関わらず、発見した問題をCREだけが知っている状態にしておくことは、いいことであるとは言えません。
また、問題ではないにしても、「こんな風になったらいいのに！」というユーザーからの要望を含むような問い合わせであれば、
開発チームが新たな機能を作る際の参考になります。

いずれにせよ、お問い合わせから分かったことを
CREだけの宝物にしてしまうのはもったいないので、
他のチームにも共有するようにしています。

幸い、私のいる事業部は、Slack上での交流が活発で、
「こんなお問い合わせがありましたよ」と投稿すれば、誰かが反応してくれます。
また、それぞれの開発チームのPdMや代表者を集めた定例も開催しているので、そうした場で問題提起や情報共有をすることもできます。

私が敬愛する先輩によると、ディレクターの仕事は
「エンジニアとデザイナーがする仕事以外のこと全部」
なのだそうです。

その中でも特に大事なのは、組織の赤血球になることだと私は思っています。
具体的には、それぞれのチームがうまく機能していくために、
情報という名の酸素を運び続ける必要があります。

とくにCREは、多くの情報を持っているチームであり、
多くの情報を必要とするチームでもあります。
開発チームが作った機能が発端となって問い合わせが発生することもあり、
そうした際に、新機能の存在を認識しているといないとでは、
問い合わせがの対応にかかる時間が大きく異なるからです。
ということもあり、私は他のチームと連携して情報のやり取りをすることを特に大事だと感じています（十分にできているかと言われればそうでもないです。精進します）。

CREにディレクターを配属することの価値

正直なところ、すでにエンジニア・デザイナーのみでうまく回っているのであれば、貴重な人件費を割いてディレクターを配属する価値はそこまでないと思います。

CREというのはかなり新しい専門職であり、
日進月歩、二歩進んで三歩戻るみたいな状況になっているところもあるのではないでしょうか。
もし、そんな状況に陥っている原因として、以下のようなことが考えられるのであれば、まずはお試しで3か月くらい開発ディレクターを投入するのも手ではないかと思います。

• 「やらなきゃいけない気がする」ことが山積み

• 「やらなきゃいけない気がする」ことを片っ端から対応しようとしているが、うまくいっていない

• 他のチームとの情報共有がうまくいっていない

• そもそもCREの存在意義が分からない（自分がなんのために働いているのか、見失いかけている）

自分で言うと誇大広告みたいでアレなのですが、
やること山積み激務のCREにとって、
お問い合わせ対応においては戦力外なディレクターは、
うまく機能すれば「北極星」になりえます。

何を実現するためにチームが存在しているか、
そのためにやっていくべきことは何か、
誰と協力し合うべきか、
などなど、状況整理・改善をするのはディレクターの専門領域だと思います。

果たして私が北極星かと言われれば、百歩譲っても、しし座って感じですが・・・。