アークランプ

ITアーキテクトが、ビジネス書とかデザインとか建築とかからシステム開発を妄想するタンブラー。ブログ:http://www.arclamp.jp/

permalink
モックアップは、装飾を排除しないと評価が難しくなる

モックアップはきれいに作りすぎてはいけない、という話 - 7korobi8oki.com (via gothedistance)

装飾を排除して、かつコンセプトの整合性はきちんと入れないといけない。何度も言っているのに何で自爆するかな。

permalink

夢を見ること、健やかなること

2009/10/6に青山ブックセンター六本木店で行われた西村佳哲さんと石村由起子さんのトークイベント。メモなので時系列はバラバラです。

西村「お店にはたくさんのスタッフがいるけど」

石村「いまは40名。スタッフの中には自分が客として来てみて気持ちよかったからといって働き始める人がいる。そうした人は完成された状態しか見ていない。だから、そこに至るまでにあるまでの作業に押しつぶされがち。自分のやりたいことと違う、と。お客として来ることと、それを仕事にするのは全然違うこと。」

西村「石村さん自身も、そういう経験がある?」

石村「自分も25年前に始めたときには「自分が思っていたのと違う」と良く感じていた。あぜ道に咲く花をキレイと思って花瓶に生けていたら「こんな草、見たくもない、どけてくれ」と言われたこともある。食べ残しや飲み残しもすごい気になる。自分がやっていることが間違っているのではないか、自分には価値がないのではないか?いつも葛藤している。でも、少しずつお客様が増えていくという結果によって自信がついてきた。」

西村「でも、25年間やってこれた」

石村「先日、夫が身体の調子が悪くて病院に行ったら「パーキンソン症候群」(パーキンソン病手前)と診断された。いろいろな本を読んだが不治の病とあった。そのとき「これまで自分は夫に支えられて好きなことやってこれたから、これからは私が車いすの夫を支えよう。寂しいだろうから、たくさんの人を家に呼ぼう」と思えた。すごく前向きに事態をとらえて悲観的にはならなかった。その後、違う病院へいったらヘルニアであることが分かって安心した。そのときに前向きに考えられた自分がいたことが分かった。25年前では無理だった。くるみの木が私を育ててくれた。

西村「どうやって問題を解決しているの?」

石村「私の中には「ゆるがない由起子さん」がいる。現場にいる私は、ちょっとしたことにわたわたしている。そんなとき、もう一人の由起子さんが「あんたが好きではじめんやろ」と言ってくれる。その由起子さんは、常に未来を見ている。未来に向けて真っすぐに立っている。わたわたしている現場の私を冷静に見ていて、冷静に答えを出してくれる。神様って、自分の中にいるんだと気付いた(宗教はやってませんよ;-))」

西村「今の課題は?」

石村「これまではお客様ばかりをみてきた。これからはスタッフのことも考えていきたい。どっちもスゴイ大事だと気付いた。いつも「明日どうなるか分からない」と思って過ごしている。サービス業ってそういうもの。ただ、スタッフと未来の話ができていると「明日も大丈夫かな」って思える。スタッフは大事。」

(会場から:仕事はツライが家族もいるから辞められない友人にアドバイスを)

西村「アドバイスしない。結局、その人の問題。重い荷物を一緒に持ってあげることはできるから、たくさん話は聞いてあげるけど」

石村「優しい言葉が優しさとは限らない。結局、自分で解決するしかいない。どんなに辛くても悩んでも、最終的に答えが出せるのは自分だけ。周りがなにかできるっていうわけでもない」

(会場から:25年間やってこれたエネルギーの源は?)

石村「25年間やってこれたのは夢を見続けたから。きっと、普通には計画とか目標というものだと思う。夢って叶うもの。夢みたときから目標に向けて全てが動き出す。」

(会場から:コレだ!というものが見つかったとき飛び込む?まずは経験を溜める?)

