Regional Scrum Gathering Tokyo 2024 で「アジャイルの価値を活かせる受託開発案件の取り方・始め方」という登壇をしてきた

aratafuji

2024.01.13

はじめに

こんにちは、モダンオフショア事業推進担当兼Classmethod Vietnam(Danang)の藤村です。2024年1月10日〜1月12日に東京の御茶ノ水ソラシティカンファレンスセンターで開催されたRegional Scrum Gathering Tokyo 2024で「アジャイルの価値を活かせる受託開発案件の取り方・始め方」という登壇をしてきました。

RSGTでの登壇は、RSGT2015「開発モデルの作り方～守破離の破！～」、RSGT2016「フィリピンのスタートアップにスクラムを導入しようとしてみたお話」、RSGT2020「最高のScrumキメた後にスケールさせようとして混乱した話」、RSGT2021「モダンオフショア開発のすすめ」に続いて5回目となります。

登壇資料

登壇資料は以下となります。

登壇内容ダイジェスト

今回の登壇で発表した、"アジャイルの価値を活かせる受託開発案件の取り方・始め方における新(アラタ)十則"について、簡単にご紹介します。

1. 取り組んだら事例化しろ、案件は事例から創られる

受託開発案件を取るにあたって一番重要なのは、やはり過去の開発事例です。過去の開発事例を見て問い合わせして頂けることが多いため、当たり前のことではありますが、第1則として取り上げました。開発に取り組んだら、なんとしてでも事例として会社のHPにアップさせてもらえるよう、発注者様にお願いしましょう。

2. なんでもかんでもやるな、案件を選べ

開発の問い合わせを頂けると、何とか顧客の期待に応えたいと考え、何でもかんでも獲得に動こうとしてしまうことがありますが、無理して獲得した案件は大抵失敗しますし、顧客の信頼を失うだけでなく自社のメンバーも疲弊し、時には退職につながってしまうこともあります。

また第1則に関連しますが、開発事例に多種多様の案件実績が並んでいると、自社の強みが伝わりにくくなりますし、社内にもドメイン知識や特定の技術のナレッジが溜まりません。

問い合わせがあった際は、無理なく顧客の期待に応えられる体制を組めるか、未来に繋がる案件か、自社のナレッジ蓄積に繋がるかの観点でしっかりと精査しましょう。断る勇気も重要ですし、それが結果的に顧客、自社のためになることも多いです。

3. 失注を恐れるな、言い辛いことは最初に言え

特にどうしても獲得したい開発案件において、提案時に言い辛いことがなかなか言い出せず、先延ばしにすることで結果的に顧客の信頼を損なってしまうことがあります。そのような案件は獲得できたところで良い結果には繋がらないため、言い辛いことは最初に言いましょう。また経験上、どうせ獲得できないだろうと考え、ダメ元で言い辛いこと満載の提案をした案件に限って受注できてしまったケースも多いです。本気の発注者はイエスマン的な開発ベンダーを求めていません。失注を恐れず、言い辛いことはちゃんと提案書に書いて、しっかりと説明しましょう。

4. アセスメントから取れ、しっかりと精査せよ

ベンダーチェンジ案件において、提示されたRFPのみで自信を持って巻き取れる、またはリニューアルできると提案することは難しいです。NDAを結んだ上でドキュメントやソースコードを開示頂けるお客さんも多いですが、片手間の対応での1, 2週間で精度高い提案をすることは難しいですし、その部分を無償で行うことが求められるとしたらその時点で対等な関係ではないと思います。しっかりと予算を頂き、ちゃんと体制を組んで、少なくとも1ヶ月はアセスメントさせて頂いた上で、精度の高い提案をすることが結果的には発注者のためにもなります。

5. リニューアルするな、リファクタリングで臨め

ベンダーチェンジ案件において、顧客からこのタイミングで現行踏襲＋新機能追加のリニューアルを求められることが多いですが、オススメしません。顧客にとってはコスト的なインパクトが非常に大きいですし、現行踏襲が何事もなくスムーズにいくことはほぼ無いので、顧客のユーザーにも影響が及びます。また、発注側の社内稟議の都合で何かしら目玉となる新機能が含まれていることが多く、より複雑性が増すので、よほどのことが無い限りは現行のソースコードをベースに、段階的かつ継続的にリファクタリングと新機能開発を行う提案をしましょう。なお、この判断をする上でも、第4則のアセスメントは不可欠です。

