サービス

社内SEから見たシステム更改

▶この記事を読んでほしい人
  • 社内SE・情報システム部門で業務を行っている方
  • システム更改のやり方が分からない方
  • ベンダーとしてユーザ側のシステム部門担当者と折衝する方

社内SEの方、システム開発会社の方、こんにちわ

迷えるアラサー鬼人「餓鬼の子」です

皆さんは、システム更改してますか?
それかバージョンアップ対応してますかー?

マリアン

楽しんでますかーー!!、みたいに聞くんじゃないよ!

ごめんなさい、調子に乗りました

皆さんシステムの更改やバージョンアップをする際に、プロジェクトをスムーズに進行できていますか?社内SEでシステム開発を外注してたり、パッケージを使用する場合はシステム開発の上流部分で重要な役割を担うはずです

ですけど、プロジェクトの推進って本当に難しい

社内SEって、システム更改・開発にどう関わっていけばいいか分からない人や、
今、進行しているプロジェクトが本当に順調に進んでいるか分からない人
そんな人に向けて今回は記事を書いていきます

メニュー

今回のスコープ対象

システム更改といっても企業における社内SEや情報システム部門の立ち位置や役割によって様々です

なので今回はコーディングや詳細設計はやらない社内SEや情シスに向けて記事を書かせていただきます

多くの社内SEはコーディングは行わずシステム開発における最上流の工程を行う、またはベンダーのサポートに回ることが多いのではないかと思います

今回はこのような役割の社内SEにスコープを当てさせていただきます

システム開発の流れ

そもそもの話になりますが、この記事を読んでいただいている皆様は以下の図が理解できていますか?

これはウォータフォール型開発のおけるV字モデルというものです

オークマ

ナニコレ?こんなの初めてみた

初めて見ましたか?ならもっと基礎を固める必要があるね

ウォーターフォールでのシステム開発流れ、それぞれの工程の意味・やることはしっかり勉強した方がいいです

開発の工程は「要件定義」「基本設計」「詳細設計」「システム実装」「テスト」という流れが基本です。ウォーターフォールモデルでは、この一つひとつの工程を順番に進めていきます。

出典:ITトレンド

ここがあやふやだと土台がグラグラしてシステム開発の途中で今何をやっているのか、何をやらなければいけないか分からなくなる可能性があります

これさえ読んどけば大丈夫!っっていう書籍は今度紹介します

特に社内SEは要求分析・要件定義・運用テストでプロジェクトを進めるうえで非常に大きな役割を担うことになります

もしかしたらシステム開発を何度も経験した人が社内SEをやっていると基本設計にも一部関わることはがあります
私がそのタイプです(笑)テーブルの構造やGUI(グラフィカルインターフェース)についてベンダー側と頻繁に連絡を取り合って内容を詰めるタイプです

社内SEの役割について

システム更改や導入における社内SEの役割は大きく2つだと思います

1.ベンダーコントロール

2.現場のユーザーの意見を吸い上げシステムの要求とベンダーに伝える

細かいことを作業内容を言えばもっとありますが、大きくは上記の2つ考えてよいのでないでしょうか

オークマ

ベンダーコントロールって、作業内容を全部指示する必要があるってこと?

そこまではしなくていいと思います。ベンダーも素人ではないので

むしろ変な支持出してベンダー側が持っているノウハウまでぶち壊してプロジェクトを混乱させる可能があるので、変なベンダーじゃなければ以下の事を意識するばいいのではないかと

  • 全体のスケジュール管理
  • 上流工程でのベンダー側のプロジェクトのやり方を確認
  • 打ち合わせの調整
  • ベンダーが提出した成果物の検証
  • コストを意識したシステム要件の策定

まぁ、こんな感じだと思います

特にプロジェクトの進捗には常日頃から意識を持っていた方がいいです

少しの遅れで納期がずれてしまうことがあり、余分に費用が掛かってしまうことがあります

