フローチャートを1記事で理解する｜シェアサイクルの全プロセスを分析

あらゆる製品設計において、構築プロセスは避けられないリンクです。これは、その後の製品フレームワークの基礎を築き、ユーザー エクスペリエンスの基礎となります。本記事では、フローチャートの定義や分類から始まり、実際の事例を交えながらフローチャートの役割や描き方をわかりやすく解説します。

意味

プロセス - 名前が示すように、水の流れの経路、進行中の物事の順序またはシーケンスの配置と調整。プロセスは自然に存在します。標準化されておらず、固定されておらず、問題だらけである可能性もあります。

2 つ以上のステップで完全な動作を完了するプロセスをプロセスと呼ぶことができます。プロセスは 2 つ以上のステップであることに注意してください。

フローチャートの核心は、物事を実行する順序をどのように配置するかにあります。順序が異なると、結果がまったく異なる可能性があります。

目的

プロダクトマネージャーがフローチャートを描く目的は、次の点だけです。

1. フローチャートは製品設計の基礎であり、製品の使用ロジックが合理的かつスムーズであることを保証できます。
2. 要件を伝え、フローチャートを使用して製品ロジックをより適切に表現する
3. 漏れがないか確認し、不足している分岐プロセスがあるかどうかを確認します。

分類

フローチャートは、ビジネス プロセス図、ページ フロー図、機能フロー図、データ フロー図などのオブジェクト分類を記述するために使用されます。

トランザクションフロー図 (TFD)

宋丹丹のスケッチから頭の体操を例に挙げてみましょう。象を冷蔵庫に入れるには何ステップありますか?

3 つのステップ:

• 最初のステップは冷蔵庫のドアを開けることです。
• 2 番目のステップは、象を入れることです。
• ステップ3: 冷蔵庫のドアを閉じます。

これは冗談のように思えるかもしれませんが、実際には強力な論理的思考が含まれています。まず第一に、ここでは多くの実際的な制約が無視されています。たとえば、冷蔵庫の容量を考えると、ほとんどの冷蔵庫に象を詰め込むことは不可能です。たとえば、象を切り刻んで冷蔵庫に入れることは可能でしょうか?そこに象を詰め込んだら、また逃げてしまうのでしょうか？しかし、これらの制限を除けば、象を冷蔵庫に詰め込むための最小限のプロセスは、わずか 3 つのステップです。冷蔵庫のドアを開けて象を入れ、ドアを閉めます。

ビジネス プロセス図を作成するときは、既存の多くの認知的制限を脇に置き、具体的な動作を 1 つずつ抽象化して、「象を冷蔵庫に詰め込む」という考え方を持つ必要があることがよくあります。

上記の例と組み合わせて、「ビジネス プロセス図」の定義を詳しく見てみましょう。

具体的な操作や実行の詳細を含まず、物事の順序やシーケンスを抽象的に説明します。インターネットソフトウェア業界では、通常、製品設計とは切り離されたユーザー行動プロセスを指します。ビジネス プロセス図は、システム アナリストが理解できる共通言語であり、システムの組織構造とビジネス プロセスを記述するために使用されます。

上記の定義を理解しているかどうかに関わらず、抽象的な思考でショッピング行動のビジネスプロセス図がどのようになるかを考えてみましょう。

上記の 3 つのステップは、あらゆるショッピング行動の中核を完全にカバーする最もシンプルなプロセスを構成します。オンラインで買い物をする場合でも、実際のスーパーマーケットで買い物をする場合でも、これら 3 つの行動が中心となり、その後拡張されます。通常目にする複雑なオンライン ショッピングのフローチャートと比較すると、上記の 3 ステップのプロセスは信じられないほど単純であり、シンプルさの原則を証明しています。私は、どんなに複雑なものでも、極めて単純なものに単純化できると常に信じてきました。単純化できないということは、その本質を理解していないということになります。

上記の最小処理単位をベースに、さらに拡張して、より詳細なフローチャートに適用してみます。

