インターラクティブ アプリケーションソフトウエアサービス開発について

# はじめに
経営者として、実務者として、マネージメントと運営を並行して行うことがあります。そして、立ち上げ時期や成長時期のインターネット関連事業や事業のソフトウエア開発部門に携わっています。

会社はビジョンや指針などより抽象的な概念を示し、会社の価値を唄うことがあります。それは会社の価値の定義のようなもので、第三者によりソフトに伝え、伝わる内容になっています。開発現場は、その理念のために業務を実行します。つまり、仕事をします。

一方、そんな抽象的なゴールに向う仕事を進める現場は、よりハードで具体的です。一つ一つの積み上げ作業の連続によって、具体的なものに表していきます。その連続作業の途中、手段と目的が相互に連続連動し入れ替わりながらそのサイクルが循環します。何とかその開発を概念化できないか、考えていました。

今回は、インターラクティブアプリケーションソフトウエア開発として概念化してみることにしました。

インターネット上でサービスを提供しているインターネットの事業があります。そして、そのインターネットの構造は、人と人の間にある情報の相互作用のサイクルの中、連続連動しながら、重層的で複雑な概念で形成され、絶えず新たなものに更新されていることで成り立っています。それは、常に **利用者の感動や満足** によって支えられています。 **使われなかったら、無いと同じ** です。また、鑑賞するものでもありません。 **使われるために使う人を絶えずモチベート** する必要があります。

次に、ソフトウエア開発ですが、この **最終的なアウトプットは機能** です。そして、開発は、その機能をつくり、再利用可能なものをつくり、ものごとを制御するという特徴があります。機能は、目に見えるインターフェスをもったものや、目に見えない単なる処理など区分することができます。

アウトプットが機能であるがゆえに、ソフトウエアの実装現場では、 **どんな機能を作るかということに重きを置く** 傾向があります。作業者目線でいくと、仕方のないことで、必然があり、磨く工程など場合によっては、とても重要なことになります。

しかし、機能は、サービスの一部で、掘り下げていくとその機能にたどり着くまで、多くのことが考慮されています。そして、複数名のチームで行う場合が想定されます。

つまり、どのように機能を実装するのか、 **機能を実装する以前の背景が重要** になってきます。そして、この背景を開発チームで理解しておく必要があります。

**どのように、どんな機能をリリースするのか** で一番重要なことは **俯瞰作業** です。この作業によって、その背景を共有することができます。

この **俯瞰作業** により **より明確に問題にフォーカスし共有** することができ、 **コンセンサスのとれた状態での課題化(イシュー化)** ができるようになります。この **課題化（イシュー化）** によって、実装準備が容易になります。

結果、 **俯瞰作業** を概念化することで、概要・目的にあるようにチームで対話的に開発がスムーズに行われ、よりよいアウトプットがもたらせると考えています。

最後に、 **作業は常に現場** で起きています。**楽しく作業ができることことが、ソフトウエアサービスエンジニアの生きがいであって欲しい** なと思っています。

そして、インターネットをより良いものにしてくために、 **ソフトウエアサービスエンジニアがもっと活躍**
 できるようになったら良いなと思っています。

# 概要・目的
インターラクティブアプリケーションソフトウエアサービス開発(IASSD)とは、具体的なアクションプランを作成するための開発課題の決定基準を定め、サービスとしてのソフトウエアーをチームで対話的に開発するためのコンセプトをSnapDishの事例で紹介しています。

# IASSD概念
IASSDは、ビジネスの動力を開発し走らせることを目的としています。動力源は、ユーザーのよりインターラクティブな体験を通じた感動です。言い換えると、IASSDは、利用者がサービスのストリーを体験し感動をすることでサービスと継続的な関係を築き、その提供者が継続的なビジネスを行うための開発概念です。

# 継続的ビジネス
感動体験によりサービスが継続し、収益を得続けることです。

# 開発の心得
私たちはサービスとしてアプリケーションソフトウェアを開発します。それは機能の集合ではなく、人々が感動するものです。

