もし、あなたが、次のようなことをしているのであれば、これは大いに反省すべきだ。 自分たちの「できること」でしか解決策を示そうとしない。 機能や性能については説明できるが経営や事業の成果にどのような貢献ができるのか説明できない。 これからのテクノロジーやその可能性について分かりやすく説明できない。 お客様が新しい方法論や見積を求めても旧来のやり方で提案しようとする。 新しい方法論やテクノロジーの適用を求めると保証できない、実績がない、時期尚早などのネガティブ・ワードで翻意を迫る。 やがて、お客様から愛想を尽かされてしまうだろう。 工数の需要がなくなるわけではない。ただ、作業工数に応じた労働力に対価を支払うというやり方は、自動化ツールやクラウド・サービスとの競合や人口の減少と相まって、そこでの収益の拡大を期待することができなくなる。 また、工数需要そのものの内容が変わる。例えば、「コードを書く
京都市の件 京都市の基幹システム刷新が、またもや暗礁に乗り上げているようです。 tech.nikkeibp.co.jp 京都市はNEC製メインフレーム上で約30年稼働する基幹系システムのバッチ処理をオープンシステムに刷新するプロジェクトにおいて、サブシステムの1つである新福祉系システムの稼働を当初予定の2020年1月から延期する。再稼働の日程は確定していない。京都市総合企画局が2019年12月23日の京都市会で明らかにした。 現行がNECなのに、刷新にはNECが絡んでいないところが最近のNECの調子の良さが現れているなあと思います。案件の選択こそSIerの肝ですから。「おお世の腕自慢の諸君、このパズルを解いたら15億円を差し上げよう」という王様の号令に引き寄せられた夢多きベンダーや技術者が、今頃セピア色の世界で心晴れぬまま年越しをしている状況が手に取るようにわかります。 もはやこの件、SI
※当然ながら、障害発生時はどのグレードでも0bpsになります 「なら専用線選んでおけばいいじゃん」と思うかもしれませんが、費用が圧倒的に違い、同じ帯域なら１段あがるごとに2～10倍ほどになります。たとえば5倍として、ベストエフォート100Mbpsで月額10万円なら、帯域確保は50万円、帯域保証は250万円、専用線は1000万円という差になってしまうでしょう。予算は有限ですから、むやみに高い品質を選んでしまうと帯域がとれないということになります。同じ予算であれば、1Gbpsベストエフォートがよいのか、200Mbps帯域確保がよいのかは場合によって異なるので、適切な選択をするべきです。 そして、ベストエフォートはベストエフォートでも、1Gbpsで100Mbpsしか出ないキャリアもあれば、1Gbpsで900Mbpsくらいを保証しているキャリアもあります。これは概ね値段に比例しますが、つまりベスト
朝も早くから目が覚めたので、出社前に愚痴っとく。 当方のスペックは ・30代、化学系メーカに勤務。 ・大学での専攻は情報系ではない。パソコンは趣味でいじってきた。 1. SIerへの思い ・毎回、見積もりの度に「何人月ですか？」と聞くが、聞いてる私だって無意味な質問だと思ってるよ。 すまん、私の説明が悪すぎるのか、こっちの決裁権者は上から下まで人月でしか理解できないんだよ。 妥当かどうかはわからんけど、例えばソースの行数単価とか、プログラムの容量単価とかで説明したこともある。「訳がわからないから、やっぱり人月で表現してくれ」と言われたがな。 ・要求する機能に対して短い納期を設定しているが、「なんとかします」って言ってくれてありがとう。無理をねじ込んでごめん。 私にはお金関係を決裁する権限もなければ給料も安いから、ありがとう、ごめんと言うしかできない。 ・毎年「保守費、下がりませんか？」とお
昔々、具体的には約1万7千年前の旧石器時代、大学の情報工学科を卒業して、新卒22歳でSIerに就職した男(以下SE)がいました。 SEはある日、上司に言われました。 「2016年くらいに、銀行で大規模な基幹システムが必要になるらしいから、今から君一人で作り始めて。工数は20万人月ね。」 そういうと、上司はシステム企画構想やそれに伴う提案書、ノートPCを1つSEに渡して、自分は狩りに出かけました。 途方にくれるSE氏、ここから彼の約1万7千年(1万6666年)にも及ぶ、20万人月のシステム開発が始まるのでした。 約1万7千年前 |- 要件定義書を作成着手。 | 周りの人達は狩りをしながら生きている。 | 約1万6千年前 |- 要件定義書の作成が完了する。 | 基本設計に着手する。 | 土器を作り始める人が現れる | 徐々に日本列島が大陸から離れ列島になっていく。 | 約1万4100年前 |-
この投稿は 8年半 前に公開されました。いまではもう無効になった内容を含んでいるかもしれないことをご了承ください。 僕は会社を独立してからずっと受託でお金を稼いでいるのですが、基本的に頼まれたことをやっているだけなので、わりと取引先を失うことがあります。なので、失注と言っても競合プレゼンで敗北するのではなく、気づいたらいつのまにか別の業者に鞍替えされてたというパターンですね。 このパターンに陥るケースとしては、だいたい以下の条件を満たしています。 先方はすごい沢山の提案を貰いたがっている 予算感が提示されない 本業がITとは縁遠い 実はこのサイクルに陥るのには黄金パターンがあります。それは、「Webに詳しい人が僕を見つけ出して依頼した」という代理店的なパターンですね。基本的に営業をしない弊社では、それが受注のすべてです。 で、いつのまにか僕が直接依頼を受けるようになることがあります。その人
SmartNewsやBacklogの華やかな成功をみていると、SIになんて明るい未来はないんだから、これからはスタートアップをやるべきだと思う方も少なくはないでしょう。 だけど、世の中そんなに甘くない。 私は、2011年から5年間、スタートアップのようなことをずっとやっていますが、未だに何一つ成功していません。 問題は、技術にあった訳ではありません。やりたいことで実現できなかったことなんてなかった。 問題が、アイディアにあった訳でもありません。もちろん、アイディアが今一で、失敗したプロジェクトもありますが。電通の人たちと一緒に仕事をやっているので、アイディアは面白そうなものがほとんどです。でも、実際に実装してみると、それほど面白いものにならない。 これ、実はしょうがないんです。アイディアは実装するまで、その本当の面白さを確認できないから。 だから、スタートアップでは、アイディアの面白さが確
受託開発やっている、いまの開発スタイルを書く。 この前のブログはわりとフォーカスをしぼったはなしだったので、今回は簡単に全体のはなし。（書く順番が逆っぽい） 今回のプロジェクトではアーキテクトとして、この↓開発スタイルの構築と運用をしていて学び多い。 バージョン管理はGit プロジェクト用サーバーにGitBucketをたててソースコードを管理している。 オフショアと仕事をするなど、開発拠点がわかれることが多い。 ソースコードに対してロックをとったりしちゃうと、他の人が開発すすめられなくなるし、拠点別れて並行開発する大規模案件だからこそ、Gitを使う必要がある。 各開発者がブランチをきって開発をして、プルリクでレビュー依頼、からのマージをすることで、レビューが済んでいるソースしかmasterブランチに取り込まれない、というのもイイ。 弊社の”エンジニア”はみんな当たり前のようにGitを使って
筆者は、数年前に大手ユーザー系SIerから中小のとある卸売業会社に転職し、誰もエンジニアがいない環境で一から会社の営業活動を支えるシステムの構築などに取り組んでいます。いわゆる「ひとり情シス」として、システムを組み上げてから約3年の間、システムを運用改善していく中で、ようやく会社全体を俯瞰できるようになり、エンジニアならではの視点で、会社の経営改革を促すことができました。ここでは、この実体験をもとに、どのようにしてエンジニアが経営を変えていくことができたのかについてご紹介します。 筆者の所属している企業では、エプロン・かっぽう着・ルームウエアをシーズンごとにOEM生産して販売するメーカー業と、他メーカーのインテリア雑貨を仕入れて雑貨店に販売する卸売業の2つの事業を展開しています。 販売先は雑貨を販売されている小売店です。かつて売上の比率はメーカー業が8割、卸売が2割でした。比率の差は販売数
2015/03/22 JAWS-UG 2015 ~ クラウドへダイブ
よんてんごP @yontengoP 昨日はIT企業に内定した子たちの合同懇親会というのに参加していて、 話を聞く機会があったのだけれど、 多くの大学生たちにとって「IT業界」というのはやっぱり「ブラックの代名詞」であって、 そこに入ったとなっては彼らにとっては「絶望」に他ならないそうだ。 2015-03-04 09:24:24 よんてんごP @yontengoP 勿論、理系とか情報系とか元々IT業界を志望していた子にとっては 願ったりかなったりの職場である場合も多いけど、 文系卒、あるいは理系でもITとか関係ない職種を希望していて、運悪くその 志望業界に入れず、仕方なくIT業界を望んだ子たちにとっては 「絶望感」もひとしおらしい。 2015-03-04 09:25:49
第32回WebSig会議「便利さと、怖さと、心強さと〜戦う会社のための社内セキュリティ 2013年のスタンダードとは？！」2013年3月9日 http://websig247.jp/meeting/32/ チームラボ佐伯さん，高須さんの発表資料です。Read less
社会保障や税の情報を一元化するため国民一人一人に番号を割り振る「共通番号制度」の導入などで、今後、不足するのではないかという懸念も出ているシステムエンジニアを確保しようという集団面接会が東京・千代田区で開かれました。 コンピューターのプログラムの設計などを行うシステムエンジニアを巡っては、国民一人一人に個人番号を割り振り社会保障や納税の情報を一元化する「共通番号制度」の導入など、今後、さまざまな制度の導入や改正が重なり、人材が不足するという懸念がＩＴ業界から出ています。 こうしたなか、システムエンジニアの採用に向け合同面接会が東京・千代田区で開かれ、ＩＴ関連企業など１１社が参加しました。 会場では、先月、大学を卒業した人など１７人が面接に臨み、企業の担当者が志望動機を質問したり、事業内容や人材の育成方法などを説明したりしていました。 参加した企業の担当者は「面接に訪れた人たちは意欲的で、こ
もう2007年といえば5年前のことになってしまう。時のたつのは早いものです。 当時の増田のエントリが何故か今頃盛り上がっていて、その結果それに言及した僕のエントリも盛り上がっているようなのですが、5年前の状況というのはさすがに古かろう、ということでちょっとアップデートしてみたいと思います。 参考： IT業界で無事にいたいなら銀行に関わるな 銀行SE…かわいそうです… - novtan別館 ここ最近の銀行システムの大きなトピックというのは三菱統合UFJ銀行のDAY2（システム完全統合）と、みずほ銀行の3.11後の大障害とそれに伴う銀行の統合・システム刷新でしょう。 特に後者は銀行システムの停止が社会に与える影響が如何に大きいものかということを体現してくれました。 なんどかリークもされているからここだけの話をすると、みずほ銀行はいわゆる第三次オンラインをちゃんとやらなかった建て増しシステムであ
http://itpro.nikkeibp.co.jp/article/NEWS/20120329/388219/ http://itpro.nikkeibp.co.jp/article/COLUMN/20110804/363621/ http://itpro.nikkeibp.co.jp/article/COLUMN/20120330/388310/ http://slashdot.jp/story/12/03/30/1830220/ http://togetter.com/li/280424 メモ 発言を見る限りは有りがちなデスマーチ． 勘定系システムの開発失敗を巡り、スルガ銀行が日本IBMに115億8000万円の支払いを求めた裁判で、東京地方裁判所は2012年3月29日、日本IBMに74億1366万6128円の支払いを命じる判決を言い渡した。 スルガ銀行は2000年代初頭に勘定系シス
最近とにかく、移動が多いので、その中でちょいちょい考えたことをまとめておきます。まずは仕様の理解の仕方とか、業務例外とか、押さえておきましょうという視点から。別にこれが正解で必須というわけではないので、あくまで個人の経験をまとめただけです。 モデリングとか、なんというかそういう高尚な話ではなくて、実際に仕様をまとめるときに、現実的に落ちる穴を、経験的に書きます。大抵のプロジェクトでは、仕様が固まらずに、または手戻りが発生して酷くコストが膨らむということがやはり多いわけで。理屈はともかく自分の経験的な対策案です。 （なんというか、開発方法論や手法・ドキュメントのまとめ方は、なんとかBOKから始まって、アジャイルや押しくらまんじゅうやらでいくらでもであるのですが、その一方で丁寧な要求定義や設計それ自体ができる人材は、むしろ急激に減っているような印象すら受けます。海外からの翻訳や輸入はやたらと多
特許庁が進めてきた基幹系システムの刷新プロジェクトが失敗に終わり、開発に投じた約55億円が無駄になってしまったことが、先週相次いで報じられました。 ［スクープ］特許庁、難航していた基幹系刷新を中止へ - ニュース：ITpro 朝日新聞デジタル：費やした５５億円、水の泡に 特許庁がシステム開発中断 - ビジネス・経済 このプロジェクトに「内閣官房GPMO（ガバメントプログラムマネジメントオフィス）補佐官」の肩書きで2009年まで民間から参加した萩本順三氏（現 匠BusinessPlace 代表取締役社長）がFacebook上で当時を述懐しつつ、失敗の要因を分析していました。今後、失敗プロジェクトを繰り返さないためにも、重要な発言として本人の許可をいただいてまとめました。 特許庁の情報部門に幾度も中止を迫った 萩本順三氏の発言の主要な部分を引用します。 内閣官房GPMO（ガバメントプログラムマ
次の2つのエントリを読み、香川晋平氏の書籍も読んでみたいと思い、購入。 「デキるつもり」の自称・黒字社員に身につけさせたい「絶対黒字感覚」 (1/2) - ITmedia エグゼクティブ 黒字社員、赤字社員を見抜く方法 | ブクペ 「デキるつもり」が会社を潰す - 「絶対黒字感覚」のある人、ない人 (中公新書ラクレ) 作者: 香川晋平出版社/メーカー: 中央公論新社発売日: 2011/10/07メディア: 新書購入: 12人 クリック: 107回この商品を含むブログ (5件) を見る 1番目のエントリの内容は、この書籍の“導入”というよりも“骨格”（かなり荒っぽくまとめてある）。で、前々から、自分はいくら稼げばよいのかを数値で知りたかったので、この機会に算出しておく。 1. 準委任の場合 システムを（準）委任契約（いわゆる期間売り）で開発していて、年収が600万円の社員の場合を考える。書籍
つい先日、富士通がグループで抱える3万人ものSEを再教育して、職務転換を行う計画であるというニュースを知りました。 富士通の3万人SE職務転換大作戦は成功するのか？ - GoTheDistance 一つのシステムを複数の企業などが利用するクラウドサービスがこのまま普及すれば、顧客の要望を聞いて個別システムを作り込むＳＥは仕事がなくなり、余剰人員問題が顕在化するからだ。 クラウドの普及により、オーダーメイドでシステムをゼロから構築する必要がなくなり、そもそも顧客からの要件をまとめてシステムを設計するSEの仕事が不要になったり、基盤を構築、運用するエンジニアが不要になるということは、最近になってよく言われることであり、特に新しいことではありません。もちろん、クラウドの普及によって、これらの伝統的なSEの仕事が少なくなり、人員が余るという議論は間違いではないと思います。 ただし、一方でより本質的
調査報告書 平成２２年８月２０日 特許庁情報システムに関する調査委員会 目次 第１部 調査の経緯及び目的 ・・・・・・・・・・・・・ １ 第２部 事実関係の解明及び再発防止策について （事実解明チーム担当） ・・・・・・・・・・・・・ ３ 第１ 事実解明チームの調査方法等 ・・・・・・・・・・ ３ 第２ 事実関係 ・・・・・・・・・・・・・・・・・・・ ５ 第３ 法的検討 ・・・・・・・・・・・・・・・・・・・２２ 第４ 再発防止策の提言 ・・・・・・・・・・・・・３３ 第３部 特許庁情報システムの技術的検証及び今後 の開発に向けての提言（技術検証チーム担当） ・３８ 第１ 技術検証チームの目的、検証対象及び検証方法 ・３８ 第２ 最適化プロジェクトの概要 ・・・・・・・・・・４０ 第３ これまでの設計の経緯 ・・・・・・・・・・・・・４７ 第４ 「設計成果物」の技術的検証 ・・・・・・
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
