[B! Development][sier] Oooのブックマーク

ユーザのための要件定義ガイド第2版要件定義を成功に導く128の勘どころ | アーカイブ | IPA 独立行政法人情報処理推進機構

デジタル技術を活用して企業のビジネスを変革し、自社の競争力を高めていく「デジタル・トランスフォーメーション（DX）」が注目を集めるなか、従来のようなITベンダやシステム部門が中心になって要件定義をすすめるスタイルから、業務部門のユーザが主体的に関与するスタイルへの変革の必要性が増しています。システムの要件を定義する責任は、構築されたシステムを利用してビジネスに貢献する役目を負うユーザにあると言われています。しかしながら、システム開発の遅延の過半は要件定義の失敗にあると言われるように、要件定義においては、その過程で様々な問題に直面します。そこでIPAでは、要件定義の過程で直面する問題への対応をガイドすることが、ユーザへのよりいっそうの支援策となると考え、「ユーザのための要件定義ガイド(初版)」の内容を一新し、「ユーザのための要件定義ガイド第2版要件定義を成功に導く128の勘どころ」と

Ooo 2023/08/16

リンク

民法改正で変わる瑕疵担保責任の考え方

本連載がセミナーになります！ ■■■民法改正！判例に学ぶIT導入改善講座―失敗しないプロジェクトの掟■■■ 主催：翔泳社　2017年12月7日（木）　19:00～21:00　＠ベルサール九段詳細・お申込みはこちら→　http://event.shoeisha.jp/seminar/20171207/ 瑕疵担保責任とはさて、今回は一連の民法改正のお話の最終回、瑕疵担保責任についての考え方が変わったことについてお話ししたいと思います。瑕疵担保責任という言葉については、すでに、ご存じの方も多いかと思います。受注者が請負契約に基づいて作った成果物に瑕疵、システム開発で言えばバグ等の不具合が見つかっ場合、発注者は契約を解除することも可能だし、そうまでしなくても、受注者にその補修や損害賠償を請求することができるというものです。今までの民法では以下のように規定されていました。第六百三十五条仕事の

Ooo 2016/11/01

リンク

[devsumi2013]サステイナブルなSIを実現する開発基盤のあり方

2013年2月14日のデブサミ2013 14-B-6 にて講演した「サステイナブルなSIを実現する開発基盤のあり方」のスライドです。Read less

Ooo 2013/02/15

リンク

SIer系エンジニアがベンチャーで働き始めるとぶつかる壁のリスト - IDEA and Players

元ド底辺SIerの私が心機一転、スタートアップに参加して約1年半が立ちました。今後の自分の仕事を占う意味でも、ここらで自分がこれまでに感じたこと、悩んだこと、考えたことを整理しておこうかと思います。もしも現在、SIer系の仕事をされていて、いずれはベンチャーで働いてみたいという人の参考になればもちろん嬉しいのだけど、ベンチャーってのは本当に千差万別で、ここで書いたことがそのまま他のベンチャー企業に当てはまるとは限らない、ということだけはご了承を。「仕様」って言うな！最初の問題はこれ。 SIerにとって「仕様」って言葉は絶対的な意味があるわけですよ。お客様から要求を聞いて、要件を定義して、「はい、コレコレこういうもの作りますよ。この製品ではこういうことができます。逆にこういうことはできません。よろしいですか？」と約束した結果が仕様だから当然と言えば当然。だからこそ、仕様を定めること

Ooo 2013/01/18

リンク

ソフト開発をステップ数で見積っていることに疑問を持たなくてはならない - レベルエンター山本大のブログ

ステップ数を見積もり根拠にする会社さんは、いまだに多い。嘘じゃない。お世話になってる会社さんもそういう仕組みをとってるところがあって、いいにくい部分もなきにもあらずだが、お世話になってるからこそいいたい。そんなことやってちゃだめだと。１キロステップの生産性指数をだして、今回の開発は10キロだから１０００万円とか。汎用機時代ならまだ百歩譲ってわからんでもないけど、オープン系という言葉すら死語になりつつあるこのご時世において、ステップ数が１キロ（１０００行）だったら１人月とかどうこうという話は、もはや見積もりでもなんでもなく、こじつけだ。フレームワークのコアのコードも、ビジネスロジックの肝のコードも、ネットワークの通信コードも、自動生成したコードも同じ１ステップとカウントする。見積もり時の計画ステップ数と、実際に開発したときの実績ステップ数を比較して次の開発の値決め（ダンピ

Ooo 2012/04/22

リンク

ITスタッフの9割はスキル不足：調査結果

Ooo 2012/03/15

リンク

いわゆる仕様と業務例外について - 急がば回れ、選ぶなら近道

