開発の前に、まずビジネスを理解する

企業がプラットフォームの開発を検討するとき、話はたいてい目に見えるものから始まります。

デザイン。

モジュール。

機能。

アクセス制御。

レポート。

しかし、そのすべての前に、結果の大部分を左右しうる段階があります。

それは、ビジネスが実際にどのように動いているかを理解することです。

見た目が優れたプラットフォームでも、支えるべき業務を正しく表現できていないことがあるからです。

まず、ビジネスロジックがある

どの企業にも、独自の業務の進め方があります。

決まった手順に沿って進むプロセスがあります。

特定の条件によって変わるルールがあります。

ユーザーごとに異なる権限があります。

特定のタイミングでだけ表示されるべき情報があります。

状況に応じて異なる対応が求められる場面もあります。

これらはすべて、テクノロジーになる前から存在しています。

そして明確に理解されていなければ、開発は問題の一部しか解決できずに終わる可能性があります。

機能はシンプルに見えても、全体を掘り下げると違って見える

プラットフォームへの人の登録という、ごく日常的なことを考えてみてください。

一見すると、ただのフォームに見えるかもしれません。

しかし、その裏にはいくつもの判断が隠れていることがあります。

どのような情報を求めるべきか？

どの項目を必須にするか？

登録後に何が起きるのか？

ユーザーにはどのような権限が与えられるのか？

何にアクセスできるのか？

どのプロセスが自動的に開始されるのか？

目に見える機能はシンプルかもしれません。

その裏にあるロジックは、そうとは限りません。

テクノロジーを設計することは、問いを立てることでもある

構築する前に、理解する必要があります。

最初に何が起きるのか？

何が何に依存しているのか？

それぞれの操作を誰が実行できるのか？

条件が満たされないときはどうなるのか？

各ロールにはどのような情報が必要なのか？

どのプロセスに人の介入が必要なのか？

何を自動化できるのか？

どのような例外があるのか？

こうした問いが、漠然としたアイデアを、システムの中で表現できる業務へと変える助けになります。

例外もビジネスの一部である

プロセスは、理想的なシナリオを前提に説明されることがよくあります。

しかし、日々の業務がそのとおりにだけ進むことはまれです。

特殊なケースがあります。

変化する条件があります。

確認が必要な状況があります。

メインの流れどおりには進まない取引もあります。

こうした例外を最初から考慮しておかないと、システムの外で処理されることになりかねません。

やがて、その場しのぎの対応が、管理の難しいプロセスになっていくことがあります。

開発には文脈が必要

テクノロジーチームは機能を構築できます。

しかし、正しい機能を構築するには、その機能がなぜ存在するのかを理解する必要があります。

誰が使うのか。

どのような問題を解決するのか。

どのような情報を受け取るのか。

どのような情報を生み出すのか。

そして、業務の他の部分とどのようにつながるのか。

その文脈が、開発の進め方を変えます。

仕事は、もはや依頼をこなすことだけではありません。

その依頼がビジネスの中で果たす役割を理解することです。

プラットフォームはビジネス上の判断も映し出す

すべての権限は、ひとつの判断を映し出しています。

すべてのワークフローは、ひとつの優先順位を映し出しています。

すべての自動化は、ひとつのルールを映し出しています。

すべてのレポートは、ひとつの情報ニーズを映し出しています。

だからこそ、プラットフォームは単なるツールの集まりではありません。

企業がどのように組織されているかを表すものにもなりえます。

その組織のあり方が明確であるほど、テクノロジーへの落とし込みもより一貫したものになります。

より良く構築することは、より良く理解することでもある

プロジェクトをいきなり機能から始めると、画面に何を表示すべきかに意識が向きがちです。

業務から始めると、話の中身が変わります。

チームは、何が起きる必要があるのかを検討します。

なぜそれが起きるのか。

誰が関わるのか。

どのような情報が関係するのか。

そして、どのような結果を生むべきなのか。

その違いは、最初は小さく見えるかもしれません。

しかし、その後に構築されるすべてに影響を与えうるのです。

おわりに

テクノロジーは、コードを書いたときに始まるのではありません。

解決すべき問題を理解したときに始まります。

画面を設計する前に、プロセスを理解しておくと役に立ちます。

操作を自動化する前に、ルールを理解しておくと役に立ちます。

機能を構築する前に、その目的を理解しておくと役に立ちます。

企業のためにテクノロジーを開発するとは、ツールを作ることだけではないからです。

実際の業務を、意味のあるデジタルの構造へと落とし込むことなのです。