DIGGLE株式会社でエンジニアリングマネージャー（EM）を務める岡崎に、エンジニア組織のリアルを語っていただくインタビュー。開発プロセスやDIGGLEの“人”、DIGGLEらしさの土台であるカルチャーについて、現在の姿とこれから目指す姿を教えてもらいました。

[参考]
▼EM岡崎のプロフィールがわかる記事
DIGGLE社員インタビュー＃6
驚くほどマネジメントがいらない開発チームはどうして出来上がったか

DIGGLEが経営と現場のコミュニケーションツールに。事業部を巻き込む機能の拡大フェーズ

ーDIGGLEには様々な機能がありますが、どのような考えをベースに開発しているのでしょうか？

DIGGLEは、企業の予実管理などの経営情報を一元化し、経営判断をより迅速に正確に行う為の経営管理プラットフォームです。ただデータを管理するだけでなく、予算策定・予実突合・見込管理・レポートといった色々な機能があり、経営管理業務全体をプラットフォーム上で一気通貫で行っていただける機能を提供しています。

弊社のサービスはSaaSとして提供しておりますので、お客様の個別要件に沿った開発は行わず、あくまで普遍的なお客さまが求める共通部分を作ることがプロダクト作りの軸になっています。

例えばお客さまが「こういう機能がほしい」と言ったときに、まずは「他のお客さまも必要とする機能なのか」を考え、実際にヒアリングなどを行い、様々なお客様に共通して適用できるものだと判断した上で開発をすることが重要となります。これは社内ソフトなどお客さまの要望に沿った製品を作る社内SEやSIerとは異なる部分だと思います。

ー現在開発に取り組んでいる機能について簡単に教えてください。

弊社では「コラボレーション強化機能」と呼んでいるのですが、事業部をいかに巻き込むかといった部分に注力しています。

まず、会社には経営陣の直轄というかたちで経営企画部があり、期初に作成した予算と、経理が持っている実績のデータを突合して予実の比較・分析を行います。

しかし、経理から渡される実績データは、月半ばを過ぎたくらいで、ようやく前月のデータが入ってくるかこないかぐらいの状態になります。そのため、今月以降の実績データについては予算の値を仮置きしておくなどの対応が必要になるのですが、期初に考えた予算の値ではなく、もっと現実に即した『見込』の値を使用することで、精度の高い分析を行うことが可能になります。

そのためには、『見込』データを入手する必要があるのですが、『見込』データの最新の値は現場（以降、事業部）の方しか知らないため、事業部の方に聞く必要があります。そして事業部の方は業務の合間を縫って『見込』データを入力する必要があるのですが、いかに事業部の方が操作しやすい機能を提供するかが、鮮度の高い『見込』データの収集には必要不可欠だと弊社では考えています。

では、どのようにして実現するのかというと、分かりやすい例では、メンション機能があります。現在でもコメント機能はあるのですが、メンションを付けて特定の方へコメントを送ることがDIGGLE上ではできませんでした。そのため、『見込』データを入力してもらうためには、メールなどのDIGGLE以外のツールを用いて事業部の方へ『見込』データの入力を依頼する必要がありました。

メンション機能を実装することで、事業部の方は『見込』データを記入する必要がある箇所を簡単に把握することができますし、コメントを返信することで、経営企画部の方と双方向にDIGGLE上でコミュニケーションを取ることが可能になります。あくまでもこれは一例でして、ほかにもいろいろな機能をこれからも作っていく予定です。

ー開発はどのようなプロセスで進めていますか？

まず、組織として大きくプロダクトチームがありまして、そのトップがCTO水上です。その中に、PdM、デザイン、DEVの3チームがあります。その中で、私はDEVチームのEMとなります。

各チームの役割分担ですが、まずPdMチームが「こんな機能があればいいのではないか」という要件を考え、ユーザーストーリー（要件）の形でデザインチームへ渡します。先ほどお話ししたメンション機能であれば、「ユーザーはメンションを付けてコメントができる」のような形です。その後、デザイナーが画面のデザインイメージを作成したところでDEVチームが開発を開始します。そして、このとき渡される要件はフロントエンドとバックエンドの区分けがない状態のものになります。

一般的な企業では、フロントエンドエンジニア・バックエンドエンジニアなどに分かれて開発していると思いますが、そのように分けてしまうと1つ要件がくる度に2人アサインしなければなりません。弊社の場合は、全エンジニアがフルスタックに開発を行うことが可能ですので、1つの要件に対してエンジニア1人をアサインすれば良く、エンジニアの人数のぶんだけ並行して開発が可能になっています。

こう聞くと、「フルスタックでの開発経験が無いとDIGGLEに入れないのではないか」と思われるかもしれませんが、現在在籍しているエンジニアの経歴として、もちろん前職でフルスタックに開発していた人もいますが、全員がそうではなく、フロントエンドだけであったり、バックエンドだけを経験していたメンバーも在籍しています。そういったメンバーには、入社後に未経験分野のキャッチアップをしてもらっていて、キャッチアップが終わった現在では、フルスタックに活躍してもらっています。

