「2017年07月」一覧

こんな 『 不祥事 』 は初めてとも言える人為的事故を引き起こしてしまったのです。折角落ち着き始めた矢先のことなので、唖然としてしまいました。当然ながら取引先へもその影響を及ぼしてしまったのです。システムは回復しても、ユーザが取引先に対して失墜した信頼は、そう簡単には回復できないのです。回復ばかりではなく、取り引きそのものに影響を及ぼすこともあるのです。結果次第では、ユーザ企業の『 信用 』を失墜しかねないとの自覚をベンダーのＳＥは強く持つべきでしょう。

極端な例ですが、あるユーザ企業のシステム更改プロジェクトに関与した際、既存システムの設計書が全くないという由々しき事態に遭遇した事もあります。理由を尋ねたら、システム開発費用のダウンをベンダーに申し入れたら、ベンダーからは費用をダウンさせるために設計書を作らないと回答され、両社合意の上で設計者が納品物とならなかったのです。

『操作マニュアル』も必要ですが、ユーザとしては、この業務はこういう手順で行うんですよっていう業務運用に関する『運用マニュアル』が欲しいところです。ところで『運用マニュアル』は誰が用意すべきなのでしょうか？提供してくれるベンダーもあるでしょうが、本来、業務的視点で作成されるマニュアルですから、ユーザ企業がシステム運用のノウハウを蓄積しながら、自ら作り上げていくべきものではないでしょうか。要するに、運用ノウハウ集ということです。

スマホやタブレットで簡単に画像や動画ベースのマニュアルが作れるサービスのセミナーに参加。マニュアル作成に限らず、様々な業務シーンを思い浮かべながら聞いてましたが、利用の仕方を工夫すれば、より広範囲な業務で使えそうかな？ システムという道具揃えついて、改めて考えさせられる思いでした。

見積り／契約時点での開発費用、実際にプロジェクトが進む中で起きる費用の増額。その増額に関する発注側（ユーザ企業）と受注側（ベンダー）の交渉・・・当たり前のごとく繰り返されている光景です。面白い事に、この光景はベンダー側の利益が損なわれる場面で突如として出現し、ベンダーにとって得になる場面では出現しないのです。

ユーザ企業の社長と常務と共に、システム開発を委託しているベンダーをアポなしで表敬訪問。突然の訪問に、ベンダーの営業課長は大慌て。それはそうですよね。お客様の社長と常務が前触れもなく、突然現れたんですから。通された会議室に、営業部長、システム開発部長が慌てた様子で飛び込んできました。最後には社長までもが・・・。

さて、購買部門の責任者が同席した最終プレゼンの開始です。最初はＡ社。意気揚々と１０人もの陣容で望んできました。無難にプレゼンが進み、何の問題もなくＡ社で決まるかと思ったとたん、何と営業の一人が居眠りを始めたではないですか。それを見た購買部門の責任者は、当然のごとくあきれた顔。次にＢ社。５人ほどの陣容で、無難にプレゼンが終了。購買部門の責任者が一言。Ａ社はあり得ないね！舐めてるとしか言い様がない！

ユーザ企業としてわかり難いのが、システム検収（検収手順）についてのようです。そもそもユーザ企業にとって『システム検収』とは何をすべきなのでしょうか。簡単に言ってしまえば　『確かに要望した通りにシステムが出来上がっている』　事を確認し、承認する事です。しかし、闇雲にシステムを動かしてみても、まんべんなくシステムの検収が行えるものではありません。確実にシステムの検収を行うためにも、『何をどの様に確認するか』　という視点で　『検収手順』　を明確にすることはとても大切な事なのです。

新規の開発案件を積極的に獲得したいとの想いとは裏腹に、技術者がいないので積極的に案件を取りにいけずジレンマに陥っている会社が結構多いようです。また、新規の案件を獲得したのは良いけれど、社内には対応する技術者がいないため、人手不足で困っている会社も結構多いようです。

ある会社にホームページ制作をお願いしようとしたそうです。早速、その会社より見積書と契約書が送られてきたのですが、記載されている条項や文言が良く分からない。良く分からないけど 『プロ』 の言う事だからと直ぐに契約してしまうところ、何かピンと来ることがあったのか、見積書と契約書を精査して欲しいとの依頼でした。そこで、見積書と契約書を拝見させていただきました。