受託開発のSEって、ダサイの？

　自分が、この仕事を選んだのは、

１、自分の実力を試したかった。

２、システム化する事によって困っている人の手助けをしたかった。

３、お客さんに喜んでもらいたかった。

４、やりがいがあり、この仕事が大好きである。

　この気持ちは、現在まで変わらずに来ていますが、最近の若い人達には、そのような感覚がないようです。

　昼休みの時間に、私のブログを更新していた時、ふと、「飲みにケーション」なる言葉が思い浮かび、（何か、当社の名前に似ているのが、気になったりした。）

「最近、そんな言葉言わなくなったな～。っか、自分は、使った事、無いし。そもそも、この言葉ってオヤジギャグの一種じゃないのかな？」

　そんな事を思いながらGoogleツールバーに「飲みにケーション」と入力して検索してみた。すると検索結果の中に目を引く文字を見つけた。

「SEって、飲みニケーション嫌いだよね？」

　ん？そうかな～？と思いつつクリックした。そのページは、転職系のサイトで、各職種の人のタイプを紹介しているようだ。その中に、SEの行動パターンをマンガによって紹介されたいた。いくつかの記事があり、軽く読んでみると自分とほとんどが一致している。色々な意味で納得しながら、苦笑し読んでいくと、こんな記事に行き当たった。

「受託開発のSEなんて、ダサイよね？」

　なんと、当社は受託開発型のビジネスモデルで、尚、私は、そこのSEである。この記事、穏やかじゃないですね～。とても、気になって内容を読んでみた。すると、受託開発のSEとは、困っているお客さんに、システム化することにより喜んでもらい、それをやりがいがあると感じ、その仕事が大好きである。

　ここまで読んで、先に述べた通り、私と全く一緒であり、やたら共感を得て、ニヤニヤと笑ってしまった。

しかし、読み進めていくと若い人達にとっては、受託開発のSEは、下請け的な印象があり、ダサイと嫌われているらしい。「そうか～。だから、人材が不足気味なんだな～。」と、また、納得してしまった。

　ただ、読み終わってみて、「なんで、こんな楽しい仕事が敬遠されているんだろう」と若い人達の気持ちが、全く理解できない状態は、やはりSEの思考回路なんだろうと思ってしまった。

私の行動パターンは、こちらに書かれている内容とほぼ一致しております。また、同業の方、自分の行動パターンが書かれているようで楽しいですよ。一度、読まれてみてください。笑えます。内容は、きたみりゅうじさんの著書の抜粋の様です。きたみりゅうじさんの著書も読まれてみても良いかと思います。

「Dr.きたみりゅうじのSE業界ありがち勘違いクリニック」

きたみりゅうじ/著　講談社　1,575円

ISBN：978-4-06-282057-8 （4-06-282057-9）

リクナビNext Tech総研　「エンジニア解体新書」

Dr.きたみりゅうじの“IT業界の勘違い”クリニック

http://rikunabi-next.yahoo.co.jp/tech/docs/ct_s01400.jsp?p=000657&rfr_id=tags

ここをチョッと変えたい

　システム開発の依頼を頂くお客様は、システム開発を安易にお考えになっている方が多く、「ここをちょっと変えるだけだよ」とおっしゃられるお客様が結構おられます。

　システム開発のプロジェクトについてについて、家の建築に比喩されることが良くありますが、その通りだと考えます。

　家を建てるにおいての工程を簡単に書くと下の様になります。

１、どんな家が建てたいのかを確認し
２、設計書や完成予想図を作って確認
３、建築開始
４、建て終わって引渡し

　さあ、基礎工事も終わって、棟上も終わりましたという時に、お客さんが、「いや、この真ん中の部屋、やっぱり、6畳じゃなくて、10畳にしてもらえる？」と言ってきました。これを、どう思われますか？

　建設会社としては、当然、断るでしょうが、どうしてもと頼まれた場合は、当初の要望確認や設計も含めた棟上までに掛かった費用と建てた途中までの家の取り壊し等の費用の見積り、及び、10畳に変更した部屋を含めた再設計から引渡しまでの見積りが出てくると思われます。

「また、大げさな建築物だったら大変だけど、コンピューターのプログラムなら大した事無いでしょ？」と思われておられる方も多いかと思います。確かに建物に比べれば材料も無いですので、簡単に思えるかと思います。

　では、システムの構築においての工程を簡単に書いてみましょう。

１、どんなシステムを作りたいのか確認し

２、設計書や完成イメージを作って確認

３、製造開始

４、製造が完了して納品

工程は、家を建てる時と酷似していますね。いや、同一といえるでしょう。

　先ほどの10畳へ変更したいという例ですと、システム開発では、差し詰めシステム全体に関わるデータベースのテーブル変更といったところでしょうか。

　つまり、先ほどの例の、「当初の要望確認や設計も含めた棟上までに掛かった費用と建てた途中までの家の取り壊し等の費用の見積り、及び、10畳に変更した部屋を含めた再設計から引渡しまでの見積り」と同じ様にシステムに置き換えて書けば、「製造途中のシステムの破棄等の費用は発生しないにしても、当初の要件確認や設計も含めた製作途中までに掛かった費用の見積り、及び、テーブル変更した部分を含めた再設計から納品までの見積り」となります。つまり、それまでの掛かった費用と、これから掛かる費用の要求は、家の建築と同じような見積りとなるということです。

　また、一戸建ての家の設計変更であれば、良いですが（良くないですが）、これが、50階建てのビルだったら、大変なことになります。システムで置き換えれば、一戸建てが、簡単な問合せフォームだとしたら、50階建てのビルは、大掛かりな基幹システムですね。

　この問題は、私にだけに起きているのではなく、システム業界全てで起きており、そのため、もっと上手くシステム開発を進める事が出来る様に、新しいシステム開発手法も考案されています。それは、製造途中での仕様変更にも対応できるような手法です。先進的な考え方でお客様の要望を迅速に取り込むことができ、使いやすいシステムを実現できると考えますが、それでも、仕様変更の大きさや頻度により限界が出てくると思われ、また、工数の換算が出しにくく、短期間での要望の実現が可能なようですが、プロジェクトは、なかなか終了しない様な印象を受けました。

　しかし、実際にお客様よりいただく「使ってみないと分からない」という声は、開発している側としても、良く理解しております。この問題は、システム業界の永遠の難問となると考えます。

帰郷

以前、勤めていた会社の先輩（年齢は、私より下）の結婚式に行ってまいりました。先輩も含め、久しぶりに会う気が置けない昔の会社の仲間達と、すごすひと時は、とても癒されました。

また、結婚式場は、私の第二の故郷※である松本でしたので、久しぶりに見る町並みを楽しんでまいりました。写真は、国宝松本城です。

※前の会社の時代に約10年程住んでおり、本当の故郷ではありません。