【スタートアップ×アジャイル開発との向き合い方】でも最後は結局、信頼関係
アジャイル開発と一口に言っても
開発会社によって色々と手法がありますが
代表的なものとしては
・スクラム
・エクストリーム・プログラミング(XP)
・ユーザー機能駆動開発(FDD)
あまり耳馴染みがないものとしては
・ASD(Adaptive Software Development)
・リーンソフトウェア開発(LSD)
・クリスタル・クリア
・アジャイルモデリング
・DSDM(Dynamic System Development Methodology)
といったものがあります。
詳細に関しては、ここでは本題ではないので割愛しますので、皆さんで気になるワードを調べてください。
まあ結局は進め方の方針、体制、フローを策定してるということですよ
大事なのは手法ではなく、工夫の仕方や
配慮だと思うのです。
もちろん先駆者の既存の手法のルールに乗っ取れば、それに見合った成果は得られますが
正直やってみて、これは微妙だと思ったのもありました。
例えば、スクラムですが、これは弊社のようなスタートアップ様や新規事業案件をメインに従事している開発会社には合いません。
具体的には、やる事(日々の進捗管理に重きを置くための業務フローのイベント)が多くなり、いつの間にか、それをこなすことがゴールに置き換わり、本質を見失う気がしたからです。
個人的に、スクラムが向いてるのは、仕様がある程度定まっており、あとは頑張って大きく進めるだけ、でも手戻りも少しあるかもね…
的なケースで、ジュニアレベルのエンジニアを多数登用する時の管理面だと思います。
少なくとも、弊社にはマッチしませんでした。
ユーザー機能駆動開発(FDD)ベースでの開発
現在、株式会社マイムでは
これに近い何か(笑)みたいな開発方針を取っています。
部分的に、他のアジャイル開発手法もミックスして、お客様との対話に重きを置き
都度、予算、ゴールを調整しています。
元々、大規模開発向けに編み出された手法ですが、弊社では小規模ながら
この手法から学びを得て、プロジェクトへの関わり方を意識しています。
この手法について、ざっくりと偏見、自己解釈を混じえつつ説明をしますと
大規模開発では、多人数になりますから
プロジェクトのビジョンや価値観、業務内容を等しく伝えるのが困難です。
そこで、それを強く意識せず済むよう
機能を細分化します。
例えば、Web決済機能で考えます。
・Web上で商品を選ぶ
・カード情報などを入力する
・決済会社とのAPI通信
・間違いがないかDB整合性のチェック
・完了画面
大まかにこのようになります。
しかし、ここから更に細分化します。
・Web上で商品を選ぶ
ここは、商品一覧画面ないし、商品詳細、もしくは商品カートの概念があるはずで
すでにこの時点で、簡単にはここまでたどり着けない機能であるはずなのです。
ユーザー関連の機能も出てきていません。
つまり、何も無いスタート地点では
かなり作るのが厳しい機能であることがわかります。
弊社では、こういったことが考えられる際に
マストなのか、代替案はないのか
必要になるフェーズはどこなのか、顧客様とすり合わせ、協議していきます。
この粒度で機能のレベルを細分化して行くと
パズルのピースが出来上がり
それは
・業務フロー、業界知識が求められるパーツ
・普遍的な価値観で誰でも作れるパーツ
とで、区分されます。
そして、これらをいくつか組み合わせると
達成される１機能が沢山あるという状態になります。
細分化の粒度は内容によりけりですが、ここを大きくカテゴライズして担当範囲として割り振ってしまうと、あとで調整が大変になり、多くの開発プロジェクトではこの部分がネックでトラブルが起きると、経験上、弊社は考えています。
粒が小さいほど管理の大変さは出てきますが、ミスった際のダメージが少ないということで、弊社では少数で良い所取りを目指したスタイルを取っています。
弊社では、こういった内容をもとに予算やスケジュールを組み、順序だてて開発方針を擦り合わせていきます。
過去事例の紹介
■プロジェクト
都内企業様某マッチングWebアプリ
■予算/スケジュール
当初：300万、3ヶ月
結果：350万、4ヶ月
※デザイン含む
■説明
こちらは某業界の人材をビジネスマッチさせる仕組みのサービスでした。
当初はオンライン決済の仕組みが組み込まれていましたが、サービス化する際に
ターゲットとなるペルソナ的や、その決済頻度から、決済機能自体を見送り
代わりにほかに通知の機能を作りこんだり
不足分の機能を盛り込んで半月ほど
当初のスケジュールから遅れてのリリースとなりました。
ビジネスモデルも少し変化していて、そこにシステム的に対応する工数なども生じ
とはいえ、スケジュールが伸びるのも今日できる範囲で良い感じの落とし所を探るといった調整もありました。
■所感
このようにして、スタートアップ、新規事業では、開発や時間が進むにつれ
オーナー様の気持ちの変化や、ここはやっぱりこうした方が良いよね？
これは別に最初から無くてもサービスとしては成り立つよね？
といった事案が少なからず発生し、柔軟な対応が求められます。
ひとつのアジャイル開発の手法に制限されてしまうと、この部分でトラブルになるため
弊社では基本的に何かが発生することを見込んで、こまめに定例で擦り合わせをしつつ
融通が効くところが多くなるよう、あまり縛りをいれておりません。
顧客様によっては管理をガチガチに行って安心したい部分もあるのですが、弊社では
この辺の見積もりにはあまり時間をとっておらず、機能だけ洗い出し、全体の進み方に応じて都度調整をしています。
これはあとからスケジュール感が決まるというより、タイムリミットまで何が出来るか現実的に探るためです。
基本的には大きくズレませんが、平均してスタートアップ、新規事業では他のもろもろの調整も含め、半月〜1ヶ月は多めに見たスケジュール感をお伝えしています。
こういった調整をご納得いただくには
それを裏付ける説明資料や、築き上げてきた信頼関係しかないと思っており、弊社ではそこに1番の重きを置いております。
最後に発注企業様に向けて
システム開発会社といっても、開発手法は沢山ありますが、全てに共通するのは
単なる使用人だと思ってしまうと、結果として発注者様に損だということです。
システム屋は黙って作るのに専念していれば良い
こう思ってしまうとですね、我々にはもちろん伝わります（笑）
そして弊社同様、他の開発会社様も今まで沢山のシステムにたずさわってますから
プロジェクトを進めていて、色々な気づきがあるのです。
弊社としては、それをお伝えし、併走して改善方法を探るお手伝いもしたいと考えており、実際にそのように動いています。
それはお金や言い訳ではなく、本当に発注様のためを思って問題提起しているのです。もちろん解決策や落とし所は一緒に探していくつもりなので、「いや絶対に何がなんでも当初通りに行くんだ」という気持ちもわかりますが、まずは一度飲み込んでいただけるよう弊社も注意深くお伝えしています。リスクをご理解いただき、それでもということなら、それはそれで覚悟を決めて進めていくだけですので、弊社としてもその中で出来ることで並走していきます。
また頼れる味方と感じていただけると、何よりもっと親切にしたくなるのが人情というものです。
ご自身の過去のトラブルや、高額になりがちな開発費といった側面で、最初はなかなか信頼できないかもしれませんが
開発会社は頼ってナンボだと思います。
なにか突発的な問題が起きた際も、やはり頑張って対応しますし
変な話、信頼関係がないと、いやそんな事は約束してないので対応しませんみたいな塩対応でフェードアウトなども起こりえます。
こうなると本末転倒で、メンテできないシステムだけが残ります。
そうならないように、弊社のような開発会社と付き合う際は、信頼関係が築いていけそうかという判断要素はとても重要なのです。
弊社では、お仕事をいただくまでに数ヶ月前からヒアリングを行なっており、そちらに関しては完全に無償です。
その際、弊社のお出しした資料も、相見積もりや、比較にご利用いただくことを推奨しております。
弊社としても最初の信頼を勝ち取るために、出せる情報は惜しまず全てお出ししますので、良いアイデアがあれば、そのままご自分のモノにされて構わないくらいのスタンスです。（NDAも契約前から巻いています）
実際に、弊社には「他社様と比較して一番内容が明瞭で良かったので決めました」といった感想をもとに発注される企業様が多いです。
特に初期のスタートアップ様は、内製しない限りは、事業の存続とシステム開発会社とは、一蓮托生のようなものですから、金銭面もそうですが、あらゆる事を想定して御検討なされると良いと思います。
この記事が気に入ったらサポートをしてみませんか？