コラム一覧へ

2013年12月アーカイブ

 困ったことなのですが、何か頼むと平気でいやな顔をしたり、しっかり対応しないSEは割と多く存在します。

 私はこのタイプのSEを「後ろ向きのSE」と呼んでいます。

 「後ろ向きのSE」が担当すると事前に把握できるのなら、そんなベンダーに発注することはないと思いますが、発注後に一部の機能を担当するSEが このタイプであったり、一旦完成したシステムの担当者が異動して、後任のSEがこのタイプであったりすることはあり得る話です。

【問題行動とその対応方法】

 後ろ向きのSEの代表的な問題行動と、その対応方法を3つご紹介します。

 1)仕様の検討をお客様に要求する

 ビジネスではなく、コンピュータだけと向き合うのがSEの仕事と勘違いしているパターンです。何か課題が発生すると「仕様を決めてください」とか「どうすればよいですか?」などと連発します。仕様案の策定を自分の仕事と思っていないことが代表的な原因です。

 処方箋は1つ。明確に「仕様の検討」を要求すること。それが仕事なのだと認識すると、それまでの対応の悪さから一転して対応が良くなります。

 2)ビジネスのことを考えずに案を出してくる

 お客様のビジネスを理解しようとせずに、技術的に出来る案をごく軽く提案するパターンです。2つの案があるとき、メリットデメリットを考慮せずに、並列に提示するのが特徴です。

 SE:「この課題に対しては、A案、B案の2つが選べます。どちらがよろしいですか?」

 お客様:「どちらが望ましいの?」

 SE:「A案は、・・・が・・・で、・・・になっていまして、B案は・・・」

 お客様:「・・・・いや、そうじゃなくって。じゃあ、A案のメリットを教えて」

 SE:「A案の機能は・・・が・・・で、・・・」

 お客様:「(単純にどちらが良いかを判断したいだけなのに・・・)」

 本人はいたってまじめなのですが、やりとりが増えることでお客様の時間を浪費します。この場合の対応策は、メリット・デメリットを整理した案を口頭ではなく、メールや資料で提示するように指定すること。これで整理されたものが出てくるようになります。

 3)何か要求するとよく考えずに出来ないと言う

 最も問題があるパターンです。

 「データベースの構造上出来ません」とか、「○○に影響するので、出来ないと考えてください」など、それらしい理由が付けられることが多く、どこまでが本当なのか、わかりにくいのが特徴です。

 システム開発でプロジェクト実行中に課題が発生するのは当たり前のこと。その課題に対してSEは説明責任をきちんと果たすべきです。お客様が理解できるように説明出来ていないわけですから、業務怠慢と考えるべきではないでしょうか。

 この問題はSEがビジネスに対しての課題を甘くみていることが主な原因です。「できない」で済むと思っていることが多いのです。課題解決が必須なら、「課題解決は必須だ」と言い切ってください。SEは答えようと努力するはずです。

【なぜ後ろ向きのSEが存在するのか】

 お客様商売なのに、なぜ後ろ向きのSEが存在するのでしょうか。

 もともとコミュニケーションが苦手だからソフトウェアの道に進んだとか、仕事でずっとコンピュータを触っているから視界が狭くなっているなどの意見も聞かれますが、私はもっと単純な理由だと思います。「お客様のビジネスの成功」がSEの目標になっていないのです。

 逆に一般的なのは、納期を守ることと品質基準を守ること。この2つは、SIベンダーの社内行動基準にも明記されたりする原則的な物です。そして、「お客様のビジネスの成功」が目標になっていないSEの仕事の考え方はこうなります。

 ・依頼を受けたら、適切な見積もりを行う。
 ・発注されたら品質を確保したうえで納期を守る。
 ・納期を守るために無理しない。仕事は少ないほどよい。

 新たな要求に回答することが新たなハードルを設定することに繋がるので、後ろ向きな感情が前に出てしまうのです。

【SEにとって大切なこと】

 紹介したとおり、後ろ向きのSEと付き合うと発注者の時間が無駄に浪費されます。対応が長引くようなら、SEの交代か話ができる営業マンの同行を要求するのが良い方法です。

 SEは、幅広くしっかりした技術力を確保するだけではなく、その先の対応「お客様のビジネスの成功を追求する姿勢」が大切なのは当然ですよね。


 業務システムを構築する際、何らかの開発ツールを利用しますが、これには大きく分けて2つの選択肢が存在します。1つ目は、スタンダードな製品を利用すること。具体的にはそのハードウェアやOSを製造・開発している企業が提供している開発ツール(ファーストパーティ製品)や、オープンソースなどに代表される事実上の標準に該当するもの(デファクトスタンダード)を利用することです。

 これには、例えるならiPhone,iPad用のネイティブアプリ開発ならApple社が提供するXcodeが該当しますし、データベースを含めたWeb系システムではLAMP(*1)やLAPP(*1)などのオープンソースの組み合わせが該当します。

 *1 Linux, Apache, MySQL / PostgreSQL, PHPの組み合わせのことです。(同じ頭文字の他のソフトウェアを指すこともあります。)

【サードパーティの製品を使うことの問題点】

 2つ目の選択肢は、サードパーティ製の開発ツールを利用することです。ここでのサードパーティとは、OSを始めとするソフトウェアの動作環境を提供していない企業のことを指します。

 サードパーティ製の開発ツールは前述のスタンダードなものに比べ、ツールの学習期間を短くすることが出来たり、より簡単に開発が行えるなど、開発コストを下げられることが多く、なかなか魅力的です。しかし、業務システムは開発終了後も業務にあわせてメンテナンスしていく必要があるため、次の2点について注意する必要があります。

 1)メンテナンスする技術者は確保し続けられるか。
 2)ツールそのものが廃れてしまわないか。OSのバージョンアップに対応できるのか。

 1は自分一人で開発して自分一人で使うシステムでもない限り、必ずついて来る問題です。これは自社で開発する場合だけでなく、開発ベンダーに発注する場合も同様です。「信用できるベンダーが勧めているから大丈夫だろう」などと考えると危険です。

 開発後に主要な開発メンバーがそのベンダーから退職してしまい、その後のメンテナンスのサービスレベルが極端に悪化するケースは実際に耳にします。この場合、採用されているツールがマイナーなことが問題の本質であるため、他ベンダーへの乗り換えも難しくなります。

 2の開発ツールそのものが廃れる問題は深刻です。新しいバージョンのOSやミドルウェアへの対応が打ち切られると、せっかく開発したシステムを使い続けることが難しくなってしまいます。

 一度開発した業務システムは企業の資産として考える訳ですから、使えなくなる状況はなんとしても避けるべきです。

【業務システムで使う開発ツールは長期視点で選択しよう】

 つまるところ、業務システム構築におけるサードパーティ製の開発ツール利用の可否は「メンテナンスが困難になったら作り直せば良いと判断できるか」で決まります。本格的に採用するには慎重に検討する必要があるのです。

 私がシステム化の提案をする際、サードパーティ製のツールを検討するのは、PDFの帳票データを生成したり、ブラウザ上にグラフを描画したりする場合など、局所的でリスクが少なく効果が大きい場合に限定しています。業務システムのメイン部分の開発に、サードパーティ製のツールをお勧めすることは、ほとんどありません。


« 2013年9月 | メインページ | 2014年1月 »

お問い合わせ

システムやアプリの開発のご相談、サービスに関するご質問など、どのようなことでもお気軽にお問い合わせください。