「残業ゼロ」の仕事力 ― 2008-03-01 22:20
もうちょっと書いてみる。 この本は、仕事のスタイルを変えて生産性アップだぜというよりは、組織の生産性は全社残業ゼロまで向上可能であるという本だ。
こういう本を読んでいると、「本に書いてあるのはフィクションで実践できない」ようなことを言われたりして超がっかりである。俺らは俺らで地道に行こうは結構なことだが、巨人の肩の上に立たずして同じ地平に立つなんてお前はどれだけ天才なのか暇人なのか。
Web2.0のレコメンドより旧メディア ― 2008-03-02 21:43
Amazonのおすすめより新聞の書評やラジオで流れている曲を購入している気がする。レコメンド機能で出てくるのは関連が強すぎていかんね。
がしがし興味がありませんをクリックしたり、原因の商品を反映から外してしまうと一時的にはすっきり。出てくるおすすめは居心地の良い安心感の掃き溜めで、新たな発見はもはや無い。
Googleリーダーのおすすめもがしがし排除してたら「おすすめフィードはありません」になってしまった。こういうのはあまりコントロールしようとしない方が良いんじゃないかと思った。
管理はコントロールじゃない ― 2008-03-02 22:09
７割くらい読んだ。Joel on Softwareも高いなーと思ったので二千円以下にならんかねえ。日本でも誰かこういうのを出さないかな。オフ会とかカンファレンスとか直接行動派は多いよね。
マネジメント関係の本をたくさん読んでも、現実に行われている管理が何故ダメダメなのかをうまく説明できないでいたんだ。「テストメトリクスでテスタを測定することはできない」「チームへの報償」でわかった。人はコントロールできないんだ（難しいとしてもいいよ）。評価するには具体的な数値が必要とされるが、その数値はパフォーマンスを現しているものでなければならない。間違っているとパフォーマンスに関係しない動機付けが行われてしまう。 このパフォーマンスは仕事が速いとか顧客満足度じゃあダメ、それを目的にしてしまう。コストを度外視すればみせかけの顧客満足度を得るのはたやすいよね。
マイクロマネジメントがいかんのもそれはコントロールであって、制御する人がコントロール可能な限界以上の事を組織的に行うことはできなくなるんじゃないか。 それで飽和すると、商品の単価を上げるしか会社の成長の道がなくなっちゃうんだね。
競争力 ― 2008-03-04 20:53
asahi.com：ゆうちょ銀、ヤマトのメール便使う 日本郵政社長が怒る
「グループ総合力を最大限活用しなければ他社と戦うための競争力などつくはずがない」
Amazon.co.jp： 壁を壊すにはグループの会社からも買ってもらえない＝競争力がないって書いてあったな。グループに関係なく市場の競争原理にさらされないといけない。グループ内でささえあっていたら競争力などつくはずがない。
リーン開発の本質 第１章 歴史 ― 2008-03-06 22:20
Amazon.co.jp： リーン開発の本質 ソフトウエア開発に生かす7つの原則
トヨタ生産方式なソフト開発。よく見聞きするのは「かんばん」とか「見える化」を意識したものだけど。さてさて。
Amazon.co.jp： ソニー中村研究所 経営は「1・10・100」にはとにかく付加価値を生まないものは排除しろな感じだったが、その究極的なのがトヨタ生産方式なのかも。ライフハックも観点はとにかく付加価値を生まない時間を減らすことにつきる。
本家のかんばんは本当のところは見える化じゃない感じがするなあ。toyotaサイト見に行ったらIT化されているじゃん。スケジュールトークンというところが変わってないのでこれが本質か。
そしてジャストインタイムよりもラインストップの文化が重要そうだ。問題が起きたらラインを止めて原因追求の再発防止。
リーン開発の本質 第２章 原則 ― 2008-03-06 23:30
Amazon.co.jp： リーン開発の本質 ソフトウエア開発に生かす7つの原則
リーンもトヨタ生産方式も「直感に反する」らしいので見た目だけまねしてもよくない。
Amazon.co.jp： デッドライン―ソフト開発を成功に導く101の法則には「コーディングは遅らせて本当の設計をしろ！」という仕様バグや設計ミスをなくす話がでてくる。デッドラインのはぱくりなパッケージソフトの開発なのでいいのかもしれないが、アジャイル開発では本当に顧客がほしいものを開発しないといけない。（ものによっては有効なやりかたが変わるからいろいろ書いてるデッドラインも良いよ、ていうかデマルコ本も読め。）
間違っている神話として「早く仕様を固めればムダが減る」が出てくる。うん、機能を盛り込むのはこの仕様作成の機会しかないぜーとむやみに必要の薄いものもてんこもりもり入れるからね。PDCAサイクルまわしていったほうがムダ在庫な機能をつくらんで済むと。
リーン開発の本質 第３章 価値 ― 2008-03-08 08:14
Amazon.co.jp： リーン開発の本質 ソフトウエア開発に生かす7つの原則
人事の評価制度は成果の数値で判定されたりするが、数値目標さえ達成すればよいと考えるとろくなことにならない。売上目標の達成ためにコストを度外視して案件を受注すると、利益はしぼんで赤字にさえなる→がんばったところでボーナスないし時間外手当かせぐしかないな！
成果主義はだめっぽいと認識されてもコンサルタントにはくいっぱぐれなどない。つけこむところが増えてうれしいくらいではないか。なんかわけわからん評価が出てくるだけで終了、で済むといいな。
成果を評価すると部分最適化による弊害が起こりえる。成果というのは結果にすぎないのでプロセスそのものを評価してカイゼンしていくことが成功への道。
初期は投資として実績を積んでうんぬんは詭弁で、そんな参入が困難な市場ではますます顧客を儲けさせて儲けるしか生き残れないだろう。
あまり本の内容と関係ないこと書いたような気がするが気にしない。
成果と評価制度 ― 2008-03-09 00:57
Amazon.co.jp： 非営利組織の成果重視マネジメント―NPO・行政・公益法人のための「自己評価手法」
おお！評価制度とは関係なかったなこの本……。組織の自己評価手法の本だ。成果を重視するならば、個人の成果じゃなくて組織の成果を評価するのはいいね。
個人について成果を評価するとか、細かい個々の部分を評価するとどうも部分を最適化したところで全体の最適化につながらない。なので人事評価に成果を絡めるとおかしくなる。
組織目標の達成を個人の目標に落としこめるやり方よりも、この自己評価を行うとより価値のある成果を出せるのではないだろうか。
自己評価のための５つの質問
- われわれの使命は何か？
- われわれの顧客は誰か？
- 顧客は何を価値あるものと考えるか？
- われわれの成果は何か？
- われわれの計画は何か？
いやー悶絶するね。
変愚パッチ ユニークな世界 ― 2008-03-12 00:49
ついカッとなって取り掛かってしまった。構想２年くらい、制作３時間くらい。テストはこれからだ！
9up ― 2008-03-12 21:34
二回もアップデートを見逃せるか！ということでminiUSB？のケーブル買ってきた。やっぱりXP x64にはUSBドライバがインストールできない罠。
ぐぐったらばinf書き換えでいけるみたい。
最近のコメント