“D”九州のベンチャー企業で、システム屋をやっております。「共創」「サービス」「IT」がテーマです。2010/05/31奇跡のプロジェクトをずっと詳細にお話ししていても詮ないことですので、プロジェクト中の大小エピソードをいくつかご紹介したいと思います。プロジェクトとしての良し悪しはあるかと思いますが、今後の考察に対するイメージと、これから経験するプロジェクトへの何らかの参考となれば幸いです。■「やっぱり、お祓いした方がよかったんちゃう?」プロジェクトが佳境に入ってくると、精神を病んで脱落する者が出たり、開発ルームで結核が発生し保健所の立ち入り検査があったりと、いろいろなことがありました。そんなときに、誰かが言ったセリフ。1世代前のシステム開発の際には実際にお祓いをしたらしく、運用管理室には神棚もありました。大勢の人がかかわると、いろいろな人がいます。なかには強烈なリーダシップを発揮するプロジェクトリーダーがいました。この人がいなければ、プロジェクトが途中で挫折してしまったかもしれない......と誰もが認めるところではありますが、反面、彼の下で心を病んで脱落していったメンバーも数名いました。そんな中で、まことしやかに囁かれていた噂。大企業の方にしては珍しく、顧客企業のプロジェクトリーダーは「仕様は俺が決める」という方でした。その方がプロジェクト統括会議で、顧客企業のプロジェクトメンバー及び開発会社のプロジェクトリーダーたちを前にして言ったセリフです。「システムは設計思想を貫くのが大切である。仕様は俺が決めるから、お前たち俺のコピーとなって、考え方をメンバー全員に徹底させよ」という意味が込められております。各開発会社からはプロジェクトメンバーがアサインされ、顧客企業と他の開発会社のメンバーと共同で作業を進めていきます。この際、開発会社のメンバーは二重の指示系統に悩まされます。1つは顧客企業のリーダー、もう1つは自社の上司。すると、何かにつけて「戻って上司に相談しないと」「上司から、それはウチの作業ではないといわたもので」「上から、こうしろ、と言われた」という言葉が多くなってしまいます。業を煮やした顧客企業のリーダーは開発会社の社長まで(時には自社のトップも使って)、メンバーを青天井にするよう直談判にゆきました。このエピソードは少し考えさせられるものがあります。建設業界には「現場代理人」という言葉があります。これは現場での総責任者の呼び名ですが、何の代理かといいますと「現場では社長の代理として、そのすべての権限を持つ」という意味なのだそうです。システム開発の分野でもプロジェクトリーダーは、それなりの権限を持つ必要があるのかもしれません。本プロジェクトの開発会社には、メーカー系開発会社(以下メーカー)と顧客のシステム子会社(以下、子会社)が参画しており、メーカーへの発注は子会社を通して行われておりました。SIerの位置付けですが、実質的にはほとんどが丸投げで、メーカーの下で一部開発を請け負っておりました。プロジェクトは大荒れで、コストも大きく揺れました。その際に子会社の上司は、親会社に「足りない、なんとかしてくれ」とだけ何度も訴えたそうです。それでとうとう堪忍袋の緒を切らした親会社は上記のセリフを吐いて、しばらく子会社を出入り禁止にしたとか、しないとか......。設計事務所と平行して、一部開発もやりました。メインではなく、おまけに近いサブシステムです。概要からすると、設備台帳から官庁報告用の書類を出力すること。年に一度、特定のユーザーしか使いませんが、意外と難しい。日々の業務で管理する設備の管理方法と報告書にまとめる集約方法はまったく異なるのです。それを自動生成するシステムを設計し、見積もるとウン億の見積書になりました。担当者はぜひほしい、というのですが顧客企業のリーダーからはOKが出ません。それをウチの社長に相談した際の言葉。年に1回の仕事で、それが自動化されたからといってウン億も効果が出るわけでもない。ウン百万円程度の価値しかないシステムだ、というのがその理由でした。システムの価格というのは作業の積み上げによって決まるのではなく、顧客企業の価値によって決まるものなのだな、と目から鱗の一言でした。結局、緒元データは設備台帳から取り出すけど書類へのまとめは人間系でやる、という方向で落ち着きました。■「ルールを変えよ」システムもいよいよ運開し、各現場で使われはじめました。システムは無事に稼働したのですが、最初は現場からの不満が多く出ました。なかには「ルールに従ってないから使えない。システムを改修しろ」という意見も出ました。その際の、顧客企業リーダーの言葉。現場はそれぞれで勝手な運用ルールを作っており、システムはすべての運用ルールを満たすことはできない、という背景があっての言葉です。「誰がそんなルールを決めたのか。今度からこのシステムがルールだ」と続きます。■「システムが分からないのではない。運開当初、サポートデスクには「システムが分からない」という問い合わせが多くあったそうです。その旨をサポートデスクの担当者が、顧客企業リーダーに伝えた際に言われた言葉。周囲からは、高い金を使って、そんなに使いづらいシステムを作ったのか、というような批判もあったようです。「システムが分からないとは画面を見て、どこにボタンがあるのか、登録する際にどうすればよいのか分からないときに使う言葉である。そんな変なシステムは作った覚えがない。今回はITを活用した業務改革が目的である。業務自体のやり方が変わっているから、その業務が分からないといっているのだ。現場の上長は、そこをしっかり指導しなければならない」これも身に詰まされるエピソードです。この大規模プロジェクトにかかわらず、あちこちでこういった問題に突き当たります。「システムが使えない」「表示されるデータが嘘だ」そんな言葉を客先の管理職が言い、クレームが入ったりします。操作性の問題や集計のバグであるなら、改修すれば事足りるのですが、実際は「(自分が、ではなく)現場の人が使えないと言っている」であり、現場は「使い方が分からない」「使う意味が分からない」「パソコンが使えない」だったりします。データも「入力したデータ自体が間違っていた」であったり、「入力されてなかった」「何を入力して良いかわからない」であったりで、結果、「管理職にとって見たいデータがきちんと表示されない」のです。いった問題にどう取り組んでゆくか、本コラムのテーマの1つにしたいと思っております。いうことで、今回はこれくらいにしておきたいと思います。いうエピソードはまだまだありますので、機会を見つけて紹介していきます。16:39はじめまして。コラム楽しみにさせて頂いております。仰るとおり、顧客の立場に立つ上で利用者としての見方と経営者としての見方の、両方で見る必要が有ると思います。お金を出す立場である経営者の意向が優先されますので費用対効果についてはSEの立場でも考えて提案すべきだと思いますね。>■「システムが分からないのではない。顧客企業リーダーの方は素晴らしい方ですね。それと同時に、SEの立場としては現行業務と新業務でどの様に変わるのかを利用者に周知出来ていなかった部分を反省すべきでしょう。お客様が求めているのは、システムではなく業務改善である事を肝に命じてこれからも業務に邁進していきたいと思います。14:30S様はじめまして。コメントいただき、ありがとうございます。自身、本プロジェクトに参加して得られた一番のメリットは、お客様の"実態"と"ホンネ"と"課題"に直に触れられたことではないかと思っております。これはもしかすると、100万Stepのプログラムを書くよりも大切な事だったと感じております。そんな経験が、本当にお客様の為に働いているSEさんをはじめ、この業界に携わっている多くの方々の一助になれば、と思っています。九州のベンチャー企業で、システム屋をやっております。「共創」「サービス」「IT」がテーマです。久しぶりの対面研修で思ったことよく学びよく遊びよく寝る、頭の回転が良い子供がたくさん育つ国になるといいな。新着記事SpecialPR@ITメールマガジンのお申し込み新着記事をいち早く知りたい、オリジナルコラムを読みたい――メールマガジンに登録して、@ITを120%使いこなそう。ITmediaはアイティメディア株式会社の登録商標です。