西村「人それぞれ。ただ、他人にやりたいコトを投影してエネルギーを浪費することはしなくてない。たとえば小説家になりたい人が小説家の周辺の職業に就くとか」

(会場から:魅力的な人とは?)

西村「健やかであること」

石村「根っこがある人。年齢には関係ない」

感想:とても「打ち合わせゼロ」とは思えない濃密な言葉ばかり。で、石村さんは、とてもカワイイ人。夢を叶える人として、経営者としてあふれ出るナニカがある。

permalink

25 投稿日:2006/05/03(水) 01:06:40
営業上がりの上司が最初に言ったお言葉。

「開発者全員が最初からバグが1つもないプログラムを作って下さい!そのための方法を皆さんで考えて下さい!」
と熱く語ってくれました。

何でも、最初からバグを一つも入れなければ開発期間が短くなって、テスト工程がいらなくなって期間も経費も大幅削減できるからだそうです。

28 投稿日:2006/05/03(水) 01:30:28
»25
他人事だと笑えるな

29 投稿日:2006/05/03(水) 01:32:18
»25
素晴らしい上司を持ったな、うらやましいぜ。

30  25 投稿日:2006/05/03(水) 01:49:06
»28-29
笑えるか、コンチクショーorz

大馬鹿者だ

営業上がりの上司が言ったこと コピペ新聞 (via petapeta)
2008-09-10 (via gkojay) (via eternityscape)

(via puruhime) (via takeori) (via tenkao) (via ishibashi)

でもさ、けっこう面白い命題だと思うよ。間違ってないし。その上司とやらをまじえて真剣に議論する価値はある。バグ、テスト、品質、開発、コストなどなど。対決しないで、対話できれば得られるモノは多い気がするよ。

permalink twittermeigen:
saetomin
アートじゃなくて、デザインだろ、デザイン

twittermeigen:

saetomin

アートじゃなくて、デザインだろ、デザイン

permalink

オープンソースは、社会的組織における、所有権に関する典型的な理解に対する実験である。所有権とは、もちろん、どんな条件下においても複雑な概念である。しかし、近代経済における所有権というものが、どのように理解されているかを少し考えてみて欲しい。最も一般的な所有権の定義とは、ある個人が、ほかの個人との関係において、ある「物」について強制力をもった主張をすることである。私有財産というものは、他人に「譲る」(交換したり、売ったり、貸したり、さもなければ移転する)ことができるということの上に成り立っている。「物」を管理する、もしくは他人を排除する権利が、所有者の定める条件の上に成立する。(中略)

オープンソースは、所有権に対する根本的な理解をラジカルに、真逆のものへと変革する。オープンソースにおける「所有権」は、基本的に、配布する権利であり、他者に使わせない権利ではない。この文章がまだ不自然に聞こえるとしたら、それは、所有権の概念が、いかに私たちの本能において他者を排除することと一体化しているかの証拠というべきだろう。

死んでしまったら私のことなんか誰も話さない: オープンソースは「所有」に対する既成概念に相反する/Steven Weber “The Success of Open Source”

CCの概念も同じ。使わせない権利ではなくて、使ってもらう権利。逆にいえば、いかに使わせないかではなく、いかに使ってもらうか。クラウドやWeb2.0が持つプラットフォーム性は後者に含まれるのです。僕の中ではOSSとクラウドは直線上。

permalink これからのITアーキテクト/開発者のあり方 :ITアーキテクト Vol.25
ITアーキテクトもこれで休刊。最後の写真がサグラダ・ファミリアっつーのは粋だねぇ。

これからのITアーキテクト/開発者のあり方 :ITアーキテクト Vol.25

ITアーキテクトもこれで休刊。最後の写真がサグラダ・ファミリアっつーのは粋だねぇ。

permalink

