一山いくらで人月見積の大手ベンダーを外し始めたユーザー企業のITガバナンス石橋秀仁 @zerobase 先日某社のIT担当者と話して着々とベンダー(SIer)外しが進んでいる実態を知った。新規案件はどんどんAmazon EC2に構築し、委託先もウェブ系の制作会社やソフトハウス。それに対応できない大手ベンダーの「ジレンマ」。まあ対応せず潰れてください。社会のために。 2011-02-05 15:45:49
受託開発が抱える本質的な非効率性に関する考察 - GeekFactory
受託開発が抱える本質的な非効率性について考えました。ここで挙げたことはどの開発プロセスでも発生しうる問題と思います。 外注のオーバーヘッド 契約に係るコスト。 限られた場所や時間で質疑応答を行うことによる損失 情報の伝達コストは「機会」により決まる。拠点の違い、限られた時間、組織の壁により機会は減り、伝達コストは高くなる。 打合せや質問票を中心に質疑応答を行うため、情報の伝達コストが高くなる。 発注側の縦割り部門、受託側の下請け構造により、情報の伝達コストが高くなる。 決定に要する時間が長くなる。 開発者が業務プロセスを学習するコスト 前提として、どんな要件でも学習コストは必ず発生する。 過去に学習した知識を再利用できるとは限らない。受託側に業務スペシャリストが存在するとは限らない。 発注側から業務に関する説明を受ける機会（＝教育）が十分にないため、極めて非効率な学習にならざるを得ない。
400万行のコードを15分で見える化！ プログラム解析ツール『Understand』で開発効率アップ
システムの多機能化により、プログラムの内容が複雑化している。テクマトリックスの『Understand』は、プログラムの構造を可視化することで、ソースコードの解析時間を大幅に削減できる開発支援ツール。今回は同社の福永一寛氏に、Understandの機能や特徴について聞いた。 システムの多機能化により、プログラムの内容は複雑化している。既存コードの改修や多人数での開発における情報共有のためには、プログラム構造の理解が必須だが、ドキュメントと実装内容とが乖離している場合も多く、解析自体に工数がかかることもある。テクマトリックスの『Understand』は、プログラムの構造を可視化することで効率的なソフトウェア開発をサポートするソフトウェア開発環境。「組込みシステム開発技術展（ESEC）」にて、同社の福永一寛氏にその特徴を聞いた。 ソースコードの解析作業時間を大幅に削減する『Understand』
プロの開発者なら品質を確保できるのは当たり前 - rabbit2goのブログ
ソフトウェア開発の現場では、QCD（品質、コスト、納期）のバランスが重要と言われることがある。バランスと言っても、実際問題としてどれかを後回しにすることはあり得ないので、各項目について「それなりのレベル」を確保することが求められるが、コスト（お金）や納期（日時）は客観的な数値なので分かりやすい反面、品質なら幾らでも恣意的に解釈可能なので、結果的にバランスのしわ寄せは品質に来ることが多い。 そんな品質後回しの作業現場には、首をひねりたくなるような言葉が飛び交うことになる。 品質は評価部門で確保するので心配するな 納期最優先でドンドン作れ バグが多ければ追加人員を投入する こんな発言を聞く場合、大抵は右肩上がりの障害件数と共に開発現場はデスマーチ一直線となってしまうようだ。もちろん、テストを増やせば取り除けるバグも増えるかも知れないが、それは起こってしまった問題の対処療法に過ぎず、何ら本質的解
貧乏だってプロファイリングは出来る！！ - poor man's profiler
従来より、プロファイリングのためのソフトウェアと言えば高価なものが中心であった。もっと安く、お金を掛けずに、簡単に、早くプログラムのボトルネックを探し出す方法はないのか？！ということで編み出されたプロファイリングテクノロジーがある。その名も、「poor man's profiler」だ。 poor man's profilerの全容は、次のページで知ることが出来る。 Poor Man's Profiler http://poormansprofiler.org/ poor man's profilerは、現Facebook（元MySQL ABのサポートエンジニア）のDomas Mituzasによって開発されたプロファイリングテクノロジーである。以下が、その全ソースコードである。 #!/bin/bash nsamples=1 sleeptime=0 pid=$(pidof mysqld) f
「アジャイルの現状と未来、次に来るもの。～リーン開発への展望～」Agile Japan 2010基調講演から
「アジャイルの現状と未来、次に来るもの。～リーン開発への展望～」Agile Japan 2010基調講演から アジャイル開発手法として知られるXPやスクラムは、国内で徐々に浸透し始めています。しかしアジャイルをさらに推し進めて企業レベルでアジャイルを活用したり、あるいは企業自身がビジネスをアジャイルに回すためにはどうすればよいのでしょうか。 4月9日と10日の2日間開催されたイベント「Agile Japan 2010」。2日目の基調講演に登壇したAlan Shalloway氏は「アジャイルの現状と未来、次に来るもの。〜リーン開発への展望〜」（What Is Next In the Agile World）と題し、企業をマネジメントする視点からのアジャイルについて講演を行いました。 Shalloway氏の講演は、アジャイルについてよく言われる「プロジェクトではうまくいくが、会社レベルで展開し
IPAが書いたアジャイル開発の研究会報告書 - プログラマの思索
IPAが200頁にものぼるアジャイル開発の研究報告を公開していた。 IPAが公開している研究報告は、RubyやRailsやアジャイル開発などの昨今の話題を日本のIT業界のエスタブリッシュメントがどんな観点で見ているのか、を知る上で非常に参考になる。 運営委員に平鍋さんや羽生田さんがいて議論に加わっているのが興味深い。 気になる文言をメモ。 【元ネタ】 情報処理推進機構：ソフトウェアエンジニアリング 調査報告書[1.68MB] 研究会報告書[924KB] 成果概要資料[702KB] ・共通フレームについても、改めて見直してみたが、ウォーターフォールを標榜していると誤解されても仕方が無いなと感じた。ウォーターフォールを定義できる辞書を整備して、最後に、段階的や進化的プロセスも説明できるよという書き方になっている。要求定義が不十分であることが、リスクとして扱われている。アジャイルプロセスでは、こ
日本のアジャイルは海外と比べると周回遅れか、アジャイル開発が国内で普及するには？ IPAの報告書から
海外ではアジャイル型開発の採用は開発企業のステータスとしての側面があり、現在のアジャイルの次にくるものの議論が始まっている。我が国の状況は周回遅れとも表現されることが少なからずあった。 日本のエンジニアが生き生きと働くためにどうすればよいのか？ その一環として独立行政法人情報処理推進機構（IPA）が発表した「非ウォーターフォール型開発に関する調査」では、まとめとしてこのような説明が掲載されています。 アジャイル開発普及のための3つのポイント こうした状況を脱し、国内でアジャイル開発を普及するためにどうすればいいのでしょうか？ 発表されたIPAの報告書では次の3つの指摘がありました。 (1) ビジネス等のコンテキストに応じた開発方法の選択 開発するソフトウェアの特性やプロジェクトに与えられる制約などを踏まえ、妥当な開発手法を定めた結果として、ウォーターフォール型開発色が強い場合もあれば、その
アジャイルな開発プロセス導入にあたって検討すべきこと - Ryuzee氏の講演資料から -：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
3/19（金）のTech Fieldersセミナー「Agile Day 2 - ペアで参加し、セッションとワークショップを楽しもう！」の講演の1つに表題の講演があったそうだ。講演資料がここで公開されている。全体とりまとめをされている長沢氏のエントリにも紹介がある。IBMエバンジェリスト玉川氏、すくすくスクラムの今村氏の講演とワークショップで構成されたそうだ。 講演資料にはプロセスを変える際に検討すべきこと、準備すべきことが書かれている。これからアジャイルな開発プロセスを導入しようとする方だけでなく、アジャイルに限らず開発プロセスの変更や新しい方法を導入するとき一般にも、通用する内容というのが私の印象。 私が興味深いと思ったことは以下のとおり。 現状がうまくいかないからといって、目的を明確にせず、プロセスを変えたり、技術・技法を導入しようとしない。 導入に際して組織のトップへの働きかけと現場
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
