技術が確立されたと思い込む愚 - masayang's diary
元GE技術者・菊地洋一さん講演 「命はほんとうに輝いている」の一部をパロってみた。 いろいろやってきたわけですけれども、実際に働いてみますと、システム開発の技術というのは全然確立していなかった。もう詳しい話は技術的な専門的な話になりますのでいいませんけれど、とにかくハチャメチャなんですね、施工で。施工というかシステムを造っていく開発の段階で。開発のミスが出るということは人間のやっていることですから、よく起こることですけれども、問題なのは設計そのものも十分検討されていない、いいかげんな感じで開発が進められていました。ですか ら開発中にしょっちゅう変更がある、そのことにもびっくりしましたけれども、送られてくるモジュールのインターフェースがあちこちぶつかっていたり、そういうことにもびっくりしました。自分でチェックしてみて余りにもぶつかっているので、びっくりしましたけれども、とにかく確立された技術
今日のシステム延命は向こう5年の技術的負債（しかも高金利雪だるま） - masayang's diary
相変わらずクラウド活用とAgile開発を売り歩く日々なわけだが。 企業のシステム投資周期は必ずしも景気循環周期とは同期してくれない。償却が迫り、老朽化が目立っているシステムのその後を検討する際に、外部経済環境が最悪で動くに動けない、という状況に陥るのは珍しい話ではない。 だからといって現行システムの延命を図ることが正解なのだろうか。 今延命を図ろうとしているシステムは少なくとも5年前の事業戦略・事業設計・システム設計を基準にしているわけだ。当時の事業戦略が今も有効である可能性は高くはないだろう。そこを無理して延命すれば、5年後に改修ないしは再構築が待っている確率は極めて高くなる。 その場合(5年前のシステムを延命して5年待った後): 基準となる事業戦略は10年前のもの。 それを継承する事業設計も10年前のもの。 システムとして具現化した基盤もアプリも10年前の設計・技術。 これらを熟知して
日経ITProの記事にケチつけておく - masayang's diary
日経ITPro: アジャイルはウォーターフォールよりも難しい 何を持って簡単・困難を定義するのかがわからないけど、「アジャイルはウォーターフォールよりもごまかすのが難しい」というのであれば、その通りだろう。 そもそもアジャイルは、大規模プロジェクトを想定していないし、請負契約が多い国内のプロジェクトは、要求の増加に歯止めが利きにくいアジャイルと相性が悪い。 そもそも大規模プロジェクトを想定して生まれた手法は存在しないわけで。 ウォーターフォールは他に選択肢がなかったために大規模に適用されてきたけど、それが適切だったかはなんとも言えない。失敗しても他に選択肢がないんだから「ウォータフォールが悪い」って言えなかったしね。 ただ、最近は大規模でのAgile事例は増えてきている。日本ではまだ少ない、というところでしょ。 「要求の増加に歯止めが利きにくいアジャイル」というのも変だよね。 当初の一欄に
Agileの現状に対する漠然とした不安 - masayang's diary
去年のAgile2009では漠然としか感じていなかったのだけど、今年のAgile2010ではその不安がより確実になってきた。去年はCode Smellのたとえで言えば「どこかでタバコ吸ってる人がいるな」くらいの感覚だったのが、今年は「同じ部屋でタバコ吸ってるバカがいるぞ」、みたいな。 ただしCode Smellみたいなものなので、何かおかしいぞ、という程度の感覚でしかないのも事実である。 その漠然とした不安を抱かせる要因は何かというと「Agileのコモディティ化」なのであります。 自己紹介に「Certified Scrum Masterです」と説明を入れたり、「アナーターハーCSMデースカァー？」みたいな質問をしてきたりする人が今年は昨年よりも確実に目立つ。 あるいは...「わが社は自分では作りません。計画管理と実装は、コントラクタ(契約ベースで請け負う別会社)に任せてます。」みたいな丸投
設計書の意味をもう一度考えてみろよ - masayang's diary
katzchangのつぶやきで、オブジェクト指向開発を理解した開発者に、設計書は不要という両記事を知る。書かれていることは特に目新しくない。前から言われていることだし別にオブジェクト指向に限った話でもなかろう。→The Source Code Is The Design 2009年2月23日に書いた記事より再掲: 今更ながら「設計ができる」人に問いかける その「設計書」なるもので、本当にコード書けるの？ 「書ける『はず』」ってのは「書ける」のとは違うよ。 だが、はてぶに寄せられた意見にはなんだかな〜と思わせるものも目立つ。 これは一緒に仕事したくない人だ。UMLも書きたくないのかな →UMLからコード起こせるの？ Really? この記事は酷い。この著者は10年間で何をしてきたのか？偏った開発経験しかしていない気の毒な開発者。 →ただしい開発現場で経験を積んできたようにしか見えないが...
制度会計とAgile開発・"Stupid Finance team!" - masayang's diary
Scrumのメーリングリストで興味深いネタがあがっていた。 まず質問した人 our Finance team has instructed us to code all of our hours to one of the following categories: Analysis, Design, Build, Test, Post Launch Support. 弊社の経理チームが、私たち開発チームの勤務時間を「分析」「設計」「開発」「テスト」「サポート保守」に区分して報告するように要求してきました。 Obviously, this feels pretty non-agile. The response to questions on this has been that this coding follows Generally Acceptable Accounting Pri
Agile2009二日目 - masayang's diary
本日聞いてきたお話。 基調講演: I Come to Bury Agile, �Not to Praise It(PowerPoint資料) シェークスピアを読んでないと理解できない題名。 当然俺はなんのことかわからなかった。 「Agileを葬る」といっても、もうAgileが終わりということではない。 「Agileが普通になる」という宣言。 How the FBI learned to catch bad guys one iteration at a time 政府系受託開発のお話。 日本でいうSI屋さん。 お客はFBI。 FBIにおけるシステム開発の失敗事例は色々有名らしい。 そのFBIシステム部門がAgile開発を受け入れることで体質が変わりつつある、というお話。 二週間の周回開発。 計画ポーカー採用。 ペアプログラミング。 継続的統合。 一方で、CMMI Level-3は満たしてい
Rintaさんの質問に答える - masayang's diary
http://d.hatena.ne.jp/Rinta/20070814#p1 長いので引用はしないよ。質問は4点あるようで Agileはプロジェクト管理の失敗をケアできるものなの？ 少人数のイタレーションでプロジェクトをまわしてくAgileでは大規模に対応できないのでは？ テストベンチはAgileだけの特徴ではないよね？ 設計書なしで保守をどうするの？ Agileはプロジェクト管理の失敗をケアできるものなの？ 次の質問への答が参考になるはず。失敗とはなにか？も参照のこと。 少人数のイタレーションでプロジェクトをまわしてくAgileでは大規模に対応できないのでは？ ウォーターフォールと同じものをAgile開発に期待するのなら、その通り。少人数でまわせば時間がかかるようになるだけ。 ここでいう「同じもの」というのは 全く使われない要件（フィーチャ） ほとんど使われない要件（フィーチャ） 使わ
おじさんに求められる資質 - masayang's diary
自分の知らない事象を、自分の持っている知識の範囲内に置換えて考えるのは、割と普通の事である。 「あ、それはメインフレーム時代で言う○○みたいなことだね」 「なるほど。富山の薬売りみたいな事業構造だね」 だけど、そういう縮退した状態で意思決定しちゃいかんと思うんだな。 特に否定しちゃうのはよろしくない。 「あ、それはメインフレーム時代で言う○○みたいなことだな。じゃぁ、やっちゃだめだ。」 「なるほど。富山の薬売りみたいな事業構造だな。じゃぁ、やっちゃだめだ。」 こういう判断で失われるものは二つ。 新事業や技術革新の機会。 その判断をした人に対する畏敬の念。(存在していれば、の話だが) 若手が持ってきた提案を、昔の知識に置換えて考えざるを得ない状況にあることを発見したら、おじさんが取れる道は二つしかない。 勉強する。 引退する。 自分も気をつけよっと。
開発現場におけるワークシェア - masayang's diary
フジサンケイ: 日本型ワークシェア、政労使合意へ 不協和音も痛み分け 仕事を分け合い、雇用を維持するワークシェアリングの導入に向けて、政府と日本経団連、連合の政労使３者が２３日に合意する見通しとなった。 ウォーターフォール型開発現場は、もう10年以上ワークシェアリングを実施しているわけだが... Aが穴を掘る。 Bがそれに落ちる。 CはBが落ちたままの穴を埋めようとする。 DがBを助けろと指示を出す。 B救出のために大勢の人が借り出される。 そいつらがまた穴を掘り出す。 そこに落ち込む人がたくさん出てくる。 その過程が非効率なので標準化しろという奴がでてくる。 大勢の人が標準化を検討する。 たくさんの人が穴を効率的に掘って、効率的に落ちて、効率的に助け出せるようになったか監視する人達の職が生み出される... 穴を掘って埋める過程と、それらを監視するという非生産的な作業が日常化する。 必要な
Agile失敗パターン三部作 - masayang's diary
Allan Kelly氏の「Agile失敗三部作」を適当に日本語訳してみた。 Agileで失敗する時 続・Agileでうまくいかないとき まだあった・Agileでうまくいかないとき 読めばわかってもらえると思うけど、「Agileだからうまくいかない」というわけではない。 未知の技術を採用したり、未知の領域のアプリを開発したりするような場合には、プロジェクトはそれなりの(把握できない)リスクを抱える事になる。だとしても、プロジェクト終盤で問題が発覚することが多いウォーターフォール型開発よりは、比較的早い段階で問題を把握できるAgileの方が有利ではある。ただしそれも、「問題が起きている」ということを把握できる実力がAgileチームにあれば、の話である。 二番目と三番目は、それぞれAgile計画管理、そしてAgile開発手法に特化した話だが、ぎゅっと圧縮すれば「経験がなければ問題が起きている事
フィーチャで考えると見えてなかったものが見えてくる - masayang's diary
その１ 最近Agileに切り替えたとあるプロジェクトのリーダーは、こんな事を語ってくれた。 以前は進捗会議の話題が「納期」や「予算」に話が偏る傾向があった。 切替後は、開発されたフィーチャやこれから着手するフィーチャについて議論されるようになった。 →いかに中身を見ないでお金や納期の話をしていたか、ということが浮き彫りになった。 その２ Agile採用を検討しているプロジェクトのリーダー曰く： フィーチャで考えるのは難しい。 ユーザがどんなフィーチャを欲しがっているのか、意外にわかってない。 →フィーチャで考えるという事は、受入れテストの必要条件を考えているのに等しい。そこを曖昧にしたまま包括的に記述してしまう従来型の要求定義だと、受入れテスト〜納品の段階で非常にややこしいことになる。フィーチャで考えるのは大変だが、プロジェクト最終段階でのゴタゴタを前取りしていると思った方が良い。
Agileで失敗する時 - masayang's diary
ちょっと古いけど、こんな記事があったので訳してみた。 Allan's Blog: Failures in Agile process?(Agileでの失敗?) ACCU*1の会議でよく受ける質問に「Agile開発の欠点は？」「Agileでの失敗はどんな感じなの？」というのがある。 一つ目の質問には答える事ができなかった。ただ、プロダクトオーナーに負担がかかりやすい、という問題点はあるかもしれない。通常はビジネスアナリスト、製品マネージャ、顧客、あるいは顧客窓口の人がプロダクトオーナーになるのだけど、とても負荷のかかる仕事だ。このあたりはJames Nobleが研究しているね。 プロダクトオーナーは本来の仕事をこなしつつ、Agileチームの相手をすることになる。Agile開発チームの生産性があがってくれば、チームはプロダクトオーナーに「あれはどうするの？」「これはどうするの？」と色々と質問す
要件定義とか設計とか真面目に考えてみよう - masayang's diary
画面設計とか外部設計とか、もうやめようよに対し色々意見をいただいた。感謝。 要点繰り返し 自分は「画面の見本を使ってフィーチャを抽出する」というやり方に反対はしてない。 ただし、その「見本」が妙に具体的かつ詳細になってくると、本来フィーチャではないものまでフィーチャとして取り出してしまい、後続の工数が膨れちゃうよ、ということを警告しているのである。 「妙に具体的かつ詳細な見本」ってのは、世の人がいう「画面設計書」でしょ？ なのでそんなのはやめちゃえ、ということ。 以下、頂いた意見に対しての感想などを。 家やマンションに例えない 「家やマンションは最初に完成像をみてもらい納得してもらう必要がある。システム開発も同じだ。」みたいな意見があった。 画面の見本があれば完成像を想像しやすくはなるけど、実際に動く見本があれば想像する必要はなくなる。 むしろ、操作することで「紙芝居」ではわからなかった要
画面設計とか外部設計とか、もうやめようよ - masayang's diary
昨日は特徴(Feature)、粗筋(Story)、脚本(Scenario)でちょいと言及した「Feature, Story, Scenarioがごっちゃになりかけている」プロジェクトの人達とお話しする機会があった。 よくよく見ると、FeatureとFunctionとがごっちゃになっていた。 つまり、要件分析の段階で実装のことを考えていたのである。 なぜ、そうなったのだろう？ 画面から要件分析をすると、こうなる どうやら要件分析する前の段階で「コンサルタント」の人達が、画面を使ってお客さんと「要件定義」をしていたらしい。 「この画面でこういうデータを入力すると、こんな画面に遷移します」みたいなやりとりがあったのだろう。 紙芝居感覚で交渉できるからわかりやすい。 だけど、先に画面を決めちゃうというのはいくつかの(そして時に致命的な)問題を抱えている。 実装をフィーチャとして捉える可能性。 例え
不況とマイクロマネージメントの相乗効果 - masayang's diary
昨年9月以来の日本出張。 システム開発業界にも冷たい風が吹きまくりなのを実感。 前回出張時より確実に状況はまずくなっている。 マイクロマネージメントは状況を悪化させる その「まずい」状況をよりまずくさせている要因がある。 マイクロマネージメントだ！ 利益が減っていく中で細々とした管理を徹底すると、利益はさらに低下してしまうか、赤字に陥る。 一方、世の中には「マイクロマネージメントで赤字が減らせる」と思っている現場があるらしい。*1 正しくは「マイクロマネージメントで原価が膨れ上がったプロジェクトに対してもお金を払ってくれる太っ腹な*2お客さんがいた*3」というだけのこと。 売上が減ると...現場は悲惨なことになる。 あなたの現場はマイクロマネージメント？ 以下に該当する項目が多ければ多いほど、あなたの現場はマイクロマネージメントだと思ってよい。 パワーポイントのマスタースライドは所定のもの
Rinse, wash, and repeat! - masayang's diary
今回もAgile導入のお手伝いやらAgile開発のススメやらで来日。 ゆっくりだけど確実にAgile開発は普及しつつある。 だけど...組織の体質を変えるのはそんなに簡単ではない。 それを実感した出来事。 なぜ文書整備から入るのか？ 今回お話を聞いたプロジェクトのうち二つで、こんな悩みを相談された。 「Agileでは不要な分書類を作ってしまう。画面設計書、画面遷移図、テスト計画書など」 よくよく理由を聞くとおもしろいことがわかった。 それらの文書類を作る人達は、「なぜ、その文書を作るのか」という理由をわかってない可能性があるのだ。 もっと具体的に言うと、「これまでの開発手順では、そういう文書を作ることになっていたから」となる。 つまり、開発手順のマニュアル化による副作用だ。 対策 マニュアル化＝考えないことの推奨 つまり、その弊害を取り除くには「考える」ようにするしかない。 実践（プラクテ
Agileによる再構築 - masayang's diary
「レガシーシステムとは？」と訊かれたら、自分は迷わず「Agileで作られてないシステム」と答える。 Java(servlet直呼び出し)で書かれた古いシステムをRailsで書き直したことがあるけど、非常にコンパクトなコードになってしまった。むしろ周囲が「これで旧システムと互換性あるの？」と心配したくらいである。 で、同じような案件がないか調べていたら次の短論文を発見。 An Agile Approach to a Legacy System(PDF、英語) 例によって無断適当に邦訳。長文注意。 An Agile Approach to a Legacy System Chris Stevenson and Andy Pols 概要: 本稿では小規模かつ自発的に形成されたXPチームがいかにしてぐちゃぐちゃな問題を抱えたシステムをきれいにしていったかを解説する。我々はレガシーアプリケーションを
Agileが根付かないもう一つの理由 - masayang's diary
「プロジェクト失敗率とリスク」の続き。 id:suikyojinさんからトラックバックをいただいた。 大規模Agileの失敗率は驚異的に低い? そもそも、大規模プロジェクトの失敗率って、ものすごく高くて、70%とか80%とかいった数字を見たことがある。基準が同じとはかぎらないので、断定できないが……。 そうなのです。「失敗」の定義は意外と難しい。随分前に訳した「失敗とは何か」では CHAOSレポートによれば、成功するプロジェクトの割合はたったの34%だそうな。 Standish GroupのCHAOS reportは、長年に渡ってドブに捨てられてきた何十億ドルにもなるIT関係プロジェクトの話を延々と述べている。34％の成功率っていうのは実は改善された数値で、2001年の調査では28％だったんだな。 とのこと。失敗率66%。ただし、この記事でMartin Fowler氏は 納期が遅れたとか予
SI屋と顧客の未来 - masayang's diary
id:zakincoさんから、トラックバック「SIerにキンタマつかまれてるユーザー企業はSIerと心中するしかないね」をいただく。 どっちにしろモラルの無いSIerに未来は無い。だけど、会社としての未来は無いと分かっていても、社員を使い捨てにして自分達の退職金だけはせしめようってお偉方が居るSIerには気をつけましょう。 利益追求を求められる会社組織としてみれば、キンタマつかんだSI屋ってのは、実は「モラルのある」行動をとってきたわけですよ。 顧客からは「もっと安くしろ」といわれ 株主からは「もっと利益をあげよ」といわれ その妥協点として、「過去のソフトウェア資産を活用する」戦術が選ばれたわけ。 ところが、過去のソフトウェア資産なんていうのは実はCOBOL時代のデータ構造を引き継いだ時代遅れな代物。だんだん保守効率は低下し、ちょっとした修正でも偉く工数がかかるようになってしまう。かといっ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
