納品のない受託開発、ソニックガーデンがノウハウとブランドの提供を開始。「ソニックガーデンギルド」
受託開発という一般的なIT業界のビジネスモデルには、開発側が完成責任のリスクが負わされるため価格にリスク吸収用のマージンを載せざるを得ない点や、人月で工数やコストを計算するためにスケジュールの遅れをサービス残業で吸収せざるを得なかったり、値下げのために人件費が圧迫されたりといった課題が指摘されています。 こうした課題に対して「納品のない受託開発」という新しいビジネスモデルを提案し、実践しているのがソニックガーデンです。 納品のない受託開発とは、発注者と受注者がパートナーとなり、受注者はビジネスの立ち上げに必要なソフトウェアの企画開発から運用まですべてを請け負うスタイル。発注側は要件を開発者と相談しつつ固めていくことができ、しかも実際に動作するソフトウェアをすぐに入手できるため、利用者や市場の反応を確かめながらシステムを完成させていくことができるようになります。 ソニックガーデンの「納品のな
なんでもかんでもクラウドにあげるのか？ - 急がば回れ、選ぶなら近道
某エントリーの話で、「なんでもかんでもクラウド化なのか？」というお話もご意見も多数頂戴いたしまして。一応念押しですが、そういうつもりはまったくないですよ。以下、個人的な補足メモです。会社の意見ではありません。一応、会社の公式声明は「できるものは、とっとクラウド化したほうがいいですよ。」です。 クラウド化の是非については、いろいろあるでしょう。ユーザーの所属する産業毎にシステムのあり方・考え方は違うでしょうし、当然クラウド化すべきだという意見や、いやそもそも無理があるという意見もあると思います。ただ、今までのように先例がないから無理、という理屈は通用しなくなっているのが現状でしょう。その意味では無茶な理屈ではなく、普通に選択肢としてクラウド化が候補になっている、と思います。その上で、クラウド化しない、するという議論が普通にできる状態になりつつあると思います。 そんな中でいろいろ思うところをち
ダメなシステムが無くならない理由はエンジニアを正しく活用できないから - GoTheDistance
Twitterで流れてきたのでつい見てしまいましたが、この方の連載は全体的にやっつけ感が否めないですね。 なぜ“ダメなシステム”は無くならないのか？ - なぜ“ダメなシステム”は無くならないのか？：ITpro この"ダメだしとっつあん"があの手この手で言わんとしてることは｢上流工程と下流工程の分断は悪であり、ダメなシステムはそこから生まれている｣ということですので、この記事を読んだ人は連載読まなくて大丈夫です。僕が書いたこのエントリ読んでください。もっと突っ込んで書いてあります。 ｢SIerでのキャリアパスを考える｣というイベントに登壇しました - GoTheDistance もうそろそろぶっちゃけてもいいでしょ。ダメなシステムができる理由は簡単だってことに。ウオーターフォールが逆流できないせいだ/丸投げするからダメ/リスクをとらないからダメ/技術力のないやつが舵を取るからダメ・・・ってさ
情報処理推進機構：ソフトウェア・エンジニアリング ｢アジャイル型開発におけるプラクティス活用事例調査｣の報告書とリファレンスガイドを公開
2013年3月19日公開 独立行政法人情報処理推進機構 技術本部 ソフトウェア・エンジニアリング・センター 概要 インターネット販売サイトやSNS(ソーシャルネットワークサービス)等のシステムでは、その構築において要件のすべてが明確にならなくても開発に着手し、要件の明確化や変更には開発と並行して対応します。それは、いかに早くサービスを提供するかに、ビジネスの命運がかかっているからです。 こうした要件の変化に柔軟に対応できる開発手法として、「アジャイル型開発」があります。これは、ビジネス上の優先度が高い順に、短いサイクルで機能単位の開発を繰り返す手法です。 このアジャイル型開発手法は自社開発（内製）が中心の米国で発展したものであり、要件を決めて外部に開発を委託することが多い等、受発注環境が異なる日本でアジャイル型開発を適用するのは難しいと考えられています(*1)。 「アジャイル型開発」には、
ソフトウェア開発にとって最大の阻害要因は納期 - 狐の王国
えっらそうに大規模開発を語るような立場じゃないんだけど、何かと話題のこのへんの記事を読んでいろいろと日ごろ思うところがふつふつとわいてきたので……。 Life is beautiful: 特許庁のシステム開発が破綻した本当の理由 Fumi's Travelblog: "費やした55億円、水の泡に 特許庁がシステム開発中断"って一体何だったのか、報告書を読んでみた 特許庁システムのことはそれなりに話題で、日本についてから何度も話にあがってきている。まあ不祥事だのなんだのって話もあるがそれはおいとくとしても、設計段階で60人体制ってだけでも多すぎるのに、増員で1300人体制とか……。設計を穴掘りかなにかと勘違いしてるとしか思えない対策でそりゃまあ破綻するよなあと。 それからね、中嶋さんの記事のコメント欄に書き込まれてた、よく言われる大規模開発でのこのへんの話。 SIerが開発を行う場合、この1
設計と実装の狭間で - 急がば回れ、選ぶなら近道
・現状 ・・・相変わらず溝は埋まっていません。希望の星と目されたDSLは現時点ではかなりの不発弾に近い感じで、設計系クラスターはあまり元気がないですね。翻って見れば、設計と実装が最も近かった時代は、なんのことはなくて、自分も含めて（懐古趣味の老人を除いた）皆さんが毛嫌いするCOBOL＋汎用機の時代だったかもしれないという意見すら出る惨状です。あの時代以降、 UMLが登場し、まさに銀の弾丸状態で、それ以降Unified Processやら何やらが、インフルエンザの如く流行りました。ま、その延長上に今のアジャイルまでの流れがあるわけですが、気がついてみれば、これほど設計と実装が離れてしまった時代もないという状態になってしまっています。・・・設計と実装の狭間は、相変わらず埋まっていない気がします。 ここへ来て、実装技術の多様化は、カンブリア紀を思わせる拡大の一途になっています。開発環境のみならず
ふつうの受託開発チームのつくりかた
2022年9月13日 株式会社メンバーズ ポップインサイトカンパニーでのウェビナーのスライドです。「ユーザーが欲しいと言った機能をつけたのに使われない！」という経験はありませんか。プロダクトをつくるとき「ユーザーの心理を理解しよう」とよく言われます。しかし、ユーザーに言われたままやることと、ユーザーが本当に望んでいることは異なります。「UXデザイン・UXリサーチ」は、ユーザーを理解するための専門技術です。ユーザーインタビューやユーザビリティテストを用いてファクトを集めることで、ユーザーの表面的な言葉に惑わされない、本当のインサイトにたどりつくことができます。かんたんなワークも交えながら、体系的に解説いたします。
継続インテグレーションは強みではなくなった: 柴田 芳樹 (Yoshiki Shibata)
Subversion/Gitなどを使用したソースコード管理、Jenkinsを使用した継続的インテグレーション、様々なxUnitフレームワークを使用した自動テストなどをソフトウェア開発組織として実践することは、今日では、その開発組織の技術的な強みではありません。 それらを実践しないことが、ソフトウェア開発組織の「弱み」なのです。また、組織としてそれらの実践を推進しない、あるいはサポートできないマネージャも「弱み」となります。さらに、大規模なソフトウェア開発組織においては、それらのためのインフラ整備をプロジェクトごとに立ち上げなければならず、サポート部門が存在しないことも弱みとなります。※1 ※1 プロジェクトを始めるごとに、ソースコード管理やJenkins用のサーバの調達、OSから様々なツールのインストールを一通り行うためには、それなりの時間を要します。したがって、バックアップをも含めて環境
新人SEがSIerに絶望した時に読みたいスライド4選 - ギークに憧れて
新社会人の皆さん､いかがお過ごしでしょうか｡ 最近､SIerに就職した知人が｢会社辞めたい｣というのをちらほら聞く｡聞いてみれば､彼等は仕事で挫折しているわけではない｡むしろ､技術に優れ熱意を持っている事が多い｡ではなぜ辞めたいのかと聞けば､一日中画面のスクリーンキャプチャ撮らされたりCOBOL読まされたりしていて､｢ああ､そっか…そうだよね…｡｣となる｡ そんな時は､SI業界の熱い人達のスライドを見て何かを感じよう！という事で4つ選んでみた｡弊社関係者が多いのは僕のネットウォッチの都合上お許しください｡moon and strategy moon and strategy from toshihiro ichitani 永和の@papandaさんのスライド｡｢自分の生き方を他人任せにしない｣受託プログラマの進路〜アジャイルセールスと手塚モデル〜 受託プログラマの進路 〜アジャイルセールス
アマゾンにおけるソフトウェア開発の仕事について感じたこと - 達人プログラマーを目指して
ちょうど、先日アマゾンのオープンハウスというイベントでお話をさせていただく機会があったのですが、開発者向けの20日のセクションだけで90名近くの方々にご参加いただきました。平日にもかかわらず、多数の方々にご参加いただき、どうもありがとうございました。 私自身は、昨年秋にSIerからアマゾンに転職してまだ半年ですが、この機会にアマゾンにおけるソフトウェア開発の文化や考え方について、ブログでご紹介できる範囲でまとめてみたいと思います。 私は、ずっとブログに書いてきたようにSI業界からの転職だったのですが、一般的なSIerにおけるソフトウェア開発の考え方や手法といろいろな面で違っているということは予想していたというか、もともと覚悟の上での転職でした。それでもやはり最初のうちはあまりにも大きな変化に自分の仕事のスタイルを合わせるのにいろいろと苦労しました。基本的には転職したての頃に抱いた感想（転職
いわゆる仕様と業務例外について - 急がば回れ、選ぶなら近道
最近とにかく、移動が多いので、その中でちょいちょい考えたことをまとめておきます。まずは仕様の理解の仕方とか、業務例外とか、押さえておきましょうという視点から。別にこれが正解で必須というわけではないので、あくまで個人の経験をまとめただけです。 モデリングとか、なんというかそういう高尚な話ではなくて、実際に仕様をまとめるときに、現実的に落ちる穴を、経験的に書きます。大抵のプロジェクトでは、仕様が固まらずに、または手戻りが発生して酷くコストが膨らむということがやはり多いわけで。理屈はともかく自分の経験的な対策案です。 （なんというか、開発方法論や手法・ドキュメントのまとめ方は、なんとかBOKから始まって、アジャイルや押しくらまんじゅうやらでいくらでもであるのですが、その一方で丁寧な要求定義や設計それ自体ができる人材は、むしろ急激に減っているような印象すら受けます。海外からの翻訳や輸入はやたらと多
ITを活用できる組織を増やす為に必要なこと - GoTheDistance
Publickeyさんで特許庁の基幹システム問題が取り上げられています。今回の件はどう考えても特許庁の体制が根本的な原因なので、TSOLが50人を1300人に増やしたことを槍玉に挙げても不毛だなと思っております。 特許庁の基幹システム失敗の背景にある、日本におけるITプロジェクトの実態 － Publickey この辺のITのメディアの言説は大抵「なぜXXXプロジェクトは失敗したか」的なざっくりとした問題提起なのですが、失敗にも色んなケースがありますので、本来はそれらを因数分解して細部を議論しなければ教訓は得難い。後に残るものは、ワイドショーレベルの非生産的な言説をみのもんたが茶化すぐらいの微妙な空気ですか。こういう言説がIT業界のイメージダウンに繋がっていることを認識してもらいたいものです。Publickeyさんみたいに、生産的な言説が増えていかないといけない。そういうITのメディアを作っ
特許庁の基幹システム失敗の背景にある、日本におけるITプロジェクトの実態
今週月曜日に公開した記事「特許庁の基幹システムはなぜ失敗したのか。元内閣官房GPMO補佐官、萩本順三氏の述懐」は、記事に対して数多くのブックマークやツイートが行われ、大きな反響をいただきました。 その萩本氏から「問題提起だけで終わるのではなく、こうあるべきだという提案もしたい」、という依頼をいただいたので、記事にいただいた反響への返答という意味も込めて、萩本氏の提案についても掲載したいと思います。 以下からは萩本氏の文章となります。 これまでのIT業界の慣習を捨て去り、あるべき姿へ 僕が日記（注：記事の元になったFacebookへの書き込み）を書いたのは、二度とこのような案件が出ないよう本質的な問題提起をしようと思ったからです。 それが僕の責任だと思いました。 本質的問題を提起したつもりですが、しかし本当に理解していただいたのかというのが心配でもあり、また理解していただいたとしても、今後何
特許庁の基幹システムはなぜ失敗したのか。元内閣官房GPMO補佐官、萩本順三氏の述懐
特許庁が進めてきた基幹系システムの刷新プロジェクトが失敗に終わり、開発に投じた約55億円が無駄になってしまったことが、先週相次いで報じられました。 ［スクープ］特許庁、難航していた基幹系刷新を中止へ - ニュース：ITpro 朝日新聞デジタル：費やした５５億円、水の泡に 特許庁がシステム開発中断 - ビジネス・経済 このプロジェクトに「内閣官房GPMO（ガバメントプログラムマネジメントオフィス）補佐官」の肩書きで2009年まで民間から参加した萩本順三氏（現 匠BusinessPlace 代表取締役社長）がFacebook上で当時を述懐しつつ、失敗の要因を分析していました。今後、失敗プロジェクトを繰り返さないためにも、重要な発言として本人の許可をいただいてまとめました。 特許庁の情報部門に幾度も中止を迫った 萩本順三氏の発言の主要な部分を引用します。 内閣官房GPMO（ガバメントプログラムマ
特許庁、難航していた基幹系刷新を中止へ | スラッシュドット・ジャパン IT
特許庁が5年前から進めてきた基幹系システムの刷新プロジェクトについて、中止する方針だと日経コンピュータが報じている。要件定義と設計が難航。稼働を3年遅らせたが結局中止となるという。 現場は相当酷いデスマーチ状態だったと推測出来ますが、結局2004年のシステムが最良だった言うのが最高の皮肉でしょうか？
開発コストや技術リスクを考えない「上流設計」がシステムの複雑化と大規模な障害の原因となっているのでは？ - 達人プログラマーを目指して
皆さん、明けましておめでとうございます。昨年の後半は私自身SI業界からWeb業界へ転職したことなど仕事環境の変化があり、ブログの更新頻度も鈍りがちになってしまっていましたが、本年もどうぞよろしくお願いいたします。 さて、ちょうど、一年前のお正月にはグルーポンのおせち料理事件が話題になっていましたが、私はおせち料理の品質とIT業界における品質の問題を絡めて、以下の記事を書きました。 グルーポンのおせち事件を受けてSI業界が本当に教訓とすべきこと - 達人プログラマーを目指して この記事では、一般にSIerによって開発される日本のシステムはあの事件のおせち料理のように、低い品質に甘んじているが、多くの場合、社内システムなどではそういった品質の問題が公に明らかにされることが少ないのではということを指摘しました。ただ、その時は私の希望も込めて 最近はOSSやクラウドなどの影響で社内システムもどんど
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
