自己紹介と会社概要

前田：シンプレクス株式会社に所属しています。私は約15年前にキャリアをスタートしました。
最初はFX（外国為替証拠金取引）の取引システムの運用保守を担当し、その後、自社のパッケージプロダクトの導入や、証券取引システムのフルスクラッチ開発といったプロジェクトを経験しました。さまざまなプロジェクトを経験する中で、アジャイル開発のフレームワークであるスクラムに出会い、以降は、金融に限らずさまざまなお客様のプロダクト開発に取り組んでおります。チームには、スクラムマスターか開発者として参画することがほとんどです。

シンプレクスは1997年に創業した会社で、メガバンクや大手総合証券を筆頭に、日本を代表する金融機関のテクノロジーパートナーとしてビジネスを展開してきました。金融機関向けのトレーディングツールや取引システムといった、ミッションクリティカルなシステムの提供実績が豊富です。最近では、金融領域で培った豊富なノウハウをもとに、金融以外の幅広い業界のお客様にもサービスを展開しようとしています。当社には、創業以来大切にしている3つのこだわりがあります。1つ目は、下請けにならず、下請けに丸投げもしないことです。自社でエンジニアを雇用して育て、自分たちでコードを書いてお客様に届けることにこだわっています。2つ目は、一気通貫の体制です。お客様がビジネスを構想してから、サービスを世の中に出し、クローズするまで、責任を持って伴走し続けることを大切にしています。3つ目は、プレイヤーを自社で獲得し、育成することです。

複数ドメインを渡り歩くチームの歴史

金融ドメインを中心に事業を展開してきた会社が、新しい業界ドメインで価値を提供しようとするときには、学習スピードを上げる必要があります。ここでご紹介するのは、私も所属しているあるチームの話です。このチームは、金融以外の業界に挑戦する部門に属しており、さまざまな業界のお客様と関係性を築きながらプロダクトを開発することをミッションとしています。

会社のコーポレートサイトで公開されている事例では、化粧品業界のポーラ様や教育業界のベネッセコーポレーション様など、お客様とゼロから関係性を築き、プロダクトを開発してきました。

実際のチームの歴史は、こちらの図のとおりです。さまざまなプロジェクトに取り組んできました。2年から3年ほどの期間で、化粧品、不動産、教育、債権保証、ライセンス販売管理、決済といった多様な業界に同じチームで取り組んでおり、プロジェクトが並走することもあります。

私の場合は、最初に不動産、次に教育、債権保証のプロジェクトを経て、現在は決済のプロジェクトに取り組んでいます。これと同じことが、チームのメンバー一人ひとりに起きています。

やってみて分かった3つのこと

複数の業界に取り組む中で、見えてきたことが3つあります。1つ目は、業務領域が多彩であることです。プロジェクトごとに業界が全く異なるため、立ち上げのたびに、お客様の業務プロセスや業務ルール、ビジネスモデルを一から学ぶ必要があります。業界ごとにコミュニケーションの取り方や文化も異なるため、これらもあわせて学ばなければなりません。

2つ目は、技術スタックが多彩になることです。作るものが異なるため、React × TypeScriptのウェブアプリ、Flutterのスマートフォンアプリ、ECS上のKotlinによるウェブサーバー、Lambda上のサーバーサイドTypeScript、AWSではなくAzureというように、エンジニアが学ぶべき技術スタックはプロジェクトごとに大きく異なります。

3つ目は、人の異動が多いことです。私たちはお客様と契約を結んでプロジェクトを始めるため、進行中に課題が出て忙しくなったり、新しい案件の引き合いが来たりすることがよくあります。その結果、大小さまざまなプロジェクトが次々と立ち上がり、メンバーの異動も頻繁に起こります。

