議論するまでもない - masayang's diary
ITMedia: クラウドコンピューティングは本当に安上がりなのか？ →はい。安上がりです（終了） 補足 能力は想定繁忙時にあわせる。 サーバ機器を5年償却で保有。 この前提だけで、充分クラウドのほうが安上がり。そもそも想定繁忙時をどうやって見積もるのかで、高給取りのコンサルタントやら上流設計技術者やらがワラワラ沸いてきて高額な請求書を置いていく。そしてその想定繁忙能力がいかに妥当か、外れたときの責任所在をいかに曖昧にするかの駆け引きが続き、これだけでプロジェクト着手が数ヶ月は遅れる→稼動しなかった分は「機会損失」ね。 で、普通は責任所在を曖昧にするために繁忙時能力は多めに見積もられる。つまりは過剰投資。そして繁忙時／閑散時の能力差が大きいほど、この投資効果は低くなる。100あるサーバ能力が100使われることは滅多になく、普段は10とか5で動いていたら、それは損失だよね。でも負荷に応じてサ
Unit Test vs Functional TestそしてClean Code - masayang's diary
Agile2008でもらったゴムバンドを未だに手首につけている。確かBob Martinだったと思うが、テスト駆動開発と「Clean Code」の関係について熱く語っていた年だ。 メソッドは短く。 メソッドが実現することは一つ。 あるメソッドのテストに色々と条件を設定しているのなら、それはClean Codeではない。 だが我々はその基本を簡単に忘れてしまう。色々とテストのための道具が揃ってきたせいもあろう。基本を忘れて一つのメソッドに色々と詰め込みすぎるとテストが大変になる。Mockがあっても、だ。Fixture使うのはさらに大変だし、Seleniumとかで入力から何から条件を与えるのはもっと面倒。そしておそらく抜けが発生する。 最近、内職でPython使ったアプリを組んでいるのだが、今回は上記「基本」を徹底するようにしている。例えばこんなコードがある。 def nearby(reque
日経ITProの記事にケチつけておく - masayang's diary
日経ITPro: アジャイルはウォーターフォールよりも難しい 何を持って簡単・困難を定義するのかがわからないけど、「アジャイルはウォーターフォールよりもごまかすのが難しい」というのであれば、その通りだろう。 そもそもアジャイルは、大規模プロジェクトを想定していないし、請負契約が多い国内のプロジェクトは、要求の増加に歯止めが利きにくいアジャイルと相性が悪い。 そもそも大規模プロジェクトを想定して生まれた手法は存在しないわけで。 ウォーターフォールは他に選択肢がなかったために大規模に適用されてきたけど、それが適切だったかはなんとも言えない。失敗しても他に選択肢がないんだから「ウォータフォールが悪い」って言えなかったしね。 ただ、最近は大規模でのAgile事例は増えてきている。日本ではまだ少ない、というところでしょ。 「要求の増加に歯止めが利きにくいアジャイル」というのも変だよね。 当初の一欄に
Agile2010 Day Four - masayang's diary
終わった！ 午後参加した二つの発表はレガシーコードとどう付き合うか、という毎年ある話。 だけど、年々より具体的かつある程度体系化された手法が確立されつつある。 今日のは納得いく発表だった。 って、報告はもう疲れたので帰りの飛行機か、帰宅してからにします。 この日は午後の二つのセッションに参加。いずれもレガシーコードに関わる話題だ。 一件目のThe Worst of Legacy Code: Forensic Developmentは「本当に」レガシーなコードをどうやってリファクタリングしていくか、の提案で対象は「オブジェクト指向だろうが手続き型だろうが問わない」ということだった。(ただし手続き型の場合は、CやCOBOLでテスト書くのと同じくらいの煩雑さは増えると思われる) ここでいう「本当に」レガシーなコードとはテスト自動化が足りてないあるいは全く達成されていない、と思ってよい。何か触れば
Agile2010 Day Three - masayang's diary
本日も我が道を行く。 From Estimate to Contract - Choosing the Right Model for Your Situation Becoming Agile: Designing a Transition Plan from Waterfall to Agile From Estimate to Contract - Choosing the Right Model for Your Situation Chris Shinkle/Jim LaRue両氏による好発表。基礎となっているのは「熊とワルツを」で紹介されているモンテカルロ法を使ったプロジェクト見積もり変動シミュレーション。このシミュレーションを元に、契約をFFP(Firm Fixed Price: 定額)にするのか、T&M(Time and Material: いわゆる人月課金)にするのか、ハ
Agileの現状に対する漠然とした不安 - masayang's diary
去年のAgile2009では漠然としか感じていなかったのだけど、今年のAgile2010ではその不安がより確実になってきた。去年はCode Smellのたとえで言えば「どこかでタバコ吸ってる人がいるな」くらいの感覚だったのが、今年は「同じ部屋でタバコ吸ってるバカがいるぞ」、みたいな。 ただしCode Smellみたいなものなので、何かおかしいぞ、という程度の感覚でしかないのも事実である。 その漠然とした不安を抱かせる要因は何かというと「Agileのコモディティ化」なのであります。 自己紹介に「Certified Scrum Masterです」と説明を入れたり、「アナーターハーCSMデースカァー？」みたいな質問をしてきたりする人が今年は昨年よりも確実に目立つ。 あるいは...「わが社は自分では作りません。計画管理と実装は、コントラクタ(契約ベースで請け負う別会社)に任せてます。」みたいな丸投
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
吉岡さんがレガシーコード改善ガイド読書会という勉強会を立ち上げた。レガシーコードとどう付き合っていくか、を議論していくらしい。可能なら参加したいが、ちょいと距離があるので中々難しい。 自分もこのお題目については色々考えてきたし、自分なりに実践もしてきたつもりなので、トラックバック送りながら意見などを... レガシーの定義 「テストがないコードはレガシーコードだ」という定義には100%同意。 我々は今この瞬間にもレガシーコードを簡単に書くことができる。 だけど、そのテストのないレガシーコードにも「レガシー度」みたいな尺度があるのではないかと。 レガシー度 といっても簡単に数値化できるようなものではない。 monolithic度合い。何千行とある関数とか、何百とメソッド持ってるクラスとか。 結合度、依存性などという言葉で表現されるアレ。 Interfaceの設計。変な値を渡さない工夫をしている
AgileとCMMIの融合:SEPG Conferenceより - masayang's diary
CMMIにAgileの思想とプラクティスを取り込む動きは2006年あたりから始まっていたが、今回開催されたSEPG Conferenceにおいて以下のような議論が進行した。 従来のウォーターフォール思想を基盤としたCMMIは今後メンテされない。つまり進化しない。(お猿さん向けに残るには残る。) AgileはCMMIに正式に取り込まれる。 ただし、CMMIが重視する「成熟度」「再現性」などはAgileであっても尊重されなければならない。 成熟度や再現性が問われる以上、プロジェクトは一定以上の「見通し」が確保されるべきである。 すなわち、イタレーションやスプリントという言葉に代表される「やってみて、できるところまで作業する」という姿勢は正されるべきである。 このような考えのもと、Agile+CMMIはRUP(Rational Unified Process)を踏襲した工程名を採用することになっ
Twitter規制 - masayang's diary
総務通達第◯◯◯◯号 件名: ツイッター利用に関する件 当社社内LANでは許可されたインターネット以外は閲覧できなくなっています。最近話題のツイッターは非許可サイトなので閲覧も投稿もできません。しかしながら、個人所有の携帯電話を使ってツイッターに投稿する事例が増えていることから以下の規制を設けます。 1. ツイッター利用は原則禁止とします。 2. ツイッターアカウントが必要な場合、ツイッターアカウント取得申請書(総務申請書書式◯◯号)にアカウント名、利用端末区分と理由を記載の上、部課長の許可をもらってください。 3. ツイッターに投稿する場合、事前にツイッター投稿申請書(総務申請書書式◯◯号)に投稿内容を記載の上、所属課長および総務部の審査を受けてください。 4. ツイッターに投稿された内容がRTされた場合、ツイッターRT状況報告書(総務申請書書式◯◯号)を総務部に送付してください。 なん
従順であることを教えるのは、独創的であることを教えるより簡単なのである - masayang's diary
Wizard Of Crowds経由: Seth's Blog: It's easier to teach compliance than initiative It's easier to teach compliance than initiative 従順であることを教えるのは、独創的であることを教えるより簡単なのである Compliance is simple to measure, simple to test for and simple to teach. Punish non-compliance, reward obedience and repeat. 従順さは簡単に測れる。従順かどうかは簡単に試せる。そして、従順であることを教えるのは簡単なのである。従わなかったら叱り、服従したら褒める。これを繰り返せば良い。 Initiative is very difficult
動かしながら変えていくということ - masayang's diary
いまさらだけど、2008年春の時点では、FacebookはMySQLに強く依存していたんだよね。しかも1800サーバ(900のMaster/Slave組み合わせ)!! そして、裏ではCassandraへの移行が既に始まっていた、と。 いくらx86とはいえ、1800台もサーバ動かせばそれは「資産」として扱いたくなる心境だけど、そこを敢えて否定してCassandraに持っていった姿勢は見習う必要がある。そして、その移行の理由は: Cassandra does not support a full relational data model; instead, it provides clients with a simple data model that supports dynamic control over data layout and format. →データスキーマをより素早く変
システムのコストを下げる vs システムでコストを下げる - masayang's diary
今回の出張でもお客様から直接話をうかがったり、同業の皆様達との情報交換で色々な現場の状況が見えてきた。 クラウドという言葉の引きは強いが、そこにある期待は「システムコスト削減」が中心。正確にはシステム「の」コストをクラウド活用で減らそう、というもの。 もちろん、コスト削減は重要だよ。年間1000万円の節約は、利益率5%の企業なら2億円の売上増と同等だ。 だけど、このようなコスト削減は持続的な成長にはつながらない。今季1000万円節約できたから、来季もさらに1000万円削ろう、などという作戦は長続きしないのだ。企業に求められるのは持続的な成長力のはずである。 では、なぜこのような「システムのコストを削ろう」という発想が出てくるのであろうか。 そもそものシステムを導入する理由は以下のいずれかの筈である。 システム導入「で」無駄なコストを削減する。 システム導入「で」新たな付加価値を生む。 なん
SocialWok面白そう - masayang's diary
SocialWokが面白そう。 GMailアカウントがあればすぐ使える。 これは何？ 仲間内で閉じたTwitter的空間を作る。 仕事仲間 学校・学級・同窓会 研究室・ゼミ・サークル 趣味仲間 .... その仲間内で共同作業をする際の道具になる。 Twitterみたいな仕掛でワイガヤ的議論 ファイル添付可能 つぶやきにコメントを付けられる Google Calendarを使ったスケジュール共有 Google Documentを使った資料作成・共有 必要に応じて、Twitter的つぶやきを他のサービスに公開できる Twitter Facebook FriendFeed LinkedIn なんのこっちゃかわからん人は、まず使ってみる事だ。 使い始める GMailアカウントを持っていれば、すぐ使えるよ。 http://apps.socialwok.com/ に接続 GMailアカウントを入力して
金融システム開発終わりの始まり - masayang's diary
Naked Capitalism経由FT: Hidden costs emerge from the debris of Lehman crash リーマン崩壊からほぼ一年。 その債務処理にかかる費用が当初の予想を大きく越えそうだ、という記事。 理由はいつものあれだよ。 そう、システム保守にかかる費用が見積もりを大きく越えてしまったらしい。 理由は簡単。リーマンで働いていたシステム開発要員達がごっそり消えてしまった(evaporated)から。 破綻後に採用された人達は「仕様書がないからわからない〜」という、いつものアレで仕事が進まない、と。 雑感 金融のフロント周りって、トレーダーと開発者が渾然一体となって、どっかんどっかん開発を進めることが多い。 Agileの一派であるXPを推進してきた人達は、金融フロント開発出身が珍しくない。 高い利益を上げるトレーダーに、高い利益を生む開発者。 こ
生産性は測れない - masayang's diary
現実逃避で、Martin FowlerのBlogを無断邦訳してみた...ちょっと古い記事だけど、その後画期的な生産性指標が発見されたとは聞いてないので、今でも使える話でしょ。 我々はソフトウェア開発プロセスだとか、設計プラクティスだとかの話題になるとついつい感情的な議論を始めちゃうけどさ。こういう議論の多くは実は結論を出せないんだな。なぜなら、我々がいるソフトウェア業界というのは、ソフトウェア開発の効率を測定するという極々基本的な要素を欠いているからなんだよね。 もちろんここでいう生産性とは、ある活動における入力と出力とを観測することで定まる「何か」だよ。つまり、ソフトウェアの生産性を測定するには、ソフトウェア開発における出力を測定する必要があるわけだ。生産性を測れないというのは、実はこの出力を測れないことに理由があるんだな。 測れない、というのは、みんなが試さない、ということじゃないよ。
今さらだけど... - masayang's diary
文書類の整備に関して異様にこだわる人達って、文書類の整備に口を出す以外に能力がないからではないかという結論に到達した。
IT業界で楽しく仕事をするための10カ条(毒) - masayang's diary
JavaBlackさんとこ経由: IT業界で楽しく仕事をするための10カ条のぱくり。 其の一、仕事は遊ぶための資金稼ぎと割り切るべし。 其の二、分からないことは、「わかりません」と素直にみとめるべし。 其の三、仕事中はひたすらブクマ項目追加に努めるべし。 其の四、社内外で毒を吐くべし。 其の五、勉強会やセミナーでは発表者が「もういいよ」というまで質問すべし。 其の六、専門分野を隠し、知ったかぶりする上司を嘲笑すべし。 其の七、会議は寝る場。 其の八、パソコンも携帯も持ってないととぼけるべし。 其の九、コーディングはできません、と演技すべし。 其の十、メモはポストイットで充分。 其の一、仕事は遊ぶための資金稼ぎと割り切るべし。 自分も趣味のプログラミングからこの業界に入ったけど、趣味と仕事とは別次元。趣味＝楽しい、仕事＝楽しくない。楽しみは仕事以外に持つのが吉。 其の二、分からないことは、「
投資と負債は違うよ(2) - masayang's diary
売り切れました: そりゃ投資と負債は違う id:shivashantiさんからトラックバックをいただいた。 １億円かけてシステムつくれば１億の投資。 運用保守に年間１５００万円で耐用年数５年なら７５００万の負債。 システム導入は投資の結果として負債が手元に残る。 だから導入による効用は投資額＋負債総額を上回るように計画しなくてはならない。 開発費1億円のシステムを5%で5年かけて償却していくと、月額212万7135円 運用保守費年間1500万円=月額125万円 つまり、このシステム投資は月当たり337万7135円以上の付加価値を生まないと「投資に見合った収益がでない」、ということになる。 まあ、普通なら「月に400万円の付加価値を生むシステムを作ろう。そのための投資は月に337万7135円だから、毎月63万円弱の利益が出る」と判断するから、投資に踏み切れるわけで。 で、その開発費分は積んで
権限は要件か？ - masayang's diary
画面設計とか外部設計とか、もうやめようよにおいて 「権限」「ステータス」など、システム内部の話がでている。→明らかに実装と要件とを勘違いしている。 と書いたら「権限って要件じゃないの？」という問い合わせをいくつかいただいた。 できるだけ簡単・簡素に考えよう 例えば「水泳選手として、指定した水泳種目の記録を折れ線グラフで見ることができる」というストーリがあったとする。*1 ここで「水泳選手を特定するために認証を実装する必要がある」と考えちゃう時点で、余分なことを考えちゃっている、と言ってよい。 極端な話、マイケル・フェルプス専用の端末を用意し、彼しか入れない部屋にそれを設置すれば、認証の実装は不要なのである。 「そんなのインチキ」と思うかもしれない。 でも、実際に開発する場合には認証もへったくれもなしで実装・テストしておいて、後から権限や認証を実装するほうが、開発もテストもすっきりする...
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
