タグ

ブックマーク / www.arclamp.jp (9)

  • 生産性(続き)、アーキテクチャとフレームワーク (arclamp.jp アークランプ)

    前回のエントリから時間が空いてしまいました、ごめんなさい。せっかくひがさんとkoichikさんにコメントをいただいたので整理します。 ひがさんのコメントが象徴的だと思っていて、 選ぶことが大事じゃなくて作ることが大事なのでは。 という点で、僕は「選ぶことが大事だ」と思っています。そもそも僕はひがさんやkoichikさんのように「(フレームワークを)作る」力がない(気持ちとか、そういうのも含めて)。 なので、koichikさんの 規模で世の中の 80% を占めるところのエンタープライズシステムでは Spring の方が生産性を高められる<中略>の根拠たり得る説得力ある意見が聞きたかった については、「選ぶ」という視点ではSpringの方が最適化されているからという答えになります(ここまで断定的な言い方をしているつもりはなくて、『そういう場合が多い』というぐらいだけど)。 「規模で世の中の 8

    itengineer
    itengineer 2008/06/21
    フレームワークは使うもので、思想の中核になるものじゃないよね。
  • オンリーワンになるためのエンジニアプロ論 (arclamp.jp アークランプ)

    開発の現場で集めたインタビュー集、オンリーワンになるためのエンジニアプロ論。僕のインタビューも掲載されています。 僕が新卒で会社に入ってから、いまにいたるまでのまとめみたいになっています。技術への目覚め、働き方への気づき、そして、その根底にある考え方。 「インターネットの可能性を信じているから」だと思います。きっと世界には、自分に共感してくれる人がいて、その人とインターネットでつながることができる。そうシンプルに信じているな、と。 自分の快不快を直感的に信じながら、失敗を恐れずにやっていくことが重要なのではないかと。だから、小さな限られた中で最適化を目指して「小さな成功」を納めるよりも、自分の直感を信じて、より大きなくくりの中で考えて挑戦することで結果として「偉大な失敗」をするほうが、人は成長するし、次の世代に引き継ぐものが出来ると思うんです。 いいこと言っているけど、いまは実現できていな

    itengineer
    itengineer 2008/05/25
    「偉大な失敗」をまずはしないとなぁ
  • 僕はなぜアーキテクチャにこだわるのか (arclamp.jp アークランプ)

    「僕はITアーキテクトです」と名乗るのが、昔は恥ずかしかったものです。ですが、ある時期から吹っ切れていました。やはり僕の原点なんだなと思って。 そのものではなく環境を見る 大体において、「そのもの」が悪いってことはないのです。日経SYSTEMSのコラムに書いたものを引用します。 「間違えたのはITエンジニアだから悪いのはITエンジニアである」ということから一歩進んで,「なぜITエンジニアが間違えなくてはならなかったのか」と考えるわけである。そのためには,プログラミングという作業全体を俯瞰し,その前後左右に何があるのかを見る ITエンジニアを取り囲む環境の中に,バグを誘引する要素がある 書き方がバラバラな仕様書,複雑で理解しにくいアプリケーション・フレームワーク,ドキュメントが無いライブラリ群,使いこなせないIDE(統合開発環境),など。いずれも,バグを引き起こす原因になることは説明するま

  • 人月を超えるということ

    人月というのは文字通り働いた時間に応じて請求が行われるというもの。ブルーカラー的な労働をしている限りは人月で働くことは正当なわけです。 「作らない」という視点 人月を超えるためには時間に関係なく圧倒的な成果を挙げる方法を見つけなくてはいけません。でも、圧倒的に生産性をあげるという視点ではだめ。生産性を上げているというのは、あるプロセスの作業効率をあげて時間を短くしているに過ぎないので時間給の罠からは逃げられない。ありがちな話として3ヶ月かかるAさんよりも、2人月でできるBさんのほうが実入りが少ない。 では、どうするかというと「作らない」という視点になる必要性があります。作らないというのどういうことかというと「作ったものをいかに使いまわせすか」か「いかに他人に作ってもらうか」ということです。 作ったものをいかに使いまわせすか=レバレッジを効かす 使いまわすというのはレバレッジ(てこ)を効

  • SIerにあるべき組織とは (arclamp.jp アークランプ)

    最近、組織関連のを読んでいます。1つ、大きな特徴を上げるとインターネット後におきた極端な分権型組織ブームの影響を受けていることです。多くの論調は、イノベーションや創造性のためには分権型の組織が向いているというものです。これの反対が中央集権型組織。両者を比べてみましょう。 ■中央集権型組織(ツリー型) 特徴: ・コミュニケーションパスを固定化して、流量を少なくする ・プロセスを明示する ・上意下達 メリット: ・処理効率が非常に高まる ・メンバースキルのブレが安定する ・作業負荷が増えても耐えられる デメリット: ・変化に弱い。一度、固定化したものを容易には代えられない  ・プロセスそのものの非効率性が修正されにくい ・参加意識が弱い。歯車化 ■分権型組織(ネットワーク型、フラット型) 特徴: ・全員がフラットで、コミュニケーションパスがたくさんある ・適宜、

  • ITにおける品質と効率とは (arclamp.jp アークランプ)

    先ほどのエントリを最後にしようと思っていたのですが、トヨタ信奉への違和感へのnakagomeさんからのコメントが秀逸だったので。 自動車産業の製造というのは、金型作った後にやることで、何千、何万という製品を、殆ど機械的に複製することを指す。これは、ソフトウェア産業でいえば、コンパイルやビルド、または媒体コピーなどに相当するものだ。 しかし、ソフトウェア産業で製造と呼ばれるのは一般に、原始コードを書いたりすることなどを指している。自動車産業でいえば、むしろ金型を作るまでの部分に似ている。デザインの延長であって、知的で創作的で、かつ技芸的な要素の色濃い作業なのだ。 これを行灯で何とかしようとすることをナンセンス以外になんと形容できようか。 この問いかけは真剣に考えるべきことです。確かに製造業における品質向上や効率化は確実に先を行っていますし、積み重ねられてきた実績も大きい。でも、それがITにお

  • 品質についての気づき (arclamp.jp アークランプ)

    製造業における品質というのは、多くの場合は生産工程におけるブレのことをいいます。Wikipediaにによるとシックスシグマとは、次のようなもの。 6σの状態とは、ある製品組立工程の品質特性値が正規分布に従うと仮定するならば、6σの外に出る確率は、100万分の3.4である。すなわち、ある工程では100万個製品を組み立てて3.4個のばらつき(不良品)が生じる。「100万回作業を実施しても不良品の発生率を3.4回に抑える」ことへのスローガンとしてシックス・シグマという言葉は使われ、定着していった。 システムでの生産とはランタイム ではシステムでいう生産工程はどこのことでしょうか?ふつうは実装と思われがちですよね。でも、製造業における生産とは「同じ作業を繰り返し行うこと」という前提があります。だからこそ、そこで不良品が出る割合を抑えようと考えるのです。では、システムでいう生産工程とはどこか。それ

  • Facebook Platformから見る、次のアーキテクチャ (arclamp.jp アークランプ)

    Facebookの認知度は上がってきていると思います。2007年5月にFacebook Platformを発表して以降は「次世代のソーシャルOS」というラベルが貼られ、その動向が注目されています。10月24日にはMicrosoftが2億4000万ドルを出資し、評価額は150億ドル(1.7兆)に跳ね上がりました。また、11月2日に発表されたGoogleのオープンソーシャルに対しては当然のように参加を表明していません。 Facebook Platformとは Facebook Platformはサードパーティの開発者がFacebook上の情報を利用してアプリケーションを開発できる仕組みです。それだけならデータベース型ですが、加えて開発したアプリケーションはFacebookに登録することが可能です。Facebookユーザーはアプリケーションの一覧から欲しいアプリケーションをクリックするだけで自

  • ITアーキテクト:実行性のあるプロジェクト・ビジョン (arclamp.jp アークランプ)

    arclamp.jp アークランプ ITアーキテクトが、ビジネス書とかデザインとか建築とかからシステム開発を妄想するブログ 前エントリではITアーキテクトについて書いたのですが、僕が考えるITアーキテクトの作業として重要なものが「プロジェクト・ビジョン」です。 建築のビジョンは完成物が主 建築業界の建築家というと、クライアントの示したビジネス・ビジョンに対して、それを実現する建物のビジョンやコンセプトを定義するというものです。もちろん、それが建設できなくてはいけませんから建築学や物理学に基づいたチェックは行われています。 とはいえクライアントが重視するのは建築過程ではなく完成物です。それは「言うからにはちゃんと建つだろう」という最低限の約束が成立しているからです。もちろん建築業界も遅延や不良品と無縁ではありませんが、歴史的に見てびっくりするほど問題ではないでしょう。 システム開発のビジョ

  • 1