※クラシル開発チーム向けの資料を外向けに公開した内容です

これから開発メンバーが増えてくるので、カルチャーを言語化してみた。今できている文化もあると思うし、今後の考え方を言語化したモノもある。

これをクラシル開発チームのオンボーディング資料として、継続的にアップデートしていくことにする。

これは何に使うのか

・新メンバー向けのカルチャー説明
・メンバー同士で声を掛け合ってカルチャーを浸透させていく
・採用面接やリファラル採用時の文化説明

作った背景

開発部もエンジニア、デザイナーが増えて組織が大きくなってきた。常にユーザーファーストであり続けられるよう今から言語化しておく事にする。

「成長痛」とも言われるが、ベンチャー企業の組織拡大に伴い30 / 50 / 100人の壁が存在していて、組織に歪が生じやすいし、個人で成果を出すのが難しくなってくるタイミングがある。

人が増えていく過程で様々なカルチャーが持ち込まれ、それぞれの想いがぶつかり、肥大化後にヤバいと思った時には遅しで、そこから軌道修正するのはとてもエネルギーを使う。

『前職ではこうでした』ではなく、過去の知識を活かしてdelyはどうあるべきかを話していこう。この資料は組織とサービスのステージに合わせてアップデートしていくと思う。

今のチームはとても良い状態だと思う。エンジニア、デザイナーが100人になってもこの気持ち良く開発できるチームを維持できるよう願いを込めて。

先ずその初稿。

当事者意識を持って視座を高め、視野を広げて相互理解量を増やそう

堀江さんのメッセージでもある当事者意識の幅と高さを諦めず、広げ続ける事を意識しよう。

料理に例えると、繊細で複雑な献立を100人で一緒に作っている状況だ。それは極めて難易度の高い作業で、隣の部門や異なる職種の状況を理解し合う連携が必要になってくる。

縦割りの視点を捨て、相手の状況を想像して、お互いに思考を共有することがその高い難易度を乗り越える攻略法だと思う。

元ネタ：当事者意識を世界に広げろ

全員が一歩でもボールをゴールへ近づけろ！

ユーザー体験はデザイナーや特定の人が作るのではなく、チームで作っていく状態を作りたい。健康診断のような感じで数字はチームでモニタリングして、対話して開発して行こう。時に個人プレーでいける所までいくのも大事。チームプレーと個人プレーの使い分けを意識しよう。

元ネタ：『シュート!』3巻の久保さん。

経験値は1人だけではなく、パーティー全員が得られるように

クラシルでは、チーム開発をとても大事にしているので、全員で成長していきたい。

僕は一応CXO（Chief Experience Officer）なんて、凄いデザインをしそうなカッコつけたラベルにしちゃったけど、1人でできる事なんてたかが知れてて、ユーザー体験はチームで作りあげていくスタイルを大事にしている。

前にもつぶやいたけど、自分の考えをチームに相談するし、意思決定の理由は可視化していきたいし、プロセスと結果の答え合わせを透明化する事が、経験値アップに効いてくると思うので、皆で積極的にやっていきたい次第。

人ではなくコトに向かおう

DeNA 南場さんがよく言ってたセリフ。色々学んだし今でもよく思い出す。コトに集中できるチームを維持しよう。もし半径5メートルの仲間が仲間を批判してたり愚痴ってたら、これを伝えて「コトに向かう」を思い出して欲しい。

元ネタ：DeNA南場智子さんの講演「ことに向かう力」がいい話だった【全文】

部門を越境案件の最適化努力

部門横断型の実現タスクはユーザー体験の評価責任が曖昧になり品質が落ちやすい。部門それぞれの正義もあるし評価軸も違う。マーケ側・営業側など部門の壁を超えてユーザーにとって最適な体験をワンチームで考えていこう。いざとなった時は部門トップが調整するのも大事。

言いたい事は、本人に直言しよう

伝言ゲームでDISられた時や調整された時ってショックが倍増するよね。当事者の自分に直接言ってよって事あると思う。発言した人にそんなつもりが無くても恨みを買いやすいし人間関係に亀裂が生まれるので、思う事があれば直言しよう。褒めるのは積極的にやろう。

