特徴(Feature)、粗筋(Story)、脚本(Scenario) - masayang's diary
Agile開発に限らないが、システム*1業界用語ってカタカナ*2表記が多すぎる。 「いや、元々が舶来なので日本語では微妙に表現できないのですよ」という人もいるかもしれない。 でも、この「カタカナ表記のまま」ってのが意思決定者の判断を誤らせたり、新規参入者に対する壁を高くしたりしている可能性は排除できないのではないかな。 今日、この後打ち合わせが入ってるプロジェクト*3もFeature、Story、Scenarioがごっちゃになりかけている。 なんとかわかりやすく表現できないかと悩み中。 以下、自分の案。名訳があったら、是非教えていただきたい。 Feature=特徴 自分は今までFeatureを「機能」と紹介してきた。 同じ「機能」でも開発者が対象にするのはFunctionで、利用者が対象にするのはFeatureですよ、と説明してきた。 でも、安井さんと角谷さんの本29頁を読むと「特徴」がい
生産性を考える - masayang's diary
ITPro: ［OSC島根］「RubyでCOBOL技術者は復活する」---松江市の基幹システム開発で得られた実感 RubyでCOBOL技術者は復活する？ 本当かな？ 以下、わりと長文なので注意。 Rubyの生産性について，吉岡氏は「COBOLやC/Sシステムとほぼ同じだった」とする。全体の30％を占める設計工程はCOBOLでもRubuyでも同じ。全体の40％を占める製造工程は4分の3の工数で開発できた。全体の30％であるテスト工程は同じ。実際に開発する前は，Railsのテスト自動化機能によりテストの工数を削減できるのではないかと期待していたが，自動テスト機能は，プログラムの状態やデータベースの状態が同じでなければ使えないことなどにより削減できなかった。繰り返し型の開発で威力を発揮する自動テスト機能も，今回の開発はウォータフォール型で1回限りの開発のため工数削減にはつながらなかった。しかし全
Rools vs Ruleby - masayang's diary
Railsでちょいと大きめなシステムを開発する事になった。既存の焼き直し。100万行？まじっすか？ 既存システムの大半は条件判断(いわゆる大量のif文)で成り立っているみたい。 ならばそこをルールエンジンに外出ししてやれば本体は小さくなるのではないか。 と思ってRubyで動くルールエンジンを調べてみた。候補に残ったのは二つ。 Rools Ruleby Roolsはルール記述をテーブルやyamlに入れておけるみたいなんだけど、説明書があまり整備されてなくてやり方がわからん。 Rulebyはルール記述をyamlに入れておけるし、Rubyコード中に記述するよりもすっきりして良さげ。 ルールエンジンは昔々エキスパートエンジンとかなんとか呼ばれていた頃もあって商用製品が中心だったけど、いつの間にかOpenRulesみたいなオープンソースものが成長していたのね。時代の流れを感じる。 JSR 94 JS
迷ったら狩野さん！...狩野分析法による優先度付け - masayangの日記（ピスト通勤他
追記 id:discypusさんから、狩野分析法の出典に関するコメントをいただきました。 狩野法って、 狩野 紀昭 氏 http://www.sangakuplaza.jp/page/134499 の http://www.yahoo-vi.co.jp/method/b10.html の手法かと 思うのですが、合ってますでしょうか？ まさにこれですね。http://www.yahoo-vi.co.jp/method/b10.html にある日本語のほうがすっきりしてます。 お詫び 分析用配列に誤りがありました。修正してあります。 要旨 先日受講したScrum Product Owner Trainingで印象に残った分析法を紹介。 Agile開発では「優先度順に要件（フィーチャ）を開発していく」のが基本だが、いざ優先度をつけようにも話は簡単ではない。発注側に強力な指導者がいてその人が独裁的
安物買いの銭失い...開発をアウトソースしてはいけないという事例 - masayang's diary
機内で読んだWall Street Journal（紙媒体版）2007年12月7日金曜日A1面の記事より Boeing Scrambles to Repair Problems With New Plane 要旨 次期旅客機787Dreamlinerの開発が遅れている 最大の理由は自社開発ではなく、アウトソース活用を試みたこと 機体の設計開発をアウトソースしたのはボーイング91年の歴史で初の試み アウトソースした理由 機体素材に炭素繊維を使う787は基礎研究だけで大きな投資が必要だった 開発投資額は100億ドル(1兆1000億円)に達する 開発投資を抑えるため、部品供給メーカ達に設計開発を委託（アウトソース） 発生した問題 多国にまたがるアウトソース 言語の壁 米国では想定していなかった各種規制 孫請けに仕事を分散させることによるオーバーヘッド 同じ企業なら会って話せば済むのに、大量の文書
中央集権的な集団意思決定体制がよろしくないのではなかろうか - masayang's diary
アメリカにも日本のSI屋のような業態は存在する。営業が御用聞きで要件を聞き出し、きっちりと開発計画と見積もりを立ててから契約。そして開発は外注、という流れである。 そんな仕事をしている米国IBMの営業担当から聞いた話。 彼が担当している顧客の中には、日本企業の米国支社もある。東証一部上場の、日本人なら誰でも知っている(非IT系の)会社だ。そして、米国支社の経営陣と上級管理職は全て日本からの出向社員が固めているそうな。まあ、典型的な日系企業米国支社の体制だわな。 その会社が使っているシステムのいくつかが、今年から制度変更となった夏時間・冬時間切り替えのための改造が必要となっていた。 というのを、開発とテスト期間を充分に見越した１年以上前から顧客に提案していたのだが、米国支社からの返事は常に「日本本社からの回答待ち」。米国支社の「社長」とか「上級副社長」とかには意思決定の権限がないのである。こ
保身という反Agileパターン - masayang's diary
日本にいる開発部隊にAgile開発の指導をしている。いろいろ苦労はしているけど、まあなんとか動き出してきたところ。が、問題発生。 ラップトップ持ち出し禁止 その会社は社内規定で「ラップトップの持ち出し禁止」となっているらしい。なので、イタレーション毎にでてくるプログラムをお客さんの所に持っていく事ができない。彼らがとろうとした手段は「画面を印刷してお客さんの所に持っていく」というもの。 なんかバカらしくなってきたので、その社内規定を破る事を勧めた。 保身につきあう必要はない おそらくは、ラップトップ紛失→顧客情報流出、みたいな不祥事を気にしてラップトップ持ち出し禁止などというルールを作った輩がいるのであろう。そいつは「ラップトップ持ち出し禁止にすることで発生する損失」を考えた事があるのだろうか？ おそらくは「何か問題がおきて、俺様が面倒なことに関わる羽目になるのは嫌だから、とりあえずラップ
ウォーターフォール開発＋工程別入札制度＝税金の無駄遣い - masayang's diary
社保庁、年金システム３億円随意契約 入札の原則決定後 随意契約されたのは、社保庁の年金記録システムの基盤部分で使うデータベースソフトなどの製品を選ぶ作業。基盤の基本設計を昨年８月に約２０億円で受注した大手システム会社が約３億円で請け負った。 他の公共系システム同様、社保庁のシステムも工程別で業者を決めているのね。 工程別で入札させることで得られる透明性 工程別で業者が変わることによるオーバーヘッド[*1] 「透明性」なんてのは、完成後に第三者機関が納品物を監査すれば済む話。でも、工程別で業者を変えることで発生する無駄は純粋な損失であり、返ってこない。公正さを求めるためには税金を無駄遣いしてもよい、ってことなのかね。アホくさい。 *1:そもそものウォーターフォールのオーバーヘッドは言うまでもない
COBOL屋の呪縛 - masayang's diary
今回の日本出張ではいくつかのプロジェクトの状況をみてきた。で、思ったこと。 「COBOL時代のデータ構造を引きずることで、生産性や保守性が落ちている」 フラグだらけのマスター 本物のコードをだすわけにはいかないので、すごく簡略化した例で説明したい。あるシステムを利用できるユーザのマスターテーブルがあるのだけど、そいつには「なんちゃらサービス利用可否フラグ」みたいなのがたくさんついているのね。 この方式の問題は以下の通り。 テスト負荷 フラグがあるということはそれをチェックするif文があるということ。 if文があればテスト件数は最低２件は増える。 入れ子になれば、４件、８件...と増えていく。andやorでも同じ。 コードの冗長性 「あるユーザがサービスAを使えるか」を調べる処理と「あるユーザがサービスBを使えるか」を調べる処理はほぼ同様になることは明らか。 「サービスAを使えるユーザ」を調
お客さん側の問題 - masayang's diary
8時半まで仕事して、それから飲みに行ってきた。皆さん、当たり前のように9時10時まで残業しているそうで。なんだかなー。 発注側にも問題がある 今日の現場をみていて思ったのは、開発を発注する側の体質。お客さんのせいにするのは申し訳ないけど、もうちょっと戦略的に発注するべきじゃないかな。問題点は以下のとおり。 やたらと値切る 細かい 散々粘って発注しない 朝令暮改 「やたらと値切る」ってのは、とにかく「高い〜 安くしろ〜 高い〜 安くしろ〜」と文句をいうお客さん。費用対効果の観点がばっさりと欠如している。そのシステムでいくら儲けるのかを考えていない。同様に、いくらまで損したら中止するかという撤退戦略もない。[*1] 「○○億円投資して、N年かけてα%で回収する。損失が××万円になったら撤退する。」という基本戦略があれば、無理して値切る必要はないんだよ。そこを無理して値切るから、開発する側は開発
大規模ってなんだろう - masayang's diary
大規模ってなんだろう 責任者の数が多く，その責任範囲が曖昧． 管理職の数が多く，現場の人間が少ない． 会議の時間が長く，開発の時間が少ない． 1993年に当時Taligentで働いていたおっさんから教えてもらった小話。 日本とアメリカがエイト（９人乗りの手漕ぎ船）での競争をすることになった。 そしてアメリカは日本にあっさりと負けてしまった。 敗退でショックを受けた監督は全米から優秀なコンサルタントを招き、敗因を分析してもらった。 以下の事実が判明した。 日本は１名の音頭取りがいて、８人の漕ぎ手が働いている アメリカは５人の音頭取りがいて、漕ぎ手が４人しかいない アメリカチームは１年間かけて対策を立て、再び日本に勝負を挑んだ。 だが、またもあっさりと負けてしまった。 再びコンサルタントが呼ばれ、敗因が分析された。 以下の事実が分かった。 日本は１名の音頭取りがいて、８人の漕ぎ手が働いている
Agileは難しいのか？ - masayang's diary
「Agile開発は難しい（難しそうだ）」という意見を聞くことがある。「難しい」のは 政治的に難しい（社内ルールと合致しない） 営業上、難しい（道幅課金を顧客に納得させる必要がある） 技術上、難しい の３つに分類できるのだけど、ここでは「技術上難しいか」だけ書いてみたい。 Agileは「平均的な人達」のための技術 自分は「Agileは平均的な技術力を持った人達のための開発技術」だと思っている。 平均的というのは 要件分析や定義で平均的に抜けや誤りを発生させて 設計で平均的に抜けや誤りを発生させて 実装で平均的にバグを埋め込んで テストやデバッグでのバグ検知修正が平均的に下手 ということ。要は神でも天才でもない人達だ。自分ももちろんこの範囲に納まっている。 平均的な人達は平均的に間違いを犯す。 ソフトウェア開発においては、それらの間違いは「発覚が遅れるほど、傷が深くなる」のは周知の事実。 神で
Agile関係５つの誤解 - masayang's diary
リファラから辿って色々な人のブログを見ているのだけど、Agile（あるいはTDD）で誤解をしている人が少なくないと感じたので自分の思うことを書いてみる。なお、本日自転車でコケて頭を打っているので変な内容になるかもしれないがそこは笑って見逃して。あと、対象として考えているのはビジネス系のアプリケーション。ゲームや組み込みは自分の範疇外なので... TDDはテストコードを書く分生産性が落ちる 自分がAgileの営業（？）をしていても良く帰ってくる反応のひとつ。確かにテストコードを書くのは手間と時間がかかる。でも、書いてしまったテストコードを実行するのは比較的短時間で済む。一件あたり１秒かかったとしても、１０００件のテストをするのに１０００秒（１７分弱）しかかからない。これを人間が手でテストしていたら、この１０倍（３時間弱）〜１００倍（２８時間）はかかるはず。 テストコードを書く分生産性が落ちる
Rintaさんの質問に答える - masayang's diary
http://d.hatena.ne.jp/Rinta/20070814#p1 長いので引用はしないよ。質問は4点あるようで Agileはプロジェクト管理の失敗をケアできるものなの？ 少人数のイタレーションでプロジェクトをまわしてくAgileでは大規模に対応できないのでは？ テストベンチはAgileだけの特徴ではないよね？ 設計書なしで保守をどうするの？ Agileはプロジェクト管理の失敗をケアできるものなの？ 次の質問への答が参考になるはず。失敗とはなにか？も参照のこと。 少人数のイタレーションでプロジェクトをまわしてくAgileでは大規模に対応できないのでは？ ウォーターフォールと同じものをAgile開発に期待するのなら、その通り。少人数でまわせば時間がかかるようになるだけ。 ここでいう「同じもの」というのは 全く使われない要件（フィーチャ） ほとんど使われない要件（フィーチャ） 使わ
大規模Agileの生産性 - masayang's diary
大規模Agileの生産性の話を見つけた。QSM社のデータなので間もなく客観的数値が上がってくるであろうが 7チーム100名の並列SCRUM QSM社の生産性データベースの上位5%以内に入るのは確実 この領域に到達するのに２年しかかかってない
「それ、どうやってテストするの？」（続） - masayang's diary
http://d.hatena.ne.jp/JavaBlack/20070808/p1 ほとんどのまともなプログラマーなら，無意識のうちにそういうテスト可能／デバッグ可能なコードを書くことを心がけている．テスト／デバッグ不可能なコードを書く人というのは，まともなプログラマとは思えない． JavaBlackさんは「自分で何を作るか考えてコードを書く人」について語っているとみた。完成像を理解しているプログラマなら、「コードのあるべき姿」もわかっているからテスト機械化のハードルも低いだろう。 問題なのは下記のような分業状況。 何を作るかは考えるけどコードは書かない人（別名：設計担当） 何を作るか考えることは許されず、言われたとおりにコードを書く人（別名：開発担当） 設計担当はコードを書くことはない。書くのは設計書なる文書だけ。「その設計書、どうやってテストするの？」と聞いてみるがよい。答えに窮す
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
話が噛み合わない時 - masayang's diary