ソフトウェア開発をちゃんと考える(13):
柳生新陰流プロジェクトマネジメント
切り合いならば相手が打ち込みたいときに打ち込みたいところに打ち込んでもらえるようにする。プロジェクト・マネージャならば、メンバー自らが問題を発見して、それを解決したくなるようにマネージャ自身は「引く」こともあるかもしれない。(2007/9/11)
ソフトウェア開発をちゃんと考える(12):
「要求」と「システム」のしなやかな平衡
一部のベンダやユーザーはソフトウェア開発とは「要求というものを入れると一定期間後に完成されたソフトウェアが出てくる箱」と考えているフシがある(2007/6/12)
ソフトウェア開発をちゃんと考える(11):
「価値工学」批判
価値はモノの側ではなく、モノを使う側にあるはずであり、もっというと価値はモノとモノの間にあるように思えないだろうか。(2007/3/13)
ソフトウェア開発をちゃんと考える(10):
価値工学とソフトウェア開発
「価値」の重要性はリーン生産方式でも同じだし、アジャイル・プロセス全体にとってもとても重要なものだ。(2007/1/31)
ソフトウェア開発をちゃんと考える(9):
制約理論を読みほどく
今回は前回「セル生産方式+アジャイルという枠組み」のセル生産方式+アジャイルに続いて、制約理論+アジャイルという枠組みを考えてみる。参考にしながら読むのは以下の書籍だ。ただし制約理論に関してはこれ(「ザ・ゴール」)は代表的な1冊にすぎず、さまざまなトピックに関して多くの書籍が出版されている。(2006/11/8)
ソフトウェア開発をちゃんと考える(8):
セル生産方式+アジャイルという枠組み
今回はセル生産方式+アジャイルという枠組みを考える。(2006/10/11)
ソフトウェア開発をちゃんと考える(7):
滑らかなアーキテクチャ
今回は(アレグザンダーのパターン)シリーズ最終巻「まちづくりの新しい理論」に目を通してみよう。われわれの(アレグザンダーの、ではなく)キーワードは「滑らか」、あるいは滑らかなアーキテクチャ」だ。(2006/8/11)
ソフトウェア開発をちゃんと考える(6):
パターンと生きたプロセス
(2006/7/12)
ソフトウェア開発をちゃんと考える(5):
自然言語としてのパターン
建築家クリストファー・アレグザンダーが考えていたパターンと、われわれソフトウェア業界で通常パターンと呼ぶものとの間には大きな隔たりがある。われわれが本当に必要としているのはどちらのパターンだろうか?(2006/6/28)
ソフトウェア開発をちゃんと考える(4):
XPの欠陥修正フィードバック・ループを分析する
前回(「口に出す前に考える、『システムって何?』」)で紹介した「逆システム学」は、経済や生物にとって重要なのは「多重で階層的な、開かれたフィードバック制御」なのであって、要素還元論でも全体的原理主義でもないのだ、という話だった。(2006/4/12)
ソフトウェア開発をちゃんと考える(3):
口に出す前に考える、「システムって何?」
われわれは日常的にたやすくシステムという言葉を使ってしまうけれど、システムって何だ? システムズ・エンジニアって誰だ? 「最近システムがよく落ちるんで困るっすよ」ってどーゆーことだ?。(2006/2/17)
ソフトウェア開発をちゃんと考える(2):
開発者の集合はどのように形作られているか
ソフトウェア開発の効率性を考えていると、いつかは必ず人の問題に突き当たる。プロジェクトチームという開発者の集合はどのように形作られ、どのように動いていくものなのだろうか。そこには必ず何らかの機構(メカニズム)があるはずだ。(@IT編集部)(2005/12/21)
ソフトウェア開発をちゃんと考える(1):
開発コストと工数を下げるためのアイデア
本連載は、メタボリックスの山田正樹氏が、仕事の合間に読む数冊の書籍に刺激を受けて思考した過程やその結果を記述したものである。参考にするのは必ずしもソフトウェア工学に関わる書籍ではないかもしれないが、いずれその思考の軌跡はソフトウェア工学的な輪郭を帯びることになる。(@IT編集部)(2005/9/17)