2006年12月17日 (日)

接点

今年一年、日記を書いていろいろ考えてきた。結果としてとても良かったと思う。曖昧にしてきたことを少しずつクリアにできたと実感できる。

私の生業はコンピュータのシステム開発だ。そう言うと難しそうな仕事だと言う人がいる。それは単純な誤解で、この仕事の難しさは他のどんな仕事の難しさと変わるところはない。幸いなことに、この仕事に従事する人の多くはネットワークに接続していていろいろとヒントを与えてくれる。そこから多くのことを学ぶことができる。とてもラッキーだ。

例えば「ソフトウェア開発の落とし穴」。ここに書かれていることを理解し実践できればソフトウェア技術者として最強間違いなし!本当に必要なことは然程多くない。もちろん、理解すべきことがわずかだとしても、そのマスターが簡単なわけではない。まず最初の壁は、その理解を必要と理解すること。それを重要と思うか思わないか、そこが分かれ道となるだろう。

「ソフトウェア開発の落とし穴」の中で気に入っているひとつは、「どんな初心者でも時間さえかければそのシステムを開発することができる」というところ。大事なところなのにすっかり忘れてしまってた。

誰もが同じ道を歩くわけでない。また誰もが自分の道しか歩くことはできない。僕は、まずクリアに観察できるようになる。目標が見えるようになってくる。後はどんなに時間がかかるとしても、最短の道を歩いていく。これがとりあえず今日の自分が辿り着けた自分とビジネスとの接点だ。

| | コメント (0) | トラックバック (0)

2006年9月 2日 (土)

ビジネス再考

という風に、いかにも人間らしいのらりくらりした回り道をこの業界ではビジネスとしている。新しい言葉をどんどん作り出し、新しい消費を作り出している。忙しそうに戦う場を作り出し嬉々として動き回る。大事なことはどこに向かって歩いているか?ではなく、ただそこで戦うことができること。落ちこぼれもせず。

なので、ときどき、ふと気付けば虚しくなることがある。あるいは時には心を撃たれ大怪我をすることもある。気がふれて仲間を撃つことがあるかもしれない。再チャレンジというのは、心の傷を癒して再び戦場に戻ること。

心だって撃たれればほんとうに死ぬこともある。そうすると、ビジネスとか言って。ビジネス=忙しく。という意味だよね??みんなが急げばその場は本当に戦場となってしまう。楽しかったのも束の間。やがて悲しみばかりが多くなり、恨みの塊となって僕等の生きてく場を覆うことになるだろう。もしかして神さまはその先の結論が見たくて人間を作り出したのかも。

でもさ~~
歩みを止めることだってできるんだよね>人間はその意思で。もし戦うのが目的ではなく、ただ単に急ぎすぎてるだけ。というのだったら、歩調を直すこともできる。ゆっくり周りの景色を楽しみながらさ~~。そんな調子だからその社会の原動力はビジネスでなくなる^^;;というイメージも人間には可能なんだよね。

でだ、僕等は先にいったい何処?を望んでいるのか。
そこまでどこをどう回り道していくのか。滅びの美を見ていくのも道だろう。ざらざらした荒野を行く人もいる。花の草原をのんびりいく人達もいるかもしれない。どの道も、たくさんの道がいずれ訪れるひとつの因果の世界に続いていく。さてと、どっちへ行こうかなあ~~

| | コメント (0) | トラックバック (0)

回り道

非常に長い目で見ればどんな問題もその問題はいずれは解消される。そのスパンの中での開発プロジェクトはOneOfイテレーション。ある地点に立つのに1イテレーションで済む場合もあれば、3イテレーション費やすこともあるだろう。

どこまでやれるか?
は、そのときのその担当者(チーム)の力量。Aの1イテレーションは、Bの3イテレーションに相当する。そのAも最初からその力量があったわけでない。そこに至るまでいくつもの回り道を繰り返して蓄積をした。いわゆるパターン。Bはまだ3イテレーションの力だが、蓄積され整理されたパターン抜きにはそこにさえ至ることはできない。もしBが担当すれば無駄が多くなるかもしれない。が、そこに新たな蓄積ができるかもしれない。

を繰り返していくのが、システム開発なのだろう。と、考えると、そこには正解はない。成功も失敗もない。たいした変わりもなく日々繰り返される僕等の生活と同じ。せいぜい、今日はいい日だったね。とか、さんざんだったね。とか^^;

| | コメント (0) | トラックバック (0)

