誠ブログは2015年4月6日に「オルタナティブ・ブログ」になりました。
各ブロガーの新規エントリーは「オルタナティブ・ブログ」でご覧ください。
049.【業界の話】「ホワイト企業に入社して」を見ての雑感(1)
»2013年7月 3日
IT雑貨屋、日々のつづり
049.【業界の話】「ホワイト企業に入社して」を見ての雑感(1)
1967年生まれ、神奈川県横浜市在住。ひょんな事からIT業界に努めて四半世紀、嫁と子供2人、あとメス猫一匹を抱えて、日々奮闘しているエンジニア(??)です。趣味はバイクと読書。IT業界の事、仕事の事、趣味や日々の雑感などについて、これから書いていきたいと思います。
当ブログ「IT雑貨屋、日々のつづり」は、2015年4月6日から新しいURL「http://blogs.itmedia.co.jp/satou55_makoto/」 に移動しました。引き続きご愛読ください。
こんにちは。
以前は通勤電車の道すがら、様々な本を読んでいたのですが、最近では残業が多くなりそれほど本を読む根性が無くなってしまいました。
その事もあってでしょうか、手持ちのスマートフォンをちょこちょこいじり、様々なサイトを眺めながら帰宅しています。
佐藤@IT雑貨屋です。
まあ残業が多いといっても、半ばフリーランスの様な立場で仕事をしているので、仕事があるだけありがたいと頑張っていますが、周囲で耳にするのは景気の良い話は相変わらず少ないもので、「アベノミクス」という言葉だけが先行していやしないかと感じたりもします。
そんな中ですが、以下のサイトの記事を見かけました。
このサイトはビジネスサイトではなく「2ちゃんねるのまとめサイト」ですが、この記事については近年私が考えている事とつながっているので少し紹介させて頂きます。
ここの記事のスレ主さんは、ブラック企業のプログラマーから、一応、ホワイト企業と呼ばれる企業に転職したとありましたが、実は私も同じように今の仕事場で仕事をする前には、システムエンジニアとして仕事に取り組んでいました。
まあ、当時の私が勤務していた職場もブラック企業であったのかもしれません。
思い返してみれば、入社当初から主任程度の役職に付けられ、残業は月二十時間まで支払われましたが、それ以上は「役職者は管理者なので付かない」と説明されていました。
私の場合、その会社の仕事では土日出勤はあたり前、日々の仕事も終電帰りか場合によっては会社の事務所に泊り込んでいましたが、世間的にようやく「サービス残業」という言葉が知られ始めてきた時期であり、システム開発業界(特に中小規模)では、あたりまえの状況でしたので、それほど大きな疑問も持ってませんでした。
その後、その会社の経営陣と様々な意見の相違もあって退職し今の職場に勤め始めましたが、今の職場は大手企業。つまり一応は先の記事のスレ主と同じような経過だとも言えます。
先の記事のスレ主はホワイト企業に転職後、やはり仕事への感覚はプログラマーの感覚だったのでしょう。それは上司から企画書を渡されて「プログラム、バリバリ書きますからね」という言葉にそれは表れています。
IT業界の転職ではこういった事が良くあるようです。「システムエンジニア」という言葉と「上流工程」という言葉を聴いても、実際にはプログラミングをするか、その詳細仕様を作成するというイメージする事しかなく、実際の業務はサービスの企画であったり提案である場合もあります。しかしプログラマー等の経験が長いと、こういった思考の変化をさせる事が出来ないものです。
これはあくまで私の私見ですが、システム開発とサービス企画開発は観点が違います。
システム開発とは、業務のプロセスなどをシステム化する事に主眼が置かれ、それぞれの業務フローからいかに効果的なシステム構築するかが主眼に置かれます。そしてその為には、業務フローの理解と共に最新のテクニカル知識も必要になります。
一方、サービス企画開発はその開発要件や費用もみますが、それ以上にサービスとしての適用範囲とかかる経費、そしてシステムをどの様に連携させて提供するかという観点と、またサービスとしての全体収支の観点も必要です。そしてこのサービス収支の中には、運用(保守面)の費用も加味しなくてはなりません。ですからシステム開発というよりも、連携するシステム全体に渡って考える必要があります。
まあ様々書きましたが、システム開発とは一般的には「製造観点」であるのに対して、サービス企画開発は運用と保守の観点、プラス全体の収支の概念が入ってきますし、全体を俯瞰してみる事と、営業やご利用者とのやりとりの能力(コミュニケーションスキル)も必要となってきます。
先の記事の中で上司は。
上司「君は下請けの会社にこの企画書をわたしてすけじゅっとけばいいんだよ」
と述べたとありました。
この言葉も少し省略しすぎの様な気もしますが、この場合には全体の予算の中で、実際に下請けに支払う開発費、またその開発費の内訳に相当する開発スケジュールの内訳についてまずは掌握する必要があったのではないでしょうか。また進捗管理などの為に、定期的な意思疎通の打合せや報告内容、また納品時の検品に関する事項を明確に把握しておく必要もあります。
そしてもしこの開発内容がかなり厳しいものであれば、なるべく早い時期にアラーム(注意喚起)を上司を通じてあげるべきであったろうし、相手の下請の実情について初期に確認ができれば、まだまだ様々な対策や必要であれば社間の調整なども可能であったのではないでしょうか。
しかしこういった感覚はプロジェクトリーダー等を経験しない限り、身に着けるのは中々難しい事でもあるので、このスレ主を単純に責める事も難しい事ではありますが、こういった事はこれからの発注側のエンジニアには必要にな要素では無いかと思うのです。
この続きは次回に継続して書かせていただきます。
ここまで読んで頂きありがとうございました。
IT雑貨屋を今後もよろしくお願いします。
※)急いで作成した文書だったので、かなり誤記がありましたので訂正しました。