システムを導入する際に必要なこと

こんにちは。
システム＆キャリアコンサルタント　よこまくかなこ　です。

さて。
『システム』ということに焦点をあて、
いくつかブログをアップしてきました。

※参考までに。。。
システムって何？
システム開発って何をするの？
システムエンジニアのお仕事
随時改訂・記事追加中です。。。

今回は、「システムを導入する際に必要なこと」ということで。
ユーザーさん側にとって、システム開発時に必要なことなどを挙げていきたいと思います。

私自身がシステム屋として四半世紀超従事してきた中で、
「なんでプロジェクトって毎回炎上するんだろう？」
「なんで同じ失敗を繰り返すんだろう？」
「なんで進歩しないんだろう？」
などなど、疑問に思っていたことを、ふとしたきっかけで「そういうことかぁ」と気付くことが出来、
であるなら、私なりにそれを説明して知ってもらえたら、、、ということで今の活動に至っています。

ＩＴ業界の常識？そんなもん知らんがなっ！！

専門用語はもちろんですが。
それ以外にも認識相違はたくさん転がっています。

例えばこんなことが。。。

「お客さんが仕様を提示してこないから手がつけられれん！」
「仕様がコロコロ変わるから何ともならん！」

これらは、システム開発の現場でよく飛び交う言葉です。

私も”雇われＳＥ”のとき、仕様変更に振り回されまくった１人です(笑)

ユーザーさんからしてみれば、
「この帳票、〇〇っていう項目も出して！」
・・・項目を一つ追加するくらい、どうってことないでしょ？

そう思うのも当然かと思います。
実際、帳票イメージの設計書の修正のみを見れば、四角い枠を一個追加して、見出しを追加するだけですからね。
ところが！
その先の設計の修正ってめちゃくちゃ大変なんです。
・その項目はどの時点のどの処理を通過した項目なの？
・その項目はＤＢに保有しているの？
・その項目はこの帳票項目のどの項目と紐づいてるの？
・新たにＤＢアクセスが必要となった、取得するための処理時間はどうなるの？
・どのＤＢにも保有していなかったら、どこから入力させるの？
・その入力画面の項目追加も必要！
・そうなると、入力処理もすべて項目追加のため画面イメージ・項目設定・ＰＧＭ・入出力ファイルレイアウト
すべて修正！
・外部インターフェイスの項目だと、相手先に項目追加の依頼も必要。追加してもらえるのか？
などなど。。。

散々調査し、対応工数などをお伝えしたところ
「ふーん、じゃあいらないや」
なんて言われちゃうと、、、
「必要じゃなかったんかいっ！！」
と突っ込みたくもなるんですよね^^;

けど、これはあくまでもシステム屋さん側の常識であって、
そんなに面倒なことになるなんて、ユーザーさんからしてみたら「知らんがな！」の一つ。

これ、繰り返されちゃうと、システム屋さんは作業に後ろ向きになってしまいます。
とはいえ、やっぱり、、、「知らんがなっっ！」がユーザーさんの本音ではないかと思います。

そうなる前に！！
必要なものを準備していただけると、スムーズなシステム開発になります。

そのためのコツをお伝えしたいと思います。

立場の違いと視点の違い

ユーザーさんとシステム屋さんの視点は真逆です。
心理学的に言うと、ニーズも真逆です。

ユーザーさん
「何となく、こんな感じで、あとはイイ感じに作ってもらえたら。。。」
「プロなんだから、うまいこと作ってくれるんでしょ。。。」

システム屋さん
「何がしたいのか、もっとちゃんと提示してくれんと作れんがな。。。」
「やりたいことが分からんのに何作ればいいんだ？。。。」

こーんな感じではないでしょうか。

この狭間の感覚が広ければ広いほど、システム開発の炎上レベルが上がります。

本来、システム屋さん側がユーザーさんから要望を聞き出し可視化してあげるのが手っ取り早いのですが、
大規模開発になればなるほど、システム屋さん側の仕事範囲が狭くなる気がします。
ユーザーさんから直接受注した会社さんのレベル、さらに、複数のシステム屋さんが参画しその会社さん同士の大人の事情だったりで、
お互いの活動範囲が必要以上に小さくなりがちです。