他には私の経験上、各工程でのスケジュールが切羽詰まってくると内容が雑になったり、本来現在の工程でやらなければいけないことを次工程で話を進めようとしたりします
こんなことをしていると確実にプロジェクトは破綻します

なのでシステム機能の全体ボリュームを把握して、うまくパワーが分散されるように
スケジュールのコントロールを行っていきましょう

システム開発でやっていけないこと

マリアン

社内SEとしてやらなくちゃいけないことは分かったわ

逆にやっちゃいけないことって何なの??

1つ絶対にやっちゃいけないことを挙げるとするなら

自社の業務にそぐわないシステム構築を行うこと

本当にこれは最悪です

スケジュールの遅延や、予算のオーバーは経営人がOKすればなんとかなるかもしれません

ってか何とかなります(お咎めは受けるかもしれませんが、途中でプロジェクトやめますって聞いたことがありません)

ただし、予算やスケジュールを意識するあまり自社の業務に全くそぐわないシステムを構築するのは最悪だと思います

普通に考えて、大金投入してシステム導入したのに運用にそぐ合わないからシステム使えませんでした、使ったら生産性落ちました、売上落ちました、なんて事態になってしまったら目も当てられません

絶対にシステム更改する際は今まで以上の何かを得られるシステムを構築するようにしてください
たとえそれがシステム機能の関係で予算オーバーになったとしてもです
それを正しく経営層に伝え追加の予算を引っ張ってくるのも社内SEや情シスの役割です

スケジュールの遅延に関しても、遅延が発生しても無理にシステムの機能を落として無理にでもプロジェクトを進めようとすることは止めた方がいいです

システムの導入はそれぞれ目的があってそこに資金が投入されています

業務の大幅改善による原価削減、トレースアビリティの向上、システムのサポート終了に伴うバージョンアップ対応

なんにせよ、システムを入れ替えて業務がダウングレードするようなことはあっていけません

予算を守ることや、スケジュールを厳守することはとても重要だと思うし本来そうであるべきだと思います

ただ、あくまでべき論です
システムの規模が大きいほどトラブルはつきものです
本当に優秀な社内SEはトラブルが発生した時にこそ実力が発揮されるものだと思っています

急がば回れ!!

システムの更改・導入する際に一つ意識してほしいワードがあります

それは、「急がば回れ」

システム開発の工程はそれぞれ意味があって上記に示したような順番で成り立っています

要求分析⇒要件定義⇒基本設計⇒詳細設計⇒・・・

逆に言うと、製造するには、詳細設計が行われていないと正確に製造ができません

詳細設計をするには、基本設計が行われていないと正確に詳細設計ができません

基本設計をするには、要件定義が行われていないと正確に基本設計ができません

要は上流工程といわれる要件分析や要件定義が不確かであやふやな状態で行うと、
間違った設計を行います

「まぁ、なんとなくこんな感じの要件でいいかって」って気持ちで要件を決めたが故、運用テストで業務が回らないことが発覚!!
しかも、そこの部分がシステムの根幹に関わる場所でシステムの修正に大幅な追加工数が必要になったりしたら・・・

それ以上は言いません💦

要は、システムの開発工程にはシステム導入を上手く進めるための手法であるため、その工程でやるべきことは確実にこれでいいって状態になるまで完璧に詰めるようにしましょう

その工程でやるべきことあやふやにすると確実に後でしわ寄せがきます

まとめ

今回書いた記事で言いたかったので社内SEとして、プロジェクトの推進を行っていくうえで各位部門やスケジュールの調整は大切ですが、一番大切なのは各工程でやるべきことは完璧と言えるといえるまで内容を詰めてから次工程へ進みましょうということが言いたかったです

要件定義を行っていると、スケジュールなどの観点から見て間に合わないから次工程ってやるかと妥協しがちになります

だけどそこは先のことを考えて、納期に間に合わせるために各工程でやることは守るようにしましょう

以上、ありがとうございました

餓鬼の子プロジェクトへの問合せは下記からお願いします