教育系パッケージソフトの導入後、管理人セイジが参画したのは大規模SAP導入プロジェクトでした。
※教育系パッケージソフトの導入については以下で詳しく解説しています。
数値的なところで言うと、総額数百億円レベルです。
その頃社内で動いていたプロジェクトの中ではダントツ1位で、本部の命運をかけたような企画でした。
参加人数もコンサルSEだけで100人、中・下流工程になってくるとさらに多くの人が増えましたので、プロジェクトに何らかの形で関わった、という見方をしてみますと、把握できないレベルの人数になりそうです。
結論から言うと、私は途中でドロップアウトするのですが、多少なりこの仕事に関われたことが自身の中でとても大きな経験になっています。
新卒2年目が持ち合わせるはずのない要求スキル
必要な能力は、
スキルセット
・SAP（Systemanalyse und Programmentwicklung）
※ALV・Dynpro・バッチインプットなどのアドオン経験必須
業務知識
見積、受注手配、売掛、会計、予算業績
工程経験
全て（要件定義～ユーザテスト）
と2年目の新米が持っているはずのない相当な要件でした。
なぜこのプロジェクトに召還されたのか未だに意味が分からないのですが、常時悪戦苦闘しながらも必死で頑張り得たものは今でも十分に活かされています。
SAPの要件定義
大規模SAP導入プロジェクトの要件定義編です。
私は勘定系を担当していましたが、業務知識が全くなかったため、リーダーの人について勉強しながら仕事をしていました。
ちなみに、リーダーは協力会社の方です。
控えめであまり派手さのないポーカーフェイスの方だったのですが、ひじょうに管理能力に長けており、自分より年上の人などをうまく取り纏めておられました。
私はリーダーというものは、人をグイグイ引っ張っていくタイプが適しているのかな、と考えていましたが、さりげない配慮を効かしてメンバーをうまくサポートしながらプロジェクトを進めるタイプも良いなぁ、とこの時感じました。
さて、要件定義フェイズに入った直後から少しずつプロジェクトや現行業務の説明を受けました。ちなみに、リーダーさんはこの作業をキャッチアップと呼んでいました。
プロジェクトの進め方
説明は週に何度か行われ、1回あたりの時間は30分程。パワーポイントの1枚物を用いて業務の概要や単語の意味を説明して頂きました。
メンバーの様子を見ながら適切なタイミングで必要な知識を補填する。各メンバーもそれをうまく理解し、早速仕事を進めていく。
経験豊富な方が多かったせいもありますが、皆さん本当に適応能力が高く、スマートに仕事をされていました。
このプロジェクトには、SE経験10年～20年といったベテランばかりが揃っていたので、当然と言えば当然かもしれませんが…
ちなみに、コンサルSEの大体の方は、SD・FI・CO・MM・などのモジュールのコンサルタント資格を持っておられました。
反対に、他の方がこれだけ能力が高いと、素人の私と言えど「知りません、分かりません」とはとても言えたものではありません。
簿記の「ぼ」の字も知らなかったので、家に帰った後は簿記の本を読み進め、業務内容が複雑で良く分からないものは、関係する設計書を引っ張りだしてきて、理解するように努めました。
このように、私のこのプロジェクトでの最初のタスクは「勉強」でした。
業務フローの分析
大規模SAP導入プロジェクトの要件定義編、その②です。
新プロジェクトは最初に行ったことは、現行業務の再確認でした。
今回のプロジェクトは、既に動いている基幹システムの5年ぶりのリプレースだったのですが、前回の構築時に作成された業務フローを解読するところから作業が始まりました。
解読作業は、以前の業務フローを今回PMが指定したフォーマットに移し直すというものです。その後、その書類を持ってユーザを訪問し、業務の変更点がないかなどをヒアリングします。
5年もたっていると、別の業務ができているので（例えば、ある機能を使って帳票を印刷した後に、それを用いて新たな報告書を作るなど）現状とどこが変わっているかを把握します。
さらに、新たな要望がないかを抽出しておき、新システムの売りとできそうなポイントを考えます。
例えば、今回のプロジェクトの場合は、ある報告書の作成にひじょうに時間がかかっていることが分かりました。
その作業は手作業で多くの計算をした上で作成されるのですが、それを自動化できれば…、ということをユーザから聞き、新システムで自動化することで業務効率の向上を図ることとなりました。
また、機能を増やすことばかりではなく、減らしたり、パッケージの標準機能に落とし込むことも重要な課題です。ある業務がなくなっていたり、頻度が低くなっている場合は、既存システムの機能を廃止・軽量化することを提案します。
利用頻度が低くとも、ユーザは保険をかけたがるので大体の場合は存続を希望されます。
そこをうまく調整したり、パッケージの標準機能を用いてアドオンプログラムをなくすことがSEの腕の見せ所です。
要件定義のポイント纏め
纏めますと、以下のようなことが要件定義での醍醐味です。
- 現在の業務内容を的確にヒアリング
- 新たな要件を抽出
- 不要な機能を削減
この工程は、交渉力や提案力が鍵になります。
当然、経験や知識がないとこれらのことができず、ユーザの言う事をホイホイ聞いて開発予算が膨らみ、プロジェクトが頓挫、もしくは構築後の保守・運用工程で悩むこととなります。
即ち、要件定義をいかにしてうまくこなすかに、後工程の運命が左右されると言えます。そして、この工程をバシッとこなせるSEはかなり希少です（本工程を担当するSEの単価が高い理由でもありますね）。
続いては、要件定義の内容を掘り下げ、細かな作業の進め方や成果物について説明します。
要件の掘り下げ
大規模SAP導入プロジェクトの要件定義編、その③です。
業務フローを作成した後の作業内容をより細かく書いてみます。
業務フローを作成し、新しい業務や変更点を抽出した後は、さらに掘り下げを行います。
- 新しく発覚した業務の内容把握
- 必要事項・疑問点の抽出
- ヒアリングによる要件のより一層の具体化
- 必要な画面や項目が見える程度に落とし込む
新しく発生した業務はどのようなものか、必要な数値や要望を具体的にヒアリングします。
ユーザと話すうちに、業務の細かな内容やニーズを引き出すことができます。後者については、ユーザ自身も漠然としたイメージしか持っていないことが多いため、話の中で提案を行い新システムでのセールスポイントをユーザと共に作っていく必要があります。
ユーザとの話の内容は、常時パワーポイントやEXCEL等にまとめ、内容を整理していきます。
疑問点が出てきたら、次回のヒアリング時に確認するなどし、ユーザが求めているものをより具体的に落とし込んでいきます。
最終的に、必要な画面や項目レベルまで落とし込みを行います。
ここまでできれば、次の基本設計の姿が見えてくるので、工程を次の段階に移すことができます。
反対に、ここが曖昧な感じで終わると、次の基本設計で新たな要件が発覚したりして、要件定義書を修正しなければならなくなります。
そういう意味で、要件定義をしっかり行うことが肝となりますが、時間をかけすぎると後工程が全て影響を受けることとなります。
本工程で適切な工数でうまく要件を抽出し、基本設計へとつなげることがSEの腕の見せ所です。
要件定義の纏め
纏めますと、主に以下のような手順を進めることになります。
- 新たな要件をより具体化する
- ヒアリングを繰り返す
- 必要な画面や項目のイメージを固める
続いては、ユーザが望む機能的な部分とは別に要件定義で行っておくべき事柄を述べます。
SAPプロジェクトの基本設計
大規模SAP導入プロジェクトは基本設計フェイズに入りました。
ここでは、業務フロー図の中で定義した機能を画面帳票などの具体的なレベルに落とし込みます。
まずは、MicrosoftのEXCELを用いて以下の要領で資料を作っていきます。
- 機能の概要説明を記述
- ざっくりとした画面イメージを作成
- 画面に表示する項目を決める
- 項目の取得先テーブルを記述する
※既存のテーブルに項目がない場合はテーブル定義を新規に作成
どこから入力するかも含めて検討が必要
以上の作業を各人が行います。
チームでの設計の進め方
仕掛中の資料は共有フォルダに置き、設計メンバー間で資料を見られるようにしておきます。
身の設計を進めていきます。
疑問点があればすぐに質問し、お互いの設計を調整していきます。
また、チーム間では定期的にレビューを行い、機能間の整合性が取れるように努めます。
コミュニケーションが苦手な人は、こういったことができず一人で設計を進めてしまい、周りの機能と全く連携できない状態になってしまい、後で皆の仕様を変更させる原因を生み出してしまいます。とは言え、聞きまくると相手も怒ってしまいますので、邪魔をしない程度に調整しつつうまく進めていくのが良いでしょう。
私の場合は、圧倒的に業務知識が不足しており、かなりの頻度でチームメンバーに質問してしまい煙たがれていました。
あまりに理解できていない自分を情けなく思い、途中で自己嫌悪に陥ったりもしました。
とは言え、作業が遅れてプロジェクトに支障が出る方がもっと恐ろしい事態ですので、何を言われようがめげずに疑問点はぶつけていきました（その分、自分でもかなり勉強しました）。
作業が進んでいくと、基本設計書やテーブル定義書が徐々にできあがってきますので、完成度の高いものから
ユーザに内容を確認してもらいます。ここで、仕様の誤りや、要件とのズレ、表示する項目の過不足などを指摘してもらい、設計書を修正
します。想定していない要件や項目を要求されることもありますが、そこは実現可能性と残工数との兼ね合いを考慮し、ユーザと調整して下さい。
SAPを使う場合は、凝った機能を付けようとするとプログラム規模が一気に増えてしまいますので、できるだけALVの利用にて済むよう、話を進めていきましょう。私がいたプロジェクトでもDynproは禁止で、全てALVにて実装していました。
私は途中で退職：その後プロジェクトはどうなったのか？
別の記事でも書きますが、私は基本設計が終わった時点で帰郷の思いが募り大阪の家電メーカーに転職してしまいました。
このプロジェクトは最終的に予算大幅超過によりほとんどの機能実装が凍結になり終了しました。
結合テスト時には信じられない次元で大炎上し、全員が「もうダメだ」と思いつつも最後まで何とかやりきったそうです。
私の退職は、周りの人から見ると「嫌になって逃げた」ように写っていたと思います。
言い訳臭いですが、私は辛すぎるながらもこのプロジェクトは最後までやり遂げたいと思っており、途中で抜けてしまったことを今でも後悔しています。
人生で二度と携わることができない貴重なSAP大規模プロジェクトであり、次に機会が巡って来た際には逃げずに最後までやり遂げたいと考えています。
コメント