最近とにかく、移動が多いので、その中でちょいちょい考えたことをまとめておきます。まずは仕様の理解の仕方とか、業務例外とか、押さえておきましょうという視点から。別にこれが正解で必須というわけではないので、あくまで個人の経験をまとめただけです。モデリングとか、なんというかそういう高尚な話ではなくて、実際に仕様をまとめるときに、現実的に落ちる穴を、経験的に書きます。大抵のプロジェクトでは、仕様が固まらずに、または手戻りが発生して酷くコストが膨らむということがやはり多いわけで。理屈はともかく自分の経験的な対策案です。（なんというか、開発方法論や手法・ドキュメントのまとめ方は、なんとかBOKから始まって、アジャイルや押しくらまんじゅうやらでいくらでもであるのですが、その一方で丁寧な要求定義や設計それ自体ができる人材は、むしろ急激に減っているような印象すら受けます。海外からの翻訳や輸入はやたらと多

Ooo 2012/02/21

リンク

これから大手SIerを困らせるだろうクリエイティブなだけのエンジニア層 - レベルエンター山本大のブログ

[特集:SEが消える 1/3] 富士通・組織人事改革担当者「SEにはWebエンジニアのような創造性が必要」と話す真意 http://engineer.typemag.jp/elife/2012/02/se.php SIからサービス開発系の会社に変革する会社が増えると何が起こるかというと多分、「クリエイティブなだけのエンジニア」が増える。「クリエイティブなだけ」といってるけど、それは第1ステップとしてとても大事なことなので否定的な意味ではない。「まずはクリエイティブなだけの」というような意味だ。クリエイティビティ（創造性）は、なかったものを生み出すことだけれどそれが世の中に受け入れられるものかどうかは別の話だ。クリエイティブでかつ使ってもらえるという「商品」を生み出すにはもう一つ足りないものがある。「売れるものを生み出す力」だ、マーケティング力というと胡散臭く聞こえるが、商品を世に広

Ooo 2012/02/15

リンク

大規模SIは少数精鋭で乗り切れるのか？ - 急がば回れ、選ぶなら近道

まず現状の認識は以下の通り 1.20-30代の就業人口の減少これは大前提になる。また情報共有も進むためよりブラックな会社が人を集めること自体のハードルがあがる。結果として、人員を集めるということがより厳しくなる。これはITに限らず、労働集約的産業全体の課題でもある 2.能力格差の拡大今の40-50代よりも間違いなく、現状の20-30代は勉強している人としていない人の格差は広がっている。ゆとり云々とは別に、社会的なプレッシャーから、むしろ勉強しないと勝ち残れないという強い意識のある集団と、ゆるふわほんわか草食集団の差が非常に非常に広がっている 3.資源の拡大要するに、割とハード・リソースに余裕が出てきているまず、クライアントサイド。要はなんでもできる状態になりつつある。 jsあたりはほぼ無法地帯の感もある。一時、jsでOSみたいのまでいけるぜ、というデモもあったが技術

Ooo 2011/09/05

リンク

SIerは自動化する対象が違っているのでは？

多くのSIerフレームワークでは、Excelなどのツールを使ってコードを自動生成することで「製造」コストを下げるということに注力しています。しかし、アジャイル開発ではContinuous Deliveryにあるように、ビルド、テスト、リリースの自動化に重きを置き、コーディングは初期のひな形生成はしても、最終的には手でメンテナンス可能なクリーンなコードを保つという考え方をします。

Ooo 2011/09/02

リンク

日本のSI業界でこそ、専門の技術者の必要性がもっと見直されるべきではないのか？ - 達人プログラマーを目指して

Twitterでフォローさせていただいている@chok12jaさんのつぶやきがきっかけで、外国人の視点から日本のSI業界の問題について分析した面白い英文の記事を見つけました。 How the Japanese IT Industry Destroys Talent | Japan -- Business People Techno logy | www.japaninc.com [ThinkIT] 第2回：なぜ日本のIT業界ではスーパーSEを育てられないのか (1/4)（New 日本語訳が見つかりました。） 2007年に書かれた記事なのでもう４年も前に書かれたものですが、日頃から私が感じてきた業界の問題点について鋭く批評を加えており、非常に共感する内容が書かれていました。本ブログの主な読者の方々にとっても興味深い内容だと思いますので、ここで簡単に内容について紹介させていただきたいと思います

Ooo 2011/04/05

リンク

プログラマーの成長を考えないSIerの仮説は間違っている - 達人プログラマーを目指して

Java EEや.NETはCOBOLやVB6よりも本当に生産性が高いか？ - 達人プログラマーを目指してのコメントで熟練者も居ることは理解しているが、開発をする上で熟練者ばかりを集めることはできない。このため初心者側にレベルを合わせざるを得ない。というコメントをいただきましたけれど、これは実に典型的なSIer（の上司）の考え方ですね。SIerの仮説と呼んでもよいくらいですね。とにかく、この仮説の前提となっているのはプログラマーのスキルレベルは一定で成長しないプログラマーは容易に交換可能なリソースであるプログラマーは単純労働者であるというモデルです。とにかく、この仮説がはびこっているから、いまだにSIerのフレームワークは「初心者側にレベルを合わせざるを得ない」という思い込みで作られていることが多いのでしょう。 COBOL（の初期の）時代ならまだしも、少なくとも現在の開発環境にお