ページフロー図

定義:電子製品に表示されるページジャンプフローチャートを指します。ビジネス プロセス ダイアグラムに含まれるビジネス フロー情報を伝えます。

次の図は、 Taobao を例に、オンライン ショッピングのページ フローを示しています。

上図の赤いボックス内の 3 つのノードから、ページ フロー図がビジネス プロセス図にまだ含まれていることがわかります。これは定義の要件を正確に満たしており、ページ フロー ダイアグラムの正確性も確認します。当初のシンプルなフローチャートと比較すると、現在のフローチャートは徐々に複雑になってきました。抽象的なビジネスを具体的なページにマッピングし、ソフトウェア ページを使用してビジネス ニーズを実現しました。上記は、ビジネスプロセス図からページフロー図への変換プロセスです。

機能フロー図

定義:ページフローに含まれる、単一ページ内または複数ページ間の機能操作フローを指します。

ページには任意の機能が含まれていますが、ページには複数の機能が含まれていることも多く、ページフローチャートだけではすべての処理を十分に表現できない場合があります。このとき、各ページに含まれる機能をより具体的に表現するには、機能フローチャートが必要になります。

上図の赤枠内の 4 つのノードから、ページ フローチャートから機能フローチャートも展開されていることがわかります。機能フローチャートはページフローチャートをさらに発展させたもので、より複雑になっています。同時に、だんだんと誰もが毎日見ているフローチャートのような形にもなっていきます。

データフロー図

定義:図は、異なるノードで処理されるデータのプロセスを記述するソフトウェア製品を指します。主にビジネス向けコンピュータプログラムの実装原理を表現します。機能フローチャート内でユーザーが実行するすべての操作は、データフローチャートに反映されます。同時に、データフロー図はプログラムフロー図（プログラムフロー図）とも呼ばれます。

情報システムの論理モデルを包括的に記述できる主要なツールです。いくつかのシンボルを使用して、システム内の情報の流れ、処理、および保存を包括的に反映できます。データフロー図は抽象的で一般的なものです。

ビジネス プロセス図、ページ フロー図、機能フロー図については誰もがよく知っているかもしれませんが、データ フロー図について知っている人は少ないかもしれません。実際、すべてのフローチャートには、さまざまな操作でシステム全体を循環するコアがあります。たとえば、ほとんどのビジネス プロセス図は人を中心にしており、各ノードはさまざまな人間の行動を伝えます。ページフローチャートと機能フローチャートは似ており、どちらも人間の操作動作と、異なるページや機能間のフローを中心にしています。しかし、データフロー図は異なります。データを中心に据え、システム全体でデータがどのように処理されるかを示します。

より技術的な思考に傾倒しており、バックグラウンド プログラムの実装原則を示すことに重点が置かれています。そのため、多くの場合、この図は開発者が描き、製品マネージャーの関与は少なくなります。しかし、プロダクトマネージャーは成長を続けるにつれて、戦略レベルに上がり、実装レベルに下がります。プログラムの開発原則とその背後にあるデータフローを理解することで、製品マネージャーは間違いなく製品設計をより深く理解できるようになります。

次のデータ フロー図もショッピング プロセスに基づいています。

以前の図と比較して、データ フロー図には手順という新しい次元が追加されています。クライアントはユーザーの操作行動を表示すると同時に、ユーザーの行動の背後にあるプログラムの動作も表現します。多くの場合、製品が複雑だと言われる人は、フロントエンドのインタラクションの複雑さだけに気づき、バックエンドのロジックの複雑さを無視することがあります。優れたプロダクトマネージャーには、フロントエンドのユーザーエクスペリエンスに注意を払うだけでなく、物事の背後にあるロジックを理解できることも必要です。結局のところ、ユーザー エクスペリエンスについては誰でもコメントできますが、プログラムの実装に関しては、プロダクト マネージャーの専門性が反映されます。

まとめ