この時点で、仕事の目的が「お客様に喜んでいただけるようなシステム作り」から「自分たちの身を守る程度のシステム作り」に
変わりつつあるので、私にとっては苦痛だったんですけどね。。。

逆に中小規模・零細・個人事業さんなどで、大掛かりな独自システム開発は厳しい場合、
既製品（＝パッケージ）を選び導入することになると思います。

この場合も互いの利害関係が丸見えになるので要注意です。
パッケージを売る側も
「うちのパッケージを使えば、御社の業務改善につながり費用以上の効果が得られます！」
など売り込みが始まるわけですが、、、

そもそも
「業務内容も会社の歴史も何も見えてない状態で、”業種”という一括りで業務改善が出来るとは言い切れんだろう？」
というのが私の持論です。

もちろん、改善できる部分も多くあると思います。
そして、自社以外の業務運用を知ることで、よりよい運用を思案するきっかけにもなります。

改善結果が出てくるのは、
『自社の課題が明確になっている』
場合だと考えています。
改善したい部分が把握できていないと、「ただ運用が変わるだけ＝手順覚え直しが面倒」となりかねません。

少なくとも
『自社の全体の流れが見えている』
状態でなければ、効果は得られないと考えます。

何故なら、、、
ユーザーさんは「今までやってきたやり方で成功した！世に通じてきたんだ！」
という自負がありますから。
それをいきなり「改善せよ！」って言われても、
「なんでやねん(－－〆)」
となるのでは？

”自分がYESだと信じていることを、見ず知らずの人にNOと言われると、逆に頑なにYESを通そうとする”
ことないですか？
もちろん「えーじゃあNOで、、」と流されてしまう場合もあるかもしれませんが。
私は「正しさを認めさせる」ことに必死になっていたこともありますので(笑)
これは心理学を学び、相当手放すことが出来ました。これについてはまた別途。。。

「知らない」では済まされない現実

では、判例を見てみましょう。

判例１

事件概要

Ａ医大が、システム会社Ｂに依頼した病院情報管理システムの刷新開発。2017年、プロジェクトが破綻。
開発プロジェクトは、Ａ医大側の膨大な追加要件により作業が思うように進まず、Ｂ社は一度仕様を凍結し、納期も延長。

しかし、Ａ医大側の追加要件は止まらず、開発はさらに遅延。結果、納期どおりに納品できなかったことを理由に、Ａ医大はＢ社に契約解除を通告。
それを受けて、Ｂ社は損害賠償を請求し、裁判となった。

結果

第一審では、プロジェクト破綻についてＢ社に８割の責任があるとされていたが、第二審では逆転。
高等裁判所は、Ａ医大にすべての責任があるとして約14億1,500万円の支払いを命じた。

Ａ医大は判決を不服として最高裁に上告したが、最高裁は上告を受理しないことを決定。
高等裁判所の判決が確定した。

（事件番号：平２３（ワ）９９号 ・ 平２３（ワ）１４８号、文献番号：2016WLJPCA03296018　より）

判例２

事件概要

ITベンダーＡ社が定額制で請け負った、ユーザー企業Ｂの基幹システム保守作業。
工数にかかわらず、毎月300万円が支払われる契約だが、実際には瑕疵対応や開発依頼の未完成を理由に減額され、Ｂ社は赤字状態となっていた。
そこで、工数に応じた請求に契約内容を変更するようＡ社に求めたが、応じてもらえず。

その後、Ｂ社は3ヶ月分の工数に基づく保守費用1,057万円を請求。それでも、Ａ社は前述の契約を盾に446万円しか支払わず、Ｂ社はＡ社を提訴。
保守作業は準委任契約で瑕疵対応や開発依頼の未完成は支払い拒否の理由にならないとして、残金約600万円の支払いを求めた。

結果

Ａ社には、請求した約600万円の半額である300万円が支払われることになった。
地方裁判所は、契約自体は業務内容ではなく稼働時間によって報酬を定めていたことから、準委任契約に近いものと判断。

