業務改善でシステム開発や導入をする意味を車に例えて解説する【SIerとコンサル】

      2018/09/24

「会社で業務改革のプロジェクト担当になった」
「システム導入ってどんなことをするのかわからない」

この記事は、そんな方へ向けて書いています。

こんにちは、TEN(@02smwhere)です。

僕は前職で業務コンサルタントとして、クライアントのシステム導入プロジェクトに関わることが多くありました。

そこで今回は、企業における業務改善やシステム導入のプロジェクトが、どんな方針で進んでいくのか、具体的な方法を交えてご紹介します。

本記事のまとめ
  • システム導入プロジェクトにおける流れがわかる
  • コンサルタントがフェーズ分けをしてプロジェクトを実施する意味がわかる

スポンサーリンク

企業の業務改善には業務系システム導入が不可欠

StockSnap C2N64OP21L

はじめに、会社が業務改革を行うためには、なぜシステムが重要なのか考えてみましょう。

会社とは、たくさんの部署や人物が、業務や処理を連携し、利益を生み出している組織です。

そして業務改善の仕事とは、そういった業務同士のつながりやかかる時間、役割分担などを整理し、より効率的に運営ができるように作り直すことを指します。

さらに現代社会において、業務にはパソコンやアプリケーションなど、システムやITの力を借りることが不可欠です。

そのため、IT部門は企業内において、コンサルタントはクライアントに対して、業務改善を行なうサポートを行う必要があります。

 
これこそが、最近のコンサルティングファームにおいてSI(システムインテグレーション)と呼ばれる、システム導入プロジェクトなどが増えている背景になります。

 
合わせて読みたい>>>> IT業界のビジネスを知るなら、アジャイル型とウォーターフォール型の開発手法の違いを知るべき
 

業務改善におけるシステム開発導入プロジェクトの流れとは

OOK82 gurafuwoyubisasu20131223 TP V

さて、具体的にシステム導入はどのような流れで進んでいくのでしょうか。

 
はじめに、計画段階として、企業や組織にどんな課題があるのか?を検討していきます。

システム導入の目的がなければ、そもそもプロジェクトとしてスタートすることはありません。

クライアントが解決したい課題があり、それを解決するために業務をどう変える必要があり、どのようなシステムが必要になるのか、構想を考えていきます。

現場やクライアントが望んでいないシステムを導入してしまうのは、誰のためにもなりません。

 
また、現行業務を見えるようにするために、コンサルタントがクライアントへヒアリングする機会を設けたり、業務フロー図を作成することがあります。

業務フロー図とは、各業務のインプットとなる文書やソース元、業務が発生するトリガー、出されるアウトプットなどを、目に見える形に書き起こしたものです。

業務フロー図を見ることで、現場の担当者やIT部門、コンサルタントが、現行業務を確認しやすくなります。

 
Account achievement bank 870902

業務改革プロジェクトでは、現行業務を分析した上で、どんなシステムが役立つのか、具体的に検討していきます。

分析を経て設計段階になると、新しい業務の詳細フロー、システムの技術的な仕様書、プロジェクトの見積や人員構成などが作成されます。

その後、実際にシステムを構築する作業に入り、システムのテストで現物を確認した後、現場へ展開・定着させ、運用・保守のサポートを通じて、プロジェクトは終わりを迎えます。

 

スポンサーリンク

車の開発に当てはめてシステム導入のフローを解説する

さて、ここまでシステム開発について述べてきましたが、やはり分かりづらい!というのが、正直な感想だと思います。

システムという定義や実態が掴みにくいので、実際のプロジェクトのイメージがつきにくいのも否めません。

 
そこで僕が新卒で働いていた自動車会社の開発業務に当てはめて、システム開発を考えてみようと思います。

こちらのほうが、現物を作っているぶん、わかりやすいでしょう。

 
システム開発は、全体としては前述のような流れで進められていきます。
 
ですが、実際の多くのプロジェクトでは、区切りの良い各フェーズに割り切って、チーム構成や予算などを組み換えつつ実施されることがほとんどです。

各フェーズの説明については別記事にまとめましたので、こちらも合わせてご覧ください。

合わせて読みたい>>>> Vモデルによるシステム開発のフェーズを自動車に例えて説明する
 

スクリーンショット 2017 11 05 12 32 38

採用する最新技術と車両のコンセプト、開発のスケジュールや予算を決める

さて、まず計画段階では、全体のスケジューリングを決めていきます。

現行モデルの車両のスペック、お客様から届く不満をまとめて改善点とします。

現状の販売状況や、新しく開発されて利用できる先進技術はないかなど、検討を重ねていきます。

 
例えば、電気自動車の航続距離が短いのがユーザからの不満点として挙がっているならば、新しく開発されたバッテリーを用いて、航続距離を1.5倍まで伸ばそう!

