信頼を築く、ウォーターフォールとアジャイルのはざまの開発手法

3/1 テック企業各社が明かすBtoB SaaS開発の秘訣
どうすれば、クライアントの要望を適切にプロダクトへと反映させられる？

主催 : ENECHANGE株式会社

ALGO ARTIS、MCデータプラス、Asobica、ENECHANGEというテックベンチャー4社にてBtoB SaaSのプロダクト開発に携わる開発者が登壇します。顧客からの要望に応えることと、リソースの限られる中でチーム開発をうまく進めることのバランスの取り方にどう向き合ってきたのか、各社の具体的なケーススタディを交えて掘り下げます。最後には、参加者の皆様の疑問を解消するためのQ&Aセッションもあります。

https://enechange-meetup.connpass.com/event/310940/

記事内リンク

【社員インタビュー】アフリカでの小学校教諭からエンジニアへとジョブチェンジ
https://www.wantedly.com/companies/enechange/post_articles/417734

「ケンブリッジ発！優秀なエンジニアが集う思いやり企業」 ENECHANGE株式会社
https://pr.forkwell.com/career_navi/enechange/

ENECHANGE CLOUD
https://enechange.co.jp/e_cloud-lp/

ENECHANGE CLOUD DR
https://dr.enechange.co.jp/

ENECHANGE CLOUD EV
https://enechange.co.jp/e_cloud-ev/

ENECHANGE CLOUD RED
https://enechange.co.jp/e_cloud-red/

Transcript

