kintoneでの開発を考える・その5／群体アプリを統合するときに考えること
プロ雑用です。
このnoteは、こちらのシリーズの第５回目です。
そろそろkintoneが出て…出て…いや、出てきません。
でもちょこっとだけ触れてます。申し訳程度に…
前回は、多くの組織が分業し専門性を高めた結果、その組織全体の目的を理解しなくても、業務が回るようにできているため、現場主導の開発はうまくいかない、という話を書きました。
今回は、最初に上げた今回のシリーズの議題「kintoneにおけるシステム統合の壁」を乗り越えるには、どんな考えで進めていけばいいのかを解説していきます。
システムを作るときは目的を芯に置く
kintoneで簡単につくれるアプリは「手段」として要求を元に作ることができます。しかし、システムは要求にしたがって作ると確実に失敗するということは、前回も述べました。
kintoneはVモデルで言うところの実装作業を省略します。それ以外の部分を言語化していく必要があり、その方法についても同様に前回述べています。
システムを作る前に、システムを使う目的を明確にすること。これが最も重要で最初に考えることです。ここをなんとなく済ませてはいけません。わからなければ「わからない」ということも含めて、関係者全員で共有する必要があります。
目的が何なのか？を考えながら役割、目標、入力、項目に分解して言語化していくのも前回述べた通りですが、実装作業、つまりは実際のアプリ開発に入る前にどこまで確定するか、を考えます。
従来のシステム開発では、項目一つに至るまでを決めます。ウォーターフォール型は、「前工程が間違っていないことを前提として詳細まで作り込む」というモデルですし、コーディングによってプログラムするということは、詳細が決まっていない「曖昧」な状態は許容しません（実態は別として）。
まぁ、それでも１からシステムを作るのだったら、ウォータフォールで進めていくのも、決して筋の悪い話ではありません。
では、各部門で作られたシステムという名の群体アプリを、どのようにシステムとして統合すればいいのか。多くの企業がある程度のところで頭を悩ませる問題です。
kintoneアプリ群の統合は何から考えるべきか
この場合も、やはり肝となるのは目的が何なのか？ということです。
各部門で作られたシステムという名の群体アプリは、どんな目的で作られているのか。統合したシステムはどういう目的を持っているのか。
目的と手段を切り分けて考える
そもそも群体アプリを使っている部門や担当者は、どんな目的や役割を担当しているのか。含まれるアプリは何を目的・目標としているのか。どんな内容を誰が入力しているのか、などを改めて整理します。
システムの統合においても、このような「kintoneとシステム以外」に目線を移して考えることがとても重要になります。むしろ、そうでなければ、０から構築するのと同様、だいたい失敗します。
一言に、目的といっても、担当者、役割、部門などによって大きく異なります。中には、一見目的がコンフリクト（衝突）している部門などもあるでしょう。こういうときに、kintoneやアプリだけを見ていても、話はまとまりません。kintoneやアプリは、あくまで手段なのですから。
異なる目的は対立している…わけではない
部門や担当者事に目的が違っている場合も多くあると思います。一つのプロセスに複数の人や部門が関わっていたとしても、例えば営業は受注数や売上が目標としてあり営業部門としての目的も持っているの同様、生産部門は事故率の低下や時間あたり生産数などを目標とし営業とは別の目的を持っているのが普通です。これは経理や情シス、経営企画、CSなど、ありとあらゆる部門でも同様です。
これは企業の中で分業をしているからこそ、あたりまえに発生することです。そもそも分業は効率性を高めるために本来は考えられた手法なのですから、本来は生産効率を高める効果があるはずです。
しかし、システム統合の際にそれが障害になるのは、分業本来の目的を、関わっている全員が「忘却」しているから、あるいは「知らないから」ということがあります。なんでもそうですが、今の時代に合わないものでも「かつては苦難の末にたどり着いた最適解」なわけで、古い仕組みが悪いわけではなく「環境変化に適応してこなかった」ことが悪いのです。
環境変化に適応してこなかったのはなぜか？といえば、それはやはり業務の目的を見失ったから・忘れてしまったから、ということに尽きるでしょう。そもそも、ひとつの企業内で目的がコンフリクトしている事自体が、その証左と言えましょう。
なので、部門や担当者、役割や立場による目的の違いからくる対立は、そのさらに上位の目的が不明瞭になっているからこそ発生する問題です。
対立を超えて上位の目的を探す
ということで、再びVモデルに戻ります。この図では、すべてのフェーズは目的に対して設計・検証されることを表しています。
システムの統合においては、以下のようにも表せます。
それぞれの部門ごとのシステム（という名の群体アプリ）の目的の上位、いわば業務プロセス全体の目的は何かを考えなければ、詳細部分の何を合わせればいいのか、あるいは合わせなくてよいのかが見えてきません。
これは見方を変えると↓のように表せます。
kintoneで考えると、これは業務プロセス全体の目的に応じて「どのデータを正しく次の工程に受け渡していくのか」と理解することもできます。しかし、データの流れだけ見ればよいのか、といえばさにあらず。
そもそもユーザー（担当者）は、シリーズその３で述べた通り、目的なんか知ったことではないので（本来はそれではダメなのですが実態として）、目的を意識させずに正しいデータを入力してもらうこと、つまり「誰が何を入力するのか」という活動を考慮する必要があります。
ということで今回はここまで。
次回はより具体的な話に移っていきます。
ようやくkintoneが出てくるか…な…？ｗ
それじゃ、また👋
この記事が気に入ったらサポートをしてみませんか？