見出し画像

今自分達は「正しいものを正しく」作れているか

DELTA

はじめに

この記事は所属するチームのteam DELTA Advent Calendar 2022 14 日目の記事です。

とあるスタートアップ開発組織の現在地と課題を、「正しいものを正しくつくる」を物差しに整理してみました。

自己紹介

中島（なかしま）悠輔といいます。
元々EPRパッケージベンダーに在籍し、ITコンサルと少し開発を担当していました。今はDELTAでプロダクトマネージャーとして、製品づくりに携わっています。


ある開発組織の事例

私がDELTAに所属したのは今年3月。ITコンサルタント出身ということもあり、プロジェクトマネージャーとして参画することになりました。要件定義やスケジュール管理を主に担当するなかで、印象の強かった出来事ご紹介します！

予定通り進まない開発

開発が2ヶ月遅延。。。

私が参画して一番最初に任されたプロジェクトは、CLINIC TEN SHIBUYAのシステムを大幅に改修する「リニューアルプロジェクト」というものでした。最初は、3月スタートの9月末完了予定でしたが、なんと７度のスケジュール調整（微調整を含めると10数回）を経て、最終11月末の着地となりました。。

開発後期で明らかになる追加要件

現場からの100件近いFB。。。

「リニューアルプロジェクト」が実装を終えて、ようやく既存システムと並行稼働のタイミングとなったタイミングで、なんと現場から100件近いFBが寄せられました。バグの報告が多かったものの、中にはクリティカルなFBがちらほら。。

少しずつ変わった反応

しかし！そんなFBに対して１つ１つ向き合う中で、徐々にユーザーからも「使いやすくなったね！」とポジティブなFBをいただくようになりました。
比例して既存システムに対して6月は週12件きていた問い合わせも、11月には月で14件と1/4まで減少していました。12月はまだ2件！（12日時点）

ポジティブなFBが返ってくるように

でもそれってなんで？？

この9ヶ月、ずっとガムシャラにプロダクト作りに向き合ってきましたが、何もないところから少しでも価値を届けられるプロダクトを作ることができた理由を、もっと整理して再現していきたいな。と思い、昔に借りっぱなしになっていた、「正しいものを、正しく作る」を手に取ることにしました。


「正しいものを正しく作る」

筆者紹介

市谷 聡啓

Energizer、 レッドジャーニー代表、株式会社リコーCDIO付きDXエグゼクティブ、元政府CIO補佐官、founder of DevLOVE、
「リーン開発の現場」翻訳者、「カイゼン・ジャーニー」・「正しいものを正しくつくる」・「チーム・ジャーニー」・「いちばんやさしいアジャイル開発の教本」など多数の書籍を執筆

https://ichitani.com/profile/
同氏個人サイトより

全体のサマリー

この本では、大きく以前の開発プロセスの課題から、アジャイル開発の説明、実践的な補足、またアジャイル開発というプロセスを用いて、どう「正しいものを作るか？」という点に焦点を当てていました。
この本を読むことで、

  • アジャイル開発の大枠

  • 実装の前段となる製品の価値探索のプロセス

  • 作り上げた製品価値仮説の実装プロセスと検証の流れ

  • つまり、アジャイル開発によって0→1を成功させるプロセス

を知ることができると感じました。

その内容について、簡単なサマリーを載せるのも面白いのですが、実は既に市谷さんが作られているので

ここでは、私たちがCLINIC TEN SHIBUYAへ提供している、予約・診療・請求管理システムの開発プロセスを振り返って、

１、自分達が実践できていること
２、取り入れたいこと

に焦点を絞って、内容を取り上げていきたいと思います。


１、自分達が実践できていること

①1週間スプリントでの開発

現在CLINIC TEN SHIBUYAの支援チームでは、毎週水曜日を起点に1週間スプリントで開発を実施しています。

得られているメリット

  • 1週間単位でチケットの整理を行うため、スケジュールが組みやすく、優先順位を開発順序に反映しやすい

  • 実装にリズムが生まれ、開始と終了が近いため中だるみしづらい

  • 成果が見えやすく、現場からのFBを得やすい

取り組み

  • 毎週火曜日までにプランニングを行い、翌スプリントの実装チケットが決まる

    • 割り当てられたものをもとに見積もりを行い、スプリント内で収まるか確認

  • 毎週水曜日にスプリントが開始され、日次で進捗確認やスケジュールの調整を実施

  • 翌週火曜日夜に実装したものをリリース

  • 翌週水曜日昼にリリースした機能の現場への共有と、実装内容に対するFBのヒアリング、問題あれば翌々週のリリースまでに修正

💡バックログ

毎週何をやるかが整理されたバックログ。チケット内容、優先順位、対応時期が主に記載されています。

バックログ一覧


②ミニプロダクトオーナー

CLINIC TEN SHIBUYAのプロジェクトにももちろんプロダクトオーナーがいますが、クリニック事業の責任者を兼ねているため非常に多忙です。そこで、私がプロダクトオーナーやクリニックメンバー（ユーザー）と頻度良くプロダクトについてコミュニケーションを取ることで、プロダクトオーナーに近い目線で製品へFBできる状態にしています。時には1日中クリニックにいる日が1ヶ月近く続いたことも。

