蕎麦っ食いの中松警部がテーマです。冒頭から3分の2は「全共闘時代の学生運動」の話であり、最後にちょろっと中松警部の名前が出てきます。こりゃあ毎朝の通勤時間の読み物としては最高だ。毎日が楽しみで仕方ないね。日記2008年6月24日火曜日BS・SS交流会6月20日(金)に、会社の事業部間交流会に参加してきた。クリエイト工房には主に2つの事業部があり、高性能DB開発・組み込み開発などの高度技術開発に携わる「戦略ソリューション事業部(略してSS)」と、クレジットカード会社の社内システムの開発・運用に携わる「ビジネスソリューション事業部(略してBS)」から成っている。2つの事業部は、業務内容も違えば勤務地もまったく異なるため、月1回の社員会でも無ければ、普段互いに顔を合わせることが無い。そのため、「もう少し顔を合わせる機会を作ろう」という声が挙がり、各事業部のマネージャー・上級SEが集まって交流会をやってみることになった。30歳前半が中心で非常に若い。いった若い人間が中心になって会社を動かしていけるというのは、うちの会社のいいところなのだろう。第1回目は手探り状態であり、まずは互いのプロジェクト内容を話し合うところから始まった。クリエイト工房の元副社長は以前から「SSとBSが協力して新しいビジネスに結びつけろ」という檄を飛ばしていたのだが、やはり互いが何をやっているのか、強み・弱みは何かを理解しなければ相乗効果は得られまい。いう意味で今回は互いを理解する良い機会であり、有意義だったと思う。SSの事業内容は、同じ会社にいながらあまりよく知らなかったのだが、聞いてみるとなかなか面白そう。いうソフトハウスがあるのだが、そこの高性能DBの事をもう少し知りたくなった。お客さんに売り込むにしても、製品のメリット・デメリットを理解した上で、価値のある使い方を提案できなければいかんからね。製品に関する技術的に突っ込んだ話は「機密情報」という事であまり詳しくは教えてはもらえないらしいが、大まかな話を聞いた感じでは企業における業務ログの統計分析とかに使えそうな。交流会1回目の感触がそこそこ良かったので、今後も定期的に実施することになった。次回は互いのプロジェクト内容を資料を持ち寄って説明する。何かおもしろい動きにつなげていければと思うのだが、はてさてどうなる事やら。「テクニカルエンジニア(情報セキュリティ)」の合格証書が届いた。試験直前の2~3月はプロジェクトのテスト工程で大忙しだったので、勉強時間が取れず苦労したが、合格できて良かった。情報セキュリティの資格を取ろうとしたきっかけは、前の会社でのソフトウェア開発においてセキュリティ対策の開発に関わったこと。その経験で感じた情報セキュリティの魅力は下記の通り。重視されているため、疎かにできないいずれ、このスキルを生かした仕事をしてみたいです。鬱からの再生ストーリー|ダイヤモンド・オンライン「パワハラ上司が原因で若手が鬱になり、退職に追い込まれる」という記事。パワハラ上司ってそんなにいっぱいいるのかしら?自分は今の会社・お客さん先・前の会社含めて、そんなに多くないという印象。100人に1~2人くらい。確かにパワハラ上司はいるし、実際1人いるだけで破壊的に職場の雰囲気を悪くする。前の会社でジャイアンみたいな部長がいて、気に入った部下は徹底的にかわいがるのだが、一旦へそを曲げると、やることなすことけなして怒鳴ってくる。仕事して、結果出してる人なら目をつぶらない事も無いのだが、タバコ部屋に入り浸ったり、会社のPCでバックギャモンやってたり、IMで女性の派遣さんに夜のお誘いしてたり。紹介記事では「何故上司がパワハラを働くのか?」の理由について「上司自身が酬われていないから」という主張をしている。一理あるのかもしれない。お客さん先の新人研修で「何故上司が部下を褒めないのか、上司に理由をアンケートした結果」の話があったそうで、アンケート結果の第1位は「部下が上司を褒めてくれないから」だったそうな。確かに上司の良いところは尊敬して、それを態度なり行動なりに表した方が良いのだろう。自分自身も気をつけてみよう。前の会社の上司達も、我々部下に尊敬されたり褒めてもらいたかったのかしら。オンライン)「付加価値や提案力が生かしづらく価格競争に陥りがちな分野(公共事業)から撤退して、利益率を向上させた」という中堅ゼネコン「矢作建設工業」の紹介記事。官公庁の公共工事や民間のマンション建設などの大規模工事案件は、通常は競争入札による発注形式が取られる。競争入札になると価格競争に陥りがちになり、受注できたとしても利益率の低いプロジェクトになってしまう。そのため、競争入札による受注ではなく特命で受注を受ける事が利益率向上につながる。特命で受注を受けるためには、建設業者の設計力や提案力がものを言う。公共工事案件は官公庁と契約した別の設計業者がすでに設計を行っており、建設業者側には設計力・提案力を発揮する余地は無いらしい。そこで、矢作建設工業がとった戦略は以下の通り。生かせない公共事業から撤退し、民間事業や自前の不動産開発へのシフトこの戦略転換により、矢作建設工業の営業利益率は2004年の4.0%から2008年には5.2%に向上。鹿島建設や大林組などの大手ゼネコンの営業利益率が3%未満に低下しているのに比べると、好業績である。公共事業から撤退した事による副作用として売上高が2004年の931億円から780億円まで低下したが、営業利益で考えると2004年の37億円から2008年には40億円に増加。高利益の健全な体質になっている。我々IT業界の1企業でも矢作建設工業を見習うことはできないだろうか?おもしろいと思ったのは大手が必死で受注に走る公共事業から手を引いているところ。IT業界では必ずしも官公庁案件=利益率が低いというわけでは無いようだ(NTTデータは営業利益率10%。富士通は3%前後で苦悩してるが)。IT業界は成熟しておらず、差別化が図りやすい土壌だということだろうか?もう一つ興味を引かれたのは、紹介記事に書いてある「川下」でのビジネス。これは施工後の建物に対して後付で耐震補強をするビジネスなのだが、これが好調らしい。システム開発で言うところの、運用フェーズでの周辺開発ってところか。保守・運用はうちの会社の強みであるし、周辺開発での実績もあるので、強化していくのが面白いかも。システム屋話2008年5月17日土曜日Advanced[es]からブログを書いてみる自分はケータイとしてAdvanced[es](以下アドエス)を使用している。フルキーボードが着いているので、アドエスからブログを投稿できないかなーと調べたところ、「MackyBlogPocket」というブログ投稿ツールを発見。作者のサイトはすでに閉鎖されているのだが、有志がインストールパッケージをアップしてくれているのを見つけ、喜び勇んでインストール。会社帰りのバスの中で使っております。うまく投稿できるかな?お。思いきや、追記に失敗。MovableTypeの投稿画面はアドエスで開くには重すぎるから、結構便利かも。ビジネス-最新ニュース:IT-PLUS「日本のIT業界は、ハードウェアに比べてソフトウェアの価値がまだまだ低く扱われており、ソフトウェア開発のやり方が発展していない」という論評。この主張には大いに賛成。日本のIT業界って結局のところ箱(ハードウェア)を作る・売るに偏りすぎていて、その箱を使ってどのようなサービス(ソフトウェア)を提供するのかというあたりがおざなりになっている。Vistaを入れちゃった。「PCと同じソフトが動けば、とりあえず便利になるはず」という安直な発想が見え見え。モバイル端末はデスクトップとインターフェース(画面・キーボードサイズ、マウス有無など)が全く異なるのだから、同じソフトウェアでも使い勝手が全く異なる。ソフトの使い勝手を考えれば、インターフェースに応じてソフトも当然異なるべきなのだ。それをやらずにハードウェアでがんばりすぎるから、日本のソフトウェア製品はイマイチなのだろう。日本ではプログラマーの地位も低いし。上流・下流とか言って分析・設計を贔屓して、実装を肉体労働扱いするから、プログラマー経験無しに業務分析だの概要設計だのしかやったことのないSEが増えるわけですわ。いうSEさん達は実現不可能なシステム設計をして、プロジェクトを破綻させるわけですわ。分析も設計も実装も、単なる役割分担に過ぎないのに。常駐先のお客さんは、今日が新人の配属日。同じフロアの別グループで、新人の女の子達が恥ずかしそうにしながら、自己紹介と今後の意気込みを社員一同の前で話していた。新人は全部で4人いたのだが、全員女性。社員の半分以上が女性というだけのことはある。IT業界では考えられない。お客さんはクレジットカード会社だが、女性が多いのは業界の特質というわけではなく、会社の風土によるものらしい。「女性が働きやすい会社ランキング」の上位にランクインする位だから、設備や制度に気を配っているのだろう。組織にとって男女比率のバランスが取れているのは大変望ましいと思う。男性ばっかりとか女性ばっかりでは、組織全体として考え方が偏ってしまい、柔軟性に欠けることになる。しているのだと聞いたことがある。それに、共同作業をする時は、色々な考え方の持ち主が知恵を出し合った方が、結果的に良いアイデアが多く出る。実際、自分が前の会社で新人研修を受けていた頃、いくつかの班に分かれてブレーンストーミングをやったのだが、一番多くのアイデアを出した班は、男女の人数比が一番バランスの良かった班だった。新卒採用で一生懸命がんばっているが、女性採用には難航している模様。うちの会社も組織全体の柔軟性を持つためにも、女性が働きやすい環境を作っていきたいね。IT業界が痛い目を見る日IT業界が工事進行基準導入を自衛のための言い訳(お客さんの機能追加要望を突っぱねたり、仕様変更として追加開発費用を要求するなど)にするのでは?というところまでが前回のお話。これ自体は悪い事では無い。開発終盤になっての機能追加要望なんて、システム屋からすれば「今更そんなこと言うなんて勘弁してよ。いう要望は最初っから言ってよ。」という話だし、当初の予定には無かった追加作業に対しては、しっかり代金を頂戴するのが商売としては正しいからだ。工事進行基準を単なる言い訳として利用することで、逆にIT業界にとって都合の悪い展開になる可能性があるのではないだろうか。それは「費用見積や作業進捗が明確になることで、ダンピングが発生する」という可能性だ。そもそも、お客さんの機能追加要望を断ったり、追加費用を取ったりする事は、お客さん側からすれば「何で機能追加できないの?本当にそんなにお金がかかるの?」という疑問を抱くだろう。突っ込めば「システム屋の言うことは妥当なのだろうか?」と考えるはずだ。お客さん側がこの疑問に対して「システム屋の言ってることがおかしいじゃないか!」と突っかかってくる事は、現実には少ないのではないだろうか。お客さんはシステム開発の事はあまりよくわからないからだ(SIerと張り合えるだけの知識・技術を持ったシステム部門を持っているユーザー企業って、それほど多くないだろう)。結局、システム屋に言いくるめられて、釈然としない気持ちを抱いたままその場は終わってしまうのだろう。ここでお客さん側に「機能追加可否や追加費用の妥当性」を判断できるだけの力が備わっているとしたらどうなるだろう?システム屋が機能追加を安い費用で請け負わされるケースが増える事は当然だが、そもそも最初の開発費用見積から妥当性を細かく調べられ、コストを削られてしまうのではないだろうか。なると、システム屋としては開発原価を切り詰めるため、人件費削減に走るだろう。それは下請け会社を叩いて搾り取る事で実現されるのかもしれない(ただでさえ安く買いたたかれているというのに・・・)。この「お客さん側が力をつけることによって、開発側がダンピングに追い込まれる」という話、建設業界で実際に起きている事なのだそうな。ここ1~2年、マンション建築が盛んに行われているにも関わらず、建設業界は利益率が激減しているらしい(2004年→2008年で、大手ゼネコン4社の売上総利益率が8%→5%に下落)。誰がマンション建築ラッシュの恩恵を受けているのかというと、発注者である不動産会社だそうで、その秘訣は「CM方式」の導入にあるのだそうな。Management」の略で、工事発注者の立場で施工業者の選定、予算・スケジュール・品質管理などを行うコンサルティングサービスのこと。日本では、建設プロジェクトをゼネコンが一括請け負いするのが普通だが、欧米では発注者がCM会社と別途契約し、CM会社に建設会社をチェックさせるのが一般的らしい。この欧米のCM会社が、98年汐留再開発の際にCM業務を受注したのをきっかけに、不動産会社がCM方式に着目。近年のマンション建築においてCM方式を導入することで、建設コストを削らせることによって、不動産会社が利益を拡大しているのだそうな。IT業界の開発プロジェクトでは、未だ建設業界のような状況にはなっていないが、CM方式を持ち込んでくるコンサル会社は出てくるかもしれないし、それによってお客さん側が発注力をつけてくるかもしれない。厳密にする」というのは、開発プロジェクトの内容をガラス張りにすることであり、CM方式によるコスト叩きには格好の材料なのだ。いう旨味を見逃さない人間は必ずいるはずだ。発注者によってコストを叩かれて、利益を出せなくなった建設業界では、下請け会社を中心に倒産が相次いでいるらしい。中には経営苦により自殺する経営者もいるのだとか。我々、日本のIT業界は「ゼネコン体質」とか「労働集約的」など、建設業界と似たものとして論じられる事が多い。その「お隣」である建設業界のような悲惨な状況にならないために、今後どうしていったらよいか?考えていきたい。確かにデスマーチ発生率を減らすことになるかもしれない。詰まるところ「年度毎の収支を安定して見せることができる」という会計上のメリットしか無いように思われます。よって、デスマーチが減る」というような論調が多いのか。それはITサービス業界の「要件定義ミスを、契約上お客さん責任とすることで、SIerのリスクを軽減したい」という思惑があるからだと思われます。必要になる」ということなのですが、もう少し深掘りすると「費用見積もりの精度を高めるためには、要件定義をちゃんとやらなきゃダメです」となり、さらには「要件定義はお客さん主体でやるべき作業なので、お客さん責任でやってください。SIerはお客さんの作った要件定義通りに設計・開発しただけなので、我々SIerは悪くないです。お客さんの責任で改修費用を負担してください。「そんな陰謀めいた馬鹿な話が?」と思うかもしれませんが、あながち間違いとも言えないでしょう。事実、ITサービス業界では「要件定義をお客さん責任とするよう、契約上明確にしよう」という動きがあります。「開発フェーズ毎の個別契約」に移行させようという方針になっています。具体的には、システム開発契約を下記3契約に分割します。ついてですが、両者の決定的な違いは「最終成果物に対する責任の所在」です。「準委任契約」では発注側(=お客さん)が成果物に対する責任を負うことになります。要件定義については「SIerはお手伝いをするだけ」という契約です。お客さん責任化」の流れがうまくいけば、デスマーチ最大の原因である「要件定義ミス」による負担をSIerがかぶる事は無くなるでしょう。「お客さんが懐を痛める」か「要望をあきらめる」の何れかによって。SIerにとっては旨い話のようですが、逆に痛い目を見る展開も可能性としてありそうなので、それについて追々書いてみます。現在、自分は某大手クレジットカード会社様の業務部門に常駐する業務SEをやっております。自分たちは「ユーザー業務をよく理解しているシステム屋」という立場によって、次世代業務システムの要件定義や、システムテスト・運用テストの計画・実施に携わっております。言うものの、自分は今の会社に2007年5月に転職したばかり。「システム開発時の性能トラブル対応」や「Webアプリケーションフレームワークの開発」といった後方技術支援的な業務ばかりだったので、クレジットカード業界の事なんてさっぱり知りませんでした。「まあ、うちの業務やシステムは複雑で覚えることがいっぱいあるので、1年くらいはかかると思います。」と慰められたりもして。結局、今のお客様先に飛び込んでから10ヶ月が経過しましたが、まだまだわからないことばかり。上司やお客様に質問しながら、自分のタスクをこなす毎日です。それでも、最初に比べたらずいぶんと主体的に判断・行動できるようになったかなあ。システム屋話2008年4月9日水曜日はじめにこのブログではシステム屋として日々思ったことを書き連ねていくことで、自分自身の振り返りをしたり、他のシステム屋さん達と情報交換するための材料にしたりしようと思います。目標は2~3日に1回は更新。たける)医療系Webサービス企業でシステム開発・運用やってるシステムエンジニアです。新聞にも掲載されましたので続報として掲載します。ご迷惑をおかけしましたが、ブログ、引っ越すことに決めました。ブログなどに詳しい知人曰く、「いずれヤフーもログインしなくても投稿できるように戻るかもしれないよ」と言います。しようか、悩んでいましたが皆さんのアドバイスで引っ越しすることにしました。このたびブログを移転することになったのでご報告。以前からお話のあったライブドアさんに移転することにしました。久しぶりのブログ更新です...(^^;)今年も8月15日~17日の間、三島大社の夏祭りが盛大に開催されました!当店の前もたくさんの人が行き来していて、本当に活気のある三日間となりました。今年の夏祭り用ディスプレイは当店のお客様で書道教室の加藤先生の作品を飾らすせていただくことになり、とても華やかな雰囲気になりました。横浜アリーナで開催されたフリーマーケットに行ってきました。出店数400店という大規模なイベントなだけに期待度も大。流行デザインのもの」というイメージがあったのですが、意外にもたくさんの掘り出し物に出会えました。投稿Atom投稿すべてのコメントAtomすべてのコメントリンク株式会社クリエイト工房フーズアンドヘルス。