スタートアップAshiraseの開発 #前編【全体概要～上流工程】
こんにちは。Ashirase CTOの田中です。
創業してはや１年半が経過しました。プレシリーズAの調達がクローズし、丁度良い節目ということもあり、あしらせに興味がある方によりあしらせのことを知っていただくためにNoteを書き始めることにしました。
本記事では、あしらせの開発をどのように行ってきたか？またどのようなツールや技術を用いているのかについてお話し致します。
これまで、投資家の方、開発パートナー、スタートアップ界隈の方、あしらせに興味を持ってくださった方など、多くの方とお話しさせていただきました。その中で、あしらせでやってきたものづくり開発に対して、幸いにも、もっと教えてほしいと興味を持っていただいたり、お褒め戴くことがありました。
まだ製品も発売前ではありますが、ユーザにとって使いやすいものを素早くリリースできる、またエンジニア自身も気持ちよく開発ができるようにいろいろと工夫をしてきました。ゼロからの開発だったので、スタートアップの生々しい内容を記載することができるのではないかと思います。
ひいては、より多くの方にあしらせについて知っていただければと思うと共に、より良い製品開発に結びつけられればと思います
本記事の全編では、あしらせを創業してから今までの開発を振り返り、全体概要から上流工程までを書きました。
後編では実装からテストを行いイテレートしていく部分について書きました。
是非読んでみてください！
想定読者
ベンチャーやスタートアップで働いてみたいと思っている方
あしらせに興味がある方
ものづくり開発に興味がある方
あしらせとは
あしらせは、視覚障がい者向けの歩行ナビゲーションシステムです。あしらせは靴装着型のデバイスです。靴に装着することで、足にフィットさせ、デバイス自身が振動することで道をナビゲーションしていきます。
あしらせは、エッジデバイス・モバイルアプリ・バックエンドシステムから構築されます。エッジデバイスではHWの製造・組み込みFWの開発が含まれます。
私が考えるスタートアップにおける開発の在り方
私見ですが、競争優位性を保ちながら自社製品を開発をし続けていくためには、開発フローとして素早くイテレートできる必要があると考えています。いわゆるアジャイル開発です。
またイテレートしていく中で大切にしているのは、なぜその修正が必要なのかといったWhyが他の人に伝わるように、また自分自身でも腹落ちしながら開発を進めていくことです。なんとなくの修正はあしらせの開発にはありません。
また、いくら良い技術でもユーザにとって価値のないものは製品として存在し続けることはできません。ユーザに取って価値があるものが造れているかどうかを確認するできる開発フローである必要があります。
そのため、基本的にはV字フローと言われる一般的な開発の流れは変わりませんが、MBSEの考え方とSysMLを利用して、要求、要件定義・設計・実装・テストの流れを一元管理しています。(MBSE・SysMLの説明は省略します)
以降は私達が実際に行っている開発の各工程の概要です。より読みやすくするために、「工夫した点」やそれによって得られた「恩恵」や「課題」等を極力記載しました。
また、各工程それぞれが、奥深いので機会があればそれぞれNoteに記載しようと思います。
①上流工程（要求分析・要件定義）
要求分析では「システムライフサイクル分析」「ユースケース分析」「コンテキスト分析」「VOXの収集」「ステークホルダ要求図の作成」「システム要求の作成」を行います。
まず、一貫して気を付けていることは、MECEにステークホルダの要求を抜き出すことです。要求で漏れがある場合は、当たり前ですがシステムに反映されません。次に要求にダブりがある場合は以降のシステム要求図(要件定義)とのトレーサビリティが取りづらくなります。
ですので、要求に漏れがないように上記の各種分析、収集を行い、それらをダブりが内容に要求図に纏めています。また、要求図に正解はありません。どのようなシステムが正しいかは分からないからです。
■ 工夫
・開発全体のワークフローをPFD図により纏めています
■ 恩恵
・各プロセスに対するinput, outputが明確になり、チーム内部での共通理解ができる
ライフサイクル分析
ライフサイクル分析は、サービスのライフサイクルを分析します。ライフサイクルには、製造、輸送、在庫、運用、保守、廃棄などの様々なステージがあります。提供するサービスの各ステージに対して要求に漏れが無いよう網羅的に解析するために行います。 まずどのようなステージがサービスに存在するのかを分析します。分析後に出てきた各ステージに対してユースケース分析・コンテキスト分析をおこないます。
■ 恩恵
・開発段階から廃棄されるまで、製品のライフサイクル全体を俯瞰することにより、輸送中や、廃棄等、普段のユースケース以外の気が付きにくい要求に気づきやすくなる
ユースケース分析・コンテキスト分析
ユースケース分析はユーザーや、ステークホルダがどのようにサービスを利用するか、どのように動作するのか(ユースケース)を分析します。
例えばあしらせでは、製品開封後に、デバイスを靴に取り付ける、スマホアプリとデバイスを接続するなどが考えられます。
一方コンテキスト分析は、サービスが対象のステージの環境(コンテキスト)で影響を受ける、あるいは与えるものは何かを分析します。
例えば、ハードウェアの販売について、輸送ステージのコンテキストを考えたとき、パッケージのサイズが輸送の効率が変動し、コストに影響を与えることになると思います。
ユースケース分析は動的な関係性を、コンテキスト分析では静的な関係性を洗い出すことを目的にしています。
■ 恩恵
・ライフサイクルステージに分けて分析することで、そのステージでのおおよその使われ方が想定できる
■ 恩恵
・ライフサイクルステージに分けて分析することで、そのステージの外的な要因を網羅的に分析できる
VOXの収集
VOXは、Voice Of XXXXの略です。VOCであれば Voice Of Customer など自由に定義すれば良いと思います。顧客の声や、自社内の声、各種ステークホルダの声を実際に聞きに行き、記載します。
これによりステークホルダ本人の声を漏らさずに要求に組み込めます。
■ 工夫
・あしらせは視覚障がい者向けのデバイスなので、VOCを正確に製品機能として落としていくことが重要と考えています。そこでユーザへのインタビューを大量に行い、それらを体系立てて纏めました(上図緑・青の要素)。次の工程では共通項を見つけ、VOCをユーザ要求へと翻訳します(上図赤の要素)。
■ 恩恵
・ユーザのペインから直接要求を抽出しているので刺さる可能性が高いです
・後から入った開発者がこのダイアグラムを見ることで、実際のユーザや・他ステークホルダの特徴を迅速に知ることが出来ます
・VOCとユーザの要求を紐づけておくことで要求の出所が分かります。この機能本当に要るのか？と疑った際にユーザの声から吸い上げているのと、社内のアイデアである場合とではその後の対応が異なるはずです。
■ 課題
・VOCは作成後アップデートしていません。以降はステークホルダ要求図を直接修正しています。やれるのであればやることが望ましいですが、VOXはステークホルダの特徴の整理を目的とし、管理コストを無くしました。
ステークホルダ要求図の作成
これまでに作成したドキュメント(ライフサイクル・ユースケース・コンテキスト・VOX)と睨みっこをし、要求図を作成します。この作業は利用者が欲しい物を翻訳する作業に当たると思っています。サービスに対してどのような要求が求められているかを考えてステークホルダ要求図としてモデルに落とし込みます。
また、VOXから全ての機能を拾い上げられることはありませんし、VOXが正しい保証もありません。またVOXから要求を抽出しているだけではいい意味でユーザを裏切ることが出来ません。自分たちでVOXを想像し、ステークホルダが持っているであろう要求も定義します。
この時、主語を必ず書く必要があります。ユーザーなのか、運用保守者なのか、など誰の要求かが分からないと曖昧さが残り、他の開発者に意図が伝わらない可能性があるからです。
■ 恩恵
・ステークホルダ要求はユースケースと紐づけて整理しています。それにより、ユーザテストをユースケース毎に行い易くなり、テストがスムーズになりました
・ステークホルダ要求にテストの要素を紐づけることで要求図から直接テスト対象の要求を抽出できます。これにより要求を更新してもテストが漏れることなく実施することが出来ています
・ステークホルダ要求は、チームの内部で認識をすり合わせるのに利用しています。開発される機能がチーム内部で共有されることでチーム内部のごたつきが防げています。
・ステークホルダ要求とシステム要求を紐づけています。これにより、システム要求からステークホルダ要求へのトレーサビリティを追うことが容易になりました
システム要求図(要件定義)の作成
ステークホルダ要求図をシステム要求図に変換します。
ここで要求の主語がステークホルダからシステムに移ります。
例えば、「ユーザーは雨の日でもサービスを利用したい。」をシステム要求に変換すると、「あしらせデバイスは、雨の日でも利用可能でなければならない。」となります。この要求をさらに分解し、「IP68以上でなければならない」等の要件レベルまで落とし込めると良いと思います。
あしらせでは各ステークホルダ要求をシステム要求図に変換する際の主語として、「あしらせデバイス」「スマホアプリ」「バックエンドシステム」それぞれを兼ねる場合は「システム」を主語としています。ステークホルダ要求図はステークホルダ毎に作成しましたが、システム要求図は1つのダイアグラムに纏めています。システム毎に作成しても良いかと思います。
■ 恩恵
・システム要求にテストの要素を紐づけることで要求図から直接テスト対象を抽出できます。これにより要求を更新してもテストが漏れることなく実施することが出来ています
・システム要求は、チームの内部で認識をすり合わせるのに利用しています。開発される機能がチーム内部で共有されることでチーム内部のごたつきが防げています。
■ 課題
・システム要求と設計が紐づいていないため、その間のトレーサビリティを追うことが出来ていません。
設計
要件定義が完了後これらを設計に落としていきます。ブロック定義図や、アクティビティ図、シーケンス図等により要件が達成できるようなアーキテクチャを考えていくことになります。しかし、あまり作り込み過ぎると、改版が大変になりますので、程々にしたほうが良いと思います。
設計部分に関してはまた機会があれば記載したいと思います。
■ 恩恵
・全体の動作概要と、フォーカスしたい機能等をに重点を置いて記載しています。それにより必要最小限の管理コストで開発者間の認識をすり合わせることが出来ています
・ダイアグラムに落とすことで、サービスやSWとしての動きが見えてきます。頭が整理され、設計しやすい状態を作れています
・ブロック定義図でクラス図同等の内容を定義しています。後から入ってくるエンジニアが内部の構造を理解しやすくなっています
■ 課題
・実際のコードと設計内容がずれてきます。気合を入れてどこかしらのタイミングで整理しなおすことを繰り返す必要があります。
まとめ
最後まで読んでいただきありがとうございます。あしらせの開発フローについて【全体概要～上流工程】について紹介させていただきました。
次は、【実装～テスト】について書こうと思います！
あしらせでは一緒に働く仲間を募集しています！
ものづくり、スタートアップ、あしらせに興味を持っていただけた方、上記の開発を一緒にやりたい、より良くしていきたい方、是非応募待っています！
この記事が気に入ったらサポートをしてみませんか？