# 開発プロセス概念モデル
まず、開発プロセスは、ストリー構築から始めます。ストリー構築後、実装計画と準備を行います。そして、実装しリリースをします。リリース後、ストリー通りの体験が提供できているか振り返り評価します。次のストリーを構築するとうプロセスでサイクルします。それぞれの構成要素は、次で解説しています。

![開発プロセス概念モデル.jpg](https://qiita-image-store.s3.amazonaws.com/0/18766/116dfb9e-ff56-ddd3-8f40-6e8aebb84554.jpeg)

# ストリー構築概念モデル
ストリー構築をする際は、サービス概念を共有理解することから始めます。サービス概念モデルで詳しく紹介しています。

まず、実際サービス自体が具体的にどのような構成要素で成り立っているか分析し俯瞰しておきます。

次に、区分されたユーザーとの相互作用性やデータの価値や提供している機能でどのような体験を提供しようとしているのか、更に掘り下げ俯瞰しておきます。

この俯瞰作業で、重層的で複雑化した状態を正しく把握し、次にどの様なストリー上の場面を提供するかを判断することができるようになります。

作業者目線で言うならば、ストリーを構成している場面から要件を整理し実装計画に繋げることができるようになります。どの場面を開発するかを決める作業が、一番時間のかかる作業になります。

![ストリー構築概念モデル.jpg](https://qiita-image-store.s3.amazonaws.com/0/18766/db24675d-9424-edaf-0fb4-0f7cbbd6abbb.jpeg)

## サービス概念モデル
下の概念モデルの様に、アプリケーションソフトウエアーサービスは、ユーザーとデータと機能と体験で成り立っています。

それぞれの構成要素の中身は、サービスの内容によって異なりますが、図の外枠に各構成要素の最も重要なことを説明しています。

この概念は、全ての構成要素が連続連動し、そして、継続的に循環している状態を表しています。

このサービス概念は、IASSDの コア・コンセプト になります。このモデルが成立することで、より質の高い開発がなされ、適切なサービスが提供できると考えます。

![サービス概念モデル.jpg](https://qiita-image-store.s3.amazonaws.com/0/18766/574dedd0-a1b8-5b55-8936-d70b3c0515cb.jpeg)

## サービス構成要素分析
SnapDish https://snapdish.co を例に分析しています。

![サービス構成要素分析.jpg](https://qiita-image-store.s3.amazonaws.com/0/18766/f01b52d2-f368-9b16-192d-825b4bb7d907.jpeg)

## ユーザー区分と定義
ユーザー区分と定義をすることで、ユーザー相互作用性を具体的に理解することができます。

それぞれの相互作用（Interaction) の定義を行います。今回は、右の表の様な定義をしています。

定義は、ストリー構成を考える際の場面の目的になります。ストリー構成で解説しています。ストリー構成にはまらない定義は、定義から省きます。より単純な状態にできれば実装準備の負担が軽減できます。

次のポジショニングマップは、継続性と動機度合いを軸に、区分と定義を可視化したものです。

今回は、より難易度の高い定義が、"More Motivation" 側になります。より継続に繋がる定義が、"More Retation" 側になります。

実際は、この区分と定義とポジショニングマップは、ストリー構成時に不都合がでたら、見直す必要があるので、ストリー構成完了後確定することになります。

![ユーザー区分と定義.jpg](https://qiita-image-store.s3.amazonaws.com/0/18766/dc816097-4a84-c29f-ef92-2b9d82e9513e.jpeg)


## ポジショニングマップ

![ポジショニングマップ.jpg](https://qiita-image-store.s3.amazonaws.com/0/18766/9c81aec4-8911-8818-fea0-116e6d6697b9.jpeg)

## ストリー構成
ストリー構成では、サービスの利用導線を可視化し、ストリー上でどんな場面を提供し終着点へ導くか把握します。今回の執着地点は、"投稿とコメント"になります。これは、"Assetizable data" が直接的に生成される定義"になります。

矢印が場面になります。場面では必ずテーマを設定し、その内容を軸に場面の組み立てを行います。矢印の先の定義が場面の目的になります。

### 登録前WEB

![登録前WEB.jpg](https://qiita-image-store.s3.amazonaws.com/0/18766/251928d9-8a6b-ede0-151c-2f8366e17606.jpeg)

### 登録前

![登録前.jpg](https://qiita-image-store.s3.amazonaws.com/0/18766/563c5616-3e2d-83c5-66d5-e68f1daff58b.jpeg)

### 登録後

![登録後.jpg](https://qiita-image-store.s3.amazonaws.com/0/18766/0cca6948-c702-3043-0199-26ea288fb160.jpeg)

# ストリーの場面設計プロセス

具体的に場面をどのように設計していくのかというプロセスを紹介します。実務部分では一番関心の高いところだと思います。

まず、どのストリーの場面設計するかを決めコンセプトを設定します。サービス概念モデルにあるUX（体験）の向上がコンセプトになります。

次に、コンセプトの構成要素を分析します。UXと何なのか？という定義になります。各構成要素ごとの分析項目を明確にします。次で解説しています。

分析後、開発の目的を決めます。コンセプトと分析項目を俯瞰しながら、やるべきことを決めます。より抽象的な内容が望ましいです。「何々を良くする」の「何々」を決めることが最も重要な作業になります。

最後に、分析項目から課題を導き出し、評価指標を定め開発した内容が後々評価できるようにします。指標が設定できないものは基本開発に取り込みません。課題と指標で解説しています。

![ストリーの場面設計プロセス.jpg](https://qiita-image-store.s3.amazonaws.com/0/18766/40c04f63-4fb4-524a-13fb-59aecd67d3a9.jpeg)

## コンセプト構成要素分析

![ストリーの場面コンセプト構成要素分析.jpg](https://qiita-image-store.s3.amazonaws.com/0/18766/ffc9ba16-85e0-30b9-2d0d-f929a800d7c2.jpeg)

## 課題と指標

![ストリーの場面設計課題と指標.jpg](https://qiita-image-store.s3.amazonaws.com/0/18766/6cddc4e0-b35f-0f74-1ba6-cd683a6c941a.jpeg)

# 実装計画と準備
ストリー構築で確認した開発対象となる場面から、要件を整理します。そして、既存のユーザーや機能とコンフリクトしていないか、など同時に検証します。コンフリクトしていることが確認された場合、ストリーを見直す必要があります。

要件が整理できたら、機能とUIを設計します。設計は、具体的な独自のアイデアや他サービスを参考に準備します。

設計後の設計レビューは、相対的条件と絶対条件を考慮して実施します。

技術的難易度や実装範囲や予定やチームやビジネスの状況によって左右される場合があるものは、相対条件になります。

絶対条件は、実装した機能の評価をするための計測を必ずできるようにすることです。開発プロセスのレビューで必要になります。

最後に、範囲と予定とチームを決めて準備完了となります。

![実装計画と準備.jpg](https://qiita-image-store.s3.amazonaws.com/0/18766/31078393-b0d0-000c-77b3-63ffe01d1626.jpeg)

# 実装とリリース
実装計画と準備で決めた、範囲と予定とチームと手法の内容によって、管理手段が決まります。

それぞれの開発に合ったツールなどを利用することが望ましいです。

リリースの条件では、最終的にリリースに必ず含ませるもと条件が整えばリリースできるものと整理します。条件は、開発MTGで決定します。

リリース条件が決まったら、作業リストを作成し実装を進めます。実装後、通常、テスト、確認、リリースの手順で新実装を公開します。

![実装とリリース.jpg](https://qiita-image-store.s3.amazonaws.com/0/18766/719fd83a-2f0e-027b-3f07-e08cb22643c3.jpeg)

# レビューと評価
レビューでは、まず計測データを確認し、ストリーの良し悪しを評価します。

そして、ストリー構築後に行ったことを振り返り、右の図のサイクルで、次回に役立てるレビュー作業を行います。

通常レビューは、MTGで行います。レビューをする前には、計測データを必ず準備しておきます。

レビュー中の反省や良かった点を次のストリー構築に役立てましょう。

![レビューと評価.jpg](https://qiita-image-store.s3.amazonaws.com/0/18766/f5c7b43b-c075-104e-0a3b-c887bce4bd1e.jpeg)