1
/
5

Wantedlyは、270万人が利用する国内最大のビジネスSNSです

This page is intended for users in Japan. Go to the page for users in United States.

超自律駆動型開発を支えるDIGGLEの組織風土

こんにちは。DIGGLEのインターン生の高田ひなこです。

本ブログでは、外側から見えづらい、DIGGLE開発チームを知って頂くために、チームを牽引するCTO・水上さんにインタビューをしました。

チームの全体像から細部に至るまで、様々な視点からお届けします。




高田:まずはDIGGLEの開発チームについてお聞きしたいのですが、現状はどのようなチームでしょうか?

水上さん:少人数というのもありますが、自律的に動いているチームだと思います。今は会社がスタートアップのフェーズなので、「仕事が降ってこないとやらない」というタイプの人は難しいと思います。なので現状は、「自律駆動型」ー何をやるべきかというのを自分で考えて進められるチームだと思います

高田:チームの課題はありますか?

水上さん:あまりないですね。仮にあったとしても、チームの課題はチームがすぐに解決しています。振り返り時に、メンバーが何か問題提起をして、他のメンバーがそれに対する打ち手を提案します。いわば、チーム自身がチームをマネジメントするという状況ですね

高田:チームがチームをマネジメントする…?

水上さん:そうです。例えば、一人の人間で考えてみてください。もし明日予定があり、早く起きなければいけないならば、夜にアラームを設定しますよね。これは自分で自分をコントロールしている、いわばセルフマネジメントしているということになります。これと全く同じ形がチームという大きさで行われているということです。

高田:水上さん自身が上司として働きかけているわけではないんですね。CTO=経営側としての水上さんの役割って何なんですか?

水上さん:僕の役割は、この自律駆動のチームを見守っていくことと、そのチームが達成するべきミッションの明確化です

高田:なるほど、具体的にはどのようなことをやっているんですか?

水上さん:前者については、DIGGLEはスクラムという、アジャイル開発の一つの手法をとっています。そこで振り返りを実施して、「どうすればチームが継続的に改善されていくか」をチームで話し合うようにしています。簡単そうですが、少しコツが必要です。たとえば「特定個人の問題にしない」ことや、「チーム全体の問題として捉える」など。そうしないと、段々と個人プレーになってしまいます。

後者については、ミッションステートメントの定義と、そのミッションの達成度を数字(KGI)として計測できる環境を作ることです。それをとにかく細かい粒度まで落とし込むことで、今何をするべきかということをメンバーが判断しやすくしています。

高田:次に、チームマネジメントについてですが、私の中で、「チームマネジメント」という言葉を自分なりに定義してみました。

チームマネジメントは、「リーダーが、広義では常に、狭義ではミーティングなど個別の対応の場において、チームの生産性を上げるために目標設定や期限設定をすることによって、メンバーが主体的に動けるように牽引していくこと」と考えました。チームマネジメントにおいて生産性を上げるというのはどういったことを指しますか?

水上さん:まず、定義ですが、これは会社・組織によって大きく異なります。開発チームだけで言うならば、今のような自律駆動型のチームだと、特に僕がメンバーの生産性を上げるために期限設定などをすることはありません。

開発の生産性を上げようと思ったら、細かいツールの使い方や、手戻りを少なくする工夫といった、小さなテクの積み上げしかありません。しかし、こうしたことはチーム内で共有すれば勝手に伸びる話なので、チームに委ねるほうが良いと考えています。他にも多くのことを可能な限りチームマターにしていくことで、僕からの直接的なマネジメントで改善できる部分は限りなくゼロに近づけることができます。

高田:もしかしてDIGGLEの開発チームにマネジメントは要らなくても良いのではないでしょうか?

