今回は、「システムを導入する際に必要なこと」ということで。ユーザーさん側にとって、システム開発時に必要なことなどを挙げていきたいと思います。「なんで進歩しないんだろう?」などなど、疑問に思っていたことを、ふとしたきっかけで「そういうことかぁ」と気付くことが出来、であるなら、私なりにそれを説明して知ってもらえたら、、、ということで今の活動に至っています。まとめIT業界の常識?そんなもん知らんがなっ!!専門用語はもちろんですが。それ以外にも認識相違はたくさん転がっています。「仕様がコロコロ変わるから何ともならん!」これらは、システム開発の現場でよく飛び交う言葉です。・・・項目を一つ追加するくらい、どうってことないでしょ?そう思うのも当然かと思います。実際、帳票イメージの設計書の修正のみを見れば、四角い枠を一個追加して、見出しを追加するだけですからね。ところが!その先の設計の修正ってめちゃくちゃ大変なんです。・その項目はどの時点のどの処理を通過した項目なの?・その項目はDBに保有しているの?・その項目はこの帳票項目のどの項目と紐づいてるの?・新たにDBアクセスが必要となった、取得するための処理時間はどうなるの?・どのDBにも保有していなかったら、どこから入力させるの?・その入力画面の項目追加も必要!・そうなると、入力処理もすべて項目追加のため画面イメージ・項目設定・PGM・入出力ファイルレイアウトすべて修正!・外部インターフェイスの項目だと、相手先に項目追加の依頼も必要。追加してもらえるのか?などなど。「必要じゃなかったんかいっ!!」と突っ込みたくもなるんですよね^^;けど、これはあくまでもシステム屋さん側の常識であって、そんなに面倒なことになるなんて、ユーザーさんからしてみたら「知らんがな!」の一つ。これ、繰り返されちゃうと、システム屋さんは作業に後ろ向きになってしまいます。いえ、やっぱり、、、「知らんがなっっ!」がユーザーさんの本音ではないかと思います。なる前に!!必要なものを準備していただけると、スムーズなシステム開発になります。そのためのコツをお伝えしたいと思います。立場の違いと視点の違いユーザーさんとシステム屋さんの視点は真逆です。心理学的に言うと、ニーズも真逆です。ユーザーさん「何となく、こんな感じで、あとはイイ感じに作ってもらえたら。「プロなんだから、うまいこと作ってくれるんでしょ。」システム屋さん「何がしたいのか、もっとちゃんと提示してくれんと作れんがな。「やりたいことが分からんのに何作ればいいんだ?。」こーんな感じではないでしょうか。この狭間の感覚が広ければ広いほど、システム開発の炎上レベルが上がります。大規模開発になればなるほど、システム屋さん側の仕事範囲が狭くなる気がします。ユーザーさんから直接受注した会社さんのレベル、さらに、複数のシステム屋さんが参画しその会社さん同士の大人の事情だったりで、お互いの活動範囲が必要以上に小さくなりがちです。この時点で、仕事の目的が「お客様に喜んでいただけるようなシステム作り」から「自分たちの身を守る程度のシステム作り」に変わりつつあるので、私にとっては苦痛だったんですけどね。既製品(=パッケージ)を選び導入することになると思います。この場合も互いの利害関係が丸見えになるので要注意です。パッケージを売る側も「うちのパッケージを使えば、御社の業務改善につながり費用以上の効果が得られます!」など売り込みが始まるわけですが、、、そもそも「業務内容も会社の歴史も何も見えてない状態で、”業種”という一括りで業務改善が出来るとは言い切れんだろう?」というのが私の持論です。改善できる部分も多くあると思います。自社以外の業務運用を知ることで、よりよい運用を思案するきっかけにもなります。場合だと考えています。改善したい部分が把握できていないと、「ただ運用が変わるだけ=手順覚え直しが面倒」となりかねません。状態でなければ、効果は得られないと考えます。ユーザーさんは「今までやってきたやり方で成功した!世に通じてきたんだ!」という自負がありますから。「なんでやねん(--〆)」となるのでは?”自分がYESだと信じていることを、見ず知らずの人にNOと言われると、逆に頑なにYESを通そうとする”ことないですか?もちろん「えーじゃあNOで、、」と流されてしまう場合もあるかもしれませんが。私は「正しさを認めさせる」ことに必死になっていたこともありますので(笑)これは心理学を学び、相当手放すことが出来ました。これについてはまた別途。「知らない」では済まされない現実では、判例を見てみましょう。判例1事件概要A医大が、システム会社Bに依頼した病院情報管理システムの刷新開発。2017年、プロジェクトが破綻。開発プロジェクトは、A医大側の膨大な追加要件により作業が思うように進まず、B社は一度仕様を凍結し、納期も延長。A医大側の追加要件は止まらず、開発はさらに遅延。結果、納期どおりに納品できなかったことを理由に、A医大はB社に契約解除を通告。それを受けて、B社は損害賠償を請求し、裁判となった。第一審では、プロジェクト破綻についてB社に8割の責任があるとされていたが、第二審では逆転。高等裁判所は、A医大にすべての責任があるとして約14億1,500万円の支払いを命じた。A医大は判決を不服として最高裁に上告したが、最高裁は上告を受理しないことを決定。高等裁判所の判決が確定した。)判例2事件概要ITベンダーA社が定額制で請け負った、ユーザー企業Bの基幹システム保守作業。工数にかかわらず、毎月300万円が支払われる契約だが、実際には瑕疵対応や開発依頼の未完成を理由に減額され、B社は赤字状態となっていた。そこで、工数に応じた請求に契約内容を変更するようA社に求めたが、応じてもらえず。その後、B社は3ヶ月分の工数に基づく保守費用1,057万円を請求。それでも、A社は前述の契約を盾に446万円しか支払わず、B社はA社を提訴。保守作業は準委任契約で瑕疵対応や開発依頼の未完成は支払い拒否の理由にならないとして、残金約600万円の支払いを求めた。結果A社には、請求した約600万円の半額である300万円が支払われることになった。地方裁判所は、契約自体は業務内容ではなく稼働時間によって報酬を定めていたことから、準委任契約に近いものと判断。当事者間の黙示的な合意により契約内容が請負へ変更されたと判決。そのため、見積もりで想定されていなかった作業は、追加費用を支払うべきとして、B社の行なった作業が本当に想定外であったかどうかも加味し、A社に請求額の半額である300万円の支払いを命じた。2012WLJPCA04258017)いかがでしょう?IT訴訟って、調べてみると結構多かったりします。IT化が訴訟になるなんて、、、と悲しい気持ちになります。シテム屋に依頼する前にしておくべきこと概算見積もり、詳細見積もり、、、などご予算相談を受ける際にも必要なことがあります。それは、『何が必要か?』が明確になっているということ。少なくとも現行の処理がどれくらいの規模でどんな処理をしているのか、その上で新システムはどう改善していくのか?新規システムであれば、業務フローは必須中の必須。ユーザーさんが何をしたいのか、が明確でないと、どれくらいの規模のものを作るのかも全く想像できないわけです。私が”雇われSE”のとき、しょっちゅう見積もりをしていました。仕様変更の都度、まず見積もりから始めるのですが。いっても、現行の処理を把握している上で、その仕様変更を行うことで影響の出るものが何で、それらをどう直すのか、をすべて洗い上げて見積もります。調査結果から導き出すと、、、そんなに差は出ないので、意外に直感がイケてます(笑)いや、直感と言いつつも、頭の中では勝手に工数をはじき出しているわけでして。『金額』については、会社さん毎に計算ルールがあるので違いはありますが、かかる工数としてはほぼ共通です。いえ、SEもPGもレベルが様々ですので、平均的なレベルでの工数を心がけます。そうそう!とある会社さんで、非常にデキに問題のある子(元請けの社員さんですね)がいたんですが。お客様まで承諾していたという、、、ちょっと不思議な現場もありました^^;話が逸れちゃいました。開発云々の前にしておくべき作業を並べていきます。自社業務の整理これは必須です。「業種で大体一緒でしょ?」と言われても。作業手順や、ましてや言葉の定義ですら会社さん・部署さんによってはバラバラです。社内異動があったとき、作業を引き継ぐ際エライコッチャになってませんか?異動に限らず、長期休暇をとってる場合、出張、産休などなど。『人に仕事がついている』という場合、その人がいなくなると業務がstopするというパターン。引き継ぎしたけど、結局引き継ぎ切れていなかった、、、というのは他人事ではないはず。『仕事に人がついている』状態であれば、自然に上記の内容が周知徹底されていたりします。業務フローとは業務を図解したものです。業務プロセスを図として可視化することで、当事者も第三者も皆が「こんなことしてるんだ~」が理解しやすくなるものです。目的もなく実施する作業ではなく、「だれかに何かを売るための作業」や「だれかに何かを届ける作業」といえます。「プロセス」:「手順や過程」です。「手順」とは「物事を実行する順序」を表し、「過程」とは「物事が変化・進行していく順序」を表します。その二つを合体した「業務プロセス」とは『何らかの価値を生み出す仕事』を実行する『順序』となります。私は、大きく2つのフローを必要と感じています。・全体業務フロー:その企業さん全体の作業の流れが分かるもの(超大企業さんだと、ちょーっと作成するのが大変ですけどね)・部分フロー:各部門毎の作業の流れが分かるものいきなり細かい内容が始まっても「ナンノコッチャ」です。見出しの変わりでもある全体フローはやっぱり必要だと思います。※こういうの書いてるとき、めちゃくちゃ楽しい私です(^-^;現業務内容の洗い出しユーザーさん側でハマってしまう罠があります。それは、、、1「そんなん誰でも知ってるでしょ」っていうヤツです。自分の毎日の作業は「正しくて、理解されている」と思いこんでいるということ。意外にそれって非常識だったりします。思ってる以上に、周りの人から見ると「え?何それ?」「それは違うってば!」ということも多いです。マニュアルがきちんと整備されていない職場であればあるほど、今一度自身の業務が何をどうやっているのかを明確にする必要があります。「変える」認識がないから出てこないわけでして。そもそも「変える」ということすら選択肢になかったりします。「えーだって、、、これやってあれやってからそれをこうする、、、って聞いてるし」と言われたままの手順でただただ素直に作業していては気付かないことです。私はいつも「あーこれメンドーだな、もっと効率よく出来んかな、、あ、ここマクロで、、、ねーこういうマクロ作って~」となります。(マクロは自分でもある程度は作れますが、、、”雇われSE”の時は、周りにマクロマニアさんたちがたくさんいらっしゃったので、しょっちゅう作ってもらっていました。他の作業が山のようにありましたからね)工夫・改善するという意識って、普段から持っていないと急に言われても覚醒しません。どんなワガママ意見でも、「こうしてほしい」「ああしてほしい」という要望はとっても大事です。要望が見えなければ何も変えることは出来ません。それって陳腐化していないですか?ちなみに。・やたらマニュアルがあるけど、どれも中途半端で組み合わせないと使えない。どれを組み合わせるのかも不明。・最初に作ったっきり。そのマニュアルに載っていることは古すぎて話にならない。