上の図は、それぞれ製品のビジネス プロセス、ページ フロー、機能フロー、データ フローを示しています。このことから、ビジネスからページ、機能、そしてデータ処理へと拡張が順次行われていることがわかります。製品ページや機能は、突然現れるのではなく、ビジネス レイヤーのさまざまなノードとプロセスに基づいて設計されます。そのため、製品設計を行う際には、まずビジネスを理解することが重要です。

フローチャートの描き方を初めて学ぶときは、業務、ページ、機能、データを明確に区別し、段階的に進めてください。複数の種類のフローチャートを混在させないでください。これではあなたの考えが混乱するだけです。

フローチャートの粒度

フローチャートのいわゆる粒度は、実際にはフローチャートの詳細レベルを指します。

フローチャートを描くとき、​​私はしばしば躊躇し、この機能ポイントをもっと詳しく説明する必要があるかどうか疑問に思います。このブランチをマークする必要がありますか?サーバーとのこの対話イベントをフローチャートに反映する必要がありますか?これらおよびその他の問題は、プロダクト マネージャーが日常的に絵を描くときに直面する問題でもあります。

ショッピングのプロセスを例に考えてみましょう。最も単純なビジネスプロセスは 3 つのステップに分かれています。これをもう少し細分化すると、さまざまなフローチャートを描くことができるでしょうか。

当然ですが、同じプロセスであっても異なるフローチャートを描くことができます。上図のように、商品の選択は3つのステップに分かれており、チェックアウトは2つのステップに分かれています。しかし、2 つのフローチャートは依然として一連のプロセスを表しています。これが、粒度に対する理解が人によって異なる理由です。多くの初心者は、常に 1 つのステップで作業を完了し、完璧なフローチャートを 1 回で描画したいと考えています。しかし、これは実は非常に望ましくない考え方です。完璧なフローチャートは、単純なものから複雑なものへとプロセスを経る必要があり、一夜にして実現できるものではありません。

理論的には、フローチャートが詳細であればあるほど、製品の設計はより正確でスムーズになります。しかし、実際には、過度の詳細さは時間の無駄です。程度を把握する能力には経験の蓄積とチームの連携が必要であり、そこにはプロダクトマネージャーの粒度把握能力が反映される部分でもあります。フローチャートを描く最終的な目的は、非常に詳細なフローチャートを描くことではなく、チーム メンバーに製品の設計を理解してもらうことです。理想的な状況は、チーム全体が理解できる最も単純な形式で図を作成することです。

フローチャートの描画

以上がフローチャートの定義と分類についての説明です。ここからは具体的なプロセスの描き方について見ていきましょう。

フローチャートの基本要素

上記はフローチャートで最もよく使用される要素です。あまり使用されない要素はここには表示されませんが、Microsoft Visio で表示できます。

スイムレーン図

スイムレーン図はフローチャートを描画する方法であり、フローチャート内のいくつかのプロセスノードをさまざまな操作の役割に応じて分割します。たとえば、先ほど示したデータ フロー ダイアグラムは、実際にはスイムレーン ダイアグラム方式を使用して表示されており、上部にはユーザーとサーバーという 2 つの異なるロールがあります。同時に、垂直レーンに基づいて水平レーンを追加し、異なるページに応じて操作を分類することもできます。

複数の役割が関係する複雑なフローチャートの場合は、スイムレーン フローチャートを描くとわかりやすくなります。

フローチャートの構成要素

フローチャートは主に 3 つの部分で構成されます。

1. メインプロセス
2. 分岐プロセス（異常プロセスは分岐プロセスに属する）
3. サブプロセス

下の図では、前の機能フローチャートの例をメインプロセスとして使用し、分岐プロセスを追加しています。フローチャートを描くときは、まずトランク、次にブランチの順序に従う必要があります。これは、ほとんどのユーザーにとって、トランク プロセスが最もよく使用されるパスであるためです。