テイラーの流れをくむIE技術者たちは、その後も工場の現場作業に対して、ストップウォッチを武器に取り組みつづけ、地味ながら立派な成果を上げつづけた。さらに人間動作を詳細に分解して、標準動作による生産性予測や改善もできるようになった。今日、まともな工場ならば、IE技術者による作業設計と不断の改善活動を定常的に行っている。

しかしながら、日本の製造業の多くの企業では、生産性のボトルネックはすでに製造現場から、設計や管理を中心とするオフィスワークに移っている。にもかかわらず、オフィスワークにおける作業時間分析は、あまり行われているのを見たことがない。不思議ではないか。

いや、我が社はタイムシートをつけている。何月何日に、どの仕事で、何時間働いたかはすべて正確に把握している--そう反論されるかもしれない。しかし、それでは不十分なのだ。時間分析には、目的別の分析と、様態別の分析と、そして機能別の分析があることを、多くの人は理解していない。タイムシートは、目的別の時間集計には使えるだろうが、様態や機能の分析にはすぐには使えない。

<中略>

同じようなことをオフィスワークで知るためには、目的別タイムシートではなく、様態別・機能別の時間集計が必要になるのである。むろん、こんな細かな作業記録を、毎日毎日タイムシートにつけることなど不可能だ。だから、サンプリング期間を区切って(例えば1日とか1週間とか)、職場全体で調査をかける必要がある。そうしてはじめて、本当の意味で「付加価値生産性」向上のための基礎データができるのである。そのために、どのようなフォームやツールがいるのか、知恵と工夫のポイントでもある。

タイム・コンサルタントの日誌から : ベーシックとしての時間分析

オフィスワーク(=ナレッジワーク)のカイゼンをするというなら、このぐらいやれってことだな。ただ実行に移すのは大変。プロジェクトごとにボトルネックも違いそうだし。

とはいえ、ユーザーに対して観察による定量化とPDCAを言うなら、同じようにスタッフに対しても取り組めということだ。

permalink

 重要なのは、未来に起こりうることを想定し、それに可能なリスクヘッジをするということです。現時点の要件だけを聞いて作ったところで、それが保守段階でだんだんと利用者との不適合をおこすのであれば、それもまた作り手としては能力が低いということになります。

 何度も繰り返していますが、小学生のお使いじゃないんだから「言われたとおりに作りました」じゃダメなんです。そんなSIerは駆逐されていきます。要件を正確に聞くことは本質じゃない。そうではなくて、要件の先にあるユーザーの真のニーズや将来的なベネフィットまで踏まえていくことが大事なのです。

 一度作られた企業システムとは少なくとも5年は付き合っていかないといけません。未来を見るといっても予測しきれないこともあるし、逆に失敗することもある。それでもユーザーときちんと話をしていけば解決策は見つかります。要件はコミュニケーションの手段でありプロセスです。それを結果のように受け取ってしまっては、相互の対立関係を変えていくことはできません。

似ているからといって機能統合してはいけない

日経SYSTEMS10月号コラムです。将来を予想するのは簡単ではありませんが、だからといってしないのは責任放棄です。

permalink

僕はアーキテクチャによって人々を管理したいのではありません。アーキテクチャによって人々の世界観を拡げることができたら、どんなにステキでしょう。

 もちろん、手段として善い面も悪い面もあるはずです。僕が創り出したモノが、もしかしたら、多くの人に迷惑をかけてしまうかも知れない。これはものすごい恐怖です。社会で生きるからには他人からの評価を気にしなくてはならない。

 でも、僕はどうしようもなく、こうした仕事をしてみたいのです。それが僕の生きる力なのです。僕はソフトウェアを作ることがたまらなく好きで、当事者でいないとダメなんです。

自分をいかして生きる (西村さんへの手紙)

ブログ書いた。昨日、いろいろTwitterしてたのからまとめてみたよ。

permalink

なんかトレイラーそのものは面白そうでいいんだけど、トレイラーの最後に出てくる字とか日本語サイトの「アバター」のフォントが台無しすぎる。