など、プロジェクトを実施する目的を定義していきます。

計画段階による成果物としては、計画書見積書などが作成され、経営陣にプロジェクトを実施する許可をもらいます。

 

各パーツまで細かく動作を落とし込む分析を行う

続く分析では、より詳細に流れや機能の洗い出しを行っていきます。

例えば、電力がバッテリーから取り出され、モーターに入力された後に、動力としてクランクシャフトを回し、タイヤが回転するまでのエネルギーの流れを考える必要があるでしょう。

さらにバッテリーに限っても、各セル、端子、車両に纏われるハーネス(電力線のようなもの)など、様々なつながりやインプットとアウトプットがあります。

これらが動作し、エネルギーや電力のやりとりが行われるケースを特定していきます。

これらを落とし込んだ成果物としては、要件定義書や見積書になります。

 

図面やプログラムのコードへ実物化する

続くフェーズは、設計フェーズです。

機械的な仕様、機能、プログラム単位まで細分化して決定していきます。

バッテリーの大きさや容量、ケーブルの長さや太さ、動作させるコンピュータなどですね。

 
成果物は機能・技術設計書、あるいは物理・論理計算モデルなどです。

ここで決めた設計に従ってプロジェクトを構築、すなわち実際に生産をしたり、プログラミングしたりします。

 

出来たものを試験しながら組み立てる

完成物は部品単位でのテストプログラム単位でのテスト使用ケースごとの結合テストの3つがあります。

各部品だけでなく、それらを組み合わせてきちんと動作するか、テストが分かれているのです。

 
電気自動車ならば、きちんと決められた電圧が発生しているか、航続距離を満たすだけの放電時間が持つか、電力は安定しているか、確認していきます。

 
ここで生まれる成果物としては、プログラムのソースコードやテストの結果報告書などが挙げられます。

 
さらに、その後により大きな括りのプロセスや業務単位でテストするプロダクトテストと、実際にクライアントに実施してもらうユーザテストが、続くテスト項目として控えています。

実際に車が完成した後に、テストコースでテストドライバーが運転して確かめたり、試乗会に一般の人を招いて、運転して感想を聞いたりするイメージです。

 

ディーラーに販売してもらい、お客様の手に届く

その後はシステムの本番稼働や引継が行われ、展開・定着をもってプロジェクトが終了します。

 
完成車をディーラーに持っていって販売したり、販売員に説明したり、説明書を作成するのが、このプロセスに入ります。

実際に現場まで足を運び、販売するための手順を整えていきます。

お客様と話したり、購入してもらうのは、現場の従業員となるので、丁寧な説明が不可欠ですね。
 

システム導入の各フェーズが積み重なって業務改善に繋がる

スクリーンショット 2017 11 05 12 32 38

本記事では、企業が業務改革においてシステム導入を行う意味を、自動車開発に例えて解説いたしました。

ここまで見てきたように、システム導入のプロジェクトは様々なフェーズを経て実行されていきます。

 
コンサルタント各個人でも、各フェーズに得意分野を持っていることが多いです。

プログラミングやシステムに詳しい人、最新技術に詳しい人、テストの効率的な回し方を知っている人など…

一つのプロジェクトでも、フェーズが移るたびに、人がよく入れ替わります。

ですがどんなフェーズにおいても、成果物があることにより、複数の人を介したチェックや伝達、あるいは経営陣やクライアントとの合意を行なうことができるのです。

 
そのため、特に最近のコンサルティングファームで行なうような上流から下流に至るまでのプロジェクトにおいては、あるルールを決めて標準化し、品質を一定にすることが大切です。

上記のVモデルについては、一番下流のテスト結果は、一番上流で決めたものを満たしているかのテスト結果となっています。

どのプロジェクトにおいても、全てのフェーズの人がいないことには、業務改善は成り立たないのです。

 
したがって、どのフェーズにおいても最終的に成し遂げたい業務改善の目的を忘れないこと。
 
上流フェーズの人は下流に迷惑をかけないように、きっちり要件やスコープ、実現性のある予算やスケジュールを決めておくこと。

下流フェーズの人は上流で既にヒアリングした内容や決定事項をきちんと把握し、責任感をもってプロジェクトに取り組むことが、非常に大切です。

 
しかしながら、本音を言ってしまうならば、上流の人のほうが給料が良かったり、下流の人を見下したり、逆に下流の人が上流の仕事をしたくて転職することもあります。

僕の経験から言えることは、下流工程を抜け出せないSEの方は、早めの転職をおすすめします。

詳しくは、以下の記事をご参照ください。

 
合わせて読みたい>>>> 将来有望なIT業界でもSIerに未来はない理由とは
 

 - データ分析