しかし、運用実態は、本来請負とすべきソフトウェア開発を行なっており、Ａ社の検収を挟むことで実績工数を大幅に下回る工数請求となっていたことから、
当事者間の黙示的な合意により契約内容が請負へ変更されたと判決。

そのため、見積もりで想定されていなかった作業は、追加費用を支払うべきとして、Ｂ社の行なった作業が本当に想定外であったかどうかも加味し、
Ａ社に請求額の半額である300万円の支払いを命じた。

（事件番号：平２１（ワ）２８８６９号、文献番号　2012WLJPCA04258017）

いかがでしょう？

ＩＴ訴訟って、調べてみると結構多かったりします。

せっかくのＩＴ化が訴訟になるなんて、、、と悲しい気持ちになります。

シテム屋に依頼する前にしておくべきこと

概算見積もり、詳細見積もり、、、などご予算相談を受ける際にも必要なことがあります。
それは、『何が必要か？』が明確になっているということ。

少なくとも現行の処理がどれくらいの規模でどんな処理をしているのか、
その上で新システムはどう改善していくのか？

新規システムであれば、業務フローは必須中の必須。

ユーザーさんが何をしたいのか、が明確でないと、
どれくらいの規模のものを作るのかも全く想像できないわけです。

私が”雇われＳＥ”のとき、しょっちゅう見積もりをしていました。
仕様変更の都度、まず見積もりから始めるのですが。。。
とはいっても、現行の処理を把握している上で、その仕様変更を行うことで影響の出るものが何で、
それらをどう直すのか、をすべて洗い上げて見積もります。

大抵、”ピン！”ときた感覚でいくらくらいというのを予想し、
調査結果から導き出すと、、、そんなに差は出ないので、意外に直感がイケてます(笑)
いや、直感と言いつつも、頭の中では勝手に工数をはじき出しているわけでして。

『金額』については、会社さん毎に計算ルールがあるので違いはありますが、
かかる工数としてはほぼ共通です。
とはいえ、ＳＥもＰＧもレベルが様々ですので、平均的なレベルでの工数を心がけます。

そうそう！
とある会社さんで、非常にデキに問題のある子（元請けの社員さんですね）がいたんですが。
その方が担当する場合は、他の人の見積もりの数倍の工数がかかる、、、ということが、
何故かお客様まで承諾していたという、、、ちょっと不思議な現場もありました^^;

話が逸れちゃいました。。。
開発云々の前にしておくべき作業を並べていきます。

自社業務の整理

これは必須です。
「業種で大体一緒でしょ？」
と言われても。

確かにもんのすごーく概要レベルでは一緒でも、
作業手順や、ましてや言葉の定義ですら会社さん・部署さんによってはバラバラです。

例えば、社内異動があったとき、作業を引き継ぐ際エライコッチャになってませんか？
異動に限らず、長期休暇をとってる場合、出張、産休などなど。。。

『人に仕事がついている』

という場合、その人がいなくなると業務がｓｔｏｐするというパターン。
引き継ぎしたけど、結局引き継ぎ切れていなかった、、、というのは他人事ではないはず。

部門毎に
・何をしているのか
・いつそれをするのか
・何故それをしているのか
・INとOUTは何か？
などなど、

『仕事に人がついている』状態であれば、自然に上記の内容が周知徹底されていたりします。

さて、皆さんの職場はいかがでしょうか？

これがあると便利、、、いや『必須』と言わせてください！『業務フロー』

業務フローとは

業務を図解したもの

です。

業務プロセスを図として可視化することで、当事者も第三者も皆が「こんなことしてるんだ～」が理解しやすくなるものです。

「業務」：「何らかの価値を生み出す仕事」で、すなわち「各組織が実施する個々の仕事」
　　　　　目的もなく実施する作業ではなく、「だれかに何かを売るための作業」や「だれかに何かを届ける作業」といえます。

「プロセス」：「手順や過程」です。 「手順」とは「物事を実行する順序」を表し、「過程」とは「物事が変化・進行していく順序」を表します。

その二つを合体した「業務プロセス」とは『何らかの価値を生み出す仕事』を実行する『順序』となります。

