先日（といいつつ結構前になりましたが）、私が社外取締役を務める株式会社クラシコムのエンジニア向けトークイベントに参加して、出番を頂いて話をしてきました。
クラシコムは、ECサイト「北欧、暮らしの道具店」を運営する会社で、商品コンテンツだけでなくドラマや映画、ポッドキャストを通じて世界観を発信しています。そうした様々な活動を支えるためにも、エンジニアチームを抱えてシステムを内製しています。
今回のイベントテーマは「社内受託にならないエンジニアチームのつくり方」で、私も含めクラシコムのテクノロジーグループが取り組んできた経験を話してきたので、本稿では私の話したことに加えて補足をいれながら言語化してみます。
目次
社内受託になりがちな内製エンジニアチーム
まず一般的な話ですが、事業会社におけるエンジニアチームの立ち位置は、場合によっては、同じ社内にもかかわらず一括請負の受託開発のように、決めたものを作るだけの役割に陥ってしまうことがあります。
そうなってしまうと、ビジネス側は事業の状況にあわせた柔軟な仕様変更が難しくなるし、開発しているエンジニア側も言われたものを作るだけで楽しくありません。せっかく内製だからこそ得られるはずの良さが消えてしまうのです。
そうなるのには様々な要因があります。たとえば、依頼するビジネス側がソフトウェア開発のことを知らなすぎるが故に、建物や工場を建てるように「一回で決めて作って終わり」と考えてしまうことです。また、コンピュータのことは難しいからと作ることを丸投げしてしまうことも原因になります。
そんな社内なのに受託みたいな状況にならないようにするために、ソフトウェア開発の本質的なところを、エンジニアではないビジネス側の人にも知ってもらいたいと思って書いたのが「人が増えても速くならない」という本でした。
本書は、私がクラシコムに関わって内製のエンジニアチームがシステムを作っていく中で、経営サイドとエンジニアサイドの間を繋ぐように理解のすりあわせをしてきた経験をもとに書いたものです。今のクラシコムのエンジニアチームは社内受託にならず、経営や現場と一体となったソフトウェア開発ができていると感じています。
社内受託にならないエンジニアのスタンス
当日イベントではクラシコムのエンジニア２名が、どういったプロセスやスタンスで取り組んでいるかプレゼンしてくれましたが、私がとても良いなと感じたポイントを紹介します。
システムを利用する関係部署に展開する際に、システム側の理想を絶対に正しいものとして押し付けない。ありたい姿に共感してもらうところから始めて、どう近づけていくのかを一緒に模索するというスタンスでいることで、一方通行ではない信頼関係を築くことができる。
エンジニアである前に、クラシコムの社員であるというスタンス。システムを作って終わりではなく、会社や事業が健全に成長し続けることを考えるなら、知識をシステムだけに閉じず、業務について勉強したり、現場に行って見学したり、メンバーの一員としての歩み寄りをすること。
システムの品質には、業務の品質も関わってくる。技術的負債を気にしすぎて、業務を複雑にしてしまうと、それも一種の業務的負債となってしまう。また、どんな業務も「お客様体験」に繋がっているので、そちらを優先してシステムの複雑さを受け入れることも大事。
このように、システム開発をしているチーム自体が境界を作らず、全体が良い状態になるために飛び越えていくスタンスでいることは、社内受託にしないためのエンジニア側の努力です。また、クラシコムでは新しいシステムや機能を導入することに、現場も非常に協力的です。そこには、同じカルチャーや価値観があり、互いに目線を揃えようとしているからではないかと思います。
社内受託にならないマネジメントのポイント
では、そうしたエンジニアチームを作って、経営サイドとしてうまく付き合っていくためにマネジメントの目線から取り組んだことを紹介します。大きく３点あります。
１．同じものを見て話す
２．スケジュールを固定しない
３．考えられるサイズにスコープを絞る
もしかすると、一般的なマネジメントの常識とは異なるように感じるかもしれませんが、ソフトウェアという目に見えないもの、変化し続けるものをマネジメントするには重要なことばかりです。それぞれについて詳しく記述します。
ポイント１：同じものを見て話す
ソフトウェア開発のプロジェクトでよく起きるのが、経営サイドから見て何が起きているかわからなくなってしまい、エンジニアの話す言葉を信じるか・信じないか、みたいな状況です。信じれているうちはよくても、度重なるトラブルや進捗の悪さによって信頼関係が失われた時、プロジェクトは崩壊します。
そうならないために、現場サイドと経営サイドで言葉だけで状況を共有するのではなく、プロジェクトの状況を見える化したもの、すなわちロードマップを作って共有するようにしています。横軸に時間軸、縦に進行中のプロジェクトを並べています。これによって、詳細はさておき全体像を把握することができます。特に経営サイドで重要なのは全体像です。
ロードマップは１度作って終わりではありません。定期的にロードマップの見直しもします。経営と現場のリーダークラスが集まって確認する定例ミーティングでも更新していきます。経営サイドとしては、進捗に遅れがあるのは仕方ないとしても、どういった状況なのか把握をしたいものです。それがロードマップの差分という形で見えるのは安心です。
また、その定例ミーティングを「ロードマップミーティング」と呼んでいますが、そこでは現場からも経営からも相談事項が持ち込まれます。難しい意思決定は、現場だけもしくは経営だけ、とせずに互いを巻き込みます。ただし、意思決定と責任を相手側に委ねるのでなく、あくまで相談の形をとることが重要です。それにより同じ問題に向き合う協力体制が作れます。
現場では難しいと思っていたことも、経営からみたら前提を変えることができるので、容易になる可能性もありますし、逆もまた然りで、経営サイドから見たら超難問でも、現場サイドでは簡単に実装できてしまうこともあります。だからこそ「現場vs経営」の対立ではなく「問題vs私たち」でありたい。そのためにも、ロードマップという眼に見えるものを作り、そこに目を向けるスタンスが重要になります。
ポイント２：スケジュールを固定しない
そのロードマップは、前述の通り継続的に更新をしていきます。よって、いわゆる計画表とは異なります。これが計画だとすると、その計画通りに進んでいるかどうかの進捗確認と、間に合わない場合はリスケを行うことになりますが、それは計画が正しいもので固定している前提に立っています。
しかし、ソフトウェア開発のように不確実性が高い場合だと、何度もリスケすることになりかねません。リスケはネガティヴな印象ですが、もともとロードマップでは更新することを前提に進めるのでポジティブです。その更新頻度は、定例ミーティングのたびに行っても構いません。進捗状況や不明だった部分が明瞭になるに合わせて更新していくのです。
ロードマップの作り方は、今後に必要となる大きめの機能や構想を枠として分解し、優先順位をつけることから始めます。そして、時間軸で近いプロジェクトやタスクについては精緻に見積もりをし、時間的に遠いものは概算でよいので見通しを立てます。もっとも近いものは１週間先で、それ位ならほぼ間違いのない状態まで見積もります。
ロードマップでは納期やスケジュールは固定しません。しかし優先順位に沿って並ぶため、いつか開発されることがわかっていることは経営にとって安心材料です。また、どれくらい先になってしまいそうかわかっていれば、それを前提に事業プランの見直しもするし、優先順位や機能のリッチさなど調整もできます。固定しない方が事業も対応しやすいのです。
ロードマップを現場サイドと経営サイドで一緒に見直していくことで、経営が一方的に納期を守らせる関係でなく、逆に、経営がエンジニアの言いなりになる関係でもなく、共通の限られたリソースを活用して、どうやったら最大限の成果を出せるかを一緒に考える関係を作ることができます。
ポイント３：考えられるサイズにスコープを絞る
ロードマップに並べるプロジェクトやタスクの大きさは、うまくマネジメントしていく上で重要なパラメータになります。特に大きいまま扱おうとすると、優先順位はつけられないし、見積もりも不透明になり、進捗状況も把握できなくなってしまいます。
ソフトウェア開発のような不確実性の高いプロジェクトにおいては、機能を増やしたりして大きな塊で一括で作ろうとするのは、かえって効率性や柔軟性を落としてしまい、結果としてコストがかかりすぎてしまうことが多くあります。
全体をリプレースするような場合を除いて、すでに稼働中のソフトウェアを改修していくことになるので、可能な限り小さな単位にしていく方が望ましい。なんだったら、たとえリプレースであっても、開発途中は内部的には小さく作って拡張していく形をとってから、リリースする方がよいでしょう。
大きいものは進捗状況をパーセントで報告するようになりますが、そうなると中身は不透明になり、経営サイドからは手を出せなくなり、完成するまで待つだけの一括請負の受発注のような関係ができあがってしまいます。一つ一つをできるだけ小さくすれば、進捗状況は「終わったか」「終わってないか」だけのシンプルにわかるようになり、経営サイドとも認識が揃います。
このように大きなものを小さくしていく「小口化」は、他にも複雑性が増した時に有効です。組織やチームも、全員がすべての業務やシステム全体を把握するのが難しくなったり、人数が増えてきたときは、把握してグリップできる範囲に小さく分けることもマネジメントの一環です。
不確実さを受け入れるマネジメント
社内受託にならないことは、すなわちソフトウェア開発を取り巻く体制の経営も利用する現場もまじえて、一緒に考える体制をどう作るのか、ということです。
経営者や利用者がITリテラシーを高めるのはあるとしても、プログラミングまでできる必要はありません。しかし、ソフトウェアの本質は理解してもらえれば、詳細はわからないなりに一緒に考えるスタンスを作ることができます。
すぐに自社のエンジニアのことを「うちのエンジニア天才」と言ってしまう経営者もいますが、本当にそうかもしれませんが、往々にして、自分がわからないことをわかっている人がいて、その人に任せきりにしたいが故に、そう思ってしまっていることが多くあります。
そもそもソフトウェア開発には、正解がありません。確実に必要な機能、確実に動く作り方、確実なコードなど最初から見通せないし、進むにつれて変わっていくものです。つまり、どんなエンジニアでさえ確実な正解などわかるはずもないのです。どれほど優れたエンジニアだとしても、丸投げしてうまくいく保証などありません。
経営者もエンジニアも、不確実なものだという前提にたって一緒に向き合っていくこと、一定の不確実さを受け入れながら、確実にできることから積み上げていくこと。ロードマップを更新しながら、認識のすりあわせを続けていくこと、学びの機会を得て軌道修正していくこと。そうした状態をアジャイルと呼ぶのだと、私は考えています。
株式会社クラシコムでは、内製のエンジニアチームがあって新規の募集してます。ご興味あれば、ぜひ覗いてみてください。
WEB・アプリ・インフラまで！北欧、暮らしの道具店WEBエンジニア募集