2006年9月 1日 (金)

どこまでやる?

さてさて、明確にする(わかりやすくする)というのは、分けることだとわかってきた。システムのデザインを「分ける」作業と見てみる。上手に分ければ、見えていなかったものが見えるようになる。下手をすれば見えなくなるものがある。どこかがConflictする。そのまま無理やり実装すればいずれ爆発するだろう。そしてやっと遅れて新たな階層を追加する。

下手をしたその個別の問題に限れば長い時間ののちいずれは解決される。上手に分けることができるまでじっくり時間をかければよいだけ。だが、開発プロジェクトは期限も予算も限られている。どこまでも際限なく「分けて」いくことは実際許されない。どこまでやればよいのだろう??

分ける前の状態があった。再度積み上げて「それ」にする。ために分割を始めた「それ」
その作業に許される時間は「それ」の大きさに依存するだろう。ゆるされた時間の中でどこまでやれるのか?の問題に変わる。

| | コメント (0) | トラックバック (0)

2006年8月25日 (金)

「わかりやすい」ということ

インタフェースがわかりやすいとか、わかりにくいとか。説明がわかるとかわからないとか。なにかと「わかりやすさ」が重要視されることが多い。

世の中がとんでもないいきおいで複雑化していて、いつのまにか身のまわりにはてんでわからない話しが満ち溢れている。まあそんな状況で、みんな「わかりやすい」に飢えている。で、簡単に見掛けの「わかりやすさ」に流れてしまう。単純なステレオタイプにはめられてしまってる。という心配はさておき。

え~~みんなそれで納得するの!?な状況で、その場の雰囲気がなんとなくそれで話しがまとまりそうというシーン。その雰囲気に水をさせないよね。で、後でそのツケがまわってくる。は、よくある話。

逆に、賛成!いや反対!といつまでたっても平行線で向かあう。といって、右側/左側それぞれの中でまとまっているかというとそうでもない。議論の争点がいつもどこかずれたまま。も、よくある話。

分かるとは分けること
ものごとが「分かる」ということは、思考対象の情報要素についてきちんと”同じ”と”違う”に「分け尽くされた」状態に辿り着くことである

う~ん明快!気持ちよい。分かるということは、簡単にだまされることではない。でもって「わかりやすい」というのは、誤解を招く短い言葉にまとめることではない。複雑な状況を、その複雑さをごまかすことなく整理して見せることなの。面倒なことなのよ。

で、この記事にある「分けるための3要素」...オブジェクト指向が唱える抽象化、カプセル化にかぶる。と、なんだかまとめがとってもわかりにくい文章になってもーたが、とにかく「わかりやすい」とはそーゆーことだ;;

| | コメント (0) | トラックバック (0)

2006年8月19日 (土)

OOを再整理

ときどきは、基本に返って確かめてみよう。

システムにはデザインの基本的原則がある。その主要構成要素である、カプセル化、継承、ポリモーフィズムを描いてみる。3つの要素は互いに深く関連している。

Oo

トライアングルの中心に「抽象化」が見えてくる。抽象化するというのは、物事の本質を捉え、矛盾を解消し、問題を解決するための新しい構造を明らかにすること。オブジェクト指向とはこの単純な原則を貫くこと。

デザインの局面で特に留意したいのが「カプセル化」。ウィキペディアの解説にそれは目的ではなく手段とある。手段というよりむしろ条件と言うべきかな。全ての幸せの源。逆にそこが崩れると何もかも台無しとなる。と思う。

カプセル化とは?
システムはさまざまな部品、部分が階層的に積み上げられて構成される。その階層を分解という手順でたどるのがシステムのデザイン。システム→サブシステム→クラス→メソッド。このように分解されたそれぞれの塊をモジュールとする。モジュールは互いに関連しあって(使い使われして)システムとなる。カプセル化というのはこのモジュール間の関係に適用される基本的原則。

関係に着目して言い換えると、モジュールとモジュールの「結合度を低くく」、モジュールの「凝縮度を高く」となる。つまり、ベタベタした関係はだめよ。さらっとした関係、そっけない関係が良いと。役割分担、責任範囲が明確でそれぞれの性格が際立っているのが良いとな。

文章にすると極めて単純であたり前。のよう。ところがどっこい。なんだよね。なんでやろ。ベタベタした関係になっちまうんだよね~。2人でひと~り♪みたいな。システムをせっかく分割して設計したはずなのに、形ばかりにサブシステムが、いつのまにか、あいまいにべっとりと複雑に絡み合った混沌としたひとつの塊となっていく。カプセル化を貫くのは難しいんだよ。