こうした状況では、誰が参加しても早く立ち上がれる状態にしたくなります。プロジェクトごとに開発のルールやプロセスが異なると、新規の立ち上げ時にも、チーム編成を変えるときにも、影響が大きくなってしまうからです。たとえば、GitのコミットメッセージをConventional Commitsにするか、チケット管理をJiraとGitHubのどちらにするか、朝会を実施するか、実施するなら何時にするか、ドキュメントを書くか、テストをどうするか、といったことです。業務領域と技術スタックの違いは避けられません。それならせめてそれ以外を統一し、誰がどこに行っても同じようにパフォーマンスを発揮できるようにしたいと、本能的に思ってしまいました。

標準プロセスを作ろうとして、やめた理由

「これが我々のチームの標準だ」と呼べるものを定義しようかと、一度真剣に考えたことがあります。具体的には、工程や作成物、チームを構成する役割、会議体などを定義するというものです。ただ、どう考えてもうまくいかないと考えました。

そもそも我々はクライアントワークの会社であり、クライアント様の業界も作るプロダクトもさまざまで、プロジェクトごとに状況が大きく異なります。標準を定めることで、各プロジェクトに取り組む人やチームが、自律的にその場で判断する余地を奪ってしまうリスクの方が大きいと考えました。これが、私が標準化をやりたくなかった理由です。何より、誰かが決めた標準に従うだけになってしまうと、個人としてコミットメントを発揮できなくなると、強く感じていました。

標準化は、会社全体が大切にしていることとも合わないと感じていました。当社では、個々のプロジェクトに任されている裁量が非常に大きく、チームの構成や技術選定、開発プロセスの設計、コミュニケーションに使うツールなども、現場が決めています。任されているからこそ、目の前のクライアントやプロジェクトに全力で向き合い、付加価値の提供やプロジェクトの成功に全力でコミットできます。これが、この会社で長く働いてきた私が、大事だと考えているポイントです。

私が好きな『組織パターン』という本の一節をご紹介します。「実際、誰かに責任を与えることはできない。できるのは、誰かに説明の義務を与えておくことだけである。責任は引き受けるものであって、与えるものではない。」個人が責任を引き受けることができて、初めてコミットメントを発揮できる。組織は、個人がこれをしやすいようにしなければならない、というパターンです。

そこで、2年ほど前に私が考えていたのは、次の2つの選択肢でした。個々のプロジェクトの最適化を重視した結果、チームと称しているだけの、実はバラバラな集団になってしまうのか。あるいは、プロセスの統一を重視した結果、レスポンシビリティを引き受けられない集団になってしまうのか。どちらかしかないのだろうか。それが、当時の私が抱えていたモヤモヤでした。

2年後の現在―標準化せずに生まれた3つの共通プラクティス

2年後の現在をご紹介します。結局、現在のチームは標準プロセスを決めておらず、明文化もしていません。それぞれのプロジェクトが状況に合わせて、自分たちが最適だと考える手段を選んでいる状態を維持しています。それでも、立ち止まって客観的にいくつかのプロジェクトを見てみると、確かに共通している部分があります。

1つ目は、エンジニアがお客様と直接対話していることです。チームのエンジニアが、業務を行う部門やビジネスを企画する部門といったお客様と直接対話することを前提としています。プロダクト開発に関わるエンジニアは、全員が対話します。

2つ目は、プロジェクトの序盤から終盤ギリギリに至るまで、実際に利用するユーザーやお客様の業務を理解することに、継続的に執着していることです。お客様とユーザーストーリーマッピングを行い、できたものを頻繁にデモし、ユーザーの方に直接会いに行きます。 会えない場合は、自分たちでロールプレイングをすることもあります。あるプロジェクトでは、実際にプロダクトが使われる場面を再現するロールプレイング大会を開催し、業務を行うお客様自身も気づいていなかった矛盾点を早期に検出できたそうです。

3つ目は、プロジェクトごとのチームで定期的に振り返りを行い、その場で新しいアプローチを生み出していることです。

なぜ標準化なしで似てくるのか―「学習」というボトルネックの仮説

最近、このことをモヤモヤと考えているときに、ヒントになるかもしれない本と出会いました。『Agile Adoption Patterns』という2008年発行の古い本です。この本は、ソフトウェア開発のボトルネックは学習であると、かなり序盤で言い切っています。