水上さん:そうかもしれないですね(笑)しかしながら、「自律駆動型」というと聞こえは良いですが、もし放任しているうちに「ただ好き勝手やってる集まり」に陥っていたら、本末転倒ですよね。そして何もしないと、得てしてそうなります。そうならないようにするには、チームの外からの”意図的な調整”が必要です。この意図的な調整が狭義のマネジメントと僕は考えています。意図的な調整の一つの方法が、”フィードバック”です。例えば「これは凄く良いと思うので継続してほしい」とか「こういうのはあまり良くないんじゃない?」とか、正直に伝えるようにしています。

高田:フィードバックのコツって具体的に何かありますか?

水上さん:フィードバックについて、大事にしていることは3つほどあります。

1つ目は、まずは自分自身もフィードバックされる前提に立つこと。経営側にも伝えるべきことは伝えて良いですよ、ということがわかるような環境をつくり、かつ自分自身が率先して改善を試みることで、フィードバックの価値に対する共通認識を醸成します。

2つ目は、ポジティブかネガティブでまず場を分けること。ポジティブなものはみんないる前で、ネガティブなものは1対1で行います。ポジティブなものをみんないる前で示すのは、本人の自信にもつながるし、他の人にとっても良い指針になります。逆にパブリックな場でのネガティブフィードバックは精神的ダメージになりやすいのですべきではないです。

3つ目は、リスペクトを常に持つこと。親身になって丁寧に話すことで、本人のために言っているものだということを理解してもらいます。フィードバックは、常に、誰にとっても精神的に大なり小なり負荷があるものですから、"受け入たほうが良い"というマインドや、精神的な余裕を作ってもらえないと、なかなか受け入れてはもらえません。

高田:なるほど。ありがとうございます。開発チームの雰囲気が分かった気がします。

水上さん:本当のことを言うと、現状うまくいっているのは、僕がすごくマネジメントを頑張っているからではなくて、チームが優秀なおかげでマネジメントコストがかかっていないというだけなんです(笑)

高田さんの定義では”リーダーが”とされていましたが、この役割が何らかの形で達成されるならば、どんな形でも良いと思います。リーダー1人で回すのもマネジメントだし、リーダーが必ず存在していなくても成り立つのであれば、それもまたマネジメントで良いのでは、と考えていますね。


高田:関連して、少し抽象的度の高い質問ですが、チームのメンバーとコミュニケーションをとる上で気をつけていることなどはありますか?

水上さん:フェアに接することですね。人としての好みをだしてしまうと、アンバランスになる可能性があるので当然ダメです。例えば、若手のエンジニアであっても対等に、同じ目線に立って説明し、変にタメ口を使うことはしません。相手に対してリスペクトを持つことに気をつけています。また、喋る量も人によって違うので、言い出せないけど意見がありそうな人が居たらちゃんと聞いています。なんにせよ、僕らにとって一番重要なのは「良いモノ」を作ることなので、そこから焦点をブレさせないように、上手くファシリテーションすることを心掛けています

高田:コミュニケーションに関して、もう1つ。目標設定についてです。私はサークル活動で雑誌制作を行っているのですが、各々の裁量は過去のアウトプットの質から判断して決められます。しかし、希望的観測ー彼ならここまでやってくれそう、という期待の意味を込めて決めることも出来ると思うのですが、DIGGLEの開発チームではどちらをとりますか?

水上さん:前者です。というか、後者は基本的に行いません。後者を続けると、「期待の目がないと出来ない人」になってしまうからです。期待を表すことは短期的にモチベーションになる反面、承認欲求が満たされるので依存性を持ってしまいます。基本的に日々の仕事は、粛々と、当たり前にこなせるべきです。そして、大抵の作業は、スタートアップであっても、残念ながらそんなに面白いものではないです。

また、基本的に開発のタスクは、ヤル気でどうにかなるものではないです。工数が2ヶ月のものを「君だったら1ヶ月でできるよ!」とか言うのはあんまり良くないことですよね。

高田:お昼の時間に出社すると、しばしばエンジニアの皆さんが何かを話し合いながらランチされていますよね。あれは何をやっていらっしゃるのでしょうか?

