"コモディティ化と人月"の現実 (arclamp.jp アークランプ)
arclamp.jp アークランプ ITアーキテクトが、ビジネス書とかデザインとか建築とかからシステム開発を妄想するブログ まだ反響をいただくこともあり、やはりみんなが興味があるところなんだなと実感しています。 まず、大前提なのですが、「ハッカーが集められない」「アジャイルは大規模開発では難しい」という事実は、もちろんそうです。僕もそう思います。だからこそ、それをどう乗り越えるのか、という話になります（ハッカーがいると良いシステムになるとか、アジャイルは顧客満足度が高いというのも前提ですね）。 倉貫さんがトラバいただいたエントリで提唱されているEXPも同じような問題意識から始まっています。XP祭り2005に倉貫さんのオープンニングセッション資料（PDF)があります。 SIerは、クライアントにとってリスク回避になっているのか？ まず、自社でハッカーを雇うのが現実解でないのもわかります。
TOYOTAで考えた、見える化の本質 (arclamp.jp アークランプ)
arclamp.jp アークランプ ITアーキテクトが、ビジネス書とかデザインとか建築とかからシステム開発を妄想するブログ 昨日、ご縁があってTOYOTAでチーフエンジニアを務められていた方から、自動車の開発プロセスについてお聞きする機会に恵まれました。 まずTOYOTAにおけるチーフエンジニアという役割を理解しなくてはいけません。チーフエンジニアは、ある車を開発する場合のコンセプト作り、役員プレゼン、車体コンセプト設計、予算・原価管理、プロジェクトマネージメント、販促、マーケティングまでの全てに携わります。単純に「車を設計すればいい」というものではなく、車を作って売るというプロセスの全てに関係するというものです。 今回の講演ではプロセス全般についてざっくり触れていただくという内容でした。なおTOYOTAの取り組みについては非常に多くの本があるかと思いますので、見える化をキーワードにして
JavaOne2006 DAY2 (arclamp.jp アークランプ)
#typoがあったので、修正しました。 DAY2です。 Spring Framework Update ロッド・ジョンソン氏によるSpring 2.0の説明。Aspect Jとの統合は既報どおり。それ以上にコンフィグの話が中心でした。このブログでも何度も紹介していますが、名前空間による設定ファイルの拡張機能を全面的に導入してきました（参考：xbean ある意味、究極の統一定義）。例えばAOPも <aop:config> <aop:aspect bean="javaBeanMonitor"> <aop:before pointcut="execution(public !void get*())" method="beforeGettor" /> <aop:afterReturning pointcut="execution(public !void set*(*))" me
頭数論 (arclamp.jp アークランプ)
なんか盛り上がっているので参加してみます。火元はこちら。 頭数論はSI業界の確かな事実 別に藤田氏の言い方に違和感は覚えません。SI業界では確かな事実です。 SI企業の事業計画を考えてみると良く分かります。SI企業に対するM&Aをされている方から聞いたのですが、買収先の企業に事業計画書を作らせると、目標売上の数字に対して人月単価で割り算した人数が記載されているそうです。その売上の実現性は営業による案件の獲得でもありますが、重要なのは人材採用計画に他なりません。 つまりSI企業の事業計画とは人材採用計画のことであり、売上は人数に比例して増えるのです。 Web2.0企業では頭数に意味はない で、藤田氏の発言に対して「理解が足らん」というメッセージが多く見受けられます。それは、もちろん正しい。 実はWeb2.0的なサービス企業は「理解が足らん」という話だけで頭数論を回避できてしまうのです。
プロジェクトマネジメントとプロジェクトコントロール (arclamp.jp アークランプ)
arclamp.jp アークランプ ITアーキテクトが、ビジネス書とかデザインとか建築とかからシステム開発を妄想するブログ ちょっと前の記事ですがnikkeibp.jpの"マネジメントとコントロールは違う"が面白かったです。 プロジェクトコントロールとは失敗しないようにすること 企業のリスクマネジメントの話なのですが、次の マネジメントの意味は、do right things、正しいことをする、である。これに対し、コントロールは、do things right、事を正しくする、である。 話を思い切り単純にして進めれば、マネジメントは企業が成長していくための活動であり、コントロールは企業が失敗しないための活動である。アイデアをうまく育て、売れる商品を作り出した企業は、マネジメントされていたことになる。逆に、製造現場をうまくコントロールし、高品質の商品を作ったとしても、それが顧客に受け入れら
ApacheにAJAX Toolkit Frameworkが提案 (arclamp.jp アークランプ)
TuscanyはエントリしないくせにAJAX Toolkit Frameworkはエントリします（だってSCAが理解できなかったんだもん）。 日本時間20日深夜にApache Incubatorあてに"AJAX Toolkit Framework"が提案されました（提案書のメール）。 これZimbraとIBMのエンジニアが中心というから驚きました。ZimbraといえばBEA Systemsの元CTOスコット・ディッゼン氏を引き抜き、カレンダー、メールなどを含むZimbra Collaboration Suiteをリリースしたことで知られるベンチャー。 しかも、そこらのAJAXフレームワークとは考えていることのでかさが違います。EclipseプラグインとしてAJAX/DHTMLのIDEを提供がメインになるようです。 a JavaScript editor with edit-time syn
AISASはうそ？ (arclamp.jp アークランプ)
AISASは、ホリスティック・コミュニケーション（秋山隆平×杉山恒太郎 宣伝会議）で紹介されていた言葉。消費者行動のAIDMA（Attention -> Interest -> Desire -> Memory -> Action）が、インターネット時代になってAISAS(Attention -> Interrest -> Search -> Action -> Share)に変わってきたと指摘したもの。興味があったら、すぐに検索して、購入し、その情報を共有するという感じだ。 ところが、製品検索の大半は直接購入に結びつかず――comScore Networks調査によると、 製品の検索を行ったユーザーのうち、実際に製品を購入したのは25％。うち92％はオフラインで購入されていた。 オンラインで購入した8％も、検索した直後に続けて製品を購入したのは15％のみで、残る85％はその後別のセッショ
システム開発のプロジェクト・ファシリテーター (arclamp.jp アークランプ)
僕がやりたいことを説明するのに「システム開発のプロジェクト・ファシリテーター」という言葉を使ったことがあります。ファシリテーションを日本語にすれば促進。狭義には円滑に会議の進めるというのになりますが、広義にはチームの力を引き出すということで良いように思います。 さて、そんなファシリテーターですが、じゃ、それがシステム開発で可能かといわれると、実は悩んでしまうことがあります。それは本当に答えを見つけさせられるのか、ということです。 システム開発で答えを見つけるのは知識が必要 ファシリテーターがやることは、答えを与えるのではなく、答えを見つけさせることです。チーム全員で答えを見つけることで、チームの方向を定め最終的なあるべき姿を考えます。皆で相談しながらキャンバスに絵を描くようなものです。 しかし、システム開発においては、この"答え"というのが非常に難しい。もちろん見つけるというプロセスが重
コモディティ化と人月への雑感 (arclamp.jp アークランプ)
arclamp.jp アークランプ ITアーキテクトが、ビジネス書とかデザインとか建築とかからシステム開発を妄想するブログ 思いつくままに書いてしまったわりには、フィードバックをいただけたので再度整理してみます。 ハッカーであれば人月の神話は実現できる 僕が書いた「ハッカーであれば人月の神話は実現できる」というのは同意していただいたみたいです。β. (Bee’s Blog)さんのエントリを引用します。 確かに、優秀な人材であれば、ほぼ見積り通りの工数かそれ以下の工数で、要求以上の品質を確保でき、結果として人月の精度がかなり向上すると思うので、この開発手法は、人月の神話を実現しうると思う。 ハッカーなんて集まらない しかし「ハッカーなんて集まらない」という指摘も同時に受けたと思います。それは、もう、その通り。なので、僕が思っているのを整理すると、次の2点です。 - 10倍優秀なら10倍払
ベストプラクティス消失が顧客主導の証 (arclamp.jp アークランプ)
ユーザー会がSAP幹部に直接質問、「日々の疑問を聞く」より。 ERPパッケージは業務に関するベストプラクティスを集合させたアプリケーション。ERPを使うことは、これまで業務に従事していた人を減らして、コンピュータに肩代わりさせるともいえる。 都築氏はこのERPの効果を取り上げて、「アウトソースすること」と表現した。しかし、SAPはESAでユーザー企業自らがビジネスプロセスを柔軟に組み替えられることをアピールしている。この戦略は、ベストプラクティスに従って業務を進めればよかったユーザー企業にとって、「選択肢が増える」（都築氏）ことを意味する。 ＠ITでの拙著“街づくり”で理解するシステム構築入門でも取り上げているのだが、パッケージ製品とはベストプラクティスという名の元、ユーザー不在で作られたものだったように思う。特にERPの場合には業界のコンサルタントやトップ企業のノウハウが混在した理想像あ
変わっていく各社の立ち位置 (arclamp.jp アークランプ)
Greg Luck氏のエントリOSCON2005: Google is the new Microsoft - Microsoft is the new IBM - IBM is the new Sun - Sun is a benevolent foundation.が面白かった。OSCON2005に参加して感想なのだが、ま、タイトル（Googleは新しいMicrosoft、Microsoftは新しいIBM、IBMは新しいSUN、SUNは善意の財団）そのままなわけです。 Googleについては、検索エンジンの独占、、、という文脈ではなくて、 "Truly great" software applies to Microsoft. I see Google as creating a new Windows only platform (Google Earth and the many
スクラムは現実解 (arclamp.jp アークランプ)
アジャイル開発というとXPに代表されるようなエンジニアリング的な要素が強いように感じられる。しかし、プロジェクトマネージメントをアジャイルにすることの方が重要だと思っている。僕が気に入っているのはスクラムだ。既に書籍が出ており、かなり明確に体系化されている。スクラムのプラクティスがなにかというのはWebや本で探ってもらうとして、なぜスクラムが良いのか・なにが難しいのか、というあたりを書いてみたい。 スクラムの良さ スクラムの良さはタイムボックスによるコントロールだ。ソフトウェア開発は、要件も技術要素も非常にあいまいで、ようはやってみなくては分からないことが多い。とはいえ何も基準がないのでは混乱をきたす。そこで、ある時間枠（土日を含む30日間）を基準とする。 チームは少人数（7人前後）で構成されており、自分達で期間内の作業にコミットする。作業ゴールは必ずテスト済みの動くアプリケーションで
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
多様性をもったソフトウェア (arclamp.jp アークランプ)