プロジェクトマネージメントって (arclamp.jp アークランプ)
プロジェクトマネージメントってなんだろうねという会話。まだまだラフですが。 本質的にマネージメントしなきゃいけないのは、1.ビジョンの実現品質、2.スループット（個々人のモチベーション）、3.リスクだと定義しました。 「ビジョン」とは望ましい将来の姿のことで、「なぜプロジェクトをやるべきか」というWHYの定義にあたります。（TODOミッションは入るのか？）。そこからシステムの仕様が段階的に導かれてきます。ビジョンの実現品質とは、きちんと段階的に導かれた仕様に従っているか、ということになります。 スループットとはプロジェクトの生産力になります。人をアサインしたからといって生産性が高いとは限りません。そのメンバーがやる気になって、十分な生産性を達成しているかが重要です。 リスクは言うまでもありませんね。変化が大きく、複雑なプロジェクトではリスクマネージメント、つまり不確定要素の管理が非常に重要
僕はなぜアーキテクチャにこだわるのか (arclamp.jp アークランプ)
「僕はITアーキテクトです」と名乗るのが、昔は恥ずかしかったものです。ですが、ある時期から吹っ切れていました。やはり僕の原点なんだなと思って。 そのものではなく環境を見る 大体において、「そのもの」が悪いってことはないのです。日経SYSTEMSのコラムに書いたものを引用します。 「間違えたのはITエンジニアだから悪いのはITエンジニアである」ということから一歩進んで，「なぜITエンジニアが間違えなくてはならなかったのか」と考えるわけである。そのためには，プログラミングという作業全体を俯瞰し，その前後左右に何があるのかを見る ITエンジニアを取り囲む環境の中に，バグを誘引する要素がある 書き方がバラバラな仕様書，複雑で理解しにくいアプリケーション・フレームワーク，ドキュメントが無いライブラリ群，使いこなせないIDE（統合開発環境），など。いずれも，バグを引き起こす原因になることは説明するま
答えを言うべきか考えさせるべきか (arclamp.jp アークランプ)
「プロジェクトで誰かから問題の解決策について質問を受けたらなんて答えますか？」という質問をされました。意図としてはすぐ答えを教えるべきか、それとも考えさせるべきかというようなこと。 これのフレームを考えてみるに以下のようになるかなと。 Aは問題を構造的に理解し、解決策が分かっている状態。これは既に問題はありません。理想的な状態です。 Bは問題を構造的に理解しているものの解決策が分かっていない状態。ここまでくればGoogleで調べて知識を補うなり、人に聞くなりして適切な解決策を見つけることが可能になります。 Cは問題を構造的に理解していないものの解決策が分かっている状態。これは特定に問題を解決することは可能ですが、応用や類似的な状態に対応することができません。 Dは問題も理解できず解決策も分かりません。 さて、誰かが質問をしてきたのであれば、その人はBかDの状態にあります。 特にDの場合には
抽象化がもたらすリアル (arclamp.jp アークランプ)
Inter Communication (インターコミュニケーション) 2007年 04月号 の特集は、「デザイン／アート 芸術と科学のインターフェイス」というもの。いくつか面白い記事があったのですが、抽象化がもたらすリアルみたいなことで思うことがありました。 まず、巻頭の茂木さんと山中さんの対談はそうだよねぇーの連続。山中さんはSuica自動改札機やCyclopsをデザインしたことで有名な方。 ところでヒューマノイド・ロボットを作るうえで、人間に似せていくほど不気味になってくるという「不気味の谷（Wikipedia）」という現象があります。山中さんは、これを「サイエンティストの傲慢」と切った上で次のように述べています。 彫刻を作るとき、睫毛を植えたり、髪の毛を生やしたりは普通しないですよね。なぜならば、そんなことをしないほうが美しく、よりリアルであることをアーティストたちは気がついてい
適切なアジャイル性を実現するアーキテクチャ (arclamp.jp アークランプ)
先日、憧れのITアーキテクトと「アジャイル・アーキテクチャ」について議論。きちんと理想と現実と捉えていて、さすがという感じでした。 アーキテクチャ自身がアジャイルなわけではない まず言われたのが「アジャイルなアーキテクチャ」といってしまうと、アーキテクチャ自体がアジャイルに変化するというミスリードをするのではないかという点。確かにそうですね。広義のアーキテクチャというのは全体性を決定する思想・概念であり、それ自体がアジャイルに変化することが求めることはあまりないと思っています。狭義のアプリケーション・アーキテクチャに変更が求められる場合はありえますが、それすら広義のアーキテクチャには織り込み済みであるべきです。 では、僕らが考えるアジャイル・アーキテクチャとは何か。それは"適切なアジャイル性を実現するアーキテクチャ"と定義できそうです。 ここで出てきたのがアーキテクチャの結合度、可変性分
編集のソフトウェア化 (arclamp.jp アークランプ)
また、最近ブログが滞っています。いかんと思いながら筆が進まぬ日々。 さて最近、もっぱら興味があるのが「編集のソフトウェア化」というキーワードです。 当たり前ですがソフトウェアはデジタル化された情報の扱いには非常に長けています。デジタル化された情報というのは、リアルの情報（文字とか絵とか）と違い、インターネットを通じて広がりを持てるというのは大きな可能性を持ちます。 「編集のソフトウェア化」というのは、デジタル化された情報を扱うことを前提としたものです。デジタル化された情報とリアルの情報（主に文字）で圧倒的に違うのは情報量です（実際に人間が扱う情報は大量なわけですが、まぁ、それはおいておく）。この情報を編集する"編集者"を考えてみます。 これまでの編集者（編集者1.0）というのは、取材し、情報を集め、構成し、編集し、メディア（雑誌、テレビなど）に載せていました。編集者1.0では自身が情報を取
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