水上さん:「ランチ弁当会」というもので、毎週開催しています。当番の人が、自らのキャリアなどのネタにしたコンテンツを準備し、発表します。例えば、バックエンドエンジニアは僕と全然違うキャリアを積んでいるので、僕の知らない技術を知っています。知らないことを知れるというのはプラスですよね。逆に「知っていることが当然」と、もし発表者が思っていても、実はそうではないと気付くきっかけになります。単純に雰囲気がよくなるというのと、チーム内の認識が段々と近づくという効果を多少は期待してやっているという感じですが、あくまでもランチなのでゆるくやっています。


高田:先ほどのお話で、開発チームは「自律駆動型」であると仰ってましたが、一体感も必要ですよね。ゴールはどのようにチームに共有していますか。

水上さん:開発チームのミッションステイトメントは極めてシンプルで、「良いプロダクトを作ること」という一文に全てを収めています。ここで「良い」という言葉一つでも、人によって捉え方が異なります。それだとダメなので、次に「良いとは何か」を因数分解し、そこから現れたワードをさらに分解して〜を繰り返すことで厳格に定義し、ドキュメント化しています。最終的に数値として計測可能な粒度に落とし込んで、開発のメンバーに共有しています。しかし「最初に良いと決めたもの」は常に正しいとは限らず、今後変わって行くものだと思うので、チームにはその旨を伝えています。また、僕の考えに、抜け漏れがあればメンバーにフィードバックをもらい、改定することもあります。

高田:良い製品をつくるためには、お客様サイドにいる営業との連携は必要不可欠だと思います。具体的に、行っていることはありますか?

水上さん:定期的に要望管理ミーティングを実施して、営業やカスタマーサクセスのメンバーがお客様の要望を開発に共有します。仮にそれがなければ、「どういう機能が求められていて何をすれば良いか」は当然わからないですよね。お客様からの顕在化した要望は、DIGGLEの進む道筋の道標になります。ただ、何でも受け止めれば良いというわけではなく、開発からも提案したりしながら、最終的にあるべき形を見つけていくというイメージです。

高田:チームとマネジメント両面の現状を踏まえて、今後どうありたいかを教えてください。

水上さん:今後は自律駆動型のまま大きくなるのが理想ですが、それは簡単なことではありません。会社が成長していくとチームが複数に分かれていくと思いますが、今の成功体験を再現性の高いものにして、今後新しく生み出されるチームの中でさらにブラッシュアップされ、組織としてさらに強くなることが最終的に目指しているところです

高田:水上さん、お忙しい中、ありがとうございました。

編集後記

インタビューを通して考えたこと、感じたことなどを2点述べたいと思います。

1つ目は、「チームマネジメントにおいて、絶対的なリーダーは必要かというと、そうとも限らない」ということです。
私は、「チームマネジメント」という語句を定義した際に、「リーダーが主体的に行うもの」と真っ先に決め込んでしまいました。
しかし、DIGGLE開発チームのように「チーム自らがチームをマネジメントする」という場合もあり、マネジメントにリーダーの存在は絶対ではないと気付くことが出来ました。ステレオタイプな考えを修正し、視野を広げるきっかけになったのは、大きな収穫です。

2つ目は、「将来はDIGGLE開発チームのような環境で働きたい」ということです。
結果にこだわり、公私混同することなく各々の職務を粛々とこなし、良い意味でドライかと思えば、チーム同士で自らの不足部分を補い合い、課題解決に向かって建設的な話し合いが行われる環境。まさに私の理想としている職場の雰囲気です。
現在、私は大学3年生で就職活動をしています。「自分がどうなりたいのか、社会において何を実現したいのか」も勿論ですが、「自分と働く仲間や職場の雰囲気がマッチしているか」も同様に大切にしています。

このインタビューを通して、読者の皆様にDIGGLE開発チームの魅力がさらに伝わっていれば幸いです。

↓DIGGLE開発チームのメンバーをwanted!

https://www.wantedly.com/projects/96738

同じタグの記事
今週のランキング