本にはこう書かれています。「私があなたの顧客で、あなたとあなたのチームにソフトウェアシステムの構築を依頼したとします。丸1年かかって納品されたソフトウェアを回収して廃棄し、あなたとあなたのチームに同じ要件・ツール・環境でシステムの再構築を依頼したら、今回はどのくらいの時間がかかりますか」という試行実験です。多くの方が「2回目はかなり短くなる」と感じるはずで、私もそう感じます。この本は、2回目が短くなる理由を、チームが学んだからだと説明しています。メンバーはチームとして互いを理解し、分析された要件だけでなく真の要件を理解し、ツールセットの使い方を学び、ソフトウェア開発の過程で必ず発生する特有の問題を経験した、というのです。学習こそがソフトウェアエンジニアリングのボトルネックなのだ、と記載されています。

何を学習しているのかについては、Dan Northさんのブログにも同じような話が出てきます。学習する対象は、使用している技術、選択可能な技術的オプションの幅、ドメイン、問題や機会に対処する方法、組織の制約、デリバリー方法論、関係を築くべき相手が誰なのか、サードパーティインテグレーションリスク、より良いモデル、組織の文化、チームメンバーの願望や不安、モチベーション、関係性など、多岐にわたります。短縮される時間のうち、どの要素がどれくらいの割合を占めるかは、チームのコンテキストによって大きく異なると考えています。

チームのメンバーにもインタビューをしてみました。過去に取り組んだプロジェクトにもう一度取り組むとしたら、どれくらい時間が短縮されるかを尋ねたところ、「2回目は60%、50〜70%、70%くらいの時間で済む」という回答から、「30%〜50%短縮」という感覚だったという回答まで、さまざまな意見がありました。では、時間の短縮に最も寄与する要素は何かと聞くと、業務プロセスや業務ルールだという答えでした。今ならそれを知っているから早い、というのです。プロジェクトの途中で学んだこと、つまり本当に発見した一番大事なコアのルールを、今なら知っている前提で始められるからだと言っています。

我々のチームの多様なプロジェクトが、標準を決めていないのに似たようなことをしているのはなぜでしょうか。業務プロセスや業務ルールを素早く学習する必要のあるコンテキストにいるため、素早く学ぶことを重視した結果、やっていることが似てきている可能性があると考えています。とはいえ、各プロジェクトが同じような必要性に駆られただけで、こうなったと考えるのは難しいです。我々は多くのプロジェクトを抱えるチームですが、チーム全体として取り組んできたことの一部が、現状にポジティブに寄与しているのではないかと考えています。

シニアエンジニアが育てる「顧客親近性」という価値基準の伝播

現状を形作ることに寄与した活動をいくつかご紹介します。1つ目は、相互認知ネットワークの把握です。チーム内で定期的に、5段階評価で回答してもらう簡易なアンケートを実施しています。段階は、名前を見てもどんな人かほとんど分からない状態から、その人の得意領域や仕事の進め方、相談の仕方が具体的に分かる状態までです。これだけでもメンバー間の相互認知のネットワークを把握できます。

2つ目は、全てのメンバーが自分のメンターを指名できるメンター制度です。レポートラインの制限は一切なく、メンターになったメンバーは、毎週集まって担当するメンティーの状況を共有しています。

3つ目は、継続的なアサイン検討です。各プロジェクトの状況や案件の引き合いをチーム内で毎週同期し、メンター制度で上がってきたメンバーの情報をもとに、中長期的な成長を考慮しながら戦略的にアサインを決めています。

これを毎週愚直に繰り返すと、このような図になります。縦軸がプロジェクト、横軸が期間で、線が人の流れです。

たとえばこちらのシニアエンジニアは、2つのプロジェクトにリードエンジニアとして、比較的安定した期間取り組んでいました。

