ウォーターフォールに何もメリットはない？ | スラド デベロッパー
ストーリー by hylom 2016年06月24日 18時25分 ウォーターフォールじゃないと下請けに丸投げできないのでは 部門より アジャイル開発が広がる昨今でも、大規模開発ではウォーターフォールといった考えが主流と思われるが、そうした考えを一蹴する、MicrosoftのDevOpsエバンジェリストの牛尾氏による「私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い」というブログが微妙に注目を集めている。 事の発端となったのは、先日来日した米Microsoftのプロジェクトマネージャで「No.1 DevOps Person」と呼ばれるサム・グッケンハイマー氏と日本企業とのやり取り。氏は企業からの「アジャイルと、ウォータフォールのメリット・デメリットを教えてください」との質問に対して「ウォータフォールは一切メリットがないので止めておきなさい」ときっぱり言い放ったとのこと。これ
ソフトウェアの納期見積もりは、星占いレベルのものであると思う - メソッド屋のブログ
このエントリでは、ソフトウェアの見積もりがどういうものであるかをシェアした上で、今後日本はどのような方向に向かえばよいのでは？という私のアイデアをシェアしたいと思う。 注：このエントリは、某銀行の件とは全く関係ありません。考えるきっかけになっていますが、中の人がどんな状況だったかもわからないのに、勝手なことを想像して、人や企業を叩くのは私の趣味ではないからです。 ソフトウェアの見積もりの正確さ ソフトウェア見積もりのことを知りたければ、下記の本がお勧めだ。 books.rakuten.co.jp この本に「不確実性のコーン」という開発フェーズごとの見積もりの正確性に関する図がある。これを見ると、最初の企画の段階で実施した見積もりは、誤差が何と16倍もあり、概算見積もりのレベルでも4倍の開きがある。画面帳票仕様を「確定」したレベルでやっと1.6倍程度の開きになる。 請負開発を実施するときに、
私がMVCフレームワークをもはや使わない理由
数ヶ月前、私はなぜここにたどり着き、何が可能かを理解する旅に出ました。この旅は、私にアプリケーションアーキテクチャ、MVCという強烈な宗教に対する疑いをもたらしました。そして、リアクティブ、関数型プログラミングの真の実力に触れたのです。また、シンプルさに集中する旅でもあり、私たちの産業はうまくやっているという考えを捨てる旅でもありました。どんなことを見つけたか興味がある方もいるでしょう。 私たちの見ている画面の背後にあるパターンはMVC –Model-View-Controllerです。まだウェブがなくソフトウエアアーキテクチャも分厚いクライアントが単一のデータベースに原始的なネットワークでアクセスするのがせいぜい、という時代にMVCは生まれました。そして数十年後、MVCはまだ現役であり、衰え知らずでオムニチャネルアプリケーションの開発に使われています。 Angular2のリリースの前にM
de:code 2016 「拝啓『変わらない開発現場』を嘆く皆様へ」を担当して
実に2年ぶりのエントリになりますが；、今日はこちらの話題を。 少し前の話になりますが、5 月下旬に弊社イベント de:code 2016 で、ちょっと変わったセッション「拝啓『変わらない開発現場』を嘆く皆様へ ～エンプラ系 SI 開発現場の「今」を変えていくために～」を担当させていただきました。内容は、エンプラ系 SIer のプロパー（PL, PjM, SE）の方々向けに、設計やテスト手法の改善テクニックの要点などを通して、開発現場を改善していくための考え方を解説する、というもの。未来をお届けするイベントなのに最新技術を一切説明しないという異色のセッションにもかかわらず、参加者満足度(NSAT)ランキングで全 125 セッション中 2 位という結果になったことに大変感謝する一方で、私自身、いかに日本のエンプラ系 SI の闇が深いのか、を改めて実感することになりました。 セッションの内容につ
「自分で人生を決めない」ことが、決定的に業界の進化を遅らせているのかもしれない - メソッド屋のブログ
先日ブログを書いたら大いに炎上した。いろんな方がいろんなブログを書かれていたようだ。しかし、私は一切読んでいない。なぜならそこに関心がないからだ。ウォータフォール vs アジャイルの比較は私の関心ではなく、私の関心は「どうやったらソフトウェアに関する新しい考えや技術が、日本でも早く導入されるようになるか」だからだ。人生は短い。自分の時間配分は自分で決めているので 申し訳ないが、今後も読まないだろう。自分の人生は自分で決めるのだから。 simplearchitect.hatenablog.com 実は、この炎上の過程でいろんな仮説を考えることができた。なぜ、日本のソフトウェア産業は、海外に大きく後れを取ってしまっているのか？どうすれば、進化する手助けができるのだろうか？ 自分の現在の仮説はマインドセット、つまり「考え方」が根本的な原因ではないか？という気がしてきた。 私が最近研究しているのは
続・拝啓『変わらない開発現場』を嘆く皆様へ ～ ウォータフォール ＆ アジャイル編～ – とあるコンサルタントのつぶやき
とあるコンサルタントのつぶやき とあるコンサルタントのつぶやき MCS （Microsoft Consulting Services） の某コンサルタントがまったり語るテクノロジのお話です。 ご存知の方も多いと思いますが、ここ最近、うちの会社の歌って踊れる DevOps エバの牛尾さんが、こんなエントリを書かれていました。 私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い http://simplearchitect.hatenablog.com/entry/2016/06/20/080807 「自分で人生を決めない」ことが、決定的に業界の進化を遅らせているのかもしれない http://simplearchitect.hatenablog.com/entry/2016/06/24/080049 特に前者は炎上気味でしたが；、二回分のエントリを通して読めば、牛尾さんが言いたい
事業会社をIT会社に転生させることが、これからのSIerのミッション - GoTheDistance
言いたいことがストレートに伝わる良い文章だと思います。 simplearchitect.hatenablog.com ウォーターフォールはなんのメリットもない。プロジェクトの工程間のつじつまを合わせることができないやり方でオーダーメイドのソフトウエアが正しく作れるわけがない。正しいし、それなら一切のメリットが無いという話も理解できる。 では、ここで小噺をひとつ。受託開発の要件定義フェーズであなたは要件を変えないと顧客にとって不都合が起こることがわかったとします。社内で相談した結果、えらい人がこう言いました。 確かに不都合はあるかもしれないけど、固まった要件を自分から揺り戻すなんて出来ないぞ。これ以外やりませんって合意を取らないと前に進めないだろ？ その変更が違う変更を産むかもしれないし、お前それ膨らんだ時に責任取れるの？ 僕の実体験を一部脚色してお伝えしています。簡単に言えば、ソフトウエア
ノーチラス・ テクノロジーズは、西鉄ストアの本部基幹システムを Asakusa Framework/Hadoopにて開発、ミッションクリティカルなシステムを アマゾン ウェブ サ―ビス上で本稼働開始 | NAUTILUS
ホーム>お知らせ>ノーチラス・ テクノロジーズは、西鉄ストアの本部基幹システムを Asakusa Framework/Hadoopにて開発、ミッションクリティカルなシステムを アマゾン ウェブ サ―ビス上で本稼働開始 ノーチラス・ テクノロジーズは、西鉄ストアの本部基幹システムを Asakusa Framework/Hadoopにて開発、ミッションクリティカルなシステムを アマゾン ウェブ サ―ビス上で本稼働開始 PDF版のダウンロードはこちら 株式会社ノーチラス・テクノロジーズ(以下ノーチラス)は、株式会社西鉄ストアの本部基幹システムの刷新を行い、2013年3月末に全面稼働を開始したことを発表いたします。 この本部基幹システムは、Hadoop/Asakusa Framework™(*1)を利用した基幹系システムでは、現時点で日本最大規模となります（当社調べ 2013年4月9日現在）。また
判例評釈速報：ＩＢＭ／スルガ銀行システム開発事件〜東京地判平成２４年３月２９日判例集未登載（控訴） - アホヲタ元法学部生の日常
ソフトウェア開発モデル契約の解説 作者: 電子情報技術産業協会ソリューションサービス事業委員会出版社/メーカー: 商事法務発売日: 2008/10メディア: 単行本購入: 4人 クリック: 57回この商品を含むブログ (1件) を見る １ 事案の概要及び主な争点 本件は、地方銀行であるＸが、システムベンダであるＹとの間で新経営システムと呼ばれる勘定系システム再構築プロジェクト（以下、「本件プロジェクト」という。）に関する契約を締結し、再構築を委託したところ、本件プロジェクトが頓挫したことから、ＸがＹに対し損害賠償を請求する訴訟を提起し、ＹがＸに対して反訴を行ったというものである（以下、「本件訴訟」という。）。 主な時系列は以下の通りである。 ・２００４年９月 プロジェクト開始（２００８年１月稼働予定） ・２００５年９月 「最終合意書」作成（以下、「本件合意書」という。） ・２００
SIビジネスの流れ - @ledsun blog
システムインテグレータ（SI）のビジネスは大きく以下のような流れで進みます。 集客 営業 要件定義 製造 検収・請求 フォローアップ 集客 どんなビジネスでも同じですが、まずは見込み客を集めます。システム開発に興味を持ったお客様を探しアポイントを取ります。よく使われる手法に商品・サービスの説明をするテレアポ、割引を謳ったDM、自社の推す技術のセミナー、役員が個人的に懇意にしている既存顧客の紹介があります。会社の規模やブランドにマッチした手法を選ぶ必要がありますが、会社が成長にするにつれ手法を変えていかなければいけないのが難しいところです。 営業 アポイントの取れたお客様に顧客に直接、自社の提供するサービス、商品の説明を行います。また会社の紹介も同時に行います。お客様がある程度の金額を掛けてソフトウェア開発を行いたいと意思表示をされた場合に次の段階に入ります。そこで現状の課題を聞き出します。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
長文日記