TLにこんなツイートが流れてきて アジャイルサムライbot　@agile_s_jp_bot 「プロジェクトのリスクについて早めに話し合うことの利点はこれだけじゃない。・プロジェクトの課題を早い段階で明らかにできる。・「いや、その理屈はおかしい」と表明するチャンスである。・単純に気持ちがすっきりする。」 https://twitter.com/agile_s_jp_bot/status/696086487352238080 ううん、「これアジャイルだからこそってわけじゃないよなぁ」と。どっちかいというと、「計画駆動型のプロジェクトの方が気にしていないといけないことだよなぁ」と思ったわけですが。 で、リスクについて早めに話し合うことは「利点」ではないのです。もう、必ずやらないといけないことだと思っています。ワタシがレビューするプロジェクトでプロジェクトのリスクについてノーケアだったら「出直して

はてなスペース、好きだったのにユーザは少なかったし今はスパムだらけだし。今月でサービス終了とアナウンスされたこの週末、音楽のところでお見送り会のように投稿が始まりましたね。 サービスなので消えていくほうが多いのはわかっているけれど、まぁ、スペースはスパムがなくてもユーザ数は少なそうだったからいずれ来る閉店が早まっただけの話なのかもしれないけれど。そうした感覚は薄々感じていたのでいよいよきたか、という感覚もあるのですが。音楽の他にはお昼ご飯の風景や朝ごはんの写真をフードログとして投稿してたのは、instagramにその場所を変えました。 で、システムエンジニアが理解していないことで起きる悲劇ですが、えっと、ワタシ的には喜劇というか自爆だと思うんですけどね。どういったことかというと、契約を知らずにプロジェクトの一担当として仕事をしちゃう。 前にこんなことがありました。そのプロジェクトのリーダは

ワタシ「それでさ、このプロジェクトは社員だけでデリバリーするんだっけ」 提案SE「そうしたいところなんですが、人がいないんですよ」 ワタシ「ふうん、で、どうするの」 提案SE「リーダクラスは確保するとして、他はパートナーとスキームを作るとおもいます」 ワタシ「人がいないんじゃそうなるよね」 提案SE「はい」 ワタシ「で、契約の条件は整理できているのかな」 提案SE「お客様とは請負で」 ワタシ「へー、請け負うんだ。請負でねぇ、これを」 提案SE「はい、請負でないとダメだと言われていますので」 ワタシ「何それ」 提案SE「だからお客様から請負でやってほしいと言われていまして」 ワタシ「ところでさ、この案件の提案、請け負えていると言えるのかなぁ」 提案SE「請け負えているじゃないですか、契約条件に『う・け・お・い！』って書きましたし」 ワタシ「（なにか変なもの見た気がする）請負って書いたら請負で

提案リーダ「と、こんな感じなんですが」 ワタシ　　「いいんじゃないの。これなら」 提案リーダ「プロジェクトのリーダは提案時にそこまで考えておかないといけないですか」 ワタシ　　「別に考えなくてもいいけれど、デリバリーのときに実際にはスキルが足らないとわかったら本人もフォローする側も追加コストが増えちゃうじゃない」 提案リーダ「そう言われればそうですが、それはプロジェクトの問題ですよね」 ワタシ　　「そう面もあるし、それをわかってアサインするのがマネージャの仕事だけどさ」 提案リーダ「そうです、マネージャの仕事です。本人も頑張ってもらわないと」 ワタシ　　「でもね、カツカツのコストだったらコスト的に頑張れないじゃない」 提案リーダ「コストが厳しい案件もありますね」 ワタシ　　「例えば、若手を実務で経験値を得させたい、育成のウエイトもある案件だったらそういった教育コストも必要なわけ」 提案リー

提案リーダ「いまいいですか。例の提案なんですがこれでいいでしょうか」 ワタシ　　「あーちょっと待ってね。このメールをポチッと。はい、なんだっけ」 提案リーダ「見積もりです」 ワタシ　　「あ、本体とは別のサブプロジェクトの提案でしたっけ」 提案リーダ「そうです」 ワタシ　　「あれ、これどんな提案内容なんだっけ」 提案リーダ「サーバを立てて、コミュニケーションツール入れて設定します」 ワタシ　　「そうなんだ。えっとそのツールはデリバリーの実績あったっけ」 提案リーダ「いえ、ないです。パートナーにお願いしようと思っています」 ワタシ　　「リーダは誰を予定しているの」 提案リーダ「インフラチームの…あ、あそこに座っている…」 ワタシ　　「（あぁ、あの人か…）そ、そうなんだ」 提案リーダ「で、どうでしょう」 ワタシ　　「パッと見たところだけれど、ダメだね」 提案リーダ「どこがですか」 ワタシ　　「全

組織デザイン、開発プロセス、マネジメントそしてリーダシップのうち、マネジメントの志向により組織がデザインされ、マネジメントとデザインされた組織としてリーダシップが発揮されるという関係は、まぁ、わかりやすいと思うのですがそれが開発プロセスとどう交わるのかという話です。 これまでのブログで書いてきたように、マネジメントのビジネスニーズから生じる管理単位をプロジェクトに対して要求します。ビジネスの変化が早いのであれば、それに合わせてプロジェクトをコントロールしないとマネジメントと現場がずれてしまって事業としてはよろしくないのは想像に難くないですよね。 開発プロセスはプロジェクトでの生産活動そのものですが、その開発プロセスはプロジェクトマネジメントの管理で制約を受けます。何から受けるかというと、マネジメントのビジネスニーズです。ここでマネジメントと開発プロセスがつながります。 イメージとしては、ビ