これからの「アジャイル」の話をしよう ――今を生き延びるための開発手法とスキル (関西バージョン)
The document compares the traditional iron triangle of project management (scope, cost, schedule) to the agile iron triangle (value, scope, cost, schedule, quality, constraints). It discusses how agile prioritizes value over scope and schedule. The document is copyrighted by Eiwa System Management and contains several diagrams related to agile project management concepts.Read less
株式会社マジカジャパンの羽生章洋が書いてるブログ:受託開発と商売と - livedoor Blog（ブログ）
厄年も明けた今、SIという商売から少し距離を置いて色んなことをやっています。そう言いながら、今週は沖縄に来て要件定義の講習とか、そんな話をやってたりもするんですが。 そうやって離れてみて感じる、SIあるいは受託開発というものについて感じることが色々とあるので、雑多に思いつくままに書いてみます。結論を先に書くと、やれること一杯あるし明るい未来は十分あるよ、です。 さて、そういう立場で世の中を見ると、いやいや結構まだまだ売れる商品がたくさんあります。ネットを挟んだあちら側とこちら側なんて話も一時期流行りましたけど、こちら側、例えば食品なんかでも面白いように売れる商品があります。こういうのは売るのが楽しいです。お客様が目の前で喜んでくれますし。他にも色々と改めて感じ入ることがいっぱいです。そういうのは、やっぱり元の商材がいいんです。良い商品というものについて、私なりに最近パラメータが見えつつあり
どのクラウドが受託に向いているか？ Javaに未来はない、インフラ担当にも未来はないのか ～ クラウドごった煮パネルディスカッション（PaaS編 後編）
どのクラウドが受託に向いているか？ Javaに未来はない、インフラ担当にも未来はないのか ～ クラウドごった煮パネルディスカッション（PaaS編 後編） 国内にあるクラウドのユーザーコミュニティに集まってもらい、ディスカッションを行う日本で初めてのイベント「クラウドごった煮」が、昨年末12月11日に開催されました。Windows Azureのユーザー会（Japan Windows Azure User Group、JAZ）の人たちが中心になり、つてをたどってほかのクラウドのユーザー会などに呼びかけて実現したものです。 （この記事は「Google App Engineは敷居が高いのがメリット？ セールスフォースは開発生産性が高いが制限にも苦しむ ～ クラウドごった煮パネルディスカッション（PaaS編 前編）」の続きです） Javaに未来はない？ 新野 PaaSの場合は言語とデータベースが決ま
Google App Engineは敷居が高いのがメリット？ セールスフォースは開発生産性が高いが制限にも苦しむ ～ クラウドごった煮パネルディスカッション（PaaS編 前編）
Google App Engineは敷居が高いのがメリット？ セールスフォースは開発生産性が高いが制限にも苦しむ ～ クラウドごった煮パネルディスカッション（PaaS編 前編） 国内にあるクラウドのユーザーコミュニティに集まってもらい、ディスカッションを行う日本で初めてのイベント「クラウドごった煮」が、昨年末12月11日に開催されました。Windows Azureのユーザー会（Japan Windows Azure User Group、JAZ）の人たちが中心になり、つてをたどってほかのクラウドのユーザー会などに呼びかけて実現したものです。 前回のIaaS編に続き、この記事ではPaaS（Platform as a Service）の機能を提供する3つのクラウド、Google App Engine（GAE）、Heroku、Salesforce.com（SFDC）のコミュニティ代表3人のパネル
SIは面白くないけどエンタープライズは面白い - きしだのはてな
ここんところ、SIという業態はもうダメという話になってます。 で、エンタープライズ(=企業向けシステム)というのは、SIという業態で開発されるので、エンタープライズ=SIという前提で、企業向けシステムは面白くないという話になっています。 そこから、企業向けアプリは面白くないからサービスを作りましょう、という流れになって、GREEやDeNAなどに人材が流れてます。 実際は、サービスや企業向けというアプリケーションの種類と、SIや内製、パッケージという構築側の業態は独立なので、別に語るべきです。 たとえば、このインタビューを見ると、ゲーム業界もSI化していて、面白くなくなっていそうなことが伺えます。 稲船敬二氏は，何を思い，何を考え，何を目指してカプコンを辞めていくのか。渦中の氏に直撃インタビュー また、GREEやDeNAが提供するゲームは急激に大規模化していて、おそらくSI形態での開発が増え
エンタープライズ開発者が負け組として軽蔑される日本のSI業界って - 達人プログラマーを目指して
本ブログの記事に対して多くの皆さんからいただいた意見を総合すると、技術力のあるトッププログラマーにとって現状の日本のSI業界での仕事というのは、働き甲斐のない、魅力の少ない仕事として認識されているという残念な事実を思い知らされます。 オブジェクト指向の基本すらいまだにきちんと使いこなせない開発の現場 技術について勉強した知識をほとんど活用できないし評価もされない 無駄なドキュメント作成などに対する膨大な単純作業を強いられる いわゆる3K職場と言われるような過酷な労働と低い賃金 20年以上も前の仕事の進め方からあまり進歩が見られない 多重下請け構造によりユーザーに直接価値を提案するような仕事が難しい 多くの業務アプリケーション開発現場における体験を通して、以上のようなことが語られているということを考えれば、「業務アプリケーションのプログラマーは負け組だ」という意見が出てくることも当然のことか
アジャイル開発を前提とした受託開発 - プログラマの思索
永和システムマネジメントさんがアジャイル開発を前提とした新しい契約形態での受託開発サービスを発表していた記事があったのでメモ。 【元ネタ】 新しい契約形態での受託開発サービス ｜ 永和システムマネジメント プライベートセミナー『アジャイルに適したまったく新しい契約形態での受託開発サービス トライアルのご紹介』(2010/11/24) ? 株式会社永和システムマネジメント コンサルティングセンター 永和システムマネジメントの新しい受託契約がすごく面白い - ただのにっき(2010-11-11) WEB技術者の事業貢献度をもっと高めたい - GoTheDistance 受託開発の契約をアジャイル開発を前提とした形態にしてSIビジネスする発想はとても興味深い。 責任者は木下史彦さんと公開されていて、XP祭り関西などで何度もお話を聞いていたから、なるほどと思った。 SW開発が製造業と異なる収益構造
エンジニアを幸福にしないヤフーというシステム - 武蔵野日記
@nokunoさんのYahoo! JAPANを退職しましたという記事を読む。いまはタイトルに「翻訳」と書いてあるので紛らわしくないが、最初は「すわ id:nokuno さんがとうとう辞めたか?!」と釣られたものである (笑) 内容を読んでみると「まあ、そうだろう」という感じで、そんなに目新しいことが書いてあるわけではない (が、Yahoo! JAPAN の労働環境について知らない人が読むと「え、Yahoo! ってそんなところだったの??」とびっくりするかも)。著者も断っているが、これはアメリカの Yahoo! のことではなく、日本の Yahoo! JAPAN のことであり、Yahoo! JAPAN は外資系の会社ではなくコテコテの日本企業である (それが悪いと思うかよいと思うかは人次第)。 (2010-10-31 追記) Yahoo! JAPAN の環境がそんなによくないのは My New
アジャイルソフトウェア開発宣言
私たちはソフトウェア開発を実践あるいは実践の手助けをする ことによって、よりよい開発方法を見つけだそうとしている。 この活動を通して、私たちは以下の価値に至った。 プロセスとツールよりも個人と対話に。 包括的なドキュメントよりも動くソフトウェアに。 契約交渉よりも顧客との協調に。 計画に従うことよりも変化への対応に。 すなわち、左側に書かれたことがらに価値をおきながらも、 私たちは右側に書かれたことがらにより価値をおく。 Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler
アジャイル開発と要件管理 - プログラマの思索
要求や要件管理に関する本「要求開発と要求管理―顧客の声を引き出すには」「成功する要求仕様 失敗する要求仕様」を読んで、アジャイル開発との関係についてメモ。 【1】IBMでは、「要求」と「要件」の言葉を意識的に使い分けていると聞いた。 「要求」とは、ユーザの生の要望。粒度が荒く、MECEでもない。 「要件」とは、SIが要求を咀嚼して、顧客が分かるレベルの要望にしたもの。 「要件」には3種類あると言う。 一つ目は、ユーザ企業の経営層の観点から見る事業要件。ビジネス要件とも言われる。 2つ目は、ユーザ企業の現場層の観点から見る業務要件。顧客の実際の業務フローのレベルに相当する。 3つ目は、システムの観点から見た機能要件。非機能要件は、性能や信頼性などに関わる要件として区別される。 我々技術者が見る要件は、システム要件に相当する。 しかし、顧客と話す場合、業務要件でなければ会話ができない。 更に、
Agileなプロセスと受託開発は本当に相性が悪いのか？
アジャイルって受託開発との相性が最悪な気がするより。釣りっぽい記事な気もするんだけど。 SIerから見たアジャイル 工程の分断が絶対許されないから、上流工程と下流工程を別会社が担当する今の日本の受託開発業との相性は最悪だね。自分たちで全部やれる人材が揃ってないといけない上に、コミュニケーションを綿密にとらないと成果物がグダグダになりそうだから、人月との相性も悪い。 要件まとめてぽーんと丸投げしたほうがSIerとしては美味しいわけだから、なんでこんな苦労を別にしなくちゃならないの的な話になってる所がいっぱいいそうなんだけど、どうだろう。アジャイル導入って自己否定なんじゃないのかしら。だからやりたくても出来ないんだね、これ。 今の日本のSIerのモデルは“まだ"建設業みたいな多重階層の構造であることは間違いない。 収益性については、一次受けのSIerは少ない要員で沢山のプロジェクトを外注使って
アジャイルって受託開発との相性が最悪な気がする - GoTheDistance
全くもって、その通りだなぁと思った。 初期段階ですべての意志決定をしても、問題はコードを書き始めてから表れるのです。そして終わりに近い時点で判断する方が、より正しい判断ができるはずです。ですから、できるだけ意志決定は先延ばしにして、正しい意志決定をしようとするのがアジャイルのやり方です。 「有能な人がコードを書くべき」「意志決定はできるだけ先延ばし」「契約を変えるのは難しい」アジャイルの専門家の答え － Publickey ｢ウオーターフォールとは｣のラベル貼りの議論になるとめんどくさいから、とりあえず｢初期段階ですべての意志決定をしようとするシステム開発の進め方｣という定義で話を進めたいと思います。 滝 ｢要件定義｣→｢設計｣→｢実装｣→｢テスト｣という一連の流れがあって、ウオーターフォールなるものは前工程が100になるまでひたすらそこでPDCAを回します。100になると言う意味は、ソフ
「個別案件」ではプログラミングの可能性を生かせない - 設計者の発言
ソフト開発企業に所属するプログラマが十年一日のように「個別案件」を相手にしているというのは、マイケル･ジャクソンが盛り場あたりで毎晩「流し」で日銭を稼いでいるようなものだ。もったいない。そんなやり方ではマイケルやプログラミングの可能性がもたらすさまざまな効果を享受できない。 仮にあるソフト会社が「ロボットの振る舞いのカスタマイズサービス」を提供しているとしよう。顧客の要望がそれぞれ微妙に違うとすれば、彼らはまず個々の要望を様式化して、その内容をあるソフトウエアに読ませるだろう。そうすればそのソフトウエアが個々の要望にしたがってロボットを動かしてくれるからだ。そんなソフトウエア、すなわち「ハードウエアドライバ」をあらかじめプログラミングしておくのが、その事業で効率的に稼いでゆくための賢いやり方というものだ。 ところが、現在の「基幹業務支援システム開発事業」の分野では、あらかじめドライバをプロ
SIerの解体と再生 - ひがやすを技術ブログ
ござ先輩のところで、SIer涙目な状態が解説されてますね。 最近SIerがだいぶヤバくなっている件 - GoTheDistance 書いていることはだいたいあっているんじゃないかと思います。 じゃ、SIerは、どうやれば生き残ることができるのか。 「今の体制のまま生き残る必要はないんじゃないの」というのが私の考えです。多重下請け構造こそ、SI業界の最大の問題点なわけだから、「ゼネコン型SIビジネスが崩壊する」のは、悪い話じゃない。 もちろん、会社がなくなったりすると職がなくなり困る人も出てくるわけですが、問題のある業界を残しておくより、一度解体し、新たにやり直したほうがいいと思います。 だって、実際に物を作れないような人たちが設計するなんて、おかしいし、効率悪いもの。 効率の悪いことをしている人が淘汰されるのは当然の話です。 だったら、なぜこれまでゼネコン型SIビジネスが生き延びてこれたの
システム開発に欠かせない契約の基礎知識まとめ - GoTheDistance
先日識者の方に色々教わったのでメモっておきます。知ってそうで知らない、元々よくわからない、そういう方に向けてまとめてみました。 僕がSIにいた頃は大抵｢基本契約｣と｢個別覚書｣ってのがありました。納期とかお金とかそういうのは個別覚書に書かれたりしていました。 開発の契約体系 ｢仕様策定〜開発まで｣と｢保守運用｣で別契約にすることが多い。 ｢仕様策定フェーズ｣で1つの契約にして、別に新しく契約を締結しなおせるほうが望ましい。リスクが低減できる。 仕様策定までは準委任、開発は請負、保守運用は準委任という契約が多い。 ちなみに準委任は｢事務作業の代行｣という意味合い。委任は｢法的効力がある作業｣の代行。サムライビジネスは後者が多い。 別に運用が事務作業とイコールじゃないけど、成果を問わないタイプの契約の場合は役務提供という位置づけになる。 かといって契約で｢僕らのコンサル案を僕らが実施し成果が出
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://chikura.fprog.com/index.php?UID=1186110219
dfltweb1.onamae.com – このドメインはお名前.comで取得されています。
dfltweb1.onamae.com – このドメインはお名前.comで取得されています。
dfltweb1.onamae.com – このドメインはお名前.comで取得されています。
dfltweb1.onamae.com – このドメインはお名前.comで取得されています。