dfltweb1.onamae.com – このドメインはお名前.comで取得されています。このドメインは、お名前.comで取得されています。 お名前.comのトップページへ Copyright © 2020 GMO Internet, Inc. All Rights Reserved.
客のことを真剣に考えると、儲からない。から、どうするか (arclamp.jp アークランプ)
先日、クラウド研究会の後、朝まで飲んでた時にNRIのSさんに「なんか、仕事してて悩みないの？」って言われて、ふと出たのが 「客のことを真剣に考えると、儲からないんですよ」 っていうので、「そーだよねー、ウンウン」って大ウケされました。で、そのあとにSさんと語ったのですが、それって1つの真理ですよねと。だけど、これをきちんとエコシステムとしてビジネスモデルにするのが僕らがやるべき仕事ですよと。 今、｢見積もり2億円のIP電話を820万円で構築した秋田県大館市から学べること｣っていうのが話題ですが、それって業者からすれば儲からないってことで、これをSIerがやる理由がないんですよ。これっぽっちもない（まぁ、記事は煽りすぎで、実際には職員の工数がかかっているので2000万ぐらいにはなるのではないだろうか。それでもひとケタ違うけど）。 で、ござ先輩に言いたい。プログラマの誇りを減衰しないビジネスモ
デルは顧客志向なのか (arclamp.jp アークランプ)
元電通総研の社長が書いたという広告会社は変われるかを読んでいるのですが、うーん、微妙。 例えば、その中の一節。 インターネットの出現は、メディアだけでなく、企業も変えてしまった。 「見込み生産・大量生産」ではなく、「まず顧客（個客」ありき」という経営スタイルの誕生を意味したのである。＜中略＞「製造と顧客の立場が逆転するモデル」は、「注文生産ではあるが大量生産である」というところに最大の特徴がある。いわゆる「マス・カスタマイゼーション」である。 マス・カスタマイゼーションを体現したのが、2001年にパソコンの出荷台数で世界一の座についたデル・コンピュータの「ダイレクト・モデル」である。デルでは、「まずモノありき」ではなく、「まず顧客ありき」である。そこでは、顧客はインターネットを通じて注文を出す。もちろん、いまだ従来方式に馴染む顧客もいるので、電話での注文も受けていけているが、インターネット
SI＝人のためにシステムを作る (arclamp.jp アークランプ)
どうも執筆や提案書作成が重なるとBlogの更新が止まります。一日に書ける文字量が決まっているのでしょうか。いや、単なる言い訳ですね。 最近、SIってなんだろうと考えています。ふと「人のためにシステムを作る」ってことがSIの本質じゃないかと思いました。 アメリカにSIはいない よく比較されますがアメリカにはSIerという業態が少ない。代わりにユーザー企業が開発部隊を抱えます。世界最大の小売業者であるウォールマートともなると数千人単位で抱えているそうで、そこらの中小SIerよりも大きいわけです。それ以外のシステム会社というとIBMやSUNといったベンダーだけ。 ご存知のとおりシステム開発のコストで大きいのは人件費です。人件費を社外に支払わずに社内の経費として落とせると財務的なメリットが大きくなります。なによりも自社でリスク管理ができるのです。SOAやアジャイルのようなユーザー主体のシステム開
形態は機能にしたがうか (arclamp.jp アークランプ)
先日、建築系の方と話をしたときソフトウェアにおいても「形態は機能にしたがうか」ということで盛り上がりました。 Form Follows Function 「形態は機能にしたがう（Form Follows Function）」というのは近代建築の祖といえるバウハウスが提唱したコンセプトとして有名です。機能主義とも呼ばれますが、形態つまり見た目や形は機能に従うという考え方です。 Form Follows Functionという言葉自体は19世紀の生物学者ジャン＝バティスト・ラマルクが提唱した用不用説という進化論で使われている言葉です。彼は研究を通じて進化が存在することに気づき、 動物がその生活の中でよく使う器官は、次第に発達する。逆に、はじめから存在する器官であっても、その生活の中で使われなければ、次第に衰え、機能を失う。このことは、我々の体でも起きることであり、自明のことと言ってよい。 そ
オープン性のポートフォリオ (arclamp.jp アークランプ)
ウィキノミクスを読んでいると繰り返し出てくるのが「どこまでオープンであるべきか」「どこまで共有してよいか」という問いかけです。本の中でも、これをポートフォリオとして管理すべきだと書かれています。 オープン性のポートフォリオとは こちらのサイトによれば ポートフォリオとは、証券用語辞典を引くと“Portfolio 資産管理”と出ています。ひとりひとりの投資家が、現在持っている金融資産をトータルで指す言葉です。 それぞれの投資家が必要とする年間の収益と、それに見合ったリスクの度合いに基づいて分散投資されることになります。 投資先を一箇所に集中させずに、できるだけ分散させた金融商品で資産運用を行うこと、つまりリスクを回避すること、これがポートフォリオを作成する最大の目的です。 ということです。より戦略的に書けば金融商品ごとの安定性や収益性を考慮し、相関の低い組み合わせることでリスクを低減しなが
予測できないことを抱きしめられるか (arclamp.jp アークランプ)
arclamp.jp アークランプ ITアーキテクトが、ビジネス書とかデザインとか建築とかからシステム開発を妄想するブログ 先日も紹介した予測する力 養成講座〔セオリー〕vol.11ですが、沢木耕太郎さんの文章が良かったのでメモ。 情報を無限に手に入れても、究極的なところではあまり意味がない。情報に向かって濃く思いを寄せることができる能力がなければ、行動はできないんですからね。 （情報の）制度も量も実はそんなに必要はなくて、ある情報に対して、その情報を基に行動ができるかどうかというのが問題なんです。 自分がそこにチップを置かなければ、その情報も、情報によって判断したことも、意味を持たない。 チップを置かなければ意味を持たない、というのはそのとおりですね。どんなに情報を集めても十分なんてない。どうせ、なんらかのフィルターで情報は見てしまうのだから、そこに濃く思いを寄せられるかが勝負。それでも
人月を超えるということ
人月というのは文字通り働いた時間に応じて請求が行われるというもの。ブルーカラー的な労働をしている限りは人月で働くことは正当なわけです。 「作らない」という視点 人月を超えるためには時間に関係なく圧倒的な成果を挙げる方法を見つけなくてはいけません。でも、圧倒的に生産性をあげるという視点ではだめ。生産性を上げているというのは、あるプロセスの作業効率をあげて時間を短くしているに過ぎないので時間給の罠からは逃げられない。ありがちな話として3ヶ月かかるAさんよりも、2人月でできるBさんのほうが実入りが少ない。 では、どうするかというと「作らない」という視点になる必要性があります。作らないというのどういうことかというと「作ったものをいかに使いまわせすか」か「いかに他人に作ってもらうか」ということです。 作ったものをいかに使いまわせすか＝レバレッジを効かす 使いまわすというのはレバレッジ（てこ）を効
コミュニティはマネージメント手法なんだ (arclamp.jp アークランプ)
最近、「コミュニティってなんだろう」ってことを考えていたのですが、１つの回答としてはコミュニティはマネージメント手法なんだなって。もちろん、マネージメントというのは、経営という意味からプロジェクト・マネージメントまで幅広く含みます。 Community Driven Commercial Development なんとなく予感がしたのはIBMがそっとスタートしたProject Zero。Project ZeroはRESTベースのWebアプリケーションをGroovyやPHPを使って開発できるWebアプリケーションフレームワーク。FAQを読むと、これがオープンソースプロジェクトないことがわかります。 Can I contribute to Project Zero? IBM is following a Community Driven Commercial Development proc
[LLSpirit]VM魂@LL魂2007 (arclamp.jp アークランプ)
LL魂2007にVM魂のパネラーとして参加してきました！発表資料はこちらから。 VM魂 MSの荒井さん、SUNの戸松さんはやっぱり面白い。リアルに言語に近いところにあるから話も伝わりますね。「性能で言えばVMにやれせることも大事だけど、そのバランスも大事」みたいなところでは、.NETの場合にはIronPythonのためにフレームワークに手を入れる一方で、Javaでは難しいだろうとか。でも、Pnutsは「（世界最速という）Luaには負けない」ためにJavaVMの特性を活かしながら色々しているとか。 あとはRubyは仕様と実装が分離しない以上JRubyがJDKにバンドルされることはないだろうとか、.NetでもIronRubyが出るけど、そのためにMS社内ではほげほげしているとか、すごい話です。 僕はどちらかというとユーザー側の視点としてJavaとLLを並存させる可能性とか、言語を使い分ける/
作るための開発と使うための開発 (arclamp.jp アークランプ)
都内某所にてエンジニア話で盛り上がったのですが、そのときに出てきたのが「グローバルではPHPできないと話にならん」という話題。確かにPHPで作られたOSSというのは非常に多くて、たとえばSugarCRMとかもそう。USでも大手ユーザー企業でもPHPを重視しているところがあるそうです。 一方でRubyやJavaというのは開発者にとって"Sweet"な言語ではあるもののユーザーには難解。ユーザーにとって使いやすい言語という点ではPHPが非常に洗練されているのではないかと。 もちろんPHPが簡単だからって、へぼ開発者が作ってしまうとメンテナンス性も何もない、ということをいうことはできます。でも、ちょっと考えてみると、それは作り手の視点なのかなと。使い手の視点からすればPHPという言語はよくできているということではないかと。 つまり、世の中でコーディング作業をする人は「モノを作るためにやる人」と、
聞くべきか、調べるべきか (arclamp.jp アークランプ)
さて昨日の続きです。そもそも「問題を発見したら質問をしてくれる」ということもちゃんと考えなくてはいけません。まず問題を解決するためのプロセスを考えてみましょう。 １．最初は問題が発生したことに気づいて認知します。 ２．次に、この問題にどのように対応するのか計画を立てます。 ３．そして行動に移して解決に向かいます。 この計画は重厚長大な書類ではありません。小さくて良いので「ちゃんと考えるているか」という感じです。では、これを絵にしてみましょう。 プロセスには「計画を立てる」と「計画を立てない」がある ここで注意すべきなのかは問題解決プロセスを[1]のように正しく踏んでいるのか、ということです。計画をする、というのは予定を立ててリソース配分を行うということです。予定があれば行動段階で実績との誤差を把握することができます。この誤差が新たな問題として認識されると再計画を行っています。[1]と
答えを言うべきか考えさせるべきか (arclamp.jp アークランプ)
「プロジェクトで誰かから問題の解決策について質問を受けたらなんて答えますか？」という質問をされました。意図としてはすぐ答えを教えるべきか、それとも考えさせるべきかというようなこと。 これのフレームを考えてみるに以下のようになるかなと。 Aは問題を構造的に理解し、解決策が分かっている状態。これは既に問題はありません。理想的な状態です。 Bは問題を構造的に理解しているものの解決策が分かっていない状態。ここまでくればGoogleで調べて知識を補うなり、人に聞くなりして適切な解決策を見つけることが可能になります。 Cは問題を構造的に理解していないものの解決策が分かっている状態。これは特定に問題を解決することは可能ですが、応用や類似的な状態に対応することができません。 Dは問題も理解できず解決策も分かりません。 さて、誰かが質問をしてきたのであれば、その人はBかDの状態にあります。 特にDの場合には
フリーランスってね。 (arclamp.jp アークランプ)
Groovin' Highの「アンチ・フリーランス・エンジニアという反発心」というエントリがすばらしい。 この状況って、結局エンジニアの現状。限界だと思う。能力がある程度高まったんで、サラリーマンやってるより個人契約というか、個人事業主になったり、自由に遊ばせてくれる会社に転職するとかね。なんか小さいなぁ。エンジニアだからビジネス・センスないって、どうなの？それでいいのか？自分の能力を限界まで尽くしたら、もっとやり方違うと思うけど。そりゃみんな起業できるわけじゃないかもしれないけどね。 もうグサグサ来ますね（ｗ。 僕も自分自身が小さいなぁと反省しています。まさに自由にさせてくれる組織に居候して仕事をさせてもらっている立場。ただ僕の場合に恵まれているのは外部に対してフリーランスであるという立場を明示しながら、内部にはチームでアプローチする形が許されていることです。都合よくワラジを履き替えなが
抽象化がもたらすリアル (arclamp.jp アークランプ)
Inter Communication (インターコミュニケーション) 2007年 04月号 の特集は、「デザイン／アート 芸術と科学のインターフェイス」というもの。いくつか面白い記事があったのですが、抽象化がもたらすリアルみたいなことで思うことがありました。 まず、巻頭の茂木さんと山中さんの対談はそうだよねぇーの連続。山中さんはSuica自動改札機やCyclopsをデザインしたことで有名な方。 ところでヒューマノイド・ロボットを作るうえで、人間に似せていくほど不気味になってくるという「不気味の谷（Wikipedia）」という現象があります。山中さんは、これを「サイエンティストの傲慢」と切った上で次のように述べています。 彫刻を作るとき、睫毛を植えたり、髪の毛を生やしたりは普通しないですよね。なぜならば、そんなことをしないほうが美しく、よりリアルであることをアーティストたちは気がついてい
何をデザインしているのか (arclamp.jp アークランプ)
arclamp.jp アークランプ ITアーキテクトが、ビジネス書とかデザインとか建築とかからシステム開発を妄想するブログ ちょっと前ですが、森さんの「仕事の価値を高める「デザイン」と「クリエイティブ」」が面白かったです。 クリエイティブ・クラス 引用されている「クリエイティブ・クラス」は、リチャード・フロリダ氏の本で最近、注目されている概念です。HBRのページから引用すると（ピンクはダニエル・ピンクね）、 ピンクの考えるところでクリエイティブ・クラスを定義すると、「左脳思考だけでなく、右脳思考もできる人」であり、「何らかの専門性を持ちながらも、そこに埋没することなく全体観を俯瞰でき」、かつ「論理的でありながらも、美しさや遊びといった、論理では説明し切れない世界を理解できる人」ということになりましょうか。 という感じ。よく言われる理想的人材像の現代版でしょうか。そして、 ただ持っているだ
門番を問いただす意味 (arclamp.jp アークランプ)
先日の情動回路で登場されていた河本さんに興味を持ち「哲学、脳を揺さぶる オートポイエーシスの練習問題」を読んでいます。いくつか面白いトピックスがあったので備忘録の意味も含めて書いておきます。 カフカの小説「審判」に掟の門という短い寓話が出てきます。Googleしてみると出てきますが良さそうなものをあげておきます。3分で読み終わるので、ぜひ読んでみてください。 掟 の 門 非常に複雑な読後感を覚えます。いくつかのブログの書かれている感想を読むと「勇気をもって門に入るべし。それを妨げるのは自分の気持ち。無目的な遅延に意味はない」といういった論調が多いようです。確かに農夫は自ら待つことを選択しているように見えるのです。 門番を問いただすことに意味があるだろうか 河本さんは「門番を問いただすことに意味があるだろうか」という投げかけをしています。仮に農夫が「どうして門が続くことを知っているのか？」
パターン化は世界を狭くし、そして爆発的に広げる (arclamp.jp アークランプ)
非システム系の友人との会話で、僕の仕事を話していたときのこと。 僕がアーキテクトの仕事を「業務のパターンをみつけて、それをソフトウェア化する方法を考えることかな」といったところ、友人が「そんなことすると人間性がなくなってつまんなくなるのだ」とネガティブな反応。 いわく人間が持っている柔軟性や才能をあるパターンに押し込んでしまうことで人間の能力を制限しているのだと。そんなことするから世界がつまらなくなるのだとおっしゃる。なるほど。 僕もしゃくなので、思いつくままに「携帯電話は遠隔コミュニケーションのパターンを固定化したけど、誰も困ってないよ」と言い返してみました。 ソフトウェアのパターン化というのは、その代替された業務だけみていると確かに制限にしか見えません。融通が利かないというか。しかし、そうしたパターン化があることで情報の流通性が非常に高まります。これまでは自由なフォーマットで書いていた
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
dfltweb1.onamae.com – このドメインはお名前.comで取得されています。
構築環境の意味を読む (arclamp.jp アークランプ)