ここからはDEVチームの開発プロセスになりますが、先ほどの要件をアサインしたエンジニアには、設計から開発、試験までの全てを一気通貫で担当してもらっています。そして、テストコードの作成や、動作確認まで終わったタイミングでプルリクエストを出すのですが、プルリクエストのレビュアはランダムアサインとなっていまして、社員の中から誰か１人がランダムにアサインされるようになっています。レビュー者を有識者に限ってしまうとその有識者がボトルネックになってしまうので、難易度が高いものなどの一部を除いて、基本的にはランダムアサインとしています。そしてレビューが終わってプルリクエストがマージされた後は、リリース前にQAを行い、問題なければリリースという流れになります。

バリューの一つである「自学成長」。個人と組織の学びが事業の成長につながる

ーDIGGLEの開発チームにはどのようなメンバーが多いですか？

DIGGLEのメンバーは、セルフマネジメントができるメンバーが多いです。自分のタスクを期限内に完遂するのはもちろん、与えられた仕事に対して与えられた以上の仕事ができる自律したエンジニアですね。開発においても、私が細かく実物をチェックするようなことはせず、進捗の確認やスケジュール調整といった少ないやり取りで進めることができています。

それができている理由は、個々のメンバーの能力の高さもありますが、スクラムマスターを全員が輪番で行う仕組みにしていることも関係していると思います。スクラムマスターの仕事の中には、他チームからの問い合わせ対応やバグの一次対応も含まれているので、スクラムマスターを経験する中で、一人ひとりが当事者意識を持って仕事を行えるようになる土壌ができているのではないかと思います。実際、全員が最初から上記の自律的なアクションが取れていたわけではなく、半年、1年と一緒に仕事をする中で、どんどん自分で考えて自律的に行動ができるようになっていったと感じています。

そのようにメンバー一人ひとりがセルフマネジメントできているため、マネージャーである私がメンバーを細かにマネジメントする必要がありません。その為、CSやSalesチームなどとの対外的なやりとりや採用活動に注力できていますし、半稼働程度ではありますが、コーディングをする時間も取れています。

ー新入社員に対してどのようなサポートをしていますか？

新入社員1人に対し、社員1人をチューターとしてつけ、仕事の進め方やカルチャーの共有などあらゆる面でサポートしています。チューター制度の中身ははっきり決まっているわけではなく、1ヶ月から2ヶ月を目安に開発プロセスを一貫してできるようになることを目指して、社員それぞれのやり方で関わってもらっています。

例えば、実施の方法としては、Q&Aのような形でやり取りをしたり、機能やコードの説明をペアプロのような形でレクチャーしたり。実施のタイミングとしては、毎日夕方に打ち合わせを設定したり、朝のデイリー後に打ち合わせをしたり、数日に1回纏めて打ち合わせをしたり。私からは「こういう方法もあるよ」という提示だけさせていただいて、以降はそれぞれに合ったやり方で、互いに相談しながら、柔軟に行ってもらうようにしています。

また、副次的な効果として、教える立場になったことで既存メンバーの意識にも変化が起きていると感じています。様々な立場で人や仕事に向き合うことで、仕事に対する責任感も生まれるのではないかと思います。

コミュニケーションが多いフラットな文化を根付かせたい。大きな裁量を持ち、ボトムアップできる組織に

ーより良い開発組織にするために行っている取り組みや工夫を教えてください。

開発を進める中で個々人が振り返りをし、気づきを次に活かすという行動は非常に重要だと考えており、振り返りを活かすための取り組みをしています。

例えば、弊社はスクラム開発を採用していますが、前のスプリントで実施したことを確認してよかった点・悪かった点を把握し、今後どうするべきかを都度考えるように努めています。振り返りの時間軸も意識しており、スプリント単位での振り返りに加えて、四半期のような大きいスパンでも振り返りを行っています。目先の問題にとらわれず広い視野で考えることをチーム全体で心がけています。

[参考]
▼振り返りの詳細については以下のブログで触れています
DIGGLE開発者ブログ　ふりかえり（レトロスペクティブ）を活用してチームの自己組織化を促す

また、社員とのコミュニケーションを増やし関係性を強める取り組みもしています。具体的には2週間に1回、1on1の面談を行っています。面談では今困っていることやチューターの状況、チームや組織に対して抱えている悩みを聞くこともありますし、今後どの領域に注力していきたいかといったキャリアパスの相談を受けることもあります。

長年一緒に働いているメンバーからは「そんなにしゃべることもないから1ヶ月に1回でいいんじゃないか」と言われることもあるのですが、しゃべることがなければ雑談すればいいじゃない、と。組織ではどうしても肩書きによって上下の認識が生まれてしまうので、フラットな文化を根付かせるためにも、たくさん雑談して仲良くなろうと心がけています。

ーEMとして、今後どのようなカルチャーを築いていきたいですか？

今後社員が増えても、今と同じように自律的に動く組織の状態を保ちたいと考えています。そのために一人ひとりが高い技術力をもってフルスタックで開発できることはもちろん、DIGGLEのバリューにある「自学成長」を心がけ、意欲的に成長してほしいと思います。社員が成長のために必要な機会を得られるように、会社としてもサポートしていきます。

組織としては、全員がフラットな立場でありたいですね。社歴や立場に左右されず、一人ひとりが考えていることを自由に言えるような環境を作りたいと思っています。私や経営陣が開発方針や内容を決めてみんながそれに従うのではなく、一人ひとりが考え意思決定できるような組織ですね。現在そのための権限移譲も積極的に進めているところです。

自律的に動き、裁量を持って意思決定を自らしたいというエンジニアの方にマッチする組織を今後も目指していきたいですね。