1. 信頼を築く、ウォーター フォールとアジャイルの はざまの開発手法 ENECHANGE株式会社 2024年3月1日 東証グロース 証券コード：4169
2. Copyright © ENECHANGE Ltd. All Rights Reserved. | 2 自己紹介 • ENECHANGE株式会社 エネルギークラウド事業部 Renewable Energy ユニット ◦ PM / backendエンジニア ◦ 主な業務: 要件定義、設計、実装、QA、運用保守 • その他 ◦ イギリス 在住 (ワークフロム UK制度) • どんな人物かは過去の記事を見てください! ◦ 【社員インタビュー】アフリカでの小学校教諭からエンジニアへとジョブチェンジ ◦ 「ケンブリッジ発！優秀なエンジニアが集う思いやり企業」 ENECHANGE株式会社
3. Copyright © ENECHANGE Ltd. All Rights Reserved. | 3 今日のお話 • スピーカー（私）のお仕事 • 開発プロセス と クライアント要望 • 試みた戦略と実施結果
4. Copyright © ENECHANGE Ltd. All Rights Reserved. | 4 本日は3つあるENECHANGEの事業のうちの1つ、データ事業 • EV充電エネチェンジ 駐車場オーナー向けEV充電インフラサービス プラットフォーム事業 データ事業 EV充電サービス事業 Deregulation 自由化 Digitalization デジタル化 Decarbonization 脱炭素化 Decentralization 分散化 • 家庭向け電力・ガス切り替えプラットフォーム • 法人向け電力・ガス切り替え支援 • ENECHANGE CLOUD Marketing （小売電気事業者向けマーケティング支援） • ENECHANGE CLOUD DR（電力データ活用） • ENECHANGE CLOUD RE/EV （EV、再エネ価値在庫管理、PPA）
5. Copyright © ENECHANGE Ltd. All Rights Reserved. | 5 4つあるユニットのうちの1つ、 REユニット ENECHANGE CLOUD RE※3 ENECHANGE CLOUD Marketing※1 電力会社向けDXサービス ENECHANGE CLOUD DR※2 家庭向けDR ENECHANGE CLOUD EV EV充電情報サービス 自由化 デジタル化 分散化 脱炭素化 再エネ業務管理・ オンライン発行等 のDXサービス （東京電力EP子会社） • ENECHANGE CLOUD • ENECHANGE CLOUD DR • ENECHANGE CLOUD EV • ENECHANGE CLOUD RED
6. Copyright © ENECHANGE Ltd. All Rights Reserved. | 6 REユニットの特性 • 脱炭素領域でのサービス展開 • BtoB • まだまだこれからの市場 → 戦略: リーディングカンパニー(大手電力会社)とサービス、プロダクトを磨き上げていく → 特性: 上記の戦略をとるため、受託開発色が強い 　REユニットの成功の鍵を握るのは、 「いかにリーディングカンパニーと信頼を築き、先見性のあるプロダクトを素早く構築していくか」
7. ウォーターフォールとアジャイル
8. Copyright © ENECHANGE Ltd. All Rights Reserved. | 8 ウォーターフォールとアジャイル 一般的なイメージとして、それぞれの特徴は次のように言われています。 ウォーターフォール アジャイル 特徴 上流工程から下流工程まで順に進め る 機能ごとに「開発→リリース」の小さな サイクルを繰り返す 開発規模 (Cost) 大規模開発に適しており、高い 小～中規模開発に適しており、低くなる 開発期間 (Delivery) (無駄に)長い ・不要な機能を作ったり、資料が膨 大だったり変更管理だったり 短い 要求・仕様 詳細に定める必要がある 途中で仕様変更は難しい 大まかに決め、開発しながら詰めていく 仕様変更にも柔軟に対応できる ※ さまざまな前提によって異なると思いますが、あくまで一般的なイメージです。
9. Copyright © ENECHANGE Ltd. All Rights Reserved. | 9 ウォーターフォールとアジャイル 向いているケースは次のように考えられる。 ウォーターフォール アジャイル 向いているケース ・作りたいシステムが明確で、要件定義 を詳細に行える場合 ・業務要件が定まっていて、変更の可能 性がない業務システム開発 ・開発工数が多く多数のエンジニアが必 要な大規模開発 ・開発の目的はあるが、要件や仕様が細か く定まっていない場合 ・市場の動向や顧客の反応などによって、 システムに変更や修正が生じる可能性が高 い開発 ・短期間でサービスをローンチしたい場合
10. ウォーターフォールには課題があるが、かといっ てアジャイルにはできない
11. Copyright © ENECHANGE Ltd. All Rights Reserved. | 11 ウォーターフォールでやるしかない。しかし変更を許容してほしいクライアント クライアントの要求 適している開発手法 MUST: いつまでに何ができるようになるのか を早く知りたい。その前提となるQCDもしりた い。 ウォーターフォール MUST: 社内の監査に対応するため、文書や設 計書が必要 ウォーターフォール WANT: 要件・仕様について詳細に定めるのは 難しいし、途中で仕様変更もしたい ※ MUSTのものもしばしば アジャイル
12. Copyright © ENECHANGE Ltd. All Rights Reserved. | 12 ウォーターフォールの限界 ウォーターフォールをやるには、要件定義と設計に相当な経験とコミット確保し続けるコストがかか る。 ウォーターフォール アジャイル 要件定義・ 基本設計の 難易度 大抵スケジュールが決まっていて、 要件を詰め る時間がない 具体的なイメージがないと 要件が膨らみやすい 体制やコミット量、スキルなど 顧客サイドに依存 するところが大きい 仕様変更の手戻りリスクが高いので 詳細まで詰 めないといけない 形を作っていきイメージを磨いていく蹴るの で要件を小さくできる 調達コスト・リ スク 上記のように難易度の高い要件定義及び設計 を長い期間行うため、 人材調達コストが高い 要件定義・基本設計が終わるまで 実装担当のエ ンジニアの待ち時間が長い ★ENECHANGEはSIerではないのでこれを続 ける体制をとるのは得策ではない 要件を小さくできるので、開発難易度は下 がりエンジニア調達コストは下がる 要件定義が長引かない上、次の開発の要 件定義を開発中に実施可能なため 実装担 当エンジニアの待ち時間が少ない
13. Copyright © ENECHANGE Ltd. All Rights Reserved. | 13 なんとかしたい課題はなにか 1. 要件定義・基本設計の難易度が高く、人材の調達コストや維持できないリスクを抱えて進むのか、はたま た要件定義や基本設計をアジャイルのように進めていくのか。 2. ウォーターフォール開発だが、仕様の変更は許容してほしいクライアント。それをどこまで許容し、いかに 仕様変更マネジメントコストを抑えるのか。
14. 試みた戦略と課題
15. Copyright © ENECHANGE Ltd. All Rights Reserved. | 15 基本方針 1. 要件定義・基本設計の難易度が高く、人材の調達コストや維持できないリスクを抱えて進むのか、はたま た要件定義や基本設計をアジャイルのように進めていくのか。 → 要件をミッションクリティカルなものに絞る 。期限は本当の最終ラインを掴んでおく 。 2. ウォーターフォール開発だが、仕様の変更は許容してほしいクライアント。それをどこまで許容し、以下に 仕様変更マネジメントコストを抑えるのか → バッファを厚めにとり、できるだけ設計書の完成を顧客と目指すが、決まりきらない部分を許容して 実装に入る (要するに、ウォーターフォールとアジャイルの間をとる選択 )
16. Copyright © ENECHANGE Ltd. All Rights Reserved. | 16 方針を実現するための戦略 1. 顧客折衝に強いチームづくり 2. ドメイン理解力と顧客折衝力の高い「オフェンス型フルサイクルエンジニア」 3. wetな信頼関係作り
17. Copyright © ENECHANGE Ltd. All Rights Reserved. | 17 顧客折衝に強いチームづくり • REユニットのPMチーム体制 ◦ 以下のメンバーは全員マネージャー・リーダークラスで、週2〜3の社外mtgに出席していま す。 ▪ PM 1人 ▪ オフェンス型フルサイクルエンジニア 1人 ▪ 上流に強いベテラン QAマネージャー 1人 ▪ 営業マネージャー 1人 • 顧客の要望をプロダクトに反映するために以下を意識しています。 ◦ プロジェクトの成功が何か知る、顧客理解力やドメイン理解力 ◦ プロジェクトの成功へのロードマップが描くエンジニアリング力 ◦ それを顧客と認識合わせして合意するPM力、顧客折衝力 • エンジニアリング力は、通常リードエンジニアが担うと思いますが、リードエンジニアの役割とし ては従来考えられていない領域も担当するオフェンス型フルサイクルエンジニアというポジショニ ングを取っています。
18. Copyright © ENECHANGE Ltd. All Rights Reserved. | 18 ドメイン理解力と顧客折衝力の高い「オフェンス型フルサイクルエンジニア」 オフェンス型フルサイクルエンジニアの動き方 1. 高い視座でビジョンを描くビジョナリーリーダーと会社と業界の方向性を共有 2. フルサイクルデリバリー を後方支援する専門集団と実現性を共有 3. 1と2の話し合いをベースにクライアントをあらゆる側面支援でリードする 
 結果として 要件を掴む場を多く持ち、素早く仕様検討・見積もりを実施できる
 DX推進者 業務担当者 オフェンス型
 フルサイクルエンジニア ・会社の方向性 ・業界の方向性 ・システムの実現性 ビジョナリーリーダー (事業部長、営業戦略部長等 ) 専門集団 (CTO室, SREチーム等) クライアント 主な業務 コンサル セールス デザイン PM 設計 実装 テスト 運用