メインプロセスとブランチプロセスは誰でも理解できますが、サブプロセスとは一体何でしょうか?フローチャートを描く過程では、ログインプロセス、登録プロセス、パスワード変更プロセスなど、頻繁に遭遇するプロセスがいくつかあります。電子商取引の場合、返品手続きやお買い物券の利用手続きなどが必要になる場合があります。関連するフローチャートを描くたびに、再度描画するのは面倒です。したがって、サブプロセスは論理的な関係を持つ複数のノードの集合であり、さまざまな場所で再利用できます。

下の図は、ログインプロセスをサブプロセスに変換した後のフローチャートです。

フローチャートの構造

フローチャートには、大まかに言って、順次構造、条件構造（選択構造とも呼ばれます）、ループ構造の 4 つの構造があります。基本的に、ほとんどのフローチャートはこれら 3 つの構造で構成されています。

場合

これまで多くの理論的な知識と概念について説明してきましたが、実際のケースを説明することから始めましょう。もともと、電子商取引の商品は、論理的思考力が非常に求められる商品であり、比較的一般的な商品であるため、電子商取引の商品を例として使いたいと考えていました。しかし、後になって、Taobao、 JD.comなどは非常に大きく複雑で、分析するには面倒すぎることがわかりました。そこで、シェアサイクルはとても良い教育事例だと思いました。その製品は非常にシンプルですが、その背後には興味深い論理構造が隠されています。特に、市場におけるMobikeと ofo の異なる製品ソリューションにより、分析はより比較しやすくなります。

シェアサイクルの前身

最も古いシェア自転車を遡ると、おそらく政府が導入したドッキング自転車だろう。導入の目的は、交通渋滞を緩和し、環境汚染を軽減することだけです。しかし、コスト、技術、当時の人口の一般的な質の制限により、自転車を停めるという解決策は非常に不便なものでした。ドッキング自転車を借りる場合は、身分証明書を持って該当のユニットでICカードを申請し、保証金と事前保証金を支払う必要があります。その後は、指定された場所でのみ自転車の貸出と返却が可能です。カードの申し込みが面倒、車の借り返しが不便、残業代がびっくりする、そんな話をせずに、シンプルに業務プロセス図で表すとしたら、どんな感じになるでしょうか？

以下は、ドックに停められた自転車を使用するビジネス プロセス図を示す最もシンプルなビジネス フォームです。

ドッキングバイクのフローチャートを見るだけでは、実は意味がありません。本当の意味は、ドッキングバイクと現在のMobikeやofoとの横並びの比較にあります。2つのシェアバイクのビジネスプロセス図を見てみましょう。

ドッキングバイク、 Mobikeバイク、 ofoバイクのいずれであっても、ビジネスプロセス図に大きな違いがないことは明らかです。では、なぜ何年も前に政府が主導したドッキングバイクはそれほど人気が​​なかったのに、2016年後半に登場したシェアバイクはそれほど人気になったのでしょうか?では、Mobike と ofo というまったく異なる 2 つの自転車の違いは何でしょうか?各ビジネスノードをより深く分析し、その機能を詳しく分析する必要があります。

自転車の使用プロセスはアプリ上だけでなく、一部の操作は実際の自転車上で行われるため、現時点ではページフローチャートだけを使用することはできず、機能フローチャートを直接使用する必要があります。ここでの機能フローチャートは、ページ内の機能に限定されるものではなく、自転車とアプリでのユーザーの操作のあらゆるステップを表現することを目的としています。

まず、ofo の自転車をご覧ください。アプリでデポジットを支払った後、自転車を探す必要があります。現時点では、ofo にはさまざまな自転車のスタイルとさまざまな自転車のロック機構があることがわかりました。しかし、今回のケースは、ofo の第 1 世代の機械式ロックと第 2 世代の疑似スマート ロックに焦点を当てています。

これら 2 種類のロックは、実際には 2 つの異なる製品ソリューションを表しています。まずは最初のタイプである機械式ロックについて説明しましょう。 （いわゆる機械式ロックは、実は私たちが日常よく目にするパスワードボックスに似ています。各パスワードボックスには、あらかじめ設定された固定パスワードがあります。ダイヤルを回して正しいパスワードを入力するとロックを解除できます。また、機械式ロックのパスワードは固定されており、変更されることはありません）。

