プロジェクトを成功させるためにフローと工程を捉えよう
フローとは
新しいプロジェクトに参画するとき、僕はフローというものを非常に気にする。
そして、フローとは「INPUT→PROCESS→OUTPUT」の連続した流れであり、
その1つ1つが工程となる。
- フロー
- 工程のまとまり。工程が時系列で並行になる場合もある。
- 工程
- INPUT→PROCESS→OUTPUT
フローを自分の中で捉えられた時、自分の中でディレクションの不安が払拭される。
これは過去のプロジェクトの経験がそうさせるのだろう。
「フローを適切に捉える事ができるか否か」は
プロジェクトだけなく、事業の成功においても必要なスキルだと思う。
僕がフローをなぜ気にするのか。
これはSIerだった頃に、クライアントの
基幹系サプライチェーンマネジメントシステム(以下SCM)を手がけていた事も
関係していると思う。
SCMとフローの関係
SCMの定義は
企業活動の管理手法の一つ。
取引先との間の受発注、資材の調達から在庫管理、製品の配送まで、
いわば事業活動の川上から川下までをコンピュータを使って
総合的に管理することで余分な在庫などを削減し、
コストを引き下げる効果があるとされる。
このようなシステムをつくるには、クライアントの業務フローに
深く入り込み、各工程の入出力を深く検証する必要がある。
時には、業務フローを変える提案を行う場合もある。
フローを工程に分解する
例えば、家具であれば、
- デザイナーがビジネス要件やユーザーニーズに応じた家具のデザインカンプを起こし、
- 設計士がラフを元に設計図を起こし、
- 工場が製造計画と設計図を元に適切な数を制作し、
- 運送会社が配送計画に基づき適切な店舗へ配送を行い、
- 店舗側で受け入れ、消費者に販売する
といったフローかと思う。
僕はこういうフローを考えるとき、各工程を頭の中で、下記のようにマトリクス化する。
※「デザインカンプ」は完成図のデザインイメージであり、ラフで済ませる場合もある。
| INPUT(入力) | PROCESS(処理)、ツールの整備 | OUTPUT(成果物) | |
|---|---|---|---|
| デザイナー | ビジネス要件、ユーザーニーズ | デザインカンプ作成 | デザインカンプ |
| 設計士 | デザインカンプ | 設計図作成 | 設計図 |
| 工場 | 設計図、製造計画 | 製造 | 家具 |
| 運送会社 | 配送計画 | 家具受け入れ、配送 | 家具 |
| 店舗 | 家具 | 家具受け入れ、店舗への配置 | 家具 |
| 消費者 | 広告、カタログ、店舗での情報 | 購入 | 家具 |
こういう既存のフローでなく、これからつくっていくフローであっても、
工程を分解する考えは必須である。
ツールとして何を採用するか？
そして、工程の分解と並行して、次の工程において、
何を「入力」とすれば意識のずれがなく、進められるのかを考える。
次の工程における「処理」だけでなく、使う「ツール」によっても
その入力は変わるため、「ツール」の分析まで踏まえ、各工程を
どう設計するかを考える。
例えば、デザインに関する工程では、Illlustrator／PhotoShop／InDesign
などのAdobe製品が互換性が高く、広く使われており、採用しやすい。
Fireworks／DreamWeaverに受け渡せばそのままコーディング作業に移ることも可能だ。
マネジメントの工程においても、MicroSoft製品群は重宝される。
なぜかというと、互換性と使っている人が多いという2つのファクターが非常に大きいのである。
ツール群としてどういった互換性があるかというのは、ギャップや手戻りを防ぐ事ができ、
非常に重要である。
フロー／工程の設計はプロジェクトの成否をわける
そういった工程を1つ1つ設計していくのもプロジェクトリーダーの役目である。
ただ、最適化されたフローを考え、工程を設計するのは非常に多くの情報を
必要とし、非常に高度な作業だと言える。
だから、現場経験がない人間は情報が不足し、工程を設計できない事が多い。
現場経験がない場合、徹底的に現場に張り付き、ヒアリングをしまくるのが吉だ。
フローの設計がしっかりしていれば適切な人員の配置、
クリティカルパスの把握、手戻りの防止を実現でき、プロジェクトは順調に進む。
一方、ここで失敗してしまうと、詰めが甘いフローが出来上がり、
プロジェクトは悲しい結末を迎える事も多い。
どうもそのあたりは深く議論されず、「フローをファジーに捉えてしまう」文化が
日本にはあるように思える。
フローをファジーに捉えるメリット、デメリットは別途記載したい。
