「部門ごとにファイル名が違う」はあり得ない！ 必要なのは業務の“共通言語化”だ：“異端児エンジニア”が仕掛けた社内改革、執念の180日（14）（4/4 ページ）

[世古雅人，EE Times Japan]

「業務範囲」に対する認識も違う？

　メンバー同士のやり取りを機に、話のバトンは杉谷から若菜へと渡った。

　「図4をご覧ください」と若菜は続ける。

図4：業務範囲の認識と属人性（クリックで拡大）

　「同じ部門で同じ仕事をしている3人（斎藤さん、田中さん、和田さん）であっても、仕事の範囲が異なる場合があります。簡単な例として、見積、発注、手配などを挙げましょう。

　斎藤さんは、A業務、B業務ともに（規定や業務分掌によって）定められた通りの範囲の仕事をしています。しかし、田中さんが行うA業務は、本来のA業務よりも少し範囲が狭くなっています。いっぽうで、和田さんは後工程のB業務の頭までがA業務であると思い込んでいる。さらにはB業務の範囲は、A業務同様にC業務（B業務の次工程）の前半までと思っているんですよね。

　このような違いを見つけるためには、業務の棚卸しで作成した棚卸表を突き合わせてみます。多くの場合、業務名称が個々人で明白になります。斎藤さんは、正しく業務範囲を理解しています。田中さんは、作成する成果物を業務名称にしています。和田さんは、後工程の頭までを業務範囲だと解釈しているため、一つの業務に二つの業務名称が入ってしまっています。加えて、業務の区切りがおかしいため、本来C業務となる「手配業務」がB業務の名称になっています。同じB業務でも斎藤さん（発注業務）と和田さん（手配業務）の業務名称を見る限り、同じ仕事をしているようには見えません。

　ここで言いたいのは、（1）言葉の定義をきちんとすること、（2）個々人による解釈の違いを知ることです。例えば、田中さんのA業務『見積書作成業務』は、見積書を作成して終わりなのか？　和田さんのA業務においては、見積業務と発注業務は内容が異なるので、別々にした方が分かりやすくないか？　などです。業務の棚卸しを進めていく過程で共有し、議論を重ね、言葉の定義を決め、業務の解釈を統一していくことが重要になります」

神崎：「例えが分かりやすいですね。庶務課は私を入れて3人が同じ仕事をしていますけど、みんな解釈が違うためか、仕事の範囲も違っています。私たちの仕事は開発の後工程になります。人によってちゃんとやってくれる人と、そうでない人がいるので、後者に当たった場合はすごく面倒なこともあります」

大森：「面倒なのって誰？　すごく気になる。まさか自分じゃないよね？」

　須藤たちはプロジェクトのメンバーと連携を取りながら、この業務の棚卸しを全部門に一斉に仕掛けた。各部門には少なからず抵抗勢力がいることは分かっているが、今は、「見える化」の第一歩を踏み出すことで、具体的な成果を出すことに集中すべきだ。その結果、味方が増えて、会社を変える原動力へとつながっていく――。須藤はそう信じている。

⇒「“異端児エンジニア”が仕掛けた社内改革、執念の180日」バックナンバー

Profile

世古雅人（せこ まさひと）

工学部電子通信工学科を卒業後、1987年に電子計測器メーカーに入社、光通信用電子計測器のハードウェア設計開発に従事する。1988年より2年間、通商産業省（現 経済産業省）管轄の研究機関にて光デバイスの基礎研究に携わり、延べ13年を開発設計と研究開発の現場で過ごす。その後、組織・業務コンサルティング会社や上場企業の経営企画業務や、開発・技術部門の“現場上がり”の経験や知識を生かしたコンサルティング業務に従事。

2009年5月に株式会社カレンコンサルティングを設立。現場の自主性を重視した「プロセス共有型」のコンサルティングスタイルを提唱。2012年からEE Times Japanにて『いまどきエンジニアの育て方』『”AI”はどこへ行った？』『勝ち抜くための組織づくりと製品アーキテクチャ』などのコラムを連載。書籍に、『上流モデリングによる業務改善手法入門（技術評論社）』、コラム記事をまとめた『いまどきエンジニアの育て方（C&R研究所）』がある。