Hadoopは借りて使え - masayang's diary
NTTデータが公開したHadoop資料が話題になっている。ざっと読む限り、コード事例もあって参考になることは確か。読まない手はないだろう。 だけど、Hadoop環境を自前で構築することには私はあまり賛同できない。技術屋が勉強するため、というのなら話は別だけど、事業でHadoopを使うのならクラウド上のを借りることをお勧めする。 例えば1000台のクラスタを構築して、デイリーバッチ処理が5分で終わるようになった！ と喜ぶのも良いだろう。でも、残りの23時間55分はそのクラスタどうするのか？寝かせておくのであればROI評価は非常に低いものになるだろう。 かといってケチって5台のクラスタにしたらほぼ1日中稼動したのでROIは高くなりましたが処理時間短縮には至りませんでした、なんていうのも馬鹿げている。 じゃ、どこに最適点があるのか？ 答は「自前で持たず、必要なときに必要な台数のクラスタを借りる」
Agileの現状に対する漠然とした不安 - masayang's diary
去年のAgile2009では漠然としか感じていなかったのだけど、今年のAgile2010ではその不安がより確実になってきた。去年はCode Smellのたとえで言えば「どこかでタバコ吸ってる人がいるな」くらいの感覚だったのが、今年は「同じ部屋でタバコ吸ってるバカがいるぞ」、みたいな。 ただしCode Smellみたいなものなので、何かおかしいぞ、という程度の感覚でしかないのも事実である。 その漠然とした不安を抱かせる要因は何かというと「Agileのコモディティ化」なのであります。 自己紹介に「Certified Scrum Masterです」と説明を入れたり、「アナーターハーCSMデースカァー？」みたいな質問をしてきたりする人が今年は昨年よりも確実に目立つ。 あるいは...「わが社は自分では作りません。計画管理と実装は、コントラクタ(契約ベースで請け負う別会社)に任せてます。」みたいな丸投
昭和の名残 - masayang's diary
例の岡崎図書館事件以後、まったりと追っかけている#Librahackだが、今日も面白いねたが出て来た。 →中野区の図書館システムにおけるテスト報告書。中身をみればわかるけど、「ああ、昭和を思い出すねぇ」という感じに懐かしさが先にでてくる。 詳しくは元の資料を参照のこと。どうやら受入テスト相当の内容と思われるが、 テスト担当が何か作業して 問題なければOKでしたと書き込み。 問題があったら、だめですた、と書き込んで対策を実施。で、「今度はOKですた」と記入して次の項目へ。 なんか懐かしいよね こういう検査をしている現場がまだあるということにびっくり。全部で350項目ほどあるようだが、環境設定〜テスト準備〜テスト実施〜結果記録、という作業を一件あたり10分としても3500分。ざっと60時間。テスト結果一覧にある記入が日付だとすれば、確かに一週間かかっている。筆跡からすると一人でやってるようだし
Agile2010 Day One - masayang's diary
本日はワークショップやチュートリアル中心の日。コマ数が多い中、Organization & Enterprisesを「持続可能な範囲で*1」聞いてきた。 目次 How Agile Taught IBM about New Leadership Competencies Agility@Scale - Experiences from the Trenches at IBM Rational Beyond Scope, Schedule, and Cost: Optimizing Value How Agile Taught IBM about New Leadership Competencies 現在はPitney Bowes社の国際技術担当副社長をのSue McKinney女史による「大企業のAgile化に求められる指導者の資質」に関する発表。彼女は去年まではIBMにて「世界各支社のI
もうこういうのやめようよ... - masayang's diary
日経SYSTEMS実践セミナー 手戻りなしの要件定義テクニック 要件定義書の内容が不十分なまま設計作業に着手したところ，要件の追加や変更が相次ぎ，そのたびに手戻りが発生した──。システム構築に携わるITエンジニアであれば，誰しもこんな経験があるでしょう。手戻りにつながる仕様変更を防ぐには，要件定義をしっかりと行い，業務改善に役立つシステム要件を明確にし，構築時におけるユーザーからの協力体制を確保することが重要です。本セミナーでは，手戻りを起こさない要件定義の方法を徹底解説します。要件定義の経験が少ないITエンジニアでも実践しやすいように方法を分かりやすく解説するのに加えて，演習によって理解を深めていただくのですぐに現場で役立ちます。 要件定義が充分かどうかは作ってみないとわからないんだってば。 むしろ、要件定義が不充分であることを前提として、物事を進めるようにするべきなんだってば。 （株）
古い発想の経営トップ - masayang's diary
ITPro: 若い時にプログラムを書こう，必ず人生の豊かさにつながる 経営トップから「ウォーターフォール型開発」「分業制度」という発想が抜けないから、こういう「昭和時代体質」が延々と生き残ることになる。 悲劇といえば悲劇。 古い発想のままでいるということが理解できてないあたりは、喜劇的ですらある。 私どもの過去の開発実績の平均値を取ると、機能拡張のような案件を除く、ごく普通の開発の場合、開発工数の比率は、要件定義と設計が3、製造が4、試験（テスト）が3です。 今言っているのは、もっと自動化を進めて、4から2まできた製造のところをもう半分減らして1にしたい、ということ。そうすると3、4、3が3、1、1ぐらいでいけるのではないか。合計で5ですから半減、つまり倍速達成となる。 Agile化でフェーズ分割＋分業のオーバーヘッドをなくせば全体で4、下手したら2で済むかもしれない、なんてことは異次元の
IT業界で楽しく仕事をするための10カ条(毒) - masayang's diary
JavaBlackさんとこ経由: IT業界で楽しく仕事をするための10カ条のぱくり。 其の一、仕事は遊ぶための資金稼ぎと割り切るべし。 其の二、分からないことは、「わかりません」と素直にみとめるべし。 其の三、仕事中はひたすらブクマ項目追加に努めるべし。 其の四、社内外で毒を吐くべし。 其の五、勉強会やセミナーでは発表者が「もういいよ」というまで質問すべし。 其の六、専門分野を隠し、知ったかぶりする上司を嘲笑すべし。 其の七、会議は寝る場。 其の八、パソコンも携帯も持ってないととぼけるべし。 其の九、コーディングはできません、と演技すべし。 其の十、メモはポストイットで充分。 其の一、仕事は遊ぶための資金稼ぎと割り切るべし。 自分も趣味のプログラミングからこの業界に入ったけど、趣味と仕事とは別次元。趣味＝楽しい、仕事＝楽しくない。楽しみは仕事以外に持つのが吉。 其の二、分からないことは、「
言い訳はうまい - masayang's diary
忙しかった頃 「Agileしましょうよ〜」 「忙しくて人を出せない」 暇になってきた今 「Agileしましょうよ〜」 「予算がないので手を出せない」
投資と負債は違うよ(2) - masayang's diary
売り切れました: そりゃ投資と負債は違う id:shivashantiさんからトラックバックをいただいた。 １億円かけてシステムつくれば１億の投資。 運用保守に年間１５００万円で耐用年数５年なら７５００万の負債。 システム導入は投資の結果として負債が手元に残る。 だから導入による効用は投資額＋負債総額を上回るように計画しなくてはならない。 開発費1億円のシステムを5%で5年かけて償却していくと、月額212万7135円 運用保守費年間1500万円=月額125万円 つまり、このシステム投資は月当たり337万7135円以上の付加価値を生まないと「投資に見合った収益がでない」、ということになる。 まあ、普通なら「月に400万円の付加価値を生むシステムを作ろう。そのための投資は月に337万7135円だから、毎月63万円弱の利益が出る」と判断するから、投資に踏み切れるわけで。 で、その開発費分は積んで
痛い目に合わないとわからない - masayang's diary
酔狂人の異説: ウォーターフォール型開発は最初から破綻している? そもそも、洗い出せていないリスクや問題点が存在しないって、どうして言えるんだろうか。存在しないことの証明は、「悪魔の証明」って言われるほどで、事実上不可能なのに。存在しないことの証明ができるなら、プログラムにバグの無いことの証明もできるだろう。最初から不可能なことをできると考える時点で、既にウォーターフォールは破綻しているということ。 そのとおり！ でもね... 洗い出せていないリスクや問題点を吸収できるだけの「ゲタ」を履かす事で、破綻する確率を下げる事ができる。 その「ゲタ」は例えば下記の通り： おびただしい量の成果物を記述するための労力分を余裕をみて請求する。 プロジェクト後半で発覚する問題点を押さえ込むための労力分を余裕をみて請求する。 それらのゲタを見越した顧客の値引き要求に対するさらなるゲタ。 その値引き要求に対す
権限は要件か？ - masayang's diary
画面設計とか外部設計とか、もうやめようよにおいて 「権限」「ステータス」など、システム内部の話がでている。→明らかに実装と要件とを勘違いしている。 と書いたら「権限って要件じゃないの？」という問い合わせをいくつかいただいた。 できるだけ簡単・簡素に考えよう 例えば「水泳選手として、指定した水泳種目の記録を折れ線グラフで見ることができる」というストーリがあったとする。*1 ここで「水泳選手を特定するために認証を実装する必要がある」と考えちゃう時点で、余分なことを考えちゃっている、と言ってよい。 極端な話、マイケル・フェルプス専用の端末を用意し、彼しか入れない部屋にそれを設置すれば、認証の実装は不要なのである。 「そんなのインチキ」と思うかもしれない。 でも、実際に開発する場合には認証もへったくれもなしで実装・テストしておいて、後から権限や認証を実装するほうが、開発もテストもすっきりする...
「まだ６０回しか稲作したことがない」という含蓄ある言葉 - masayang's diary
昨日は旧友たちと錦糸町のホルモン焼き屋で飲む。 一人は自営業の傍ら、稲作をしているおっさん。 今年で稲作6年めだとか。 以下、印象に残ったお話。 最初は手探り状態。近所の農家に指導をしてもらった。 「おいしい」米を作れる技術を持っているのは70歳の世代まで。 その後継者になるべき世代(たぶん、うちらの世代)は農政と農協のおかげでボロボロ。 その70歳のおじいちゃんが「自分はまだ稲作を６０回しかしたことがない。だからよくわからない。」と言ったそうな。 含蓄ある言葉だな、と思った... 確かに米は年一回しかとれない。 しかも気象条件は毎年必ず変わる。 そういう中で試行錯誤できる回数は、一生のうち数十回。 こんな技術はマニュアル化など到底できない。 習い(あるいは盗み)、伝えていくしかない。 実践(プラクティス)あるのみ。 システム開発も似たような所はあるよね。 一生のうちに経験できるプロジェク
今度の不況でSI業界が悲惨な状況に陥りそうな３つの理由 - masayangの日記（ピスト通勤他
釣り 題名に「３つの理由」みたいに数字を入れるとアクセス数が上がると聞いた。 本当かな？ 本題 自分がこの業界で景気後退を経験するのはこれで3度目。 一回目は1990年前半のバブル崩壊後。 二回目は2000年のネットバブル崩壊後。 今回のは1990年前半のそれを、規模・深刻さ共に凌駕すると予想している。 理由(1): 空洞化 「上流＝付加価値の高い仕事」という概念は根強く、開発という「核となる」行程を安い外部に流すようになってしまった。 レバレッジ効果があるから収益向上につながってきた。 が、新たな仕事が来なくなるとレバレッジは逆転を始める。 つまり、外部依存率を下げつつ、利益率向上を目指すという苦痛が待っている。 →開発を忘れた人達には無理。 理由(2): 分業化 1990年代初頭の情報処理試験は「二種」「一種」「特種」しかなかった。 今はなんだよ... 情報処理試験の中の人達に雇用機会
戦闘機開発もAgileでいこう - masayang's diary
Agile JournalのCASE STUDY: War Stories - Fighter Jets and Agile Development at Lockheed Martinという記事が興味深い。大企業・ハードとソフト両方・飛行機（それもF-35 Lightning II）という品質重視分野・世界各地に分散した開発チームという条件下でのAgile適用事例だ。 長いので全部は訳さないけど、ポイントをいくつか。 規模 企業の規模は、従業員１４万人、４５カ国４５７都市に分散。米国だけで９３９施設。 従来は... いわゆるウォーターフォール式で開発をしてきた。 製品の投入周期は年一度かそれ以下のペースで、製品投入直前の数ヶ月はいわゆるデスマーチに近い状態（原文では「Fire Drill」）だった。 開発チームは作業項目単位で結成された。そして、ある作業がうまくいったという「前提で」次の
安物買いの銭失い...開発をアウトソースしてはいけないという事例 - masayang's diary
機内で読んだWall Street Journal（紙媒体版）2007年12月7日金曜日A1面の記事より Boeing Scrambles to Repair Problems With New Plane 要旨 次期旅客機787Dreamlinerの開発が遅れている 最大の理由は自社開発ではなく、アウトソース活用を試みたこと 機体の設計開発をアウトソースしたのはボーイング91年の歴史で初の試み アウトソースした理由 機体素材に炭素繊維を使う787は基礎研究だけで大きな投資が必要だった 開発投資額は100億ドル(1兆1000億円)に達する 開発投資を抑えるため、部品供給メーカ達に設計開発を委託（アウトソース） 発生した問題 多国にまたがるアウトソース 言語の壁 米国では想定していなかった各種規制 孫請けに仕事を分散させることによるオーバーヘッド 同じ企業なら会って話せば済むのに、大量の文書
COBOL屋の呪縛 - masayang's diary
今回の日本出張ではいくつかのプロジェクトの状況をみてきた。で、思ったこと。 「COBOL時代のデータ構造を引きずることで、生産性や保守性が落ちている」 フラグだらけのマスター 本物のコードをだすわけにはいかないので、すごく簡略化した例で説明したい。あるシステムを利用できるユーザのマスターテーブルがあるのだけど、そいつには「なんちゃらサービス利用可否フラグ」みたいなのがたくさんついているのね。 この方式の問題は以下の通り。 テスト負荷 フラグがあるということはそれをチェックするif文があるということ。 if文があればテスト件数は最低２件は増える。 入れ子になれば、４件、８件...と増えていく。andやorでも同じ。 コードの冗長性 「あるユーザがサービスAを使えるか」を調べる処理と「あるユーザがサービスBを使えるか」を調べる処理はほぼ同様になることは明らか。 「サービスAを使えるユーザ」を調
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
薬剤師の仕事 - masayang's diary
Javaが汚い件 - masayang's diary
マニュアル化ねぇ - masayang's diary
疲れてないってば - masayang's diary