• クリティカルチェーン TOCによるプロジェクト・マネジメント
ロシア講演(アルハンゲリスク)
ロシア講演(アルハンゲリスク)

はじめに

私は、情報システム部門で大小のシステム開発に従事してきました。

1台のパソコン上だけで稼働するEXCEL、マクロからイーターネットブラウザ上で稼働するWEBシステム、メインフレーム上で稼働するオンラインシステムまで、さまざまな開発に取り組んできました。利用するユーザー数も数人から1000人を超えることもありました。さらに扱うデータ量も、数100から100万件以上とこちらもさまざまでした。

開発し運用したシステムは、当たり前の事としてさまざまな評価を受け、その成否が問われるものです。私のシステム開発経験の中には、自信を持って開発したのに散々な評価を受けたシステムもあれば、さほど苦労も無く短時間で開発したのに高い評価を受けたシステムもあります。

「評価方法にはどんなものがあるのか?」また「なぜ評価には、大きな差が出てしまうのか?」をテーマに「評価で思うこと」を紹介します。

システム評価で起こる事

一般的にシステム開発は、開発提案内容をチェックし費用対効果などが吟味され実施承認を得た上で開発に着手するなどの手順を踏みます、さらに大規模システムでは開発の様々な段階でデザインレビューを行うなど中間チェックを行います。

システム開発は、行う価値があると認められ、さまざまな審査・評価をクリアし実施され、試行・平行運用などを経て実運用となるものです。

しかし、これらの手順を経ていても良い評価を受けるシステムもあれば悪い評価のシステムもあり、評価はさまざまなのは皆さんもご承知の通りだと思います。

では、『なぜこのような差が出る』のでしょうか?

私が開発に関係した2つのシステムを通して紹介致します。

なお、本エッセーでは完成し運用後のシステム評価を中心に伝えていきます。開発段階のレビューなどは重要なテーマではありますが、また別の機会に紹介させて頂きます。

2システムの概要

Aシステム
システム名:目で見る緊急連絡

ビジネスオーナー(開発依頼部門) 総務部
主な利用対象者 20名(聴覚障害者)+ 2000名以上(構内全従業員)
開発費 100万円以下
開発体制 総務、情報システム部門から数名
開発期間 1ヶ月未満

Bシステム
システム名:構成表システムの高度化(製造日程自動作成、流用設計、など等)

ビジネスオーナー(開発依頼部門) 生産管理部
主な対象者 1000名以上(設計者、製造部、生産管理部)
開発費 1000万円以上
開発体制 設計部課長、設計、生産管理、製造、情報システム部門から選抜された10数名のプロジェクトチーム
開発期間 1年

Aシステム機能概要
マイクロソフト社のシェアーポイント(現Office365)を使いWeb上に緊急連絡内容を公開、公開された情報をあらかじめ登録された対象者に自動通知する仕組み。

構内放送は、従来より構内の全従業員への通知や緊急連絡する内容を発信部門が総務部に申し込み総務部がチェックし即時放送していました。

Aシステムでは、発信部門がWeb上で投稿し総務部へ申請します、問題がなければ承認され従来通りの構内放送を行うと同時に投稿文がWeb上で公開されます。この時にあらかじめ登録している聴覚障害者の方へ緊急連絡情報を伝えるメールが自動配信されます。(メール本文中のURLリンクでWeb上の文書が閲覧できます)

なお過去の放送内容も一定期間ホームページ上で全従業員が閲覧できるよう保存されます。

Bシステム機能概
製品の製造に必須の構成表を管理するシステムに利用者からの改善要望の多い機能をオプションとして追加し設計者の効率向上に寄与する仕組み。

具体的には、利用者である設計者、製造、工程管理者などからの要望をヒアリング、アンケートなどを使い意見収集を行い多くの要望があり、かつ投資対効果の高い機能を対象に採用し実装させたものです。

例えば 過去に製造した構成表を新しく同種製品のために簡単に流用できる機能、過去製品作りで実施した日程・工程情報を新しく製造する同種製品用に流用する機能、製造日程管理システムと構成表システムを相互連動させ日程や進捗精度向上を図る機能、設計補助機能(アラーム機能:使用する部品が製造中止・廃止品であれば設計変更する様に通知する)などを構築しました。

効果測定として従来比で数100時間/月以上の作業時間を削減させ製造工程システムとの連動で待ち時間削減などの多くのムダ時間削減対応も大きな効果を生み出します。また、補助機能が製造時製造中止・廃止部品が及ぼす影響のミニマム化により後戻り作業の削減にも貢献します。

システムを評価する視点とは?

システムを評価するにはさまざま考え方や方法があります、よく採用されているのが

1.使う側の立場 =ビジネスオーナー(システム開発の依頼部門)
2.作る側の立場 =システムオーナー(システム開発の担当部門)

の二つの視点です。
実は前述のA、B双方のシステムともに、これらの視点では及第点とされ、十分な成果・効果があったとされるレベルでした。

しかし、三つ目の視点

3.使う側エンドユーザーの立場 =システムを実務で使うエンドユーザー(対象ユーザー)

では、一つは高い評価を受け、もう一つは低い評価を受けるという大きく異なる結果となりました。

この結果は、作る側の立場であった私にとっては予想外のものとなりました。なぜ、そのような差異が起こったのでしょうか?

次回の評価で思うこと(その2)で、評価方法の三つの視点をA・Bシステムを題材にもう少し踏み込んで説明することにします。

2020.5.04 冨永宏志