今回は，仕事のインプット・アウトプットと，改善に欠かせない組織風土改革，コミュニケーションの場づくりについてお話します。

“仕事の流れ（業務プロセス）⁠”と“⁠組織の業務範囲⁠”は一致する場合と，一致しない場合がある話を第11回でお話ししました。GHテクノロジーズにおいては，佐藤さんの所属する開発部の後工程となる製造部と，不一致があるようです。さらに，開発部と製造部の間では，さほど仲もよくないセクショナリズムがありそうです。佐藤さんとよく話をしていた製造部の上司や先輩たちの多くは，GHテクノロジーズの経営再建計画の一環である早期退職で既に会社を去ってしまっています。

価値連鎖と業務連鎖

開発部と知的財産部のコアメンバーであれこれと作戦会議を練っています。何か突破口を見出したいところです。今日は，佐藤さんの大学の先輩にあたるマーケティング部の坂本課長も参加しています。

• 赤西さん：「僕ら開発部が製造部と仲たがいしていても，意味ないっすよね」

• 佐藤さん：「そりゃそうだけど，僕のことを毛嫌いしているあの部長だよ。気が進まないなぁ」

• 加藤さん：「後輩の赤西君にはっきりと言われちゃ，佐藤，お前も立場ないよな。少なくとも，村瀬開発部長の先日のお話だと，製造部長は不良品発生の解決には協力してくれるみたいだし…」

• 村瀬部長：「自分から製造部長に話は通すから，まずはどうやって改善を前に進めていく作戦が良いか，考えることが先決だ」

• 佐藤さん：「ですね……」

• 坂本課長：「マーケ（マーケティング）の仕事柄というわけじゃないけど，“⁠バリュー・チェーン（価値連鎖⁠）⁠”⁠ で社内の各部門の活動を見てみるといいかもしれないよ」

• W女史：「確かに，バリュー・チェーンは業務の流れを考えるときに，ちょうどいいわね」

• 佐藤さん・加藤さん・赤西さん・広瀬さん：「バリュー・チェーン？？」

この図は，マイケル・ポーター（M.E.Porter）の「バリュー・チェーン（価値連鎖⁠）⁠」と呼ばれる有名な図です。

「バリュー・チェーン」は，「⁠主活動」と「支援活動」に分類されます。「⁠主活動」は“⁠購買物流⁠”⁠ “⁠出荷物流⁠”⁠ “⁠マーケティング・販売⁠”⁠ “⁠サービス⁠”からなり，「⁠支援活動」は“⁠企業インフラ⁠”⁠ “⁠人材資源管理⁠”⁠ “⁠技術開発⁠”⁠ “⁠調達⁠”から構成されます。

バリュー・チェーンという言葉が示すとおり，購買した原材料等に対して各プロセスで価値（バリュー）を付加していくことが企業の主活動です。また，各プロセスはお互いに連鎖する関係にあります。企業はこのバリュー・チェーンの活動をつうじて，市場や顧客に製品やサービスを提供し，マージン（利益）が生まれます。

さて，これを簡単な企業組織図の例で考えてみましょう。

仕事は，自部門の前工程や後工程の部門と常にやり取りをしながら進みます。同時に，全ての部門と関連する本社や管理部門，情報システム部門とのやり取りも発生します。仕事は前工程から後工程への一連の流れである「共同作業」で成り立っていると言えます。しかし，担当する部門は“⁠縦割り⁠”です。したがって，業務の流れは組織・部門の壁をまたがって流れていることになり，この流れを「業務連鎖」と呼びます。

一通り，坂本課長からの説明を聞き終えて……。

• 佐藤さん・加藤さん・赤西さん・広瀬さん：「組織図と対比させるとわかりやすいですね」

• 坂本課長：「そう，“⁠チェーン⁠”という名の通り，本来，業務は連続的につながっていなければならないんだ。しかし，各部門にはそれぞれ役割があり，その構造は縦割りだ。縦割りがあまりにも強すぎると，組織に何が起きるかは予測できるだろう？」

• 佐藤さん：「セクショナリズムってことですね。まさしく，今の当社だ」

• W女史：「セクショナリズムのために，コミュニケーションが阻害され，協力関係を築くことが困難になってしまいますよね」

• S氏：「幸か不幸か，ちょうどいいタイミングで価値や業務の連鎖の話が出てきたので，仕事のインプットやアウトプットについて考えてみましょう」

仕事のインプットとアウトプット

• 赤西さん：「そう言えば，ISO9001でも“⁠設計のインプット⁠”とか聞いたことがあります」

• 佐藤さん：「うん，僕ら開発部の設計のインプットは仕様書だし，マーケやお客様からの要求がインプットになる時もある。また，アウトプットは回路図などの図面やPDM(Product Data Management)やBOM(Bills of Materials)に包括されるときも最近は多いけどね」

• S氏：「開発や設計部門ではそうなりますよね。ここで，先の価値連鎖・業務連鎖を1つ1つのプロセスにバラシて考えてみましょう」

図2をご覧ください。

業務プロセスは，“⁠子⁠”のプロセス，“⁠孫のプロセス⁠”のように，細かくバラシていく（細分化）ことができます。では，どこまでバラすかですが，これは目的によります。業務改善を目的とする場合は，可能な限り細かいレベルまで細分化が必要です。

業務プロセスを模式的に表したものを「プロセスモジュール」と呼びます。

先ほど登場した，「⁠仕事のインプット」「⁠仕事のアウトプット」に相当する“⁠②入力・出力⁠”以外に，“⁠③前提条件⁠”⁠ “⁠④開始条件⁠”⁠ “⁠⑤タイミング⁠”⁠ “⁠⑥処理⁠”などの情報が，1つ1つの業務プロセスの構成要素となります。なお，プロセスモジュールの考え方の基本は，筆者自身がデジタル回路設計やASIC設計を行っていた時の，シンボルやマクロ，ライブラリの概念が原点となっています。より詳しく知りたい方は，こちら『上流モデリングによる業務改善手法入門（技術評論社）』をご覧ください。

• 村瀬部長：「これはまた，内部統制やISOで見られる業務フローチャートの書き方とは少し異なりますね」

• S氏：「おっしゃるとおりです。ここまで細かい情報は，通常の業務フローでは書かれていません。業務改善で用いる業務フローは，業務プロセスをこのレベルまで細分化しないと，小さなミスや，人による業務の差異（属人的なやり方）が見えてきません」

• 赤西さん：「フローチャートに近くて，開発の人間はとっつきやすいですね」

• W女史：「そうですね♪ しかし，間接部門や事務業務を行っている人からすれば，難しく感じる人もいるんですよ」