理想と現実のロジカルシンキング５

プロ雑用です。
前回まで、ACフレームを使って、
目的→工程→役割→指標と分解してきました。
いよいよ機能、kintoneのアプリを設計していきます。

が、その前に。

道具の形を決定づけるもの

前回、関連する工程・役割をまとめた図を紹介しました。
ここに記された”指標"を元に、アプリの設計を行います。

ここで私がアプリを設計する際に、気をつけてることが２つあります。

一つは、アプリを「誰が」「どのように使う」という活用イメージ。
もう一つは、管理するのは「情報」か「行動」かというデータの種類。

この2つは密接に関連していて、アプリの最終形を決定づけます。
逆に言えば、この2つが抑えられていれば、設計はほぼ終わりです。

順に解説しましょう。

その刃は正面から戦う刃か、暗殺する刃か

まず、アプリを「誰が」「どのように使う」か。

アプリを「誰が」は、関連図を見れば、”役割”で明らかになっています。
では「どのように使う」の部分は、”指標”でしょうか？

前回のおさらいになりますが、指標は「可視化」することです。
よって、「どのように使う」こと、そのものではありません。
しかし、可視化することが決まっていれば、おおむね決まります。
なぜなら可視化は、結果だからです。
結果によって道具は形が変わります。

関連図を見てください。
見込顧客を把握するため、アプリをどのように使えばよいか。
受注活動を把握するため、アプリをどのように使えればよいか。
これはつまり、
＝アプリにどんなデータが入っていれば良いのか
ということです。

アプリを「誰が」「どのように使う」か、ということは、
「指標を明らかにするために、どのようなデータを持つべきか」
これを考えることで、アプリに必要となるデータが自ずと決まります。
逆にいうと、データが決まることで、アプリの形も決まるのです。

食材は冷蔵庫に、リレーにはバトンを

もう一つ、アプリで管理するのは「情報」か「行動」か。

用語の解説をしましょう。
「情報」は、いわゆる静的データ（ストック）のこと、
「行動」は、進捗などの動的データ（フロー）のことを指しています。

専門的に言うと、
静的データは、処理過程を通して不変なデータ、
動的データは、処理中に内容が変化するデータです。

簡単に言うと、
静的データは、冷蔵庫やタンスにしまうもの。それ自体は何もしません。
動的データは、運動しているもの、動きそのものとその結果です

これがアプリになんの関係があるのか？
先程「データが決まることで、アプリの形も自ずと決まる」と記しました。

正しいデータが決まらないと、アプリの形も決まらない

という意味でもあります。
正しいデータとはなんでしょうか？
この場合、正誤の意味ではありません。
適切かどうか、という意味です。

より具体的に言うと、
どのデータを、どのフィールドに収めるか、
あるいは状況によって変わる内容は、プロセス管理を使うのか、
ドロップダウンでいいのか、ラジオボタンにするのか。
ということです。

どれが正しいか、ではなく適切なものはどれか？

目的のために何が必要になるのか、という問いの、
さまざまな解答の一つが”指標”です。
その”指標”を見るため＝適切に得るための機能が、アプリです。

その適切なデータを収めるフィールドや機能を決めることが、
アプリそのものを形作っていきます。
冷蔵庫は服を収めるためではなく、食材を保管するため。
タンスは食材を保管するには適さず、服などを保管するため。
各々の目的の則って機能と形をしています。

そして食材や服を保管するのは、達成したい目的があるからです。

目的はゴール。たどり着く場所に思いを馳せよ

できあがった料理をイメージすることなく、食材を選ぶことはできません。
出かけるシーンに応じて、服を選ぶことも同じ話です。
投げられたボールを打つには日頃の素振りが欠かせません。
ゴールを決めるためには、どうやってボールを繋ぐか。
リレーで結果を出すには、走り以上にどのようにバトンを渡すか。

常に見るのは目的です。
一番の具体的ば部分である、フィールドとそこに入るデータまでもが、
ゴールである目的によって、変わってきます。

例によって、購買・新規開拓で考えてみます。

指標である、見込顧客を見るためには、未掲載のパートナーが、
どれくらいいるのか（数量）
どんなあそびを提供しているか（種類）
どんな場所でやっているか（所在地・住所などのエリア情報）
いくらで販売されているか（価格）
いつからいつまでやっているのか（季節、月）

受注活動を見るためには、
誰が、いつ、誰に、どのように、連絡したのか。
受注するまでのステップはどれくらい進んでいるか。
あるいは進んでいない理由はなにか。
失注は何件か、受注率はどれくらいか。

これらのデータを収めるフィールドとして、どれを選べばいいのか？

極端な話。
全てのデータは”文字列”だけで完結できます。
複数行のフィールド一つだけあれば、十分かもしれません。
しかし、そこに蓄積されたデータは、
それで目的を果たすための指標が把握できるなら、問題ありません。

果たしてデータをどのように活用できるか？
繰り返しになりますが、
目的から工程、役割、指標とブレイクダウンしてきたのは、
適切な機能（アプリ）を作るためでした。

だからこそ、常に目的を意識して、
フィールド一つ一つに、頭を悩ませる必要があるのです。

さて、長くなりましたので、今回はここまで。
（やっぱり終わらなかった…）

さらに具体的に、どのようにアプリを設計し作ったのか。
次回はその話を書きたいと思います。

それじゃ、また。