道路脇で機械ロックされた自転車を見つけたら、アプリを開いてナンバープレートの番号を入力するか、QR コードをスキャンし、アプリから自転車の機械ロックのパスワードを取得し、パスワードを入力して自転車のロックを解除します。この時、アプリ内でカウントダウンが始まり、カウントダウンが終了すると課金が正式に開始されます。最後に、目的地まで乗車した後、自転車をロックし、アプリの乗車終了ボタンをクリックして、この旅行の注文を確定する必要があります。

ofo のプロセスを読んでから、Mobike のプロセスと比較してみましょう。

Mobike の製品ソリューションは、自転車の QR コードをスキャンすると、機械式ロックのように手動で操作する必要なく、Mobike 自転車のロックが自動的に開くというものです。自転車をロックした後、Mobike はアプリで終了をクリックしなくても自動的に旅行を終了します。次回アプリを開いたときに請求が決済されます。

以下の図は、ofo機械式ロック自転車とMobike自転車の使用に関するフローチャートです（APPロゴは、ユーザーのAPP上での操作を表しています）。

Mobike のプロセスには ofo よりも 2 つ少ないノードがあることがはっきりとわかります。これが、ofo の第 1 世代機械式ロックに対する Mobike の優位性です。もちろん、乗り心地など他の面でも第1世代のofoはMobikeより優れています。しかし、この記事は主に製品プロセスに焦点を当てているため、サイクリング体験にはあまり時間を費やしません。

ofo 機械式ロックと Mobike スマートロックのソリューションを見ると、ofo は明らかに劣っています。機械式ロックによって生じる問題は、使用プロセスの複雑さだけでなく、製品の使用における抜け穴も数多くあることです。たとえば、自転車をロックした後、ユーザーは手動でパスワードを変更する必要があります。そうしないと、次の人が無料で乗れるようになります。たとえば、乗車後にユーザーがアプリで「終了」をクリックし忘れた場合、追加料金が発生します。他にもたくさんの質問がありますが、一つ一つ挙げることはしません。

余談ですが、ofo もこれらの問題を理解しています。機械式ロックソリューションは、閉鎖されたキャンパス内でのみ動作する場合には不十分です。しかし、キャンパス外市場に投入されれば、このソリューションは間違いなく会社に多大な損失をもたらすでしょう。では、OFO はなぜ問題を認識しながらも多額の投資を続けるのでしょうか?理由は簡単です。モバイクの拡大のスピードを考えると、当時すぐにキャンパスを離れなければ、キャンパスを離れる機会が永遠になくなるかもしれないからです。

話題に戻りましょう。これまでの議論では、非常に重要なノードである「車を見つける」という点が常に避けられてきました。道端で自転車を偶然見かけることはさておき、地図上で自転車を見つける例を見てみましょう。Ofo の第一世代の機械式ロックには GPS 測位機能はありませんでしたが、なぜ地図上に表示できたのでしょうか。

次に、ofo のロック解除プロセスのフローチャートを描いてみます。

「アプリがQRコードをスキャン/自転車番号を入力する」ノードから控除を開始します。ナンバープレート番号 XXX の自転車に乗りたい場合、パスワードを取得する必要があり、すべての自転車のパスワードは ofo の自転車データベースに保存されている必要があります。 QR コードをスキャンするか、自転車の番号を入力するかに関係なく、本質は、自転車の番号をサーバーに送信し、どの自転車のパスワードが欲しいかを伝えることです。サーバーがこの自転車のパスワードを照会した後、それを APP に送り返すと、この自転車のパスワードを確認できます。

自転車ロックの電力を節約するため、この時点ではサーバーは自転車に接続せず、手動でのパスワード入力によって自転車ロックを開きます。したがって、ofo はユーザーがパスワードを取得した後にカウントダウンを開始します。カウントダウン中はロック解除状態を解除することができ、カウントダウンが終了するとデフォルトでユーザーが乗車を開始したことになり、課金もこの時点から開始されます。

