今度の不況でSI業界が悲惨な状況に陥りそうな３つの理由 - masayangの日記（ピスト通勤他
釣り 題名に「３つの理由」みたいに数字を入れるとアクセス数が上がると聞いた。 本当かな？ 本題 自分がこの業界で景気後退を経験するのはこれで3度目。 一回目は1990年前半のバブル崩壊後。 二回目は2000年のネットバブル崩壊後。 今回のは1990年前半のそれを、規模・深刻さ共に凌駕すると予想している。 理由(1): 空洞化 「上流＝付加価値の高い仕事」という概念は根強く、開発という「核となる」行程を安い外部に流すようになってしまった。 レバレッジ効果があるから収益向上につながってきた。 が、新たな仕事が来なくなるとレバレッジは逆転を始める。 つまり、外部依存率を下げつつ、利益率向上を目指すという苦痛が待っている。 →開発を忘れた人達には無理。 理由(2): 分業化 1990年代初頭の情報処理試験は「二種」「一種」「特種」しかなかった。 今はなんだよ... 情報処理試験の中の人達に雇用機会
COBOL屋の呪縛 - masayang's diary
今回の日本出張ではいくつかのプロジェクトの状況をみてきた。で、思ったこと。 「COBOL時代のデータ構造を引きずることで、生産性や保守性が落ちている」 フラグだらけのマスター 本物のコードをだすわけにはいかないので、すごく簡略化した例で説明したい。あるシステムを利用できるユーザのマスターテーブルがあるのだけど、そいつには「なんちゃらサービス利用可否フラグ」みたいなのがたくさんついているのね。 この方式の問題は以下の通り。 テスト負荷 フラグがあるということはそれをチェックするif文があるということ。 if文があればテスト件数は最低２件は増える。 入れ子になれば、４件、８件...と増えていく。andやorでも同じ。 コードの冗長性 「あるユーザがサービスAを使えるか」を調べる処理と「あるユーザがサービスBを使えるか」を調べる処理はほぼ同様になることは明らか。 「サービスAを使えるユーザ」を調
上級ソフトウェア技術者急募 - masayang's diary
シリコンバレーのAgile開発者メーリングリストに届いた求人広告。Moody'sの子会社。 Company: Moody's Analytics Position: Senior Software Engineer Location: San Francisco, CA Moody's Analytics, a subsidiary of Moody's Corporation, is the world's leading provider of market-based quantitative credit risk products for credit risk investors. Moody's Analytics is recognized as the pioneer & market leader in credit risk measurement & managem
Investigative Tester (調査型テスト担当者) - masayang's diary
開発チームとテストチーム(QA: 品質保証)とを分けるかどうかというのはAgileコミュニティの中でもよく議論になる。 "Craftsmanship over Crap!" と叫んだBob Martinは品質保証を他人に任せることに大反対。 が、GDD(Geographically Distributed Development: 地域分散開発)に関して話してくれたScott Amblerは面白い考え方を提示してくれた Investigative Tester ある程度規模が大きくなり、複数チームで開発を進めることになっても、テストを記述するのは開発者。これは原則。*1 ただし、Investigative Tester(調査型テスト担当者)を用意するのは悪いことではない。 調査型テスト担当者は開発者が見落としているテストを探し、実行する。 バッファオーバーフローとか トラップされてないエラ
スラム街の作り方 - masayang's diary
自分は以前から「マイアミ、サンディエゴ、ラスベガス、フェニックス等、コンド(日本でいう分譲マンション)が乱立された都市では、コンドの価格が最大90%以上下落する可能性がある」と予想しているのだけど、どうやらマイアミはそういう状況になりつつあるらしい。 Mish: Miami Residents Live In Nearly Condemned Condos 題名を邦訳すると「居住禁止のコンドに住むマイアミ市民達」かな 分譲したものの「売れない」「売れても払えずForeclosure」で居住率はどんどん低下 なんとか踏みとどまれている人も、経済的に苦しくなるとAssociation Fee(共同管理費)延滞に陥る 結果、居住者から徴収するAssociation Feeが不足に そしてコンドの日々の運営が回らなくなる Mish記事に出ている例では ゴミの収集がとまり、ゴミ捨て管(ダストシュート
ああ勘違い - masayang's diary
ITPro: 使い回しの提案が目立つ「できます」と簡単に言うな 当社は全国に約190店舗を展開しているが、事業規模でいえば年商160億円の中堅企業。専任のシステム担当者もいない。 私が所属する経営企画グループの役割は、情報化戦略の企画立案だ。システム開発・運用の実務まで手が回らないのが実情である。 我々が求めるのは、情報システム部門の代わりとなって、社内を駆け回ってくれる存在。システム開発や運用・保守といった技術的な業務はもちろん、利用部門との調整作業といった役目もお願いしたい。少なくとも“使い回し”精神の企業と付き合う気はない。 そもそも論 全国で190店舗ってのは、POS端末の保守員を貼付けるには少なすぎる。 結局、他のお客の保守員と掛け持ちさせざるを得ない。 つまり、システムは使い回し前提となる ああ勘違い 「情報システム部門の代わりとなって、社内を駆け回ってくれる存在」にいくら払っ
和風Agile? Part-2 - masayang's diary
和風Agile?の続き ウォーターフォール開発に慣れ親しんだマネージャ達にAgileを売り込むときによく指摘されるのが「最初に要件も予算も確定させないAgileのやり方はおかしい」ということ。 で、「じゃぁ、ウォーターフォールで最初に『確定』させた要件や予算が正しかった事がどれくらいありましたか？」と聞いてみると、「実はそれほど正確ではない。」という答が多いのも事実。 しかも要件抜けが発覚するのがUAT段階なら良い方で、本番稼働後に発覚する事例も珍しくない。そして不思議な事に、こういう「抜け」は要件定義段階の度重なるレビューでは発覚しない。ものすごく丁寧な業務フロー図やらなんやらを描いているのに、だ。 「だからこそ、要件抜けなどに対処しやすいAgileがいいのでは？」と売り込むと、「いや、それは困る」という答。どうやらこういうことらしい。 発注元の立場では、まず最初に予算総額を確定させる必
また、器用な事をしますなぁ - masayang's diary
Adobe: Trial availability FAQ Why are some Adobe product trials currently not available? During the month of June 2008, certain product trials that are launched for the first time (regardless of when they were installed) will function for only one day instead of 30 days, due to an error in a line of code that counts down the remaining days in a trial. You will not experience this issue if you have
生産性はPDCAループのスループットで決まる - masayang's diary
ひがやすをBlog: SI業界の老害が若手と下請けを蝕む理由 その時代の生産性は、紙に文字を書くスピードで決まっていたらしい。 「これはすごい」 実際はレビューの時間などがあったので、開発者によって生産性の違いはなかったそうです。 →ちょいと古いけど、興味ある人はこちらを読んでほしい。 生産性は依頼者と作業者の間のPDCAスループットで決まる レビューがあれば、そこがボトルネック ツールや手法の発達により、依頼者と作業者の分業が不要になる場合が生じる プログラマとパンチャが同一人物になったのはその典型 その分業に固執すると、生産性は昔のまま ただし、分業制をなくすと、仕事を失う人もでてくる 両方に精通しないと、続けられない SI業界のおじさん達が分業制に固執するのも、このあたりに理由あり。 脳味噌が石灰化しているから、もう習えないのだ でも、お客トップの脳味噌も同様に石灰化しているから、当
RoRのmigrationで思ったこと - masayang's diary
最近、それなりに本格的なシステムをRailsで開発しているのだけど、ActiveRecord::Migrationに衝撃を受けた。これはすごい。 昔話 20年ほど前、ソフトウェア開発の生産性が目に見えて向上した時期がある。ここで話しているのはビジネスソフトウェアのことね。 自分が入社した87年は、こんな感じで開発する文化がまだ残っていた。おそらく最後の頃だと思うけど。 ロジックの設計をするSEがいる それをもとにコードを「紙に手書きする」プログラマがいる。専用の用紙があったのだ。 その紙を元にコードを入力するコーダ→コードは80桁のカードに入力 プログラマはカードの束をカードリーダに突っ込む バッチ処理でコンパイルされて、結果がリストに出力される コンパイルが通らない場合はプログラマが原因を突き止めて、修正したコード入力をコーダに依頼する 以下繰り返し[*1] 要するにプログラマはコーダへ
文化の差... - masayang's diary
RailsConf 2008参加中。最終日の朝一番から衝撃を受けまくり。 The Worst Rails Code You've Ever Seen (and How Not to Write it Yourself) 要はRailsでありがちな「誤ったコード」「悪いコード」の例を挙げていくセッション そして、その対策として挙げられていたのが「ベテランプログラマ、特にSmallTalkをよく知っている人を探せ。そして、その人と若手とでペアプロさせるのだ。」というお話。 歳とってもプログラマとして活躍させてもらえる土壌がある国だからこういうアイデアがでてくるのか？ プログラマ→SE→管理職、みたいなキャリアパスを定番コースにしてしまった日本は取り返しのつかない間違いをしてしまったのでは？
再びライフハッキング - masayang's diary
ライフハッキングに関してコメントをいただいたので、なんの脈絡もなくwired.comのこの記事を適当に訳しておく。 ライフハッキングとはなんですか？ コンピュータをハッキングするようなものですか？ 誰かが私の命に入り込んでくるわけですか？ そして、自分の飼い犬は今の自分よりも、そいつが入り込んだ自分のほうが好きになっちゃったりするのですか？ 待った待った。質問は一つずつね。ライフハッキングは家屋への侵入にはほとんど役に立たない。ライフハッキングとは日々の生活をより容易に、効果的に、そして生産的にするコツとか工夫とかの実践のことなんだな。 本当？ でもそれって聞いたことがあるような。今までなかったようなことなの？ うん。昔は「おばあちゃんの知恵袋」と呼ばれていたんだな。 でも、ライフハッキングと「おばあちゃんの知恵袋」は違うよね？ それは自分で判断してくれ。ちなみにこの記事を書いている時点で
迷ったら狩野さん！...狩野分析法による優先度付け - 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開発では「優先度順に要件（フィーチャ）を開発していく」のが基本だが、いざ優先度をつけようにも話は簡単ではない。発注側に強力な指導者がいてその人が独裁的
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