「各チームに共通する部分」でご紹介したように、我々のチームはエンジニア全員がお客様と直接対話することにこだわっています。誰かが代表者としてお客様と話し、要件を定義してドキュメントに起こしてチームに渡すというスタイルは、意図的に避けています。今振り返ると、各チームがこれを実践できているのはシニアエンジニアの貢献が非常に大きかったと感じます。シニアエンジニアが率先してお客様と会話しつつ、比較的ジュニアなエンジニアがお客様と直接会話する機会をつくってくれています。その結果、ジュニアなエンジニアはお客様の顔も人となりも分かるようになり、「目の前のこの人にいいものを作って喜ばせたい」という素朴なモチベーションが湧いてきます。そして自然と、その人のビジネスモデルや業務プロセス、業務ルールに興味を持つようになります。

Martin FowlerのBlikiにある一節をご紹介します。「トップクラスのエンタープライズソフトウェア開発者になるために必要なものは何かという話になると、だいたいフレームワークや言語の知識や複雑なアルゴリズムやデータ構造を理解する能力だろうという方向に話が進む。だがプログラマーや開発チームにとって最も重要なのは、私が顧客親近性と呼んでいるものだ。これはソフトウェアが対処すべきビジネスの問題、そしてそのビジネスの世界に生きている人々に対する関心および親密さを表すものである。」

先ほど、プロセスややり方が似通ってきているのは、必要性に駆られたものではないかとお話ししました。しかし、実際につぶさに見てみると、シニアエンジニアが率いるプロジェクトで、ジュニアなエンジニアの顧客親近性、つまり目の前の人を喜ばせたいというモチベーションが育ち、その結果として素早く学びたいという姿勢が生まれ、プロセスが似て見えています。

あるジュニアエンジニアは、シニアエンジニアと働いた経験をもとに、次のプロジェクトでは、そのシニアエンジニアがいなくても同じように実践しています。我々のビジネスの性質上、人の異動は避けられません。しかしだからこそ、人の異動に伴って、チーム全体に同じような価値基準が、今のところ2年から3年かけてゆっくりと伝播しているのではないかと考えています。

うまくいかなかった取り組みと、たどり着いた結論

逆に、うまく寄与しなかった取り組みもご紹介します。1つ目は、チーム内ブログの運営です。プラクティスをみんなが知っていて使える状態にしたく、プロジェクトをまたいで伝播することを狙ってNotionでチーム内ブログを始めましたが、書き手が現れなくなり、途中で断念しました。2つ目は、チーム横断で身につけたいプラクティスをよりダイレクトにまとめる、タスクフォースの設置です。異なるプロジェクトから何人か集まったものの、まとめるための指針を見つけられず、活動を断念しました。

今回の資料を作っていて頭に浮かんだのが、Extreme Programmingに出てくる図です。左側にValues、右側にPracticeがあり、それをPrinciplesという橋がつないでいます。私が今回の件で学んだのは、Practice、つまり何をするのかというHowにフォーカスすると、組織の中ではスケールしないということです。みんながレスポンシビリティを引き受け、現場でコミットメントを発揮している状態も、スケールしません。そうではなく、左側の価値基準にフォーカスすると、自然にスケールすると考えています。ただし、かなり時間がかかるとも思っています。先ほどのシニアエンジニアの異動の図のように、人の異動に伴ってゆっくりと伝播していくものではないでしょうか。

我々の場合、左側に来るのは、目の前の人を喜ばせたい、いいものを作りたい、そのためにドメインを素早く学びたい、という大事にしたい価値基準です。その結果として、右側には個別のプラクティスが浮かび上がります。頻繁にデモをする、ユーザーストーリーマッピングをお客様と一緒に行う、ユーザーに会いに行く、会えない場合はロールプレイで自分たちが理解する、といったものです。これが共通しているため、人がプロジェクトを異動しても、「当然そうなる」という状態になります。我々は、この左側のバリューを特に明文化していませんが、人の異動によって価値が伝播しています。まだ2年ほどのため、今後どうなっていくかは、またどこかでご紹介できればと思っております。

アーカイブ動画・発表資料

イベント本編は、アーカイブ動画を公開しています。また、当日の発表資料も掲載しています。あわせてご覧ください。

▼動画はこちら

※動画の視聴にはFindyへのログインが必要です。