現時点で iPhone ユーザーの場合、ofoAPP を最小化すると、携帯電話の上部にあるバッテリー バーが青色に変わることがわかります。実はこれが、自転車旅行の旅程を取得するための ofo の重要なポイントです。機械式ロックはデータをサーバーに送信できないため、ユーザーの携帯電話に引き継がせる方がよいでしょう。携帯電話の位置情報を取得して自転車走行ルートを取得します。駐車後、乗車終了をクリックして場所を報告すると、サーバーが自転車の駐車位置をマークします。しかし、実際には報告された場所に自転車はなかった。これが、OFO マップに誤ったマークが多数存在する理由です。

ofo が採用しているマーキング方法は実は非常に大雑把です。結局、ユーザーが強制的にアプリを終了させて​​しまうと、サイクリングルートは取得されません。 Ofo は、サイクリングルートが取得できない状況にも対応しています。つまり、出発地から目的地までをマークし、地図で提供されるルートに従って距離を表示します。

上の写真は私が実際にテストしたケースです。赤い矢印が実際のサイクリングルート、緑の線がofo独自のマップ上で出発地と到着地を計算したルートです。

次に、OFOメカニカルロックのプログラムフローチャートを分析し続けます。

上の図のサービス内部の部分に注目してください。手順が非常に少なく、非常にシンプルに見えますが、実際のサーバーでは、より複雑な論理的判断を行っているはずです。しかし、プロダクトマネージャーが描いたフローチャートではプログラミングにおける技術的な詳細を完全に描写することは不可能であり、プロダクトマネージャーが技術スタッフにコードの実装ロジックの考えを手助けする必要もありません。私たちがする必要があるのは、プログラムのマクロ実装ロジックを理解することです。

たとえば、QR コードをスキャンした後、アプリに他の車両のパスワードではなく、この車両のパスワードが表示されるのはなぜですか?とても簡単です。すべての自転車のパスワードはサーバーに保存されている必要があり、QR コードをスキャンするプロセスは、この自転車の ID をサーバーに送信することです。サーバーはデータベースでパスワードを見つけると、それをユーザーに返します。

この処理中に、サーバーはユーザー アカウントが正常であるか、ブロックされているかなど、他の判断を必ず行います。自転車は無効としてマークされていますか?等しかし、これらの論理的判断は上記のフローチャートには描かれていないことに気付くかもしれません。忘れましたか?実はそうではありません。ここで、この記事の核となる概念である「粒度」について触れなければなりません。この図は、プログラム実装のマクロレベルのロジックを表現することを目的としており、読者が問題の核心にもっと集中できるようにします。強調する必要があるのは主要なプロセスだけです。分岐処理や異常処理を増やすと、読者の注目度に影響します。つまり、フローチャートを描くときは、幹から始めて枝を描く必要がある、という古い格言は今でも同じです。最初から盲目的に詳細を追求しないでください。

話を元に戻すと、ofo の第一世代のロック ソリューションは抜け穴だらけでしたが、それでも自転車の位置を地図上に表示する巧妙な方法が採用されていました。 ofo が発売した第 2 世代のロックは、従来の機械式ロックの多くの問題を改善しました。最大の効果は、車のロックのパスワードが固定されなくなり、車をロックした後、旅行を終了するためにクリックする必要がなくなったことです。 ofoのロックは最適化されているのに、なぜ前回の記事では疑似スマートロックと呼ばれているのでしょうか？本物のスマートロックとの違いは何でしょうか？ ofo の自転車ロックは、Mobike のように直接開くのではなく、なぜ手動でのパスワード入力が必要なのでしょうか?地図上では車がよく見えるのに、実際の場所には車がないのはなぜでしょうか?

以下は、80 年代と 90 年代に生まれた人々の子供時代の思い出です。将軍の命令。

