SIerクエストTwitter等のアプリから開いた場合セーブが動作しないことがあります ブラウザアプリで開き直してください ©2015 Soichiro Yoshimura(@sifue) 続編のSIerクエスト2はこちら
SEとWebエンジニアの間にある「キャリアパスの断絶」をどう解消するか【連載:えふしん】 - エンジニアtype | 転職type
Twitterクライアント『モバツイ』開発者であり、2012年11月に想創社（version2）を設立した有名エンジニア・えふしん氏が、変化の激しいネットベンチャーやWeb業界の中で生き残っていくエンジニアの特徴を独自の視点で分析 BASE株式会社 取締役EVP of Development 藤川真一（えふしん）さん（@fshin2000） FA装置メーカー、Web制作のベンチャーを経て、2006年にGMOペパボへ。ショッピングモールサービスのプロデューサーのかたわら、07年からモバイル端末向けのTwitterウェブサービス型クライアント『モバツイ』の開発・運営を個人で開始。10年、想創社を設立し、12年4月まで代表取締役社長を務める。その後、想創社（version2）を設立しiPhoneアプリ『ShopCard.me』を開発。14年8月BASE株式会社のCTOに就任。19年7月から現職
IT業界で客先常駐という働き方はもうやめにできないか - あいむあらいぶ
かるび（@karub_imalive)です。 【2016年7月15日更新】 今日はウツを患って2年前に会社を去り、今は資格試験で再起を図ろうとしている昔の仲間と飲んできた帰りなので、少しグチっぽくなりますが勘弁してください。 システム開発会社で一般に普及している業務形態として、超大手から零細企業まで、「客先常駐勤務」という、いわゆる「派遣」的な働き方があります。これをどうにかしてもうやめられないか、という話です。 僕は、長年この業界でエンジニアから営業職、採用職といろいろ立場を替えて10年以上働いてきました。実際自分が体験して、また仲間を現場に送りこむ立場になって思うのは、この「客先常駐」という働き方は働き手にあまりに負荷をかけるのではないかということです。 客先常駐の成り立ちは1960年代 客先常駐っていう形態は、古くは1960年代後半の大型汎用機での開発黎明期にCSKという会社（現SC
「日本のソフトウエア品質は世界一」という事実と、その非常識
いつも、この「極言暴論」でイチャモンをつけているSIerのビジネスだが、彼らにも世界一と自慢できるものがある。それは開発を請け負ったソフトウエアの品質だ。「えっ、嘘でしょ！」と言う読者もいると思うが、これはどうやら事実のようだ。確かに、インドのITベンダーなどが作るものに比べて、バグなどが少ない高品質なソフトウエアを生み出している。 読者は「あれ、木村さん、SIerを褒めるなんて変節したの？」といぶかっているだろうが、ご安心いただきたい。私はSIerのプロジェクト管理や品質管理が素晴らしいと言うつもりもないし、SIerをはじめとする日本のITベンダーの技術者のスキルがとりわけ高いと主張するつもりもない。そんなことを言えば、それは悪い冗談である。むしろ、逆だと思っている。 今ではそんな騒ぎも少なくなったが、少し前までインドなどでのオフショア開発は失敗の連続だった。現地のITベンダーへ発注した
いつまで続けるのか、捨てられないプログラムとの不適切な関係
「プログラムを1行直すだけでも2カ月かかる場合もある。あまりにも長期間にわたり属人的な保守を続けてきた結果、コードがスパゲティー化し、わずかな変更であっても影響の及ぶ範囲を容易には特定できないからだ」。ある大手金融機関の話は、私には衝撃的だった。ところが、大規模システムの保守を担当する技術者からすれば、「当然あり得る」話だそうだ。 こんな話もある。ある大企業が自社のシステムについて調べたところ、膨大な数のプログラムのうち、実際に利用されているのは4割にすぎず、残りの6割は調査期間中には全く使われていなかったそうだ。そうした幽霊プログラムが毎日、ハードウエアなどのリソースをムダ遣いしながら、待てど暮らせど現れることのない利用者を待って稼働しているわけだ。 それもまた、大規模システムの担当者にとっては「あるある」話のようだ。割合は定かではなくても、「ざっくり言って、半分以上のプログラムは使われ
役立つのは「高い専門家」よりも「安い素人」
前回（参考書を手当たり次第に手に取り、無視する）に続いて、先の見えない暗闇プロジェクトで企画・計画を進めるためのセオリーを紹介しよう。 セオリー1 有事に平時の計画を使うのは禁物 U社のシステム構築プロジェクトは、当時としては先進的な取り組みだった。とはいえ平均より少し早い程度で、イノベーター理論でいう「アーリーマジョリティ」だった。業界の動きに目を光らせているU社の上層部は、「同業他社に比べ、かなり遅れを取っている」との意識を持っていた。 上層部からプレッシャーを受け、システム部門は早くプロジェクトを開始して、本番稼働、サービス提供につなげようと焦った。後発なのに先行各社よりもサービスの内容が劣っているようでは格好がつかない。標準機能をひと通り実現した上で、本番稼働にこぎ着ける必要がある。 通常のシステム開発は、「業務要件定義」「システム要件定義」「システム設計」「実装」という流れで進め
みずほもすなる「超高速開発」
ユーザーは想定以上に広がっている――。3年前ぶりに「超高速開発」について取材を重ねた結果、記者は素直にそう感じた。 プログラムを100％自動生成するツールを用いて開発スピードを飛躍的に高める開発手法を「超高速開発」と名付け、特集「『超高速開発』が日本を救う」を日経コンピュータに掲載したのが2012年3月。同月には関連記事として記者の眼に「あなたの知らない超高速開発」を掲載した。 ことさらバズワードを生み出したいという気持ちはなかったが、ネット上の反響を見ると懐疑的・批判的な声も少なからずみられた。3年前の話で恐縮だが、業務ロジックを記述・設定すればプログラムを100％自動生成するとうたうツール群について「本当にできるのか」という投げかけもあれば、「また自動生成か。同じことの繰り返しだ」という、おそらくは過去にCASEツールで手痛い目に遭ったり「Σ（シグマ）プロジェクト」の“失敗”をご存知の
元社畜SEが教える、IT土方から抜け出す方法 - NZ MoyaSystem
「IT業界で働きたいけど、残業が多そうで怖い」という不安を抱えている人、多いんじゃないだろうか？ 確かに、IT業界は一歩道を間違えるとデスマーチという落とし穴が待ち受けている。 あまりに過酷な働き方から「IT土方」なんて言葉もあるくらいの業界だ。 僕は、かつては日本でシステムエンジニアとして働き、毎日終電、休日出勤も当たり前のブラック労働をしていた。 そこから脱出して、今ではニュージーランドのIT企業でプログラマをやっている。 残業はゼロで毎日定時で帰れる職場だ。 天国と地獄の両方を見てきた経験から、今日はどうすれば「IT土方」にならずに働けるかについて考えたいと思う。 なおこの記事では「IT土方」を「過剰な残業(月60時間以上)、休日出勤を強いられるIT技術者」と定義する。 ITゼネコンの一部になるな 大手ITベンダー 下請け 孫請け IT土方にならないための具体的な方法 高いプログラミ
実施編その1：内容を深掘りし、本音を聞き出す
ここからは，ヒアリングの現場でのノウハウに入っていく。 目的が「情報収集」と「合意形成」のどちらでも，ヒアリングの冒頭では，雰囲気を和ませる。いわゆる「アイスブレーク」である。特に初対面のときは，いきなり本題に入ると，最後まで無用な緊張感が続きかねない。そこで「天気や景気など話題は何でもよいので，最初に少し雑談する」（野村総合研究所の増田有孝 経営システムコンサルティング部長）ことを心掛けたい。話し下手な人でも，事前に話題を考えておけば，決して難しくないはずである。 場が和んだら，メールで伝えた「プロジェクトの根本目的」や「ヒアリングの目的」「なぜあなたなのか」について改めて話す。そのうえで「何を聞きたいのか」を説明する（図3）。
「忍」と書いてシステムエンジニアと読む～仕事の「りある」
IT業界就職ラボ「就ラボ」 IT業界就職ラボ「就ラボ」は、IT業界への就職を希望する学生の就職活動を支援するサイトです。IT業界や職種の正しい知識を得てより良い選択をするためにお役立てください。 皆さん初めまして！ 現役のSE（System Engineer システムエンジニア）兼ITライターの左門至峰（さもんしほう）です。技術士（情報工学）やネットワークスペシャリストなどのIT資格を多数保有し、資格対策の本やSEに関する本を何冊か出版しております。 さて、この連載では、SEに代表されるITの技術者の仕事について、仕事の内容、日常、喜び、やりがいなどを学生の皆さんに分かりやすく紹介します。SE100人から取得した生のアンケートを踏まえながら、SEの仕事の「りある」に迫ります。 IT技術者といっても、いろいろな仕事がある 日本でITに携わる人材は、約100万人と言われています。日本の労働人口
Shibu's Diary: SIerの未来は明るい？
XP祭り2015に参加してきました。スタッフの方々お疲れ様でした。今回は、あまり外に情報が出てくることがないと思われる、社内SE業で成果を出すために実践してきたことを発表してきました。 前のブログのエントリーでも書きましたが、今回考えさせられたのが岩切さんの発表の「在庫切れのメカニズムの原因となる事象を把握していたのが、社内の情報部門の人間だけだった」ということです。また、その後の質疑でも、「金融系もそうだった」という話が出ました。ここで説明したいと思っていたのが「業務はどんどん狭く深くなる」ということですが、内容が膨れてきたので前のエントリーに分けました。 だいたいビジネス書とかで語られているような仕事効率の基本原則は、同じ時間で成果を上げるためには、儲かる部分にフォーカスして儲からない部分は削るということです。時間あたりのビジネスの効率があがれば、忙しさを抑えてインカムも増えてハッピー
paizaエンジニアツイッター大喜利3に集まった回答達 #システム開発の現場で言われた衝撃の一言_paiza
白烏 @White_Raven777 paiza.jp/ts/3 #システム開発の現場で言われた衝撃の一言_paiza 19時には帰ってます、と言われて入社した会社。実際周りが帰って行くのに帰れない私に上司から一言 「定時は22時だ。それ以降は深夜残業が付いてしまうからな。で、終電は何時だ？」 2015-08-31 13:24:34 osamu arita @osamu_arita リースのパソコンの返却期限が来ているから、1台になっているやつ2台に戻しておいて（前任の方が2台分のメモリ、HDを1台に組み込むという魔改造を‥orz） paiza.jp/ts/3 #システム開発の現場で言われた衝撃の一言_paiza 2015-08-31 13:26:45
エンジニアに“普通なら分かるでしょ”っていうな！
今回は、最近なにかと顧客との関係構築にはオウンドメディアが重要と耳にしますが、オウンドメディアだけではなく、『システム』を作る際、開発側ではなく発注側が気を付ける注意点です。 『システム』を作る際にどのようなことに気を付けないと、運用し始めてからここが使いづらいとか、いけてないな～となってしまうのでしょうか。 技術がなくても大丈夫！事前準備が成功のカギ システム開発の成否は準備段階で80、90％が決まります。 普通にやればまず失敗するということです…。このことは、インターネットで検索すると、どこでも目にします。そして、開発したシステムが失敗に終わったとしても、そのシステムを開発した会社の技術レベルが低いと言い切れるわけでもありません。むしろ個々の技術者は非常に優秀な場合もあります。 システム開発で結果に大きな差を及ぼすのは、「開発対象となるシステムが備えるべき機能要件をどれだけ事前に想定で
第5回 ユーザーとベンダーの認識齟齬をどう防ぐ？
前回までは、見積もりの基本的な事項として「見積もりプロセス」「システム開発プロセスと見積もりの関係」をテーマに取り上げました。今回は、見積もりを行う上で発生しがちなユーザーとベンダーの認識の齟齬について、その発生原因と解決策を説明します。 システム開発はユーザーとベンダーの共同作業です。それぞれの立場の担当者が集まって話を進めてみると、どうも話が噛み合わない。システム開発の上流工程では、そんな場面がたびたび発生するものです。例えば、「要求事項を細かく確認してみたら、ベンダー担当者が理解したと思っていた内容が、ユーザー担当者の意図とは異なっていた」「従来通り動作するというユーザーの認識が、ベンダー担当者には伝わっていなかった」などです。 契約を交わす前なら、こうした事態に気付いた時点で双方が確認し合うことにより手戻りを未然に防ぐことができます。しかし、見積もり内容を双方が確認し契約を交わした
「理屈」の人でも意思決定の99％は「感情」で行う
この連載では、先が見えない「暗闇プロジェクト」を任された場合に参考になりそうなヒントやノウハウを紹介している。前回（顧客の意思決定プロセスを「把握できた」と考えるのは大甘）は、プロジェクトを進める際に顧客のコンセンサスを取っていく際に役立つセオリーを紹介した。 今回はその続きである。暗闇であればあるほど、顧客との合意を取り付けるのがいかに難しいか、実感していただきたい。 セオリー1 時間がかかっても一人ずつ丁寧に説明する 暗闇プロジェクトは事例や前例がない。事例や前例を問うのが当たり前の経営層にとっては、評価のモノサシを取り上げられた形だ。現場が説明のロジックを構築するのが困難であるのと同様に、評価する側もその基準がないだけに難しくなる。 キーパーソンを説得できない ユーザー企業U社での、複数部門をまたがる統合データベース構築プロジェクト。こうしたプロジェクトは必ずと言っていいほどもめる。
これが大規模SIerな弊社のデファクトスタンダードな開発スタイルだ！！ - そこに仁義はあるのか(仮)
受託開発やっている、いまの開発スタイルを書く。 この前のブログはわりとフォーカスをしぼったはなしだったので、今回は簡単に全体のはなし。（書く順番が逆っぽい） 今回のプロジェクトではアーキテクトとして、この↓開発スタイルの構築と運用をしていて学び多い。 バージョン管理はGit プロジェクト用サーバーにGitBucketをたててソースコードを管理している。 オフショアと仕事をするなど、開発拠点がわかれることが多い。 ソースコードに対してロックをとったりしちゃうと、他の人が開発すすめられなくなるし、拠点別れて並行開発する大規模案件だからこそ、Gitを使う必要がある。 各開発者がブランチをきって開発をして、プルリクでレビュー依頼、からのマージをすることで、レビューが済んでいるソースしかmasterブランチに取り込まれない、というのもイイ。 弊社の”エンジニア”はみんな当たり前のようにGitを使って
小さなシステム開発会社で働く。社員は家族？ソフトハウスまとめ | 転職成功マガジン | パソナキャリアのコネクテッド
「小さなシステム開発会社」≒「ソフトハウス」 世の中には星の数ほどのシステム開発会社がありますが、その大半がシステムインテグレーターもしくはソフトハウスです。 言葉の定義としては システムインテグレーター（System Integrator）・・・ 読んで字のごとく、システムをイングレーション（統合、完成）するという意味から、クライアントから依頼されたシステム開発を請負、完成品を納品するのが主な事業内容です。要件定義や設計・開発だけでなく、システムで利用するパッケージやハードウェアの選定も行います。顧客と直接取引を行うことが多いため、プライムコントラクターや一次請けと呼ばれることもあります。1,000人程度から1万人程度の規模の会社が中心です。 ソフトハウス（Soft House）・・・ 一般的にシステムインテグレーターからシステム開発の一部（主に詳細設計から製造）を請負、システム開
IT系上場企業の平均給与を業種別にみてみた 2015年版［後編］ ～ パッケージベンダ、SIer、ホスティング企業
IT系上場企業の平均給与を業種別にみてみた 2015年版［後編］ ～ パッケージベンダ、SIer、ホスティング企業 IT系企業で給与が高いのは勢いのある新興ネット企業なのか、それとも伝統ある大手SIerなのか、あるいは若者に人気のエンターテイメントを提供するゲーム系企業なのでしょうか。今年もIT系の主な上場企業を分類し、比較しやすいようにまとめてみました。 前編のネット系、ゲーム／エンターテイメント系、メディア系に続いて、後編ではパッケージベンダ、SIer／システム開発、組み込み開発、ISP／ホスティングベンダなどの企業について見ていきます。 この記事は、Yahoo！ファイナンスの「業種別銘柄一覧：情報・通信」および金融庁の「EDINET」で公開されている企業の有価証券報告書などから、従業員数、平均年齢、平均年収の情報を取得、Publickeyが独自の判断で主な企業をピックアップして業種を
理不尽なユーザーの態度に振り回されない三つの極意
この連載では、先が見えない「暗闇プロジェクト」を任された場合に参考になりそうなヒントやノウハウを紹介している。前々回（予期せぬ“危機”に事前に手を打つ秘策）と前回（多数決で仕様を決めて“炎上”、少数意見に目を向けよ）は暗闇プロジェクトに役立つ要件定義の進め方を紹介した。 暗闇プロジェクトでは、ユーザー側の理不尽な言動や行動にベンダーが振り回されるケースが少なくない。今回はそうした場合に備えるための三つのセオリーを取り上げる。 セオリー1 相手の土俵で相撲を取らない 「我々はITの専門家ではないので」。システム導入プロジェクトで、顧客やユーザーがよく口にするフレーズである。こう言っておくことで、何かあった場合の責任を回避したいとする担当者の気持ちが表れている。 ベンダーは、こうした顧客の態度を嫌がるどころか、むしろ歓迎する。プロジェクト推進の主導権を握りたいと考えていたところ、頼まずとも向こ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
SIerからWebエンジニアへの失敗しない転職方法