19. Copyright © ENECHANGE Ltd. All Rights Reserved. | 19 wetな信頼関係づくり 厳密なウォーターフォールのやり方通りに進めると、どうしても「顧客満足度」が上がらない対応をしなければな らない場面が出てきます。「顧客満足度」がプロジェクトの成功指標の一つですので、クライアント側は我々ベン ダーと、ベンダー側はクライアントと wetな信頼関係を築くことが重要になってきます。 そのため、以下のようなことを意識して信頼関係を築いています。 • クライアントを取り巻くさまざまなステークホルダーと良好な関係を築く • 受け入れテストは本社に赴き総合的な支援を実施 • リリース後には必ずクライアントとともに打ち上げ
20. Copyright © ENECHANGE Ltd. All Rights Reserved. | 20 できるだけ設計書の完成を顧客と目指すが、決まりきらない部分を許容して実装に入る ❖ 要件定義と基本設計を明確に切り分けない ➢ 要件定義は基本的にクライアント側が行うべき業務ですが、システム化出来る部分やすべき部分 について知見がある当社も協力することで、より価値を最大化していくことができると考えていま す。そのため要件定義を最大限サポートし、素早く基本設計を行い、また要件を見直すというサイク ルを行うため、要件定義と基本設計を明確に切り分けずに行っています。 ❖ 基本設計工程で設計書が完成するのを待たず、手戻りにならない範囲でできるところから実装を開始す る ➢ どうしてもクライアントの別プロジェクトの状況次第で決まらないことや、別部署との折り合いがつか ずに決められないことがある。 ➢ 最低限下記の設計書は作成しておき、できるところの実装を進めている間に残る部分の設計が間 に合うかどうかをベースに実装開始判断をする。 ▪ 機能単位の仕様書概要 ▪ 画面項目定義 ▪ 機能を実現するのに重要な入力項目 ▪ 機能を実現するのに重要な出力項目
21. Copyright © ENECHANGE Ltd. All Rights Reserved. | 21 課題点 • 柔軟でハイパフォーマーの活躍によって成り立っているため属人性が高い ◦ これに関しては組織戦略も踏まえた話になるため本日は割愛 • 基本設計で設計書を完成させない方法は諸刃の剣。開発とテスト設計に待ち時間が生じたり、レビュータ イミングを仕様FIXのたびに持たないといけなくなり、開発・テスト工程の遅延につながり品質低下を招き やすい。 ◦ 以下は、今の私の考え ◦ ケースバイケースで、個別判断をしていくべき。 ◦ 今の私の関わる案件は以下の特性を持つことから、もう少し厳格に基本設計レビュー工程を挟み、 不十分な場合にはスケジュールとスコープの見直しをすべきと考える ▪ 品質リスクが高い ▪ 開発スコープが大きい ▪ 既存の実装が疎結合でなく不安定な部分がある (=影響範囲が読みにくい ) ▪ 業務ロジックが多い上に複雑 (=影響範囲が読みにくい ) ▪ 運用保守工数を厚くすることをクライアントと合意し、リリース後にカバーできる範囲を広げる ことができた ◦ 一方で上記が当てはまらないのであれば、ある程度影響範囲が小さい部分の仕様変更や遅れて の仕様FIXは許容していくことが強みになっていくのではないか
22. さいごに
23. Copyright © ENECHANGE Ltd. All Rights Reserved. | 23 あなたも一緒にエネルギーの未来をつくりませんか？ ENECHANGEでは、「エネルギーの未来をつくる」という壮大なミッションに取り組んでいただけるエンジニアを募集し ています！ https://engineer-recruit.enechange.co.jp/ または「エネチェンジ　エンジニア」で検索