私は、大きく２つのフローを必要と感じています。

・全体業務フロー：その企業さん全体の作業の流れが分かるもの（超大企業さんだと、ちょーっと作成するのが大変ですけどね）

・部分フロー：各部門毎の作業の流れが分かるもの

いきなり細かい内容が始まっても「ナンノコッチャ」です。
見出しの変わりでもある全体フローはやっぱり必要だと思います。

《業務フロー　見本》

※こういうの書いてるとき、めちゃくちゃ楽しい私です(^-^;

現業務内容の洗い出し

ユーザーさん側でハマってしまう罠があります。
それは、、、

①「そんなん誰でも知ってるでしょ」

っていうヤツです。

自分の毎日の作業は「正しくて、理解されている」と思いこんでいるということ。
意外にそれって非常識だったりします。

思ってる以上に、周りの人から見ると「え？何それ？」「それは違うってば！」ということも多いです。
マニュアルがきちんと整備されていない職場であればあるほど、今一度自身の業務が何をどうやっているのかを明確にする必要があります。

そしてもう一つ。

②「この作業は変える必要がない」

「変える」認識がないから出てこないわけでして。
そもそも「変える」ということすら選択肢になかったりします。

「えーだって、、、これやってあれやってからそれをこうする、、、って聞いてるし」
と言われたままの手順でただただ素直に作業していては気付かないことです。

私はいつも
「あーこれメンドーだな、もっと効率よく出来んかな、、あ、ここマクロで、、、ねーこういうマクロ作って～」
となります。
（マクロは自分でもある程度は作れますが、、、”雇われＳＥ”の時は、周りにマクロマニアさんたちがたくさんいらっしゃったので、しょっちゅう作ってもらっていました。他の作業が山のようにありましたからね）

工夫・改善するという意識って、普段から持っていないと急に言われても覚醒しません。

どんなワガママ意見でも、「こうしてほしい」「ああしてほしい」という要望はとっても大事です。
それが実現するか否かは技術的な問題だったり、ご予算、期間の関係もありますが、
要望が見えなければ何も変えることは出来ません。

マニュアル、あります？　それって陳腐化していないですか？

ちなみに。
・やたらマニュアルがあるけど、どれも中途半端で組み合わせないと使えない。どれを組み合わせるのかも不明。
・最初に作ったっきり。そのマニュアルに載っていることは古すぎて話にならない。
・なし。社内業務は口伝。もしくは一子相伝。
って会社さんが多かったなぁ～というのが振り返って思うことです。

システム化（システムって何？参照）してもＩＴ化するかは別問題。
しかし、マニュアル化は必要です。

『誰がやっても同じ成果』のシステム化を現実化するために、
その手順書は会社の運営に不可欠なものなのです。

要望の整理

現場作業をしている方たちに、現作業に対しての要望が挙がってきたとき、
これも文章だけではなく、図解して可視化するとより想いが通じ合います。
もちろん、文章だけでもよいのですが、私は図解をおすすめします。
・・・文章って、、、文字がいっぱい並んでると、読むの面倒くさくなりません？？？私だけ？

この文章を図にしていく段階で、業務＋要望が論理的に整理することが出来ます。

現行フローと現場の声を紐づける

どの業務でどんな声が挙がっているのか？
これをきちんと整理しないと、グーッチャグチャな仕組みとなってしまいます。

また、費用対効果が得られない仕組みとなりかねません。

とはいえ、挙がってきた声をそのまま形にすると、
逆に不合理的なことが発生したりします。

どうしてもＩＴ化が無理であれば、手運用でカバーするなどの代替案が欠かせません。
それら一つ一つが現場の想いと出来るだけ近づくようにしていく、
しかし、複雑な仕組みを作ってしまうと変更が出来なくなったり、融通効かない不便な仕組みになったりと加減が難しいところでもあります。

整理していく中で、新しい業務フローがだんだんはっきりと見えてきます。

業務の種別、単位を切り分ける

とかく、問題・課題を一緒くたにしがちです。

場合によっては、システムは論理的に解決をしていくものですが、
感情が先走ってしまうことも。。。

ひとまず、業務を部門や作業単位にわけて考えるのもテです。
全体が集まって、それぞれが別部門の話を聞いていると、
「いや、うちの方が作業が大変なんだから、こっちの要望を優先してもらわないと困る」
「そんな作業は手でやればいいじゃん」
などとお互いが『自分の方が大変』をアピールするために話がまとまらなくなることもあります。
※大手さんでも結構な頻度で見られる状況でした。中小さんでも、もしかしたら、、、と思ってしまいます。

そんな時は部門ごとや、作業単位で細かく区切って考えるとフロー化がサクサク進むことも。

また、システム屋からみて見積もりがしやすい＝予算と見比べやすいという利点が。
まとめて「ドンっ！」と要件が出てると、見積もりのときも切り分けが手間だったり、
実は切り分けられないものを切り分けてしまったり（業務知りませんもん）。

やはり、現場の人ではなければ分からないことばかりです。
現場の方が理解しやすい業務整理・フロー作成は必須ですね。

繰り返し行われる「行為」は何？

部門に分けてみたものの、、、
「あれもこれも要望が出てきてまとまらないっ！」
というとき。

考えやすいものとしては、

・（判断を不要として）繰り返し行われることは何？

ということです。

いきなりＡＩ化が出来ちゃうなら、お任せ範囲も増えるんでしょうけど、
ＡＩ化の判断も何をさせるかを検討する必要があります。

そんな時にターゲットとなるのが
「単純に繰り返されること」
です。

例えば『受注』処理。
受注データが飛んできたら、
・データを受け取り、
・在庫を確認し、
・発注者の情報を確認し、
・発送し、
・在庫データを更新し、
・請求書を発送し、
・入金確認を行い、
・領収証を発行する
という流れは、単純な繰り返し作業です。

誰が、どの商品を頼んでも、やることはすべて同じ。
（確認する商品が違う、発送先が違うなどは、「流れ」は同じで「値（変数）」が違うだけです）

このすべてをいきなりＩＴ化するのか、
それとも途中で確認作業が必要であれば、どこからどこまでをＩＴ化するのか、
などを考えるとよいでしょう。

人じゃなきゃ出来ないこと、機械に任せられること

機械に振り回されないことが大切です。
ＩＴ化したことによって、手作業が増え手間が増えた。。。となっては、ねぇ。
場合によっては、人手は増えるかもしれません。（入力追加、ボタン押下など）

しかし、トータル的に作業手間が減り、生産性が向上しなければＩＴ化の意味はありません。

予算や開発期間を考えて、どうしても機械化するところ、人手でまかなえるところを整理しておく必要があります。

まとめ

システム作りって、、、大変です。

けど、大変となる理由を理解して、何をすべきかを知っているだけでもかなり違います。
「何も知らずにシステム作り」は危険極まりなく。。。

さらに言及すると、ベンダー（システム屋）側がどこまでユーザーさん側に寄り添い対応してくれるかは分かりません。
場合によっては「要件が出せないなら作れない。提示してきた仕様が悪い」と一方的にユーザーさんの責任とする場合もあります。
いや、最近はこういったベンダー側の方が目につきます。

ユーザーさん側はベンダー側の言うなりになる必要はありません。
不明点を納得出来るまで確認し承諾する必要があります。
そして、すべての要件が取り込むことが出来なかったとしても、
何をどこまでＩＴ化出来るのか、どこが手作業かをベンダー側と話合いながら決めていく必要があります。

『対等』な関係

でシステム化を進めていきましょう！！

・・・とは言っても・・・
「日常業務が忙しくて、システム化・ＩＴ化に手が回らない」
という会社さんが多いのではないでしょうか？

特に中小さんですと、限られた人数で必死に企業運営をされているのでは？と感じています。

「業務フロー？そんなん無理無理！！」
という会社さんはいらっしゃいませんか？

四半世紀超の業務系システムエンジニア経験の私が、
業務整理・業務フロー作成・マニュアル整備などを
ユーザーさん側へお手伝いさせていただきます。

まずはお気軽にお問い合わせくださいませ。
下記問い合わせフォームからお願い致します。

～～～お問い合わせ～～～