クローズド主義かつ愚痴でチームの時間を奪う行為は粋じゃない。

意思決定プロセスをオープンに共有しながらやろう

DM(Direct Message)が絶対NGとは言わないが、開発はオープンに議論しよう。背景を皆が理解できた方が納得感が生まれるし、皆の知恵で解決していこう。チャットで収集がつかない時は声を掛けてぱっと集まろう。

席で話そう

空き会議室を探して関係者が揃うのを待つタイムラグが勿体ないし、仕様を決める行為は1日でも後ろ倒ししたくない。パッと話せば30分で決まる事はたくさんあると思う。コーディングやデザインに集中してる人も居るので同期 / 非同期コミュニケーションの使い分け大事。

あーこれは噛み合ってなくてやばいなと思ったら「今オープンスペースでさっと集まって話しますか？」と発言しよう。生産性が格段に上がる効果をもたらす呪文。

その後口頭で話した事のサマリをSlackチャンネルに流せば100点満点。

完璧を目指すよりも、まずは終わらせよう

Done is better than perfect (完璧を目指すよりもまずは終わらせろ) はFacebook創設者マーク・ザッカーバーグの名言。

時には会心の一撃も必要だけど、delyではユーザー評価ができる最小に絞ってジャブを打ちながら感覚を掴んでサービスを育てるスタイルを採用している。

その機能で何のパラメーターをどこまで上げれば、初期評価できるのか考え抜こう。

チームごとに独立性を担保しやすい組織とサービス設計を心がけている。僕が全社のデザインレビューをせずに、プロセスを可視化して常時ツッコミ型のプロダクトマネジメント手法を採用してるのは、属人的レビューで開発スピードを下げたくないから。

デザインプロセスを可視化してフロー型でやろう

何度も出ているがとにかくプロセスを可視化しよう。Slackチャンネルを職種軸で閉じず、機能軸で分けているのにはコダワリがあって、仮説、実現可能性、ユーザー体験を全員で考えるようにするため。

定例で話して軌道修正するよりリアルタイムで議論して詰めていくのが一番早い。目に見える形でアウトプットして、議論を加速させるのがクラシル開発流のデザインプロセスなので、フロー型で巻き込んだ設計をしていこう。

たまに『シェアすると意見が纏まらず収集つかなくなりません？』と言われるけど、そこに骨格を作ってブレないデザインを仕上げるのがプロの仕事。

最速で価値検証し続けるためにコードを書こう

上の話と似ているけど、スピードと負債と資産のバランス難しいよね。今のdelyはまだまだチャレンジャーであるのは間違いない。市場の価値検証、ビジネスとエンジニアリングのバランスを取る努力をしよう。

データの横断分析など資産を優先する時はきちんと説明して取り組む。

画像元ネタ：Making sense of MVP (Minimum Viable Product)

不可能を可能にしよう

エンジニアは魔法使いではないが「お互い理解する」コミュニケーションで、実現方法を考え抜こう。実現可能性を考えた結果コストや運用負荷などの具体的な話をしていくのが大事。

目的を達成するための実現方法を一緒に話していくのが大事。

自分たちが作ってるサービスを日常的に触ろう

サービス評価はユーザーと同じ環境で使わないと無理だと思う。100%無理。ユーザーに憑依する状態を維持し続けよう。

プライベートを削ってまで調理しろやって強制してるわけではなく、事業ドメインの食に興味ある人と一緒に開発していきたいじゃん。サービス愛を持って一緒に仕事すると楽んでサービス作れるよね。という話。

堀江さんはシャイで自分からあまり言わないけど、日常的に自炊して、毎日クラシルをエゴサーチして、ユーザーの気持ちを忘れずにプロダクト感覚を磨いている。そういう姿勢に刺激を受けるし、僕もユーザーの気持ちを忘れない状態で意思決定していきたいと思う。

そんな開発チームに興味があるデザイナー・エンジニアさんぜひご連絡ください！

クラシルエンジニア採用について

https://www.dely.jp/lp/recruit/index.html