| | コメント (0) | トラックバック (0)

2006年8月 5日 (土)

スタイルを買う

食空間コーディネータという仕事があるらしい
その彼女が住む高層マンションからの素晴らしい都会の景色
から、和食空間が創造される

さて、この場合も
彼女が仕事を請け負ってから
その作業としてクライアントのお客さん
つまり、その空間で食事する最終空間ユーザー
と、コーディネータの彼女が
その請負作業の中で直接会話することはない
もし貴方がクライアントだとしたら
しかも、そのコーディネイトコストを絞りたいと考えているなら
パトロンの貴方でさえその作業への横槍は拒否される
話すべき話はすべて契約前に済ませておくこと
あとは全て彼女にお任せ

いや、そんなリスクは容認できない
ひとつひとつチェックして
話し合いたい...
なら、お金に糸目はつけられない
彼女に言われるまま報酬を払うべき

リスク込みでスタイルを買う
曖昧にしてお金を注ぎ込む
どちらか
そこはっきりしてるのが
市場システムの良いところ
なはず

が、そこもあいまいにしてしまう
人間のご都合主義頭脳はそれを可能にする
システム開発プロセスはその結果
あいまいなままコストを狭小化するには?
気持ち、わかるけど
ただ、その要求と市場の関係
そこ明確にしておかないとただのわがまま
幸せにはなれんやろ~~

で、この罠を
飛び越えてしまうのがWeb2と

| | コメント (0) | トラックバック (0)

2006年8月 4日 (金)

いまだあいまいなこと

要求を開発しろ
要求→仕様→コード→テスト
徐々に曖昧さを排除するその作業
そこかしこにユーザーを巻き込めと
Rationalも勧める
なるほど
それならうまくいきそう
・・・

なにかが霞んでる
どこに契約が入り込むのか?
どこに市場があるのか?

おそらくなら
そのビッグプロセスの外側で契約されてる
そこに時間とコストの枠を設けてる
そして見積もれない
逆に考えてみる
その枠が相変わらず大きなままだから
そのプロセスが必要になる

はっきりさせておこう
そのプロセスが必要となるのは
全体があいまいなままだからなのだ
要求開発が必要なのは要求を知らないということ
下部作業にユーザー参加が必要なのは
上位要件を明確にしたという自信がないこと

開発プロセスへのあまたな提言
ここを明確に言及してることは少ない

考えてみよう
映画製作はビッグプロジェクトだ
だがその製作過程に観る人が参加することはない
どんなものが観たい?
こんな感じでよい?
が、製作費用に含まれることはない
観る人が登場できるのは
製作の前と後。だけ

| | コメント (0) | トラックバック (0)

2006年8月 3日 (木)

あきらかにする

の、「あきらか」がかみ合わない

IT開発成功の岐路は要求の明確化にある
は、ほとんど一致した見解のよう
問題を共有してその解決に一致団結
うまくいきそう

ところがどっこい
プロジェクトが進むにつれ
なにがあきらかだったのか?
どんどん見えなくなっていく

同じ問題を感じ
あきらかに明確な
同じ「目標」をかかげた
はずなのに...

人間、柔軟だからね
都合良く矛盾が解消される
どうどでもいいように解釈が変わる
ほんとうまくできてる>頭脳

そして
人の数だけ
都合良く捻じ曲げられた要求が生まれる
あいもかわらず
何もあきらかにされていない下々
苦労は尽きない^^;

さあ、どうするよ

| | コメント (0) | トラックバック (0)

2006年7月22日 (土)

IT→ICT

このChangeの意味するところは??

Communication aided by IT
なコミュニケーションが変えるもの→人、組織、社会の関係
どこからどこへ?

ICT in TV-CM
ビッグビジネスに支えられているマスメディア
ITなビジネスの限界への察知
セキュリティ、スタビリティ確保でコスト増
疲労→市場への不信→離脱
新たな起爆剤の要請
普通の流れ
わかりやすく、簡単な表面的メッセージ

彼が提供するサービスの保護の下
で成長する「C」が目指すところ
で、いつか彼も今の基盤を失う
となったとき
彼の保護サービスはそのとき?
誰の手に、どのように?
引き継がれるのだろう

内なる崩壊の芽生え
ということにしておこう!

| | コメント (0) | トラックバック (0)

その他のカテゴリー

ITとか