鈴村さんが指南する業務フロー図の上手な書き方
まずは，業務フローの例を見てみよう。UMLのアクティビティ図で書いたのが（図1）である。スイムレーンに役割を書き，上から下（または左から右）に向かって業務の進行を書いていく。かどの丸い四角形で示したアクティビティが業務プロセスに対応し，矢印で示したフローが業務の流れになる。「誰が何をするか」が明確になる。 よほど定型化されたものでない限り，業務とは複雑なものである。厳密に書こうとすると，業務フローも複雑になりがちである。しかし，分かりやすさを重視するなら，一つの業務フローに登場するアクティビティはせいぜい10～15程度にとどめるべきだ。 複雑なフローを表現したければ，一部の業務フローを別に切り出して，サブ業務フローとして記述すればよい。親の業務フローのある業務プロセスの内部が，サブ業務フローとなっているというように階層化する。 スイムレーンには顧客や営業担当など役割を設定する。「松山さん」
顧客との関係を傷付けないトラブル報告書を書くには
エンジニアの皆さんは、業務でさまざまな報告書を作成されていることと思います。エンジニアの業務で必要になる報告書は、大きく2種類に分けられます。 1つ目は、書式が決まっていて、定期的に作成する報告書です。定期報告書と呼ぶこともあります。進ちょく報告書や日報、週報、月報などが例として挙げられます。 もう1つは、不定期に発生するイベントについて記述する報告書です。この種の報告書は、書式が決まっていないものです。例としてはトラブル報告書（または障害報告書、問題対応報告書など）や、製品・技術などの調査報告書といったものが挙げられます。 これら2種類のうち、トラブルの種になりやすいのは、後者の「イベントについて記述する報告書」です。今回は、報告書の中でも特に細心の注意を払わなければならない、顧客向けのトラブル報告書（障害報告書、問題対応報告書）を作成するときに注意すべきポイントを説明します。 報告書を
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
