メンバーズのテックリードが語る、「丸投げ体質」と「ウォーターフォール的思考」が招くアジャイル開発の悲劇

もともとは旅行系の企業で、予約管理システムの販促など、ITシステムの営業をしていました。でも、システムを売っているうちにシステム開発に興味を持つようになりました。独学やアルバイトで技術を身につけ、10人規模の小さなベンチャー企業にアプリエンジニアとして拾ってもらいました。

その会社は私がいる間に100人規模まで急成長しました。最初はSES※で客先常駐も経験しましたが、自社サービスの開発に戻ってからは、アプリ、Web、サーバーのインフラ構築まで、本当に何でもやらせてもらえましたね。裁量が大きく、エンジニアとして幅広く経験を積めたのは今のベースになっています。
※SES（システムエンジニアリングサービス）：エンジニアの技術力を提供し、お客さまのオフィスなどに常駐してシステム開発や運用をおこなう契約形態のこと。

前職は個人の裁量が大きく、1人でシステムを丸ごと作れてしまう環境だったのですが、ふと「これって自分の見える範囲でしか仕事をしていないな」と気づいて。私は黙々とコードを書くのも好きですが、もっと「チームで開発したい」という思いが強くなりました。チームで切磋琢磨し、他の人の目に触れる環境のほうが、スピード感や意識の面でメリハリが出ますので。

自分の技術力の幅を広げ、より良いシステムを作るためにはチーム開発が不可欠だと感じ、メンバーズに入社を決めました。

一般的にテックリードというと、アプリからインフラまでこなせる「フルスタック型」と、特定の技術に特化した「専門特化型」の2パターンの人物像があると思います。その上で、メンバーズのテックリードは「ビジネスサイドと開発サイド、両方の側面を持ち合わせた人材」であるべきだと考えています。

私たちは「あたかも社員®」としてお客さまと準委任契約※を結んで入ります。つまり、単に言われたものを作るだけの外注業者ではありません。お客さまのビジネス面の成功や顧客価値の創出を常に頭に置きながら、技術面でリードしていくことが求められます。
※準委任契約：成果物の完成ではなく、業務の遂行に対して報酬が発生する契約のこと

そうです。今の開発現場は、ビジネスサイド（企画や営業）と開発サイドが完全に分断されていることが多いんです。一般的な開発構造ですと、「開発要件を投げて、あとは成果物が上がってきたら確認する」という、完全に分業化された関係になりがちなんですよね。そこでメンバーズのテックリードは、ビジネスと開発、両方の橋渡しができる存在として動きます。

具体的には、ビジネスサイドの方には分かりやすいように技術の話を業務的な話に持ち替えて渡します。逆に、ビジネスサイドからの要望を現場に落とし込む際は、業務の要件を、開発者が理解できる技術言語に変換して伝えるんです。両者が共通認識を持てるように翻訳するイメージですね。

なにもそこまで難しく考える必要はありません。開発者にタスクを落とし込む前に、ビジネスサイドの方に「そもそもなぜこれをやるのか？」という目的を必ずヒアリングするようにすれば大丈夫です。もし本質からズレていると感じたら、「開発に落とす前に、ビジネスサイドでもう一度揉んできてください」と差し戻すこともあります。

一方で、開発現場から重大なリスクや課題が上がってきたら、それをしっかりとビジネスサイドに引き上げて共有します。これができるのは、テックリードが「ビジネスサイドのメリット・デメリット」と「開発サイドのメリット・デメリット」の両方を深く理解した上で存在しているからこそなんです。

両者の事情を汲み取れるからこそ、顧客のビジネスに貢献できるシステム開発をリードできるのではないかと考えています。

よくあるのが、ウォーターフォール開発の意識のまま、手法としてのアジャイル開発を導入しようとしてつまずくケースです。市場への早期リリースを狙ってアジャイルを始めるものの、「承認プロセスが多い」「正解を決めてから進めたい」という旧来の組織文化が大きな阻害要因になっていますね。また、「期日までに、最初に頼んだものがすべて完成しているのが当たり前」という考え方もアジャイル開発でつまずく要因になります。

以前、あるプロジェクトで「フロント側の軽い実装のみで済む」と想定してスタートした案件がありました。しかし、実際に蓋を開けてみると、インフラやサーバーといったシステムの中核に関わる実装や、性能試験への対応まで必要であることが判明したのです。

私たちはお客さまとの対話を試みましたが、「リリース日を遅れさせることはできない」という要望を受け入れざるを得ず、結果としてエンジニア陣は大幅な残業を強いられるという事態に陥りました。

アジャイル開発を成功させるには、ゴールに向かってチーム全員で対話をしながら進むというプロセスが不可欠です。特に立ち上げたばかりのチームでは、メンバーがどれだけのパフォーマンスを発揮できるか未知数な部分も多くあります。

ゴールが見えないなかで模索していくからこそ、状況に応じて計画を変更できる柔軟な組織体制を築くこと。そして、対話を通じてお客さまとそうした働き方について合意形成しておくことが、アジャイル成功の鍵だと考えています。

大きく2つあります。 1つは「DXの目的が曖昧なこと」。単なるITツール導入による効率化・コスト削減で止まっており、ビジネスそのものをどう変革したいのかが見えていないケースが多いです。もう1つは「現在地を測る指標がないこと」です。自分たちの組織がどれくらいDXが進んでいるのか客観的に把握できていないんです。

だから私は、日本CTO協会が提供している「DX Criteria※」を導入して、まずは現状を可視化することを提案しています。
※DX Criteria：企業のデジタル化とソフトウェア活用のためのガイドライン。

メンバーズが掲げる「あたかも社員®」を体現することを強く意識しています。会社としても「ビジネス的な提案ができるように」と言われているので、その自覚が根本にありますね。そのうえで、ビジネス視点で現状を客観的に見て、お客さまに提言しています。

例えば、提示された予算や構成に対して開発の目的が不明確な場合や、費用対効果が合わなそうだということがあれば、率直にお伝えします。お客さまに利益を上げていただくことが、企業の経営において一番必要なことだと思っています。だからこそ「（コスト削減なども含めて）自分がいることで利益が上がるのか」という観点を持ち、ビジネス的な提案をするようにしています。

一方で、大手企業の社員は社内調整業務に追われがちなので、私が代行できる部分は巻き取って、社員さんが本来の業務に集中できる環境を作ることも意識していますね。

コーディングなどの実作業や情報収集はAIが代替していくでしょう。しかし、技術的な立場で会社全体のロードマップや戦略に基づき「技術選定」と「意思決定」ができるテックリードは不可欠であり、この要件は変わらないと考えています。

「選択と集中」、そして「パートナーも一緒に成長できる環境づくり」をお願いしたいです。現場では予算の都合上、1人の人材に複数の役割を兼任させているケースがよく見受けられますが、その人が2〜3年後にどんなプロフェッショナルに成長していてほしいかを想像し、そのために必要な業務に集中して取り組ませることが何よりも重要です。

そして、これは外部のパートナー企業に対しても同じだと考えています。外部パートナーを含めて「良い職場、良い環境」を整えることが、そこで働く人々の幸福につながり、それが巡り巡って開発の成功、ひいては事業の成功に直結します。

責任で縛るのではなく、自社の社員、外部のパートナー双方に裁量と成長の機会を提供すること。それが、これからのDXリーダーに求められるもっとも重要な仕事ではないでしょうか。