SIerとは何か、何であるべきか ― 偉大ならざるリスクテイカー｜ミック
はい、今回はみんな大好き（大嫌い）SIerについての話である。 デジタル庁の動きに駆動されて、日本で何度目かの内製推進が盛り上がろうとしている。 日本のITシステム開発がうまく行かない原因としてしばしば挙げられるのが、ユーザサイド（非IT産業）にエンジニアやプログラマなどのIT人材が不足しているというものだ。確かに、日本が欧米と比較してIT企業にIT人材を集中的に配置しているのは事実である。 こうしたIT人材の偏りによって、アジリティの高い開発ができない、CI/CDやDevOpsが進まない、というのは当たっているし、ユーザ企業も自らIT人材を雇用して内製を進めるべきだ、という議論にはもう十年以上の歴史がある（筆者が追えていないだけでもっと古いかもしれない）。 この時、悪玉として批判にさらされるのが、今回の主役であるSIerという存在である。日本における内製推進は、しばしばSIer批判とセッ
SI案件でアジャイル開発を進めるときの勘所
みなさんこんにちは。@ryuzeeです。 10月に発売となった『プロダクトマネジメント - ビルドトラップを避け顧客に価値を届ける』ですが、まだお読みになっていない方是非よろしくお願いします。 また、ここ数か月新しい書籍の翻訳に取り組んでいて、来年の春くらいには発売になるかと思います。この本も楽しい本だと思うので是非楽しみにお待ち下さい。 さて、先日、プライベート講演で、SIのコンテキストでアジャイル開発を進める場合に、どのような点に気をつけておくとよいかを話して来ました。 汎用的な内容で読者の方の参考になるかと思いますので、資料を公開しておきます。 以下、資料だけ見てもわからない方向けの解説です。 TL;DR（結論）SI案件でアジャイル開発を適用する場合、顧客側がアジャイルを正しく理解していない可能性があるので、案件開始前に教育すべしステークホルダーマネジメントは重要。これはウォーターフ
エンプラに Kubernetes を 導入してみて分かった 4つの Lessons Learned
Kubernetesでの性能解析 ～なんとなく遅いからの脱却～（Kubernetes Meetup Tokyo #33 発表資料）NTT DATA Technology & Innovation
SIerの生き残り戦略としてのDevOps システム運用の社葬から - Qiita
この記事に出てくる「当社」や「顧客」その他はフィクションです。ポエムです。実在のものとは関係ありません。 一部ではエンジニアの供給源として早く滅びろとまで言われているSIer、その中でも何ら価値を生み出さないゾンビ扱いのSIerのシステム運用が、もし生き延びることが出来るとしたらどんな姿なのかを考えてみるだけのポエムです。 ダラダラ書きますので、お付き合いしたいひとだけどうぞ。 社葬は嫌でもSIerで運用が好きという変態さんには、下記などを。 オカンや嫁をコアにするのではなく、システム運用をコアにしたドメイン駆動設計を、という差し迫った夢です。 システム運用のドメイン駆動設計、または運用の抽象化（とりあえず背景「SIerの伝統的な運用」） システム運用のドメイン駆動設計、または運用の抽象化（ドメインを隔離する） とりあえず、Qiitaを読んでる方が、いわゆるDevOpsやアジャイルという言
NTTデータがDXとアジャイル開発を強化、技術部門の受注貢献額を倍増の600億円へ
NTTデータは2019年4月19日に記者説明会を開き、アジャイル開発やデジタルトランスフォーメーション（DX）に対応した受託開発やソリューション提供を強化する方針を説明した。専門技術部門の参画案件数を3～10割増やし、受注貢献額を2018年度実績の300億円から600億円に倍増させる計画だ。 同社は2018年4月、システム技術本部の下に、顧客企業のDXを技術面で支援する専門部署「デジタルテクノロジ推進室」を発足させた。その後、システム技術本部の組織再編で、アジャイル開発やサービスデザインなどDXに適した開発手法のスキルを持つ技術者を「デジタル技術部」にまとめる再編をしている。 取り組みを説明したシステム技術本部の冨安寛本部長は、2019年にこの2部署の人員や体制を強化し、デジタルテクノロジ推進室によるDX案件を2018年の35件から45件に、デジタル技術部によるアジャイル開発やサービスデザ
今のSIer、共創って言いがち説 - orangeitems’s diary
共創 どこのSIerに行っても、話題は共創（きょうそう）。取りつかれたようにみんな共創、共創。どうしてしまったんでしょうか。ベンチャーは共創なんて言葉語りませんよね。決まってSIerです。これからは共創の時代だと。お客様と共にデジタルトランスフォーメーションを考えて一緒に創り上げていく。通り一辺倒の要件定義から始まるウォータフォール型開発はもう限界だと。これだけデジタル技術が高度化すると、そもそも顧客側すら要件を思いついていない。でもIT投資予算はあるから各社提案してほしい、というのは古い。だから、ビジネスモデルの部分から含めてSIerの上流に位置するコンサルタント部門と一緒に、お客様の経営に近い層と時間を共有し、新しいデジタルならではのビジネスモデルを共に、創ろう。これが共創です。私でもこの営業はできそうな気がします。だってどのSIerのイベントに行っても必ず同じことを言うんですもの。
[RSGT2019]全部スクラム！～SIerで大切だったこと、サービサーで大切だったこと～
Shigeki MorizaneSoftware Developer, Project Manager, Agile Coach at SamuraiKatamariS
![[RSGT2019]全部スクラム！～SIerで大切だったこと、サービサーで大切だったこと～](https://cdn-ak-scissors.b.st-hatena.com/image/square/ec09941a7db7f9355a35b442be0efaa563a3f211/height=288;version=1;width=512/https%3A%2F%2Fcdn.slidesharecdn.com%2Fss_thumbnails%2Frsgt20190110-190110041236-thumbnail.jpg%3Fwidth%3D640%26height%3D640%26fit%3Dbounds)
SIはやめておけ
20代の数年間SIで働いた。1年以上前に退職して今は別業界にいる。 今日、Evernoteを整理していたら「退職理由、SIの嫌な点」というメモが発掘された。退職直前のかなりストレスがたまっていた時期に書き殴った文章だった。学生の頃の私は絵を書いたりしていて、ものづくりで暮らしたいな〜などと思って始めたプログラミングが楽しかったので安易に受託開発業を選んでしまったが、その後悔が如実に表れていた。 一部自分でも覚えていない話もあったがコンテンツとしては面白かったし、今でもシステムインテグレーター業界で消耗する若者を減らしたいとは思うので公開してみる。 以下、同メモに加筆・修正したものなのでファンタジーだと思って読んでくれ。 工数至上主義受注した時点で売上がおよそ確定するので、後はその予定工数に収めて納品できれば御の字という考え方。よくある話だが、見積がおかしくても顧客と対等な関係が築けていない
現場力の崩壊、日本企業はロボットとAIに支配されるぞ！
主にIT部門やITベンダーの問題点に焦点を当てている「極言暴論」の趣旨からして、今回の記事タイトルを奇妙に感じる読者がいるかもしれない。だが、安心してほしい。必ず最後には、このコラムの趣旨にかなう話に持っていくつもりだ。では、タイトルにした「日本企業の現場で進行するロボットと人工知能（AI）による支配」の件から説き起こすとしよう。 まず言っておくが、この話は本当である。というか、ロボットやAIによる支配は既に始まっていると言ってよい。ただ一部、誇張が入っている。誇張の部分は「ロボット」。正確に言えば、今流行りのRPA（ロボティック・プロセス・オートメーション）である。「なんだ、そのことか。『現場を支配する』もオーバーな表現だな」とガッカリされそうだが、RPAとAIによる支配は間違いなく事実だぞ。 まずRPAだが、日本銀行のマイナス金利政策の悪影響などによって追い詰められた金融機関を中心に、
私は忙しいんです。システム開発に協力できる時間なんてありません――「旭川医大の惨劇」解説その2
旭川医科大学（以降、旭川医大）で発生した、システム開発のトラブルに関する訴訟。事件の概要は、「ユーザーである旭川医大が電子カルテを中心とした医療システムの導入を企図し、ベンダーのNTT東日本に開発を依頼したが、エンドユーザーである現場の医師からの要件追加、変更がいつまでたっても収束せず、スケジュールが遅れに遅れた揚げ句に破綻してしまった」というものだ。 前回は、事件の概要を説明し、高等裁判所判決のポイントとなった「ベンダーのプロジェクト管理義務」について、解説した。今回は「プロジェクトの体制」と「開発方針」について考察する。 事件の流れを把握するために、判決文を再掲しよう。 札幌高等裁判所 2017年8月31日判決から 旭川医科大学は、2008年8月に、電子カルテを中核とする病院情報管理システムの刷新を企画し、NTT東日本に開発を依頼した。 しかし、プロジェクトの開始直後から、現場の医師た
4年半勤めた SIer やめました | u0v0u
タイトルの通り，4年ちょい働いた SIer 辞めました． よかったこと，いやだったこと． せっかく4年半働いたので，まとめようと思います． おしごとについて，ざっくり ざっくりこんな感じ．浅く広く（広くもない）SIっぽいことをしてきた． 1〜3年め ：インフラやさん（Storage , Network , Server, Helpdesk） 何百のHDDの開梱作業 サーバを担いでデータセンターへ 1Uサーバももてないのに ラッキング，ケーブリング ネットワーク機器のConfig書き換え ストレージ運用，ヘルプデスク だいたい月1以上で夜間メンテ データセンターのソファーで寝るのに慣れたし， どこのデータセンターが Redbull 一番安いか，とかそんなことばかり覚えていくし，始発の時間に詳しくなる （社内異動）4年め〜現在 ：雑務屋さん（Webのうしろがわのお仕事，BI） ちょこっとプログ
プログラマーの裁量労働制は違法！ システムエンジニアの裁量労働制が違法になったケースも（今野晴貴） - エキスパート - Yahoo!ニュース
「プログラマー」には裁量労働制が適用できない 先日、「裁量労働制」について以下の記事を書いたところ、思わぬ反響があった。 トヨタの「裁量労働制」は違法か？違法な裁量労働制を見極めるポイント この記事は、「トヨタが裁量労働制を拡大した」という記事の誤りを指摘しつつ、裁量労働制がどのような場合に違法になるかを解説したものだ。意外な注目を集めたのは、次の一文である。 「ＩＴ企業で働いていても、プログラマーには裁量労働制は適用されない」 もしプログラマーなのに裁量労働制を「適用」されているのなら違法であり、残業代を請求することができる。この事実に対して、ネットで以下のような内容の反響が多数あり、ＮＰＯ法人ＰＯＳＳＥに労働相談も寄せられた。 「プログラマーだけどシステムエンジニアの業務もさせられている場合はどうなるのか」 「自分は裁量労働制でプログラミングもしてるけど、システムエンジニアとして雇われ
SIerで開発合宿を始めた話。そしてPMジェダイが立ち上がる : 小野和俊のブログ
「技術力強化、PM力強化」 この1年間、私がCTOとして向き合うべき主たる課題はこの2つだった。 ■ 技術力強化 技術力強化については、昨年4月に私が管轄するテクノベーションセンターを立ち上げ、「ものづくりの技術の会社への原点回帰」という方針に基づいて1年間で様々な施策を講じてきた。モダン開発推進チームの立ち上げによってCI/CD、テスト自動化等の概念が徐々に浸透し始めてきたし、一度モダン開発推進が支援したチームからは、その後さらなる改善に向けて継続的に相談が来たりもし始めた。全社的に利用されるようになったSlackでは毎日のようにプログラミング談義も含めた多数の技術的な質問と回答、情報共有が行われるようになった。 さらに、全社的に技術面での成長が実感できるよう、技術力評価指標を策定する取り組みも着々と進んでいる。こうした取り組みにより、技術力強化については次第に取り組んでいたことが形にな
コードの美しさがもたらすもの
SIにおけるソースコードのライフサイクル 小野 ソースコードの美しさを考える上で大事なのが、どれくらいの期間メンテナンスしていくソースコードなのか、というライフサイクルなんですよ。パッケージとかWebのサービスっていうのは、基本的にそのソフトウェアがなくなるまでの間、維持・改修し続けるもの。SIは個別のお客さん向けに作ってカットオーバーして…と、ひとつの区切りがあるわけだけれど、それは作り切りみたいな形なのか、メンテナンスされ続けるものなのか？SIにおける１つのソースコードの旅路、どこまで、何年くらい生きてくのか？どうやって変化していくのか？どういうふうに流れていくのか？そういう、SIにおけるソースコードのライフサイクルの話を有馬さんからしてもらおうかと。 有馬 SIerのコードも１度出したら使い捨てというわけでは当然ないです。たくさんの人が関わって、すごくコストをかけて開発しているので
拝啓『変わらない開発現場』を嘆く皆様へ ～変わっていくエンタープライズ系業務システム開発とマイクロソフトエンタープライズサービスの取り組み～ | Microsoft Docs
拝啓『変わらない開発現場』を嘆く皆様へ ～変わっていくエンタープライズ系業務システム開発とマイクロソフトエンタープライズサービスの取り組み～ 05/25/2017 3 minutes to read 昨年、今年と 2 回に渡って de:code にてエンプラ系 SIer さんの PL, PM, SE を対象としたセッションを担当しました。エンプラ系 SI の『闇』はかなり深いものがあり、現場担当の方々はそれを改善すべく日々奮闘されていると思うのですが、その一方で、全体論としての捉え方が正しくないが故に、アプローチが誤っていたり掛け声だけで終わってしまっているケースも少なくありません。例えばエンプラ系開発現場でも最近はトップダウンで DevOps に取り組め、なんていう指示が出たりすることもあるのですが、実際にそれがうまくいっているお客様をなかなか見かけないのも事実です。 こうした背景があり
定額制SI、本当にうまくいってる？ | 日経 xTECH（クロステック）
「問い合わせ件数が前年比で2倍のペース。2017年3月末時点で、2016年の問い合わせ総数の半分近くに達している」。ジョイゾーが手掛ける定額制SI（システムインテグレーション）サービスが好調だ。2016年は前年比40％増の伸びだったが、2017年に入ってそれがさらに加速している。手探りで始めたサービスの予想を超える広がりに、同社の四宮靖隆氏（代表取締役社長）はうれしい悲鳴を上げる。 このサービスの特徴は、個別見積もりが当たり前だったシステム開発で「定額制」を打ち出したことだ。2014年6月に39万円で業務システムを開発する「システム39（サンキュー）」を開始した。開発基盤として、ドラッグ＆ドロップで画面を作成できるサイボウズのクラウド型DBアプリ作成サービス「kintone」を利用する。kintoneの月額利用料金は別途、顧客負担となる。 「システムを作ることにどれくらいのコストが掛かるの
SIについて私が思ったこと。そしてSIerにおけるモダン開発について : 小野和俊のブログ
ひとことで言えば、「レビュー文化は良くない」ということになるだろうか。 Slack導入、そして同時期に開始した服装の自由化、バイモーダルという考え方の浸透、AIやブロックチェーンを活用したPOC等の取り組みによって、SIerとしてのセゾン情報システムズは、社内の雰囲気もずいぶんと変わってきた。 しかし、こうした取り組みだけではどうにもならないものも少なからずあった。 そのひとつは、「悪い報告がしづらい」ことだった。 これは他のSIerでも同様のことが多いのではないかと思うが、問題プロジェクトに認定されると、品質管理部のモニタリングが強化されたり、第三者によるプロジェクト監査が始まったり、経営会議での定期的な報告が求められたり、何をやっているのかとレビューでこっぴどく叩かれたり、、、。 そうした責任感から、遅れをキャッチアップできるよう少しでもがんばろう、と励まし合う中で、それなのに四方から
人月商売がエンジニアをすり潰す - 室長のひとりごち
SIerなどに見られる人月商売はエンジニアをすり潰すのです。すり潰すのはエンジニアが持っている技術を、です。 では、なぜすり潰されてしまうのでしょうか。 人月商売の値段付け 人月商売は、エンジニアを月単位に値段をつけて売るビジネスモデルです。大体は、松竹梅のような３ランクなどのランク分けをして値付けします。 いい加減なSIerだと売りたい価格にエンジニアを紐付け、売った先に送り出してしまいます。真っ当な（？）SIerであれば、エンジニアを技術評価してランク付けをしなければ顧客からクレームが来るのでそうしたことが起きないようにするものですが…。 いづれにしても、月単位に値段がつけられているところがポイントです。 買う側の理屈 エンジニアの技術料に対して費用を支払う取引とは思っていません。人月商売は、月あたりの費用ですから1ヶ月に160時間（8時間勤務＊20日）の稼働ができる場合、160時間働
損保ジャパン、要件定義に4年がかり | 日経 xTECH（クロステック）
損害保険ジャパン日本興亜が、基幹システムの再構築プロジェクトを本格化させる。まもなく要件定義を完了し、2017年5月に基本設計を始める計画である。 同社が基幹システム再構築の準備を始めたのは2013年4月。プロジェクトの序盤フェーズである要件定義の工程を終えるまでに4年かかった計算になる。一般的なシステム開発であれば失敗と見られかねない長さだが、損害保険ジャパン日本興亜の場合はやむを得ない面がある。 途中の2014年9月には企業合併に伴うシステム統合を優先せざるを得なかった。さらに、COBOLアプリケーションの大半をJavaアプリケーションに切り替える、システム刷新とともに利用部門の業務も改革するといった挑戦的な要素を含んでおり、これらの要素に対して多数の関係者の理解を得る必要があった。 実際、プロジェクトの主要メンバーはシステムを利用するさまざまな関係者の協力姿勢を引き出すことに多くの時
SIerの下請け開発者ってレベル低すぎない？ - UXエンジニアになりたい人のブログ
ネット上ではSIer批判＝技術のことをわかっておらずプログラムも書けずPMも出来ない非効率でダメダメな上流工程と、 人月単位での労働力提供という業界の慣習に縛られ、持ち前の優秀な技術力・知識を生かせず非効率な作業を強いられているかわいそうな下請け開発者、という構図が確立されているように思います。 自分が関わるまでは、まあそうなんだろうなと思っていましたが、しかし実際にそういう立場のひとと関わりをもつにつれて、どうもそうではないのではないかと思うようになりました。このあたりの実情を書いていこうと思います。 なお、先に言っておきますが本記事で書くことは、上流工程がどうのとか、業界の多重請け負い構造がどうのとか、給料が安くてとか労働条件が過酷でとか、そういう話とは全く関係がなく、純粋にプログラミングのスキルの話だけです。 対象はおもに詳細設計、実装UTだと思ってもらえれば。外部仕様が決まった状態
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
