製品設計を行う際には多くの業務プロセスが発生しますが、比較的複雑な開発プロセスを説明する必要がある場合には、明確なフローチャートが非常に重要です。
製品設計を行う場合、単純なものもあれば複雑なものもあり、単一ジョブのものや複数ジョブのものなど、多くのビジネス プロセスに遭遇することになります。どんなに詳細な記述であっても、それは明確なフローチャートよりもはるかに役に立ちません。
ビジネス プロセスがフローチャートで表現するには複雑すぎると思われる場合、おそらくそれを言葉で表現することはできません。
リベラルアーツのバックグラウンドを持つプロダクトマネージャーの中には、グラフィックスよりもテキストに敏感な人もいます。そのため、非常に詳細なテキストを使用してプロセスの詳細を説明できますが、フローチャートを描くように頼んだ場合、誰もそれを見ることができません。もしあなたがそのような人であれば、この記事があなたのお役に立てれば幸いです。
1. フローチャートを理解する
フローチャートを描画するときにそれらを正しく使用できるように、フローチャートを描画する前に、フローチャート上のさまざまなグラフィックが何を表しているのかを理解しておく必要があります。
一般に、[楕円]はプロセスの開始ノードまたは終了ノードを示し、[長方形]はプロセスの通常ノードを示し、[菱形]はプロセスの判定ノードを示し、ノードは[矢印]でつながっています。描画するときは、認識度を高めるために、さまざまなグラフィックに異なる色を追加することを検討できます。
このような規則により、フローチャートの作成者と読者が合意に達することが容易になり、また、作成されたフローチャートがより読みやすくなります。
2. 単一ジョブのフローチャート
これは最も単純な形式のフローチャートであり、システムまたは特定のシステム機能モジュールの流れにすぎず、ユーザーのアクションまたは機能モジュールの動作ロジックのみを記述します。
たとえば、最も単純なユーザーのログイン操作のフローチャートを描くことができます:
上の図は、ユーザーが業務を完了するプロセスをユーザー操作の観点から説明したものであり、このようなフローチャートは [業務フローチャート] と呼ばれます。
ログイン認証のフローチャートを描いてみましょう:
上図は機能の処理ロジックをシステムの観点から記述したもので、このようなフローチャートを「システムフローチャート」または「機能フローチャート」と呼びます。
携帯電話番号を入力する操作を個別に検証フローチャートを作成することもできます。
上記の簡単なフローチャートを通じて、適格なフローチャートをどのように描画すべきかをまとめてみましょう。
1. 適切なグラフィックを使用して対応するノードを表現します。ノードのテキストは、実行するアクションを簡潔かつ明確に説明します。必要に応じてメモを追加できます。例えば、上の図で認証用携帯電話番号の上3桁の判定ですが、条件が多く最初の3桁を全て書き出すとフローチャートが肥大化してしまいます。簡単な例 ここでどのような判断をするかを開発者に知らせるために、例を使用したり、メモを追加したりするだけですが、詳細な判断ルールについては、要件文書に詳細に記録する必要があります。
2. 同一の判定ノードについては、判定結果を 3 以内に制御し、2 が最良となるようにする 判定条件が多い場合は、できるだけ多くの判定ノードに分割し、各ノードで処理する判定条件は 1 つだけとする。判定条件に 2 つの結果がある場合、2 つの判定条件を合わせると 4 つを超える結果が得られる場合があります。
3. 線の交差や重なりをできるだけ少なくします。
4. 同じ機能を持つプロセスノードを可能な限りマージします。これによりフローチャートがより簡潔になりますが、2 つのノードに異なる機能がある場合は、同じまたは類似したノードのコピーを使用しないように注意してください。
5. 主流は上から下に描かれ、支流は左から右に伸びます。人々の読書の習慣は上から下、左から右です。
6. プロセスが複雑すぎる場合は、独立したサブプロセスをフローチャートとして描くことができます。例えば、上記の例では、ログインのメイン処理と、ログイン時の携帯電話番号入力認証のサブ処理を2つのフローチャートに分けて描いたほうが開発しやすく理解しやすいです。処理ロジックが多すぎて、メイン処理とサブ処理が混在しているため、この絵を見ると複雑すぎてわかりにくいと感じてしまうでしょう。
上記の結論に基づいて、極端な否定的な例を見てみましょう。
上記の例から、このフローチャートには次の問題があることがわかります。
1. すべてのノードが間違ったグラフを使用します。
2. 判定ノードは複数の条件判定を同時に実行するため、判定結果が多すぎて処理が混乱します。
3. プロセスラインが重なり、読み取りに影響を与えます。
4. 11桁の数字が別の判定条件であるかどうかについては、エラープロンプトの結果を出力するだけでよく、プロンプトが多すぎると処理が冗長になります。
5. プロセスが「左も右も」で、読んでいて迷いやすい。
3. マルチジョブのフローチャート
マルチジョブ フローチャートはさらに複雑で、複数の役割や複数のシステムが関与する場合があり、さらに複数の役割と複数のシステムが同時に関与する場合もあります。以下で 1 つずつ説明します。
その前に、新しいグラフ [スイム レーン グラフ] を知る必要があります。
名前が示すように、スイムレーン図には複数のスイムレーンがあり、各スイムレーンはロールまたはシステムを表すことができるため、異なるスイムレーン内の複数のロールまたは複数のシステム間のコラボレーション プロセスを表現できます。
多役割コラボレーションの例として、OA オフィス システムにおける休暇申請の主なプロセスは、従業員の休暇申請→上司の承認→人事部長の承認→部長の承認であるとします。休暇申請はすべての承認が完了して初めて有効となり、いずれかの承認者が拒否した場合、次の承認者にプロセスは送信されません。次のフローチャートを描画してみましょう。
垂直の各スイム レーンはロールを表し、承認順序に従って左から右に配置され、対応するスイム レーンに各ロールのプロセスを描画します。
複数のシステムの流れも同様に描かれていますが、複数の役割、複数のシステムが同時に存在するとどうなるでしょうか。
上記の例でも、勤怠は別個のアプレットであると想定しています。従業員は勤怠アプレットを通じて休暇を申請し、承認者は OA システムを通じて承認します。この場合、マルチシステムおよびマルチロールのコラボレーションが必要になります。上で描いたのは垂直方向のスイム レーン図ですが、現時点では、複数のシステムを表すために水平方向のスイム レーン図を導入するだけで済みます。
1. プロセスの最適化
フローチャートが良いかどうかは、それが明確かつ簡単に描かれているか、美しく簡潔に描かれているかだけでなく、それが表現するロジックが合理的かつ最適であるかどうかによって決まります。
上の図は、ほとんどのプラットフォームで登録するときに入力する必要があるフィールドを示しています。まず、上の図の登録条件に従って、登録プロセスで携帯電話番号が登録されているかどうかを確認するためのフローチャートを描きます。このフローチャートの描き方は問題なく、
論理的にも成り立つのですが、それは合理的でしょうか、あるいは最適でしょうか？それを分析してみましょう。
ユーザーが最終的にメインプロセスに従って正常に登録できた場合、このプロセスは問題ありませんが、ユーザーの携帯電話番号がすでに登録されている場合、ユーザーにとって、この時点でユーザーはすでに多くの情報を入力しているため、プラットフォームにとって、認証コードを送信するための SMS 料金は避けられる出費です。
ユーザーが携帯電話番号を入力すると、システムはまずその携帯電話番号が登録されているかどうかをチェックし、登録されている場合には、ユーザーに次のことを即座に通知することができます。 、引き続き登録情報を入力します
。認証コードを送信するときに、携帯電話番号が登録されている場合、この時点でユーザーに認証コードを送信しても意味がありません。そのため、認証コードを送信するときに、携帯電話番号が再登録されているかどうかを確認します。この
プロセスを通じて、最適化によりコストの削減と効率の向上という目的を達成できます。
コスト削減：コストを削減します。最適化されたプロセスにより、ユーザーは携帯電話番号が登録されたことがわかると入力を継続することがなくなり、ユーザーがその後の情報を入力する時間コストが削減され、認証コードを送信せずに携帯電話番号が登録されます。 、SMS料金を削減し、プラットフォームコストの経済性を削減します。
相乗効果: 効率が向上します。プロセスの最適化により、ユーザーが携帯電話番号を入力した後、その携帯電話番号がすでに登録されている場合は、事前に継続する必要のない登録プロセスを中断してすぐにログインに切り替えることができ、全体の操作時間が短縮されます。業務効率の向上を実現します。
プロセスが長すぎる場合は、プロセスを計画するときにプロセスから飛び出すノードに注意する必要があります。
たとえば、上記の登録フローチャートでは、以下のように携帯電話番号が 11 桁ではないことが判明した後も下に進み、すべての判定条件が実行された後、すべてのエラー メッセージをユーザーに一度に報告できます。この方法は
ユーザーにとって有害です エクスペリエンスは比較的良好です。すべてのエラーを認識して一度に修正できますが、システム プロセスが非常に長くなり、各ステップで多くの判断が必要となり、時間がかかる場合があります。これは、以下のように、ユーザーの携帯電話番号が11桁でなくなったと判断した場合には、判断を行わず、直接エラーメッセージを報告するように、事前に中断して処理を抜け出す別の方法を使用します。 : 最適化を行うと、プロセスはシンプルになりますが、その分
考慮するプロセスシナリオが増えるため、描かれるフローチャートがより複雑になることを意味しており、プロセスの最適化はプロダクトマネージャーの腕が問われる作業と言えます。
上記の出席プロセスを最適化する方法を見てみましょう。
これを注意深く分析すると、出席プロセスには他のシナリオも含まれていることがわかります。
シナリオ 1: 休暇申請を提出した人は部門長であり、システム内に直属の上司は存在しません。このシナリオでは、個人が上位のスーパーバイザである場合、提出後、上位のスーパーバイザはデフォルトで承認され、承認のために人事マネージャーに直接送信されます。 2 番目のシナリオ: 人事マネージャーの直属の上司が部長であると仮定します
。 , 人事 上司から休暇を申請された場合、どのような手続きが必要ですか？実際、このシナリオのプロセスは変わっていませんが、休暇を申請する人がたまたま承認者であり、同時に上司が直接の承認者であり最終承認者でもあるという特殊な状況があります。この場合でも、プロセスに従います。同じ承認者に到達すると、デフォルトの承認を通過できます。
実際にはどの工程も欠けているわけではありませんが、役割が重複しているため、2 つの役割で 4 つの役割のプロセスが完了します。プロセスが簡略化され、自動的に承認が通過するようになりましたが、システム設計時には、自動的に通過した承認ノードもシステムに記録する必要があります。
最後に、製品設計を行う際にはフローチャートを乱用しないこと、ロジックが思い浮かんだらすぐにフローチャートを描かないこと、ロジックによっては非常に単純で 1 ～ 2 文で説明できるものもありますので、フローチャートを描く必要はありません フローチャートを見る やりすぎると疲れやすいです。