プロ雑用です。
理想と現実のロジカルシンキング。
第二回目は、現実を直視した私が、その先に何を見て、
そして何を考えたのかを、記していきます。

まずはkintoneのことを知る必要がある

私は「kintoneをなんとかしてくれ」というOrderと共に、
「このままkintoneでいいのかどうかも考えてほしい」
というOrderも合わせて受けていました。
これはつまり、

kintoneは捨てても良い、別のツールへの乗り換えも含めて考えよ

と、いうことです。

折しも時期は11月。
CybozuDays2017が開催される時期。
早速わたしは幕張に飛び、二日間みっちり参加しました。
そこで、kintoneにつよい可能性を感じることができました。

2017のテーマは「壁を超えろ」。
まさに、この時、kintoneで壁を超える決意ができました。
会社に戻った私は、役員とのMTGで開口一番こう言ったのです。

「kintoneで行きましょう。kintoneならやれます」

こうして、私はkintoneを、本格的に使っていくことになります。

決意はしたけど、具体案はなし

kintoneで行くことを決意したのですが、
次に私はどこまでやるか、どうするかを具体的に考えたのですが、
すぐに壁にぶち当たりました。

前回も記した数々の問題。

1.全体統括する管理者の不在
2.肥大化したボトルネックアプリの存在
3.閲覧制限が掛かりまくっている
4.秘伝のタレと化したカスタマイズ
5.無数の管理者による勝手なアプリ改修
6.主要なデータの多くが活用できない状態
7.選択項目で最も使われているのが「その他」
8.使い方は「口伝」で継承されている
9.プロセスの全てがアプリになっているわけではない

これだけのことを一体どうやって直すというのだ？
そもそも治せるのかこれ？という壁。

そこで私はまず、kintoneに向かう前に、
「自分がどうしたいか」を考えることにしました。

何をするか、自分のWillを見つめる

この図は、WillCanMustのワークフレームです。
人間誰しも、
”出来ること”があり、
”やりたいこと”があって、
”求められている”ことがあります。
その輪が重なりが大きい＝中心が大きいほど、成長する、とされています。
（余談ですが、このフレームは、5W1Hと共に、
　汎用性が高いワークフレームの一つだと思います）

CanとMustははっきりしている。
では、Willは？

おまえのWillは何なんだ。

自問自答を繰り返し、導き出したのが、

すべての業務のボトルネックを無くす。
みんなが、顧客に全力で向き合える環境をつくる。
これを自分のVISIONとして設定し、kintoneを使って実現するのだ。

これでやるべきことが決まりました。
kintoneを治すのではない、覚悟を決めて、全て作り直すのだ。

kintoneアプリの、Willはどこにあるのか

全てを作り直すと決めたので、
その時のアプリについては、一旦すべて忘れました。

すべて忘れて、
その時はまだ存在していない、
みんなに必要であるはずの、
全てのkintoneアプリの姿を描くことにしました。

この時に考え出したワークフレームが↓これです。

名前はつけていませんが、
仮に ACフレーム（抽象 の 因数分解 と 具象 の 展開式）とでもしましょう。

ミッションをより具体的に示したビジョン、
ビジョンをたどり着くために、
どんな目的を持った人・組織が、どの工程を担い、
各々の役割を果たすために、どの指標を把握する必要があるのか。
それを実現するために、どんな機能が必要なのか。

これを、最も最上段にある、”ミッション”から紐解いていきました。

つまり再設計するにあたっては、アプリを考えるのではなく、
この組織が何を・どこを目指しているのか、を考えたわけです。

あえて遠回りする理由

アソビューのミッションとビジョンは、すでにあります。

ここから考えることにしました。

ところで、課題解決のためのアプリなんだから、
最初からアプリを考えればいいじゃないか、と思いますよね。
十分承知しています。
承知した上で、あえて言わせてもらえば、
ここまで徹底して考えたものは、後々までブレません。

なぜでしょうか？

ミッションは、とても抽象的な表現で示されていることが多いです。
抽象的であるということは、
解釈にばらつきが出やすい、ということでもあります。

一方で課題というのは、
具体性が高くないと、適切な解決策が出てきません。

例で説明しましょう。
たとえば、ある少年の夢は
「宇宙飛行士になりたい！宇宙に、月に行きたい！」だとします。

この夢を聞いたあなたは、
この願いを叶えるたった一つの案を、考えつくことができますか？
おそらく、できないのではないでしょうか。
わたしもできません😂

当然、宇宙飛行になるためには、
無数の課題が存在しているということが、想像できると思います。
たとえば必要となる学力ひとつ取り出してみても、
その学力を得るための課題が、たくさんあるはずです。

山登りでもそうです。
突然あなたがエレベストに行きたい！と思い、
着の身着のままエベレストに向かう、ということはないでしょう。

つまり、
抽象度がすごく高い理想と、具体性の高い現実との間では、
適切な問題設定ができない＝解決できる課題が見つけられない
ということなのです。

それを解決するためには、
問題を小さくする＝より具体的な課題に分解していく、必要があります。

階段を一段ずつ上がるように、
着実にクリアできる課題を考えていけばいいのです。
問題を、これ以上分解できないな、というところまで分解できれば、
必然的に、クリアできる課題がみえきます。

ここまでを踏まえた上で、
先程のACフレームでは、kintoneはどこに位置するのか？
おわかりと思いますが、そうです、機能の部分です。

つまり、あえて遠回りに見えるこのフレームは、
高い理想を実現するための問題を、
「解決できるレベルの課題に分解するため」
より具体的に言えば、

「　確実に、課題を解決するアプリを作るため　」

にとても有効なのです。

さて、長くなりましたので、今回はここまで。

次回は、このACフレームを実際にどのように使っていくのか、
実例を用いて、詳しく書いていきます。

次回「ブレイクダウン／課題を見つめる」

それじゃ、また。