悪口をいう人は多いが、僕は大手代理店やSIerの靴の裏を舐めたい | 高橋文樹.com | Web制作
この投稿は 7年半 前に公開されました。いまではもう無効になった内容を含んでいるかもしれないことをご了承ください。 僕は会社を独立してからずっと受託でお金を稼いでいるのですが、基本的に頼まれたことをやっているだけなので、わりと取引先を失うことがあります。なので、失注と言っても競合プレゼンで敗北するのではなく、気づいたらいつのまにか別の業者に鞍替えされてたというパターンですね。 このパターンに陥るケースとしては、だいたい以下の条件を満たしています。 先方はすごい沢山の提案を貰いたがっている 予算感が提示されない 本業がITとは縁遠い 実はこのサイクルに陥るのには黄金パターンがあります。それは、「Webに詳しい人が僕を見つけ出して依頼した」という代理店的なパターンですね。基本的に営業をしない弊社では、それが受注のすべてです。 で、いつのまにか僕が直接依頼を受けるようになることがあります。その人
SIerって終わってんな
海外出張の後の振り休で暇なので書いてみよう http://getlife.hateblo.jp/entry/2014/02/06/030300 こういう無知なおっさんが居るから、日本のIT業には魅力がないのだよなぁ、という印象 自分はプログラマというよりは、どちらかというと研究で飯を食ってる非SIのエンジニア このブログの著者のおっさんが言うところの、プラスアルファは手に入れてる側ではあるんでしょう 普通のプログラマであることでは、差別化が出来ないと考えたからこそ様々な挑戦を繰り返し 生き残るために研究開発というポジションについた 外資でも働いたし、海外でも勤務経験がある 分析役（SE、アプリケーションエンジニア、業務エンジニア、システムアーキテクトなど） 業務分析やシステム分析を行い、「何を作るべきか」を明確にするための分析役を担います。 実装役（コーダー、テスターなど） 実際に動くアプ
開発者を使い捨てにする会社の話 - rabbit2goのブログ
開発に関わる種々の問題を抱えている状況はどこも似たようなものだし、開発者同士でアイデアを出し合ったり、上手くいった（行かなかった）事例を紹介すれば、互いに参考にしながら上手くやっていけそうな気もする。だから、商売云々の話は別として、開発現場での取り組み事例などは非常に気になるトピックスだったりする。 そんな事を考えつつ或る人と話をしていたら、その内容が強烈だったので差し障りの無い程度に紹介してみたい。 現場で使えない人間は退職に追い込む。わざわざ教育しなくても代替の開発者は他に幾らでもいる。 毎年xxx人を採用して、同じ数の退職者が出る。生き残った者だけが仕事を続けられる。 開発現場を回すのがマネージャの仕事。そのためには人月単価の安い下請けを使うことが必須だし、常に安い所を探している。 Excelさえ有れば仕様書を書けるし、人員計画、ガントチャートや進捗報告も作れる。だから、他のツールは
はてなブログ | 無料ブログを作成しよう
うめぇヨーグルトソースでもいかがですか。個人差にもよりますが。もしよろしければ。 お久しぶりです。 最近うんめぇ〜と思ってるヨーグルトソースがあるので、書いていこうと思います。 ヨーグルトとハーブ類をもりもり使うので、そういうのが食べられない方にはうんめぇソースではないです。ごめんなさい…。もしよろしければお茶だけも…旦~ 【用意する…
SI屋さんとSIと、直近の課題について。 - 急がば回れ、選ぶなら近道
某セッションでちょっとしゃべったことをつらつらと。SIの現状と近い将来について思うところをまとめておきます。自分自身の立ち位置も確認していくという意味で。 結論的にいうと、SI自体は必要とされていますが、SI屋さんのビジネスモデルは成立しないという状況になるので、旧来の「SI屋さんの方法」ではうまくいきません。なので、別のやり方でSIをどうやっていくか？という議論が必要になりますね、という話です。 まずSI事業は人月稼働で商売をしています。スタート地点はそうではなかったのですが、一旦大きな人数を抱えると、食わせる必要があるため、より大きな仕事を取る羽目になります。要は稼働させる事、それ自体が目的になります。稼働を維持させる事で、収入を確保する事ができ、確保された収入で稼働のための人員を維持できる。そもそもそういう循環をベースに組織の目的が、「結果として」形成されてしまっています。 副作用と
SIer を再び人気職種にするためには、これだけ変えればいい - ジャスミンソフト日記
私が就職活動を行っていた20年前、SE は花形職業の一つでした。しかし今は 3K として敬遠されるようになり、力のあるプログラマーは SIer を避けるという状況となっています。 この業界で骨をうずめようと考えている身にとって、なぜ今日のような状況になったのかという原因を探ることは責務と感じます。また、これを解決するために自身（と会社）のエネルギーを注ぎたいと思っています。 まず次の二点は、私が同業の方と話をしていて、よく話題になる事項です。 人月制度に代わる見積手法が確立されていないこと。人月による見積が妥当なのはコンサルタントなど、上流設計の一部のみ。例えば製造で1,000人月という数字は、根拠があってないようなもの。 階層構造によるコミュニケーションストレスの存在。階層構造の下部に位置するSE/プログラマが仕様の矛盾に気付いても、直接確認することができない。また、お客様との接点がない
開発手法とコミュ力は捨てろ――SIエンジニアに告げる、Web企業への転職戦略
開発手法とコミュ力は捨てろ――SIエンジニアに告げる、Web企業への転職戦略：きのこる先生のエンジニア転職指南（6）（1/2 ページ） 元プログラマ、現Web系企業の人事担当者による、エンジニア転職指南。「応募書類の書き方」や「自己PRの仕方」について、エンジニアの視点を持ちながらアドバイス。エンジニアの幸せな転職のために、菌類が奮闘する。 皆さん、こんにちは。2011年も残すところあとわずか。忙しい日々をお過ごしでしょうか。 師走ということで、師に負けず菌類も走り回っています。新卒採用のエントリが始まり、やるべきことは増えるばかり。冬眠したい気持ちをぐっとこらえてフル稼働中です。 繰り返す、ここはSIerではない さて今回は、かつて私が所属していた「システム・インテグレータ（SIer）」、そしていま所属している「Web系企業」についてお話します。 SIerは、長引く不況とIT業界の構造変
人月商売が悪だと思っている、イノセントなあなたへ - GoTheDistance
色んな意味で示唆的なエントリ。山本さん、どうしちゃったんですか。飲みにでも行きますか。 人月は悪どころか、ものすごい善かもしれない - 山本大＠クロノスの日記 140文字ぐらいでまとめちゃうと、人月ではなくソフトウエアの持つ価値だけでお金を取ろうとすると、例えばスマホアプリの場合は非常に単価が安いのでペイする算段が立たないこともある。それを鑑みると、エンジニアの稼働ベースで請求できる人月ってなんだかんだでイイとこあるよ、って話です。 人月について語られる記事はエンジニアよりの観点で議論されることが多いんですが、そうなると「人月はエンジニアにとって善か悪か」という方向に話が飛んでしまい、ゼネコンは死ねば良いし多重請負は終わってるし日本のIT競争力はなんだかんだっていう感じで一定の結論が出しにくい。なので、もっとビジネスよりの観点で整理してみたい。 人月のメリットは成果物ではなく作業内容に対し
システムが無くなった日
自分のブログに書こうとも思ったのですが、会社が特定されてしまいそうなのでここに書きます。どこかに書かなければならないと思ったのは、この事実を誰かに伝えなければならないと思ったからです。 私が勤めていた会社はシステム屋さんです。2タイプの職場があって、一つはお客に注文を受けてシステムを開発してリリースして終了。もう一つはお客の会社に居候させてもらってシステムの維持管理をするというものです。私は後者のほうです。 お客は工場も複数構える結構大きな企業で、様々なプラスチック製品やコンピューター部品を作るところであります。日本だけじゃなくて海外とも取引があったと思います。 1. コンピュターシステムの入れ替えを要求されるこの不況のなか、様々な設備投資の資金を抑える事を進めていた中で、システムについても、もっとコストの安いものをと以前より私の会社の上役達と試行錯誤を繰り返してきたのですが、そもそものお
スーパークリエイターがSI業界で即戦力になれない理由 - aikeの日記
少し前に若いエンジニア達と話す機会があった。この春SI企業に入社してプログラミングの研修を受けているという。みんなそれぞれ能力が高い上に、学習の高速道路を爆走中といった感じでネット上で話題になっているような技術情報には十分詳しい。SICPを全部解いたとも言っていたし本当はプログラミングの研修なんか必要ないのだろう。未踏に応募したり勉強会を開催したりするのはこういったタイプなんだろうかとか、いまどきのSI企業の人材獲得能力はすごいなとか思いつつ、でも彼らはこの業界に何を求めてどうなろうとしているのか少し気になったりもした。 これほど優秀で勉強もしてきた人達でも、SIerとしては即戦力にはならない。社会人マナーとか仕事の進め方の話ではなくて、単純に知識不足という意味で。そのため一緒に入社したプログラミング能力の低い社員と同じように扱われる可能性が高い。これはすごく不幸な状態だと思う。SI業界が
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
株式会社スターロジックの羽生章洋が書いてるブログ:元請けにこだわる理由 - livedoor Blog（ブログ）
私は文系の大学中退（まぁ高卒ですよね）です。最初に入ったのがソフト会社で、その次もソフト会社でした。最初の会社では未経験のど素人だったのでオペレータやパンチャー、運用と保守からやらせて頂きました。その後転職した2番目の会社で、絶対に忘れないと感じる出来事に出会いました。 ＃ とりあえず、以下のエピソードのあと、新婚早々に残業400時間/月とかやってて ＃ さすがに「これは死ねるかも」と思う程度に、月に200時間残業とかするのは ＃ 当然と思っていた、それでもそれが苦にならなかったほどに一体感を持つことが出来た ＃ 今思うに幸せな時代の話です。私は当時の会社を今でも誇りに思っています。 2番目の会社にはその年の1月に入社しましたので、その年の夏のボーナス（賞与というよりも私にはボーナスという言葉の方がゴージャスに聞こえるのでこれで押しますｗ）は当然出ません。というわけで、お金に困っていた私は
SEとPG、どっちが頭がいい？（2）：下流から見たIT業界：エンジニアライフ
刺戟的な題名で続けます。 前回は日本独特のSE／PGの分業体制がどのようにして発生したのか、ということを説明しました。それは日本にソフトウェア開発が産業として根付いたときに、PGが単純作業労働者と位置付けられてしまったため、上級技術者を区別する言葉が必要とされた、それがSE（システムエンジニア）だというものでした。 ●C言語＠UNIXでは COBOLの開発ではSE作業とPG作業がきちんと分けられていると思われがちですが、これも前回述べたとおり実際には形式だけのものになっていました。これはタイムシェアリング端末の普及によってプログラミング作業が格段に効率化されたからでした。プログラミングに残っていた煩雑な手作業の部分が省力化されたのです。 この事情はBasicやC言語でも同じことです。1980年代後半、わたしは最初の会社を辞め、パソコンの開発をするようになりました。現場では、技術者はそれぞれ
SEとPG、どっちが頭がいい？（1）：下流から見たIT業界：エンジニアライフ
ちょっと刺戟的な題名をつけました。しかし決して挑戦的な意図があるわけではありません。SEとPGの分業がIT業界にもたらしている問題が今回のテーマです。 ●SEとは何か、PGとは何か まずそれぞれの職分を正しく認識することからはじめましょう。プログラマ（PG）とはどういう仕事をする人たちでしょうか。 いうまでもありません。プログラムを作る人たちのことです。大工さんは家を作る人、漁師さんは魚を取る人。こういった人々と同様にPGもその仕事の内容から自明です。 一方SE――システムエンジニアの方は必ずしもそうではありません。システムのエンジニア？ システムの技術者？ ひどくあいまいな言葉です。この言葉はじつはもともと英語ではなく、「OL」などと同じ和製英語だといわれます。海外のコンピュータ技術書にもSEという言葉はほとんど見かけません。日本人が適当に言い始めた言葉だとしたら、あいまいなのも当然です
アメリカにはSIerなんて存在しない - GoTheDistance
知人のmark-wadaさんのBlogからTB。 親子丼的ビジネス奮闘記(4) IT業界構造 SIerなんてものは無い 米国と日本との大きな違いは、米国の企業は基本的に内製なのだ。すなわち、社内のＩＴ部門に開発エンジニアを抱え、そこでシステムの開発から運用を行なう。 ですから、米国のベンダーはそこに製品を供給する役割であり、日本でいうSIerというのはほとんどなく、あっても企業でリソースが不足したらそれを補う役割でしかない。契約にしてもはっきりしますよね。提供されるプロダクトやサービスに対する対価を払えばよいわけで、かかった人月で支払ういう出来高払いのような形態は少ない。日本のようにベンダーやSIerに丸投げして、できてからこんなはずではなかったなんて事態にははじめからならない構造なのだ。 親子丼的ビジネス奮闘記(4) IT業界構造 言われてみれば・・・、っていう感じですが改めて目が鱗です
SIerの悲しい現実 - カレーなる辛口Javaな加齢日記
http://anond.hatelabo.jp/20080824080254 とりあえずメモ． SIerでお仕事してると、派遣とか常駐とか言う形で、色んな会社に行って、違う会社の人とお仕事するんだけど、「経験年数n年(n>3)です」っていう人達が、恐ろしく使えなくてびっくりすることがしばしば。 そんなもんらしい． そういう方たちは，こういう本の存在さえしらない．=>http://d.hatena.ne.jp/JavaBlack/20070522/p1 でもそういう人達の方が，SIerとしては安上がりで重宝するようだ．お客や上司が気にするのは品質や生産性ではなく価格だけだから．そしてこの主も，おそらく遠からずSIerの存在を疑問に感じ，他の道を模索するようになるんじゃないかな．よほどのコンピューター馬鹿か，或いは本当の馬鹿でなければ，SIerでプログラマを続けていくことなんて無理だろう．*
システムエンジニア不要説 - masayang's diary
JavaBlackさんからトラックバックいただいて、なんか面白い議論が進行中なのを知る。 フローチャートの呪い フローチャートがダメな3つの理由 ここではフローチャートの是非を論じるつもりはない。クソだから。もっと一般化してしまえば、○○設計書みたいに「設計書」と名のつくものは全部クソだ。だって動かないんだもん。 動かない以上、それら設計書が正しいのか、漏れがないのかは保証のしようがない。机上検証なんていう工程もあるらしいけど、君たちの脳味噌は何MIPSなんだと問い詰めたい。もちろん、机上検証で見つかる凡ミスもあるだろうけど、そんなのはズボンもパンツも履かずに会社に向かうのと同じくらいのレベルの間違いだろう。 結局はコードを仕上げてから動かして初めて「だめだこりゃ」ということになる。 そして、「だめだこりゃ」となった時に、内部設計書だか外部設計書だかなんだかしらないけど、そういう設計書関係
SI屋と顧客の未来 - masayang's diary
id:zakincoさんから、トラックバック「SIerにキンタマつかまれてるユーザー企業はSIerと心中するしかないね」をいただく。 どっちにしろモラルの無いSIerに未来は無い。だけど、会社としての未来は無いと分かっていても、社員を使い捨てにして自分達の退職金だけはせしめようってお偉方が居るSIerには気をつけましょう。 利益追求を求められる会社組織としてみれば、キンタマつかんだSI屋ってのは、実は「モラルのある」行動をとってきたわけですよ。 顧客からは「もっと安くしろ」といわれ 株主からは「もっと利益をあげよ」といわれ その妥協点として、「過去のソフトウェア資産を活用する」戦術が選ばれたわけ。 ところが、過去のソフトウェア資産なんていうのは実はCOBOL時代のデータ構造を引き継いだ時代遅れな代物。だんだん保守効率は低下し、ちょっとした修正でも偉く工数がかかるようになってしまう。かといっ
時代遅れの「基本」 - masayang's diary
フローチャート論争を見ていて思ったこと。 なにかにつけて「基本が大事」という人は、大概どこの現場にもいる 問題は...その人の言う「基本」ってのは「いつの時代の話なんだ」ということ その「基本」とやらが時代遅れであることを認識しつつ、敢えて旧式にこだわる人もいる。それはそれで一つの戦略・戦術としてはいいんじゃないかな。COBOL.co.jpみたいなやつね。新しい技術を覚えさせる必要がないということは、それだけ投資が少なくて済むということ。短期的には儲けやすい。市場がそういう開発体制を受け入れる間は商売としてはおいしいだろう。なんだかんだ言って、儲けた奴が勝ち、というのも事実。 ただし、受け入れる市場がなくなったら...そこで働く人達は、一から勉強しなおして新しい技術を習得する必要がある。旧式技術の「基本」に拘る人は、現場職員の将来を犠牲にしてお金を儲けているということを忘れてはならない。
COBOL屋の呪縛 - masayang's diary
今回の日本出張ではいくつかのプロジェクトの状況をみてきた。で、思ったこと。 「COBOL時代のデータ構造を引きずることで、生産性や保守性が落ちている」 フラグだらけのマスター 本物のコードをだすわけにはいかないので、すごく簡略化した例で説明したい。あるシステムを利用できるユーザのマスターテーブルがあるのだけど、そいつには「なんちゃらサービス利用可否フラグ」みたいなのがたくさんついているのね。 この方式の問題は以下の通り。 テスト負荷 フラグがあるということはそれをチェックするif文があるということ。 if文があればテスト件数は最低２件は増える。 入れ子になれば、４件、８件...と増えていく。andやorでも同じ。 コードの冗長性 「あるユーザがサービスAを使えるか」を調べる処理と「あるユーザがサービスBを使えるか」を調べる処理はほぼ同様になることは明らか。 「サービスAを使えるユーザ」を調
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
