僕が鬱病になりかけた時の話、あるいは負のスパイラルについて：プロジェクトマジック：オルタナティブ・ブログ
今から考えると、軽い鬱病だったんだと思う。 僕は鬱病にならなさそうなタイプだ。いい加減だし、マイペースだし、自分で言うのもアレだがリーダーシップや困難な場面の打開力もある。 だからそういうのとは無縁だと思ってきた。僕と会ったことがある人や、本やブログの読者もだいたいは同じ意見だと思う。 そういう僕の10年以上前の経験を、いつか誰かの助けになるかも、と思って書いてみる。 コンサルタントに転職して1年くらい経った時だった。ある会社を抜本的に改革するプロジェクトの立ち上げメンバーとしてアサインされた。 業務も変える、システムも変える、組織も変える、それどころかビジネスモデル自体も見直そうという野心的なプロジェクト。コンサルタント冥利に尽きるようなプロジェクトだ。 難易度が高いプロジェクトだったから、会社は優秀な人材を何人も集め、豪華な布陣を引いた。僕もその一員としてやる気満々で臨んだわけだが、パ
要件定義は誰の責任か？あるいはプロとアマの分岐点：プロジェクトマジック：オルタナティブ・ブログ
★システム構築の最初にして最大の難関 システム構築をする際の要件定義は難しい。一度決めたはずの要件が、プロジェクトが進むに従って何度も変更される。 要件はシステムの大もと（そもそも何を作りたいのか？）なので、要件が変われば、 設計書も書きなおし、 プログラムも書きなおし、 テストもやり直し、 マニュアルも書きなおし・・。 気づくのが下流工程になればなるほど、被害は大きくなる。 これほど重要な要件定義なのだが、実はシステム構築においては凄く中途半端な位置付けだ。 「要件を定義するのはユーザー（業務担当者の仕事）の仕事なので、システム開発者は要件定義の結果を受け取ればいい」 という建前論がある一方で、 「とは言っても、システムのプロじゃないんだから、ユーザーが正確で網羅的な要件定義は出来ない」という現実論がある。 その2つの見解のハザマに落っこちて、ただでさえ難しい要件定義が、ますます困難なも
あなたの作ったものはゴミである、あるいはプロとアマの分岐点：プロジェクトマジック：オルタナティブ・ブログ
「傷つかない技術」を体験した授業 というブログ記事を読み、深く共感した。 詳しくはリンク先を読んで欲しいが、かいつまむと・・ アメリカの大学でアート＆ビジネスというクラスを取っていた際、 「はい。みんな課題持って来ましたか？では、机の上に出して、紙の人はそのまま破り捨てなさい。立体物の人は壊してゴミ箱へ捨てなさい。」 と先生に言われた。 曰く、「プロのデザイナーを目指しているなら、一生懸命作ったアイデアや作品を見ることもなく破り捨てられる経験をこれからたくさんする。それに耐えられなければ、プロのデザイナーにはならない方が良い」 僕の職業はデザイナーではなく、コンサルタント（≒プロジェクトの成功請負人）なのだが、同じようなことは毎日のようにある。自分が深夜までかけて作った打ち合わせ資料が、翌日の打ち合わせ本番では全く別な資料に差し変わっていたとか、「天に唾はく様なプレゼンだ」と切り捨てられた
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