上記説明してもリニューアルを行ないたい顧客に対しては、アプリケーションのUX再検討からゼロベースで考えることをおすすめします。それも無理な顧客に対しては、現行踏襲と新機能開発を完全に分け、現行踏襲部分は最初にしっかりとアセスメントし、詳細設計まで方向づけフェーズで行ない、計画に従うことを重視して進めるしかありません。その場合でも、継続的インテグレーションなどのアジャイルプラクティスを用いる事でビッグバン結合のリスクを下げたりすることはできると考えています。

6. 新規開発はフェーズを分けろ、少なくとも2つに分けろ

新規開発では、少なくとも2つ(MVP、MUST)のフェーズに分け、開発者、担当チーム、開発プロセスも分けて行なっていきます。 MVPフェーズは、技術的(開発環境、アーキテクチャ設計など)な意味での背骨、プロダクト的(文字通りMinimum Viable Product)な意味での背骨の開発を行ないます。クラスメソッドではこのフェーズをマッハチームと呼ばれる少数精鋭なチームが担当することが多く、圧倒的なコミットメントと技術力で一気にプロダクトの背骨部分を構築し、顧客からの信頼を獲得します。始め半分という言葉がある通り、この立ち上げフェーズがプロジェクトの成否を握っています。

MUSTフェーズは、MVPフェーズで構築した背骨に肉を付けたり、剥ぎ取ったりするフェーズです。スクラムの価値が最も活きるフェーズです。

受託開発において、顧客が開発部分をアウトソースしている時点で体制の増減は間違いなく期待されます。私自身、ステーブルなチームの価値は理解しているつもりですが、顧客のビジネスに寄り添う場合はチームの体制を増減(大きめの新機能開発時は増員、リリース後は減員)しながら継続開発を行なうDevOpsチームを維持する必要があり、そのためにベトナムオフショア側にはエラスティックな(弾力性のある)チームを構成してもらっています。

このエラスティックなチームを以前日本国内でやってみた(やらざる得なかった)際は、チームメンバーの追加や脱退でチームが壊れてしまい、現場のメンバーから強い不満が出たこともあって以降は諦めていたのですが、ベトナム側のオフショアチームでは不思議と問題になることが少なく、現実的にできているところがありました。その要因についてはまだしっかりと分析できていないのですが、今のところの私の仮説は以下の通りです。

状況

ベトナム開発拠点は200人弱のメンバーが一つのオフィスで対面で働いており、全体として一つのチームの感覚に近い
社員旅行や忘年会など、全社的なイベントが数多く行われており、全社的な一体感が非常に高い
コンポーネントチーム(iOSチーム、Androidチーム、フロントエンドチーム、バックエンドチームなど)の結束が非常に強く、メンバーは案件のPJよりもコンポーネントチームへの帰属意識が非常に高い
メンバー交代は即日行われ、日々座席が変わるようなフレキシブルさに慣れている(PJ毎に同じ島に集まって座っている)

エラスティックチームが可能な要因の仮説

会社全体の一体感が非常に高いため、PJの増員で新規のメンバーが加入してもメンバー間の関係性が既に出来上がっており、混乱が生じにくい
コンポーネントチームの結束が非常に強いため、PJの脱退時の引き継ぎはコンポーネントチーム内でチーム活動として円滑に行われており、混乱が生じにくい

今回のRSGT2024のDay1のキーノートはHeidi Helfand氏による「Dynamic Reteaming, The Art and Wisdom of Changing Teams」というセッションで、まさにこのエラスティックなチームに通じるところがあると思い、廊下で勇気を出してHeidi氏に話しかけ、少しだけ質問することもできました。その際にHeidi氏からもらったステッカーには「TEAM CHANGE IS INEVITABLE(チームの変更は避けられない)」と書かれており、まさに我々開発ベンダーはこの事実に向き合っていく必要があると考えています。

なお、Dynamic Reteamingについては、大友さんの以下のスライドがとても分かりやすかったです。

7. できるだけ集まれ、少なくとも最初は集まれ

私が大好きな『組織パターン』の教えです。

ベトナムチームで開発を行う場合、プロジェクト開始時は可能な限り顧客とともにベトナムオフィスを訪問し、ベトナム開発メンバーと関係性を構築してからプロジェクトを開始するようにしています。来週末からも顧客とともにベトナム渡航予定で、今から大変楽しみです。

8. 初回リリースまでは、計画駆動とライトウイングで臨め

ここでのライトウイングは、以下の平鍋さんの記事から引用させてもらっています。

アジャイル開発を実践する上で、このライトウイング、レフトウイングの両翼とも重要だとは考えていますが、受託開発の初回リリースまでに限っては、ライトウイングのみに振り切っちゃった方が良いのではと思っています。

