リーダーへのステップ

高畠社員が、某自動車メーカーであるH社の大プロジェクトへの参加が決ったのは、2001年の春でした。
入社して9年が経過し、既にサブリーダーレベルに成長していた高畠社員は、このプロジェクトの立上げメンバーとして、 中心的役割を任されたのです。

PROFILE

高畠 TAKABATAKE
松本事業本部 ソリューションシステム部
平成４年入社

自動車メーカーの原価情報システム

当時、H社では、経営戦略のひとつとして、経理部門のシステム化、特に製品製造に関する原価などの情報の精度を上げ、より細分化し、いろいろな角度からデータを検証するツール（システム）を導入したいと考えていました。私が参加することになった原価情報システムとは、実は、製造メーカーにとって非常に先進的なシステムだったのです。折しも、自動車業界は再編の時代に突入し、弱体企業は軒並み欧米企業の傘下に入っていった頃でしたから、H社としても、このシステムの導入は急務とされていました。自然、導入の計画段階から納期の要求は厳しいものとなっていました。

100ページの要件、そして奥多摩合宿

H社の原価情報システムは、全体としては非常に大きなシステムであり、既存システムの改修部分と新規システムの部分とに大まかに分かれていましたが、そのうちAIDは、新規システムである以下の業務処理を担当しました。

システム化計画（要件定義：システム導入により何がしたいのかをまとめる）は、ユーザーサイドで固められていましたので、我々システム会社は、システム分析からの参加となりました。システム分析（要件分析とも呼ばれます）とは、要件計画としてまとめられたことを“システムとしてどうやって実現していくか”を分析する工程です。ユーザーサイドでまとめられた要件計画書は100ページにものぼっていましたので、まずは、それを理解・把握しなければなりませんでした。

当初は、夜間や土／日を利用してユーザーとの間で要件説明会が行われたり、ユーザーに個別にヒアリングしたりしていましたが、工程がおしせまった最後は、2日間の合宿を行って要件説明を受けることになりました。多摩の山奥の登山客が泊まるような旅館に、当社社員（私を含めて3名）の他、同業のシステム会社の担当者やユーザー担当者など総勢30人程が参加しての合宿です。通常のプロジェクトではめったにないことでしたね。旅館だから仕方ないのですが、説明を受ける会場が足の低いテーブルに座布団・・・そこにずーっと座って説明を受けていたため、足腰がとても痛かったこと、山奥のせいかとても寒かったことを覚えています。

でも、夜は飲み会、腕相撲大会（これで顔を覚えてもらった）、風呂（温泉だったかは不明？）・・・と楽しい思い出にもなりました。

道なきところに道を作る

システム分析が終わって、今度は外部設計、内部設計と工程は進んでいきましたが、これらの工程でも、ほぼ毎日ユーザーにヒアリングを行いながらの作業となりました。

また、自分が設計を担当した業務は、他業務に比べ1ヶ月程度先行開発していたため、プロトタイプ的要素もあり、実績がないところに対して“道”を作るような状態だったため、苦戦しっぱなしだったことを良く覚えています。

と、ここまで順調ならまだ良いのですが、そもそもこのプロジェクトは着手した時点から各工程のスケジュールが短かったため、その後の製造（プログラミング・テスト）工程でも常にハードな状態をしいられたのです。 時間がない分は、製造に携わる人数を予定より増やして対応していくことにしたのですが、このメンバー集めも簡単ではありません。社内で進行しているどのプロジェクトも、人員的にはぎりぎりのところで動いていますから、そう簡単には社員をまわしてくれません。上司の部長と相談しながら、他部門のマネージャークラスとの人員要請の交渉を進めました。こういった交渉、調整もサブリーダーになると必要なスキルになってくるのです。そう言う意味では、社内・社外を問わずSEにはコミュニケーション能力が欠かせないなと実感させられます。

当社の技術系社員は、年次の若い社員が主にプログラマとしてこの製造工程に携わりますが、今回のようなハードなスケジュールの場合は、私を含め経験のあるSEもプログラミングに協力をします。予定を守るために、ピーク時には協力会社のプログラマも含め総勢約40人体制で昼、夜の区別なく働きました。あの時はさすがにきつかったですね。

担当業務の完成度を上げるために

このプロジェクトにおいて最大の課題は、私がこのプロジェクトのサブリーダーを任されたことそのものだったかもしれません。原価計算（経理業務）の知識が少ない私が、こんな大きなプロジェクトのサブリーダーを任された（経験させていただいた）のですから・・・。着手当初は、ユーザーの言葉を理解できず、経理業務の書籍を買って読んだり、有識者に教えていただいたりして、何とか着いていくことが出来たくらいでした。

しかし、ユーザーの業務を覚えてからは、ユーザーの言った事のみを具体化するのではなく、それ以外の部分に潜む問題を洗い出すように努力しました。そういった取組みが先の作業を進める上でのひとつのポイントとなりましたし、自分の担当した業務の完成度を上げるためにはとても重要でしたから。

ＧＯＡＬ…その先にあるもの

いろいろな苦労もありましたが、最終的には無事本番稼動をむかえる事が出来ました。

私は常々、「システムを運用していただいた結果ユーザーに満足していただくことが、自分の仕事のGOALであり、たどり着かなくてはいけないところだ」と考えているのですが、このプロジェクトではそういう意味でもほぼ“GOAL”できたと満足しています。

そして、こんな経験ができたからこそ今の自分が存在するのであり、チャンスを与えてくださった会社や上司には本当に感謝しています。