dfltweb1.onamae.com – このドメインはお名前.comで取得されています。このドメインは、お名前.comで取得されています。 お名前.comのトップページへ Copyright © 2020 GMO Internet, Inc. All Rights Reserved.
生産性（続き）、アーキテクチャとフレームワーク (arclamp.jp アークランプ)
前回のエントリから時間が空いてしまいました、ごめんなさい。せっかくひがさんとkoichikさんにコメントをいただいたので整理します。 ひがさんのコメントが象徴的だと思っていて、 選ぶことが大事じゃなくて作ることが大事なのでは。 という点で、僕は「選ぶことが大事だ」と思っています。そもそも僕はひがさんやkoichikさんのように「（フレームワークを）作る」力がない（気持ちとか、そういうのも含めて）。 なので、koichikさんの 規模で世の中の 80% を占めるところのエンタープライズシステムでは Spring の方が生産性を高められる＜中略＞の根拠たり得る説得力ある意見が聞きたかった については、「選ぶ」という視点ではSpringの方が最適化されているからという答えになります（ここまで断定的な言い方をしているつもりはなくて、『そういう場合が多い』というぐらいだけど）。 「規模で世の中の 8
Springの生産性 (arclamp.jp アークランプ)
これは言っておかねばなるまい。ひがさんのCTCと夜の決闘より。 生産性を向上させるということを主目的としてフレームワークが作られたのは、基本的(もちろん例外はあるけど)にRails以降のフレームワークです。 Railsは、Struts、Spring、Hibernateへのアンチテーゼとして登場しています。裏を返せば、Struts、Spring、Hibernateを組み合わせても生産性は出ないということです。 生産性という言葉をどう取るかによりますが、確かにSpringはコードを短く書くためのフレームワークではありません。 そもそも生産性を上げるためには、アプリケーションの部位毎に個別最適化していき、それらを統合するというのが正しい戦略です。これは規模にかかわりませんし、Seasarを使おうが、Springを使おうが同じ事です。 Seasarは最適化をうまく行っているフレームワークです。ただ
それでも設定が大事な理由 (arclamp.jp アークランプ)
ひがさんのエントリ「規約ベースのフレームワークのほうが覚えることが増える? 」を読んでいて、ふとした気づき。 暗黙的な規約は直感的ではない 結論から言えば、僕は"暗黙的な規約（Tacit Convention）"ではなく"形式的な設定（Articulable Configuration）"が重要だと思っています。ちなみに、Tacit Knowledgeは暗黙知でArticulable Knowledgeは形式知のこと。 なぜなら"暗黙的な規約"は、ある意味で直感的ではないからです。 人間が情報に反応するためには、情報が何らかの形で形式化されていなくてはいけません。 たとえば何かの操作を方法を学ぶ場合を考えてみます。説明書というのは操作方法を形式化したものです。しかし、直感的ではない。それは操作対象そのものに触るわけではなく、絵などで遠まわしに説明されているからです。 一方、説明書なん
ずっと足らない経済と自分で作る経済 (arclamp.jp アークランプ)
arclamp.jp アークランプ ITアーキテクトが、ビジネス書とかデザインとか建築とかからシステム開発を妄想するブログ 梅田さんのエントリ経由で知った、「The Economics of Abundance」という概念。 ロングテールの提唱者、クリス・アンダーソンが新しく言い出したことで、大筋としてはチープ革命から起きている現在の流れを示しているもの。いままでが"Scarcity Economics"で、これからが"Abundance Economics"。参照は、以下。 梅田さんのエントリ 原文 日本語：日本語でわかるロングテール著者の新理論 で、超訳なのですが、Scarcityっていうと意味としては「足りない」って感じなのですが、うん、資料とかをみると皮肉をこめて「ずっと足らない経済」みたいな感じかなと。で、Abundanceは超訳して「自分で作る経済」。 ずっと足らない経済
要求2.0開発 (arclamp.jp アークランプ)
要求開発アライアンスの10月定例にて「要求2.0開発」というテーマで話をしてきました。題名は理事の細川さんから依頼をいただいたときにノリでつけた名前です。かなり勢いに任せた内容はなっていますが、まぁまぁ（ｗ。 要求開発2.0ではなくて、要求2.0の開発。これからの時代は要求その物が2.0化してきます。手法うんぬんではないのです。言い換えれば「ビジネスのシステム化2.0」ではなくて「ビジネス2.0のシステム化」をテーマにしていかないといけないと考えまています。 資料はアライアンスのページにあがると思いますがサマリを書いておきたいと思います。 今、何が起きているのか 次のスクリーンショットを見てください。なんだと思いますか？ 実はこれ、日本全国1万ヶ所のホテルに●を置き、最低価格が高いほど赤くしたものなのです。長野から伊豆とか、京都奈良ならあたりが赤くて、東京、大阪は件数が多いものの価格が高
階層化するサービス (arclamp.jp アークランプ)
arclamp.jp アークランプ ITアーキテクトが、ビジネス書とかデザインとか建築とかからシステム開発を妄想するブログ SOA自体、特に難しい概念ではありません。しかし、どうしてもややこしくなるのがサービスという概念です。栗原さんの書かれた「本当は単純な「SOA」という考え方」では、 実際には、SOAの考え方は極めて単純である。ソフトウェアを「サービス」という部品の集まりとして構築しようというだけのことなのだ。 サービスとは「複数のアプリケーションをまたがって共用され得るソフトウェア部品である」と言える。 サービスはビジネスプロセスの一部（サブプロセス）を表現していることが多い。 このことから、SOAとBPMの相性は極めて良いということが言える。SOAにより、ビジネスプロセス（を実装するソフトウェア）を部品化し、BPMでそれを組み合わせ、ワークフロー管理することで自由度の高い業務システ
稚北講義「スクリプト on JVM」第1回
arclamp.jp アークランプ ITアーキテクトが、ビジネス書とかデザインとか建築とかからシステム開発を妄想するブログ 2006/7/9（日）に行なった稚北 東京サテライト校での講義記録です。3回シリーズの第1回はスクリプト環境の概観ということで、Java標準仕様周りの情報をインプット後、GroovyとRhinoをひたすら触るという形で進めさせていただきました。 なお、はじめのスクリプト概観はJavaOne2006報告会講演記録を参照してください。GroovyとRhinoは、作ったコードをまとめてダウンロードできるようにしてあります。Eclipseを使ったので、Eclipse用のプロジェクトファイルにはなっていますが他のツールでも使えます。 Groovy Groovyは2003年ぐらいから開発がはじまったJava専用のスクリプト言語環境です。言語仕様だけでなく、どう使うべきかまで含
Shibuya.js Technical Talk #2 (arclamp.jp アークランプ)
arclamp.jp アークランプ ITアーキテクトが、ビジネス書とかデザインとか建築とかからシステム開発を妄想するブログ 2006年 6月30日(金)に行なわれたShibuya.js 第二回目のイベント、Shibuya.js Technical Talk #2 に参加してきました。はてなメンバーが主催者にいるこのイベントはJavaScriptをキーワードにした技術関連の講演を連発するという内容。諸事情によりご招待いただいて見ることができました（なにせ参加申し込みがあっという間に終わる人気イベントですからね）。 もっともクールだったのは、id:brazilさんによる「私の考えるJavaScript」。作りこまれた資料、テンポの良いプレゼン、そして本質をつく内容。文学からプログラミング言語を語るという素晴らしい試みでした。ぜひぜひ参考にさせていただきたいプレゼンです。 懇親会では色々とお話
TOYOTAで考えた、見える化の本質 (arclamp.jp アークランプ)
arclamp.jp アークランプ ITアーキテクトが、ビジネス書とかデザインとか建築とかからシステム開発を妄想するブログ 昨日、ご縁があってTOYOTAでチーフエンジニアを務められていた方から、自動車の開発プロセスについてお聞きする機会に恵まれました。 まずTOYOTAにおけるチーフエンジニアという役割を理解しなくてはいけません。チーフエンジニアは、ある車を開発する場合のコンセプト作り、役員プレゼン、車体コンセプト設計、予算・原価管理、プロジェクトマネージメント、販促、マーケティングまでの全てに携わります。単純に「車を設計すればいい」というものではなく、車を作って売るというプロセスの全てに関係するというものです。 今回の講演ではプロセス全般についてざっくり触れていただくという内容でした。なおTOYOTAの取り組みについては非常に多くの本があるかと思いますので、見える化をキーワードにして
我らJava世代の課題 (arclamp.jp アークランプ)
最近、何度も思うことがあります。 JavaOneでも強調されていましたが、この10年をかけてJavaは成熟してきました。女子高生がJavaという言葉を知り、あらゆる分野にJavaが進出しています。スコット・マクニーリー氏はMicrosoftもIBMもけなさずに、貧困を解決するためにデジタルデバイドへ取り組むことが使命だといいました。Javaなしに地球は回らなくなっています。 同時にJava開発者も10年という時を過ごしてきました。今、30代の多くの開発者はJava世代といえると思います。VBやCOBOLなどのクラサバ時代から、インターネットをつかったWebアプリケーションの時代へ。Javaは、そんな中で成長してきた言語です。 JavaOne報告会2006の座談会で「Javaの成熟をいつ感じますか？」と聞かれました。僕の答えは「次の世代と会話の中」というものです。 はてななどの20代の開発者
JavaOne2006 総括 (arclamp.jp アークランプ)
11泊したサンフランシスコを離れて太平洋上からエントリしています（いまどきエコノミーでも無線LANでネットができるのです）。 USでのカンファレンスというもの まず感じたのは技術というよりもカンファレンスそのものの雰囲気の違いです。それは技術よりも人という姿勢、濃密な環境、そして参加者の雰囲気です。 カンファレンスの主な目的は技術を学ぶことですが、それ以上に人と知り合おうよという意識が非常に強く感じられます。ランチタイムにもテーブルにはJ2EE、Ajaxといった札がつけられ、そのテーブルにいけば議論がすぐに始まります。セッションも60分枠が40分ぐらいで終了して、たっぷりとQAを取るのが普通です。いろんな人が会場をウロウロして友達になっています。 こうした会場は実に濃密な環境です。2つのカンファレンスとも20万円近い参加費が必要です。その代わり食事やフリードリンクが付きますしイベントや景
頭数論 (arclamp.jp アークランプ)
なんか盛り上がっているので参加してみます。火元はこちら。 頭数論はSI業界の確かな事実 別に藤田氏の言い方に違和感は覚えません。SI業界では確かな事実です。 SI企業の事業計画を考えてみると良く分かります。SI企業に対するM&Aをされている方から聞いたのですが、買収先の企業に事業計画書を作らせると、目標売上の数字に対して人月単価で割り算した人数が記載されているそうです。その売上の実現性は営業による案件の獲得でもありますが、重要なのは人材採用計画に他なりません。 つまりSI企業の事業計画とは人材採用計画のことであり、売上は人数に比例して増えるのです。 Web2.0企業では頭数に意味はない で、藤田氏の発言に対して「理解が足らん」というメッセージが多く見受けられます。それは、もちろん正しい。 実はWeb2.0的なサービス企業は「理解が足らん」という話だけで頭数論を回避できてしまうのです。
Ajax Experience DAY2 part1 (arclamp.jp アークランプ)
arclamp.jp アークランプ ITアーキテクトが、ビジネス書とかデザインとか建築とかからシステム開発を妄想するブログ 昨日に引き続きAjax Experienceです。朝昼晩とご飯がついているのはいいのですが、おかげで会場であるホテルから1歩もでません。 Ajax on Struts 朝食後は「Ajax on Struts」。Strutsといっても1.X系ではなくて、Struts Action Framework 2 （SAF2）がメイン（Open SymphonyのWebWorkからの移籍＆名称変更）。 このセッションの中でJavaから見たときのAjaxについて2つの示唆を得ました。1つ目は、AjaxがWebアプリケーションのデスクトップアプリケーション化過程だという点。2つ目がAjaxがテクノロジーではなくテクニックだという点。 まず1つ目のAjaxがWebアプリケーションのデ
SpringFramework利用実績公開 (arclamp.jp アークランプ)
豆蔵の長谷川さんが言いだしっぺで集めたSpringの利用実績情報が公開されました。豆蔵さんをはじめ、永和さん、エーティーエルシステムズさんなどにご協力いただきました。なおGNUライセンスなので好きに使っていただいて大丈夫です（自分の実績を足したい場合にはご一報を！）。 http://modern.sourceforge.jp/ 僕の周りでは、どんなに大規模な案件でもDIコンテナを使わないというのは考えられない状況にあります。 そもそも使わないリスクというものがほとんどないのです。 DIコンテナがEJBに対して軽量コンテナと呼ばれるという説明があるからか、ランタイムのアプリケーション・フレームワークであるかのような印象を持ちがちです。 しかし、実際にはDIコンテナはアプリケーションの構成管理をしているだけで、その解決をランタイムにしているに過ぎません。ですから、ランタイムで変なことがおきる
SIer2.0 @ET研 (arclamp.jp アークランプ)
arclamp.jp アークランプ ITアーキテクトが、ビジネス書とかデザインとか建築とかからシステム開発を妄想するブログ 渡辺聡さん主催のEmerging Technology研究会に参加してきました。4月開催のお題は「SIer2.0」です（渡辺さんのレポートはこちら）。 報酬構造の問題 いろいろな議論があったのですが落ちていく先は同じで成果報酬の話でしょうか。特にモノに落ちない成果、いわゆるコンサルや調整などです。 結局、プロジェクトがうまくいくかどうかは「どんなシステムをどう作るのか」という事が現実的であるかに掛かっています。上流で言えばステークホルダー間を調整したり、問題点を明確にしたり。開発現場であれば、良い方式設計を行い良いリソースを集める。 しかし、こうしたシステム作りの環境を整えるという作業に対価が支払われません。上流であればプリ・セールスという言葉で片付けられ、現場では
arclamp.jp アークランプ: それってWeb2.0なんですか？
arclamp.jp アークランプ ITアーキテクトが、ビジネス書とかデザインとか建築とかからシステム開発を妄想するブログ 正直、しばらくエントリできなかったのは、このネタがずっともやもやしていたからなのですが、まとまった気がするのでエントリ。 ブランドをハイジャックさせよ まず、ブランド・ハイジャックという本を読みました。この本はマーケティングの本です。ブランドを消費者にハイジャックさせることで新たな価値を"共創"せよみたいな感じ。 co-create hijack = 共創型ハイジャック。ブランドのイデオロギーや使い方、ペルソナ（個性）などを生み出すようサブカルチャー層を取り込み、そうすることで大衆市場への道のりを整備すること。 ここで重要なのはインターネットの存在です。口コミで成功した「ブレアウィッチプロジェクト」はWebサイトで火がつきました。でも実はその裏に巧妙に仕掛けられたも
ITアーキテクトってなんだ？ (arclamp.jp アークランプ)
arclamp.jp アークランプ ITアーキテクトが、ビジネス書とかデザインとか建築とかからシステム開発を妄想するブログ 某所でIT関連書籍の編集者に「あなたはITアーキテクトを名乗っておられるが、あなたはITアーキテクトをなんだとお考えですか？」と聞かれました。 そのときの僕の答えは「アプリケーションの"クライアントにとっての価値"を説明できる人」というものです。そのアプリが、どんなに技術的にださかろうとクライアントに、その価値を説明できればいいわけです。そういう説明責任がアーキテクトの任務だと思っています。アーキテクトがアーキテクチャーの勉強をするとか、そういうレベルは当たり前です。その上で何が必要かと聞かれれば、言葉にする力というわけです。 で、素材の美学―表面が動き始めるとき…という建築系の本を読んでいていい言葉を見つけました。第1章ではスピロ・コストフの「建築家」という本からの
フリーランスのススメ (arclamp.jp アークランプ)
arclamp.jp アークランプ ITアーキテクトが、ビジネス書とかデザインとか建築とかからシステム開発を妄想するブログ 昨年12/20に個人事業主になり1年が過ぎました。思ったよりも楽だったし、なにより楽しかったというのが率直な感想です。 楽だ、と感じるのは、良い出会いがあったため安定した収入を得られたためです。楽しかったのはブログ、雑誌、講演、案件を通じて多くの方と知り合い、いろいろな話ができたことです（そして脂肪が溜まりましたｗ）。 フリーランスは企業起業家ではない 「雇われない生き方」を選んだ理由。たぶん、仕事を出す側と対等の立場になりたかったから。つまり、やりたくない仕事をやらない権利が欲しかったのだと思います。 すごく重要なことですがフリーランスは企業起業家ではありません。あくまでも自分の能力を提供し対価を得る人間です。ここを勘違いしないでください。 僕は案件に組み込まれ、
プロジェクトマネジメントとプロジェクトコントロール (arclamp.jp アークランプ)
arclamp.jp アークランプ ITアーキテクトが、ビジネス書とかデザインとか建築とかからシステム開発を妄想するブログ ちょっと前の記事ですがnikkeibp.jpの"マネジメントとコントロールは違う"が面白かったです。 プロジェクトコントロールとは失敗しないようにすること 企業のリスクマネジメントの話なのですが、次の マネジメントの意味は、do right things、正しいことをする、である。これに対し、コントロールは、do things right、事を正しくする、である。 話を思い切り単純にして進めれば、マネジメントは企業が成長していくための活動であり、コントロールは企業が失敗しないための活動である。アイデアをうまく育て、売れる商品を作り出した企業は、マネジメントされていたことになる。逆に、製造現場をうまくコントロールし、高品質の商品を作ったとしても、それが顧客に受け入れら
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