「General's Order」（別名NetEase Account Protector）は、Guangzhou NetEase Interactive Entertainment Co., Ltd.が完全な知的財産権を有して独自に開発したハイテクID認証製品です。 NetEase Passアカウント（ゲームアカウント）と直販アカウントのパスワードを保護するために特別に設計された製品です。独自の60秒の動的自動パスワード更新技術により、アカウント盗難のリスクを最小限に抑えます。

「General's Order」の作成は、当時のFantasy Westward Journeyの人気と相まって行われ、その革新的な技術によってアカウント盗難の問題のほとんどが解決されました。それで、将軍の命令の実施メカニズムは何でしょうか?簡単に説明すると、まず「General's Order」を開くと、数字の文字列が生成されます。ゲームにログインするときにこれらの数字を入力すると、システムがアカウントのログインを許可します。同時に、「将軍の命令」の数は 60 秒ごとに動的に変化し、「将軍の命令」の認証コードはログインするたびに異なります。実装の原則は、「将軍の命令」とサーバーが同じアルゴリズムを維持し、計算結果が同時に一貫していることです。

ofo の疑似スマートロックを振り返ってみると、実際には同じ原理で動作します。各車のロックにはサーバー上に保存された個別のアルゴリズムがあり、車のロックは定期的にそのアルゴリズムに従ってパスワードを変更します。アプリを開いて自転車のパスワードを確認すると、サーバーは自転車のロックと同じアルゴリズムを使用して現時点でのパスワードを計算するため、このパスワードは自転車のロックによって計算された現在のパスワードと一致している必要があります。

次の図は、OFOの偽スマートロック自転車のプログラムフローチャートです。

上記の分析から、ofo の第 2 世代ロックでもサーバーと通信せず、自転車にはまだ GPS が搭載されておらず、位置特定にはユーザーの携帯電話に依存していることがわかります。

Mobikeのスマートロック

上記で ofo の機械式ロックと疑似スマートロックを分析した後、Mobike のスマートロックを見てみましょう。何がそんなにスマートなのでしょうか?

まず、実際の経験から、Mobike ではパスワードの入力が不要であることがわかります。 Bluetooth ローカル パスワード検証方法は別として、Mobike ロックは、アプリのスキャン後に自動的に開くためにサーバーと通信する必要があります。

この原則に基づいた、Mobike のプログラムのフローチャートは次のとおりです。

上の図を ofo のプロセスと比較すると、Mobike が採用したソリューションは、自転車をサーバーに接続することであることがわかります。すべての自転車を端末にして、地図全体でリアルタイムに同期します。これにより、優れた自動車使用体験が提供されるだけでなく、ユーザーデータも収集されます。ソリューションの点では、Mobike は ofo よりもはるかに充実しています。

上記は、ofo と Mobike のソリューション全体の比較であり、さまざまな段階のフローチャートも描いています。基本的には、ケースを分析するための私のアイデアの一部を表しています。最も重要なことは、誰もがフローチャートを理解し、日常の製品設計と分析に適用できるようにすることです。フローチャートを作成するときに、業務から手順、単純なものから複雑なものまで、この記事の方法に従うことができれば、思考がより明確かつスムーズになると思います。

要約する

この記事では、定義、分類、描画方法の観点から、階層化されたさまざまなフローチャートの特徴を説明します。その原理とメカニズムを教科書的な方法で説明してみてください。現時点ではフローチャートの統一規格がないため、記事には誤りや誤解が避けられません。皆様がそれらを指摘し、私たちとコミュニケーションを取ってくれることを願っています。

この記事の目的はフローチャートを紹介することですが、その思考プロセス全体こそが私が表現したいことの核心です。複雑なものは、最小単位に分解することができ、その最小単位から複雑なものを徐々に復元することができます。ひいては、この考え方は、実は物事を分析するための思考モデルです。これをマスターすれば、さまざまな分析シナリオに応用することができます。今後、思考モデルについて詳しく紹介する別の記事を書く機会があればと思っています。