得られているメリット

  • 現場に与えるインパクトの大きさを開発チーム内で判断できる

  • スケジュールの調整を行う際、1つの機能についてどの深さまで実装するかをその場で意思決定できる

  • 細かな仕様の意思決定を、スクラムのデイリーの中で実施できる

    • 主に細かな挙動や、UIについてはその場で意思決定してスピードを下げないようにしています

取り組み

  • 機能の要件定義を、要求のヒアリングから要件や仕様に落とし込むまでを、UI含めて担う

    • 複雑なUIへの落とし込みはデザイナーに委託

  • ユーザー（医療現場）とビジネスサイドとのコミュニケーションの窓口となる

  • ビジネスサイド内のプロダクトについての方針決めは積極的に関わる

💡スピードを担保するプロダクトオーナー

現場からのFBが、徐々に良くなっていった背景も、チームの中にミニプロダクトオーナーがいることで、スピード感をもって製品へFBを反映できていたからだと振り返っています。


２、取り入れたいこと

続いて、今DELTAチーム、特にCLINIC TEN SHIBUYAのプロダクトを開発する中で感じる課題感をもとに、「正しいものを正しくつくる」から取り入れたい施策について整理しています。

特に大きな課題

  • プロジェクト後期で主要な機能やUIに対して、見直しを迫られるFBを受ける

  • 計画に対する進捗が、遅延する傾向にある

①プロジェクト後期で機能やUIに対して、見直しを迫られるFBを受ける

課題背景

  • テストケースや、一部の画面のUIデザインをもとに現場と認識合わせを行っても、動くソフトウェアとなってから追加のFBが発生してしまう。

    • 例）予約を一覧するカレンダー画面において、予約単位の情報量と予約全体の一覧性のバランスに対して「見づらい」とFBがあり、コンポーネントの配置やコンポーネントそのもののデザインの修正が必要となった。

期待値マネジメント

書籍の中で、こういった後から明らかになる期待のことを暗黙的な期待と紹介されていました。期待を表明していなかったり、当事者が期待に気づいていない状態を指す。そうした暗黙的な期待のすり合わせを行う方法として、プロトタイピングが提案されていた。

取り組み

  • Figmaのプロトタイピング機能を用いて、できる限り実物に近い挙動をするデザインで認識合わせを行う

  • シナリオを一通り流せる状態になってから現場FBを受けたが、単体で動く状態になり次第、現場からのレビューを受ける（検証の早期化）

②計画に対して遅延してしまう

課題背景

  • ①実環境にデプロイすると、想定外の実データによって不具合・手戻りが発生してしまう。

    • 例）検索画面で実データが入ることによって、初めて表示速度が想定より遅いことがわかった

    • 例）予約を一覧するカレンダー画面において、あるデータにおいて表示崩れが発生してしまうことがわかった

  • ②当初想定していた実装見積もりから大きく外れてしまう

不確実性への適応

書籍の中で、開発の不確実性が発生する原因としては、先ほどの期待値マネジメント不足と、メンバーの学習による新たなチケットの発生によると書かれている。特に後者は避けることが難しく、想定外の工数増加は避けられない。その対策として3つの軸が示されていたが、中でもスプリント強度を高める戦術から2つほど対策を下記にピックアップした。

取り入れたい施策

  • ①実運用レベルのデータによるテスト実施

    • テスト環境のデータの充実を図る

  • ②ベロシティの計測

    • 毎スプリントごとの工数の予実の可視化

    • 過去の実績をもとにバッファを設定する（余白の戦略）


おわりに

今回は、主にアジャイル開発自体の手法について、書籍の中から取り上げてみました。

ちなみに、「正しいものを正しくつくる」には、アジャイル開発を使ってどうユーザに受け入れられる「正しいもの」をつくるか、という仮説検証型のアジャイル開発の進め方も説明されています。

DELTA でも少しずつ SaaS として社外へ販売することを目指すプロジェクトも立ち上がってきており、仮説検証型アジャイル開発についても実践する中での気づきが溜まってきたら、ぜひみなさまと共有できたら嬉しいです！

We're hiring!

ここまで読んでくださってありがとうございます！

DELTA では、多事業展開している VC の中のソフトウェア開発チームというユニークなポジションを活かし、

多様な環境での開発に日々チャレンジしています。

株主や自社事業という立場からは中長期的な視座での関わりが求められる一方、

「多」事業展開しており VC としても多様な出資先を持つため幅広な技術力が必要になる環境だと感じています。

いわば多様な技術にチャレンジし取り入れられる受託開発と、

深くコミットメントを持ち製品に向き合うことのできる自社サービス開発の「良いとこどり」のような働き方ができる職場です。

エンジニアにとっては非常に面白い環境だと思うので、ぜひぜひここまで読んでくださった方とは何らかの形で繋がりたいです！

ご興味ありましたら delta.tech@sevenrich.jp まで！


この記事が気に入ったらサポートをしてみませんか？