主な理由としては、顧客との信頼関係が構築されていない初期の開発においては、アジャイルかどうかよりも、まずは顧客が希望する最も重要な機能(背骨)をちゃんと作ることが何より重要だと考えているからです。まともに開発もできないでアジャイルマインドも何も無いだろと思ってしまっているため、例えアジャイルマインドに満ち溢れたチームだとしても、初回リリースまではまずはしっかり作る事にフォーカスして、顧客からの信頼を得ることがとても重要だと考えています。

9. 初回リリースまでは、当たり前品質だけを作れ

第8則と被る内容ではありますが、初回リリースまではあえて変化を抑えて、顧客が望む当たり前品質(必須機能≒MVP)をアジャイルのライトウイングのプラクティスを駆使して構築することにフォーカスした方が良いと考えています。積極的に検査と適応を実施するのは、初回リリース以降からでも遅くありません。

なお、ここでの初回リリースまでの期間は、3ヶ月〜6ヶ月程度の期間を想定しています。

10. 引き継いだ後も見守れ、感謝を込めて見守れ

私自身の反省から来ていますが、新しく採用したスクラムマスターにPJを引き継ぐ際に、まずは私自身が実践しているところを2週間〜1ヶ月程度見てもらい(やってみせ)、次の2週間〜1ヶ月程度は新スクラムマスターに交代して私は見てフィードバックをする側にまわり(させてみせ)、その後は完全に任せるようなステップで引き継ぎを行なっていた時期があるのですが、そのような引き継ぎ方をした案件でことごとく問題が発生してしまい、最終的には案件を継続できなくなってしまったことがありました。やってみせ、させてみせだけでなく、その後も感謝で見守り続けることがとても重要だと考えています。

まとめ

私自身の経験を元に十則という形でまとめて発表しましたが、特にお伝えしたかった点をまとめてお話しました。

さいごに

色々と偉そうに話しちゃいましたが、もちろんまだまだできていない点も多く、特に第2則の"なんでもかんでもやるな、案件を選べ"についてはとても課題を感じているので、自戒バージョンも紹介しました。

受託開発ベンダー共通の課題だとは思いますが、多数のエンジニアを抱えている以上、固定費はかかり続ける(利益を圧迫する)ため、アサイン率をとても気にすることが多く、アサインが空いていて技術的にも対応可能なら元々ターゲットにしていた領域から外れているような案件でも取りに行ってしまうことがあります。

また、同じく受託開発ベンダー共通の課題として、根拠のない理由で立てた売上、利益目標達成のために、無理してでも目の前の案件を取りに行ってしまうようなことも見かけます。

これらはどちらも、利潤の最大化という価値を重視した行動ですが、私自身"利潤の最大化のみ"を目指すビジネスに疑問を感じているところがありました。

最近読んだ『2050年を生きる僕らのマニフェスト』という本で、著者でありクラウドファンディングで有名なキックスターターの共同創業者であるヤンシー・ストリックラーは、もちろん利潤はビジネスを継続する上で必要だが、利潤最大化「以外」の価値も求めてビジネスしたほうが合理的だという主張をしていて、大変共感しました。

結果的に利潤が増えることこそ重要であって、先に利潤の目標があり、その目標に対してアクションしようとするから色々と歪みが生じてしまうのではないでしょうか。

そのような思いを持って登壇した後、Day1のナイトセッションでウルシステムズ代表取締役会長、創業者である漆原さんの登壇を聞きました。

ウルシステムズでは、「エモい開発」と「自社の売上」、「顧客満足」と「自社の売上拡大」のどちらを優先するかを悩んだ時期に、「自社の売上」ではなく、「エモい開発」、「顧客満足」に振り切り、売上目標を立てることを止めたそうです。その結果として、売上は拡大し、以降も右肩上がりの成長を続けているとの事でした。まさにやりたいのはこれ！

根拠のない売上目標を掲げ、その達成のために「エモい開発」、「顧客満足」を犠牲にしていたら、恐らく売上目標の達成は難しく、持続的な成長も止まってしまっていたのではないでしょうか。

その後Day2のランチタイムでアトラクタのRyuzeeさん、サーバントワークスの長沢さんというツヨツヨなお二人に挟まれて受託ビジネスについてご相談する機会に恵まれたのですが、その場でもウルシステムズさんがどういった事をやってきたのかがとても参考になるから調べろというアドバイスを頂けました。

※例えばこの記事とかが参考になりました

その辺りを研究し、突き詰めていくことで、"利潤最大化「以外」の価値も求めてビジネスをしたほうが合理的"ということをぜひ証明していきたいと考えています。