Cafe Diary ログに戻る

2004-6-24

FP法についてちょっとだけ加筆

検索エンジンからの訪問が多い、FP法についてに一部説明を加えました。
「測った数値をどう利用するのか?」を間違うと大勢が不幸になるので、その注意書きです。
このへん当時自分のなかでも曖昧だったので、まとめてみました。

計測よりも計測結果の利用方法が大事

数値で管理できるもの「だけ」で測る目標管理には弊害がある。なにかの貢献度を単純化した近似値であらわし、その数値が増えても、そこにあらわれていない別の要素(離職率、製品の品質、顧客満足度、個人の成長…etc.)に悪影響があれば、本当の目標に近づいたとは言いがたい。なにか問題が発生するたびに目標管理を修正しても、いたちごっこはいつまでも続く。数値の限界を知っておくことが重要だ。

「ゆとりの法則」でトム・デマルコ氏はこう言う。

目標管理は、人為的に外部から「目標」というモチベーションを与え、労働者に内在するモチベーションを追い出してしまう。そのため、たとえば、ノルマを達成するという外部からのモチベーションに動かされている営業担当者は、顧客を満足させるという内在するモチベーションを無視するようになる。

このことに注意し「数値であらわせるもの」と「そうでないもの」の両方を評価する必要がある。これはもともと目標を明確な数値で管理していなくても、上司の評価が「顧客を満足させること」に向かっていなければ同じことだ。

また、トム・デマルコ氏は昔「測定できない事柄を、コントロールするわけにはいかない」といってソフトウェア開発管理に計測することをすすめたが、最近はこの言葉を思いなおしている。というのも、

わたしたちが生産性を計測するとき、自分の生産性がどうか見極めたり実質的な生産能力に見合った方向へ修正するために計測するのではない。生産性を計測するとき、わたしたちは声高にはっきりと、生産性を上げろと言っているのであって、それは牧童の突き棒と同じなのだ。

どの方法を採用するか決めたり、なんらかの発見をするために計測するのはいいが、そうでなければ「計測するな」ということ。プレッシャーを与え続ける(=牧童の突き棒)のはコスト、品質、時間すべてにおいて悪い結果を生む。このあたりはブックレビューピープルウェア、ゆとりの法則を参照のこと。グレートゲーム・オブ・ビジネスでも数値を使うが、基本は叱るためにではなく、日々個人が喜ぶために使っている。


Tag : 開発

2004-6-20

話題のロボット

「ROBO-ONE」が生んだ市販ロボット〜KONDO「KHR-1」が誕生するまで
今日はPRIDEグランプリですが、ロボット格闘技大会ROBO-ONEから生まれた市販ロボットの話題が記事になっていたので紹介します。生まれる過程の興味本位っぽさ、そこから始まる成功談が素晴らしい。実際の動きなどは『ウワサのキットロボット「KHR-1」を見てきました』をどうぞ。センサーやジャイロを一切搭載していないのにバランス保持できる仕組みや、実際のロボットを使って行うモーション入力の仕組みなど、シンプルさの力を感じます。ゲーム制作やプログラミングに必要なのはこの発想だと思いました。



2004-6-17

ゆとりの法則

ピープルウェアでおなじみのトム・デマルコの本。ソフトウェア会社やソフトウェア開発プロジェクトのよりよい運営にはゆとりが必要だ、という主張です。

最初ゆとりと聞いたとき時間のことかと思ったのだけれど、それだけではなく「管理のゆとり」、つまり上司が一方的に権限を行使するのではなく部下に自由にやらせるなどあらゆる意味での「ゆとり」が含まれてるのがポイント。

ゆとりの法則の内容は、2004年頭に開かれたDevelopers Summit 2004での講演でも述べられています。詳しくは「効率化しすぎると、作業が遅くなり変化にも対応できない」とトム・デマルコ氏トム・デマルコ講演の個人的メモなどトム・デマルコ関連リンクからたどっていただくとして……ここではゆとりについてもう少し。

ありがちな意見として「もちろんゆとりはあったほうがいいけど、予算や競争でそうもいかないのが現実」という声があります。けれど、ゆとりがないことの悪影響は、結局は予算超過や売れない製品として自分に返ってくると考えれば、ゆとりについて真剣に検討してもよいと思えるかもしれません。

もうひとつ理由があります。もし本当に価値のある製品だったなら、そんな予算が足らないもの? 誰もたいしてほしがらない、喜ばれないものを作っているのでは? バグがなければよい製品? 悪い点のあるなしではなく、世界や体験がどう変わったかが重要なのでは? そんな意見が検討されることはあまりないようです。

ゆとりは一種の投資である。ゆとりを無駄と考えず投資と考えることが、ビジネスを理解している組織と、単に忙しいだけの組織の違いである。

本の帯にはこんな文が引用されています。

人間は時間的プレッシャーをいくらかけられても、速くは考えられない

   ――ティム・リスター

労働者がガレー船の奴隷で、プレッシャーがむちだとしたら、むちを使うほど「これ以上は速くこげない」というところまで仕事のペースは上がるかもしれない。頭脳による識別の速度は変えられないため、プレッシャーに対応できる量は少なく、

  • 無駄な時間をなくす(そもそも知識労働者は時間の無駄を楽しむより、不満に思うことが多い。無駄にしている時間はそれほど多くない――超過勤務だらけのときは別だが)
  • クリティカルパスにない仕事を後回しにする(優先度がはっきりしているなら、仕事が完成して満足感が得られるようそれを優先したいと思っている)
  • 夜遅くまで仕事をする(短期的には効果があがるが、体にこたえるうえ、家庭や個人の生活の面でプレッシャーが高まり、いずれ適正なバランスに修正される。毎日過剰に働いてるのに昼も夜も遊ばず集中して作業したりするだろうか?)

くらいしか方法がなく、メリットがデメリットを上回るか疑問でしょう。

まちがった管理についての法則を2つ。

一.うまくいかないことがあったらもっとやれ

「いまやろうとしていることはうまくいくはずだ。うまくいっていないのは、一生懸命やっていないせいだろう」という理屈。

二.自分自身のユーティリティ・プレイヤーになれ

ストレスの過剰の組織では管理することが「危険」なので、自分がボスであると同時に部下のひとりとして仕事をすることで管理をパートタイムに処理し、安全を確保する。下部の仕事は重要だし、それを自分で受け持つのだから悪いことはなさそうに見えるけれど、管理は片手間にできるほど簡単で影響力の低いものなのか? という話[1]

  • [1]ちなみに、管理が難しいのは人間関係、そのほか微妙で「難しい技能」が必要だからであって、やるべき仕事が多いからではないという点に注意。「働きすぎている管理者はほぼ間違いなくやるべきではない仕事をやっている」

本書の内容を一部紹介するとこんな感じ。面白い本です。
最後に、ゆとりがないとどうなるのかを引用します。

必要なゆとりが足りないと、組織は狂乱状態になり、恐怖感に支配され、リスクを避けようとし、大切な従業員はもっと働くのに適した場所を求め去っていく。

もうすこし書きたいこともあるんだけど、それはまた別の機会に。
次回はTOC、ゆとりの法則をふまえて、アジャイル開発の方法論について書こうと思います。



2004-6-6

ザ・ゴール? クリティカルチェーン?

ビジネス系のベストセラー本なので聞いたことあるかもしれないですね。自分はビジネスにあまり興味がないのに加えて、すぐ出てすぐ消えるベストセラーが嫌いだったので、触れもしてませんでした。

しかし、ネットのいろんな人がこれについて触れてたり、書店に長らく置かれていたり、「なんで小説なんだ?」という好奇心があったりで、つい二ヶ月ほど前に読んでみることに。で、よい意味で想像と違ったので、今回まとめてレビューしてみます。

ザ・ゴールからクリティカルチェーンまで

経営管理の理論について書かれた指南小説。本の大筋の解説はAll About Japanの「ザ・ゴールシリーズの関連ガイド」や自動車産業関連リンク集の「TOC(制約条件の理論)」に譲るとして、ここではソフトウェア開発をする個人の視点から概説を。

ゴール ― 企業の究極の目的とは何か

イスラエルの物理学者エリヤフ・ゴールドラット博士は、工場を経営していた友人から「生産管理のスケジューリングがうまくいかない」と相談を受けたとき、物理学の研究をしてきたやり方で、その問題の解決法を考え友人に伝えました。

結果は予想以上。博士はやがてOPTという生産スケジューリングソフトを販売する会社を起こし、その販売促進用に「ザ・ゴール」という小説を書きました。OPTを導入すると短期間に生産性が上がり、余計な在庫は消える……成果は十分だったものの、詳しい原理を公表せず、疑いや無視の対象にもなっていたので、小説の形で分かりやすくその原理を説明しようとしたわけです。ベストセラー、販売も順調、しかし思わぬ状況が待っていました。

小説を読み、人の手でその考え方を実践した工場が、それだけで小説のような成果をあげたという手紙が寄せられます。現実の工場はスケジューリングが複雑だからOPTがなければ無理だと考えていたものの……どうやらそうではないらしい。博士は会社を離れTOCの研究所を設立、TOCの教育・研究を推進していくことになります。

TOCは常識的で理屈にあっているので「なぜうまくいくのか」納得できます。実績もある。しかし、工場を離れてソフトウェア開発などに応用するにはどうしたらいいのか、すでに結果をあるなら調べてみたいと思い、他シリーズも読んでみることにしました。

ザ・ゴール 2 ― 思考プロセス

ザ・ゴールは新しい考え方を主人公と一緒に追っていく形だったのに、ザ・ゴール2はすでにある思考ツールを主人公と一緒に使っていくという形になり、前よりもすっきりしない感じがします。

しかし、全シリーズを読んだあと、一番役に立ったのはこのゴール2です。応用範囲が広さがメリットであり、デメリットでもあり。

ゴール2の背景には、TOCによる改善で生産性を増した工業・部署が、生産性を増していることが原因で従業員の削減対象になるという「努力すれば仕事がなくなる」現実がありました。

制約が工場にあるのではなく、市場にある場合、どう対処すればいいのか。それに対するTOCの答えがこれです。

チェンジ・ザ・ルール!― なぜ出せるはずの利益が出ないのか?

ソフトウェア開発会社を舞台に移したということで、内容に期待していたものの、ゴール1、2のおさらいのよう。システム開発ではなく、ITシステムを導入した企業がそのメリットを活かす方法についての話が大部分。

ただ、表題にもある明確な主張の重要度を知るには、この一冊分が必要だったのかもしれないです。

「チェンジ・ザ・ルール」

暗黙の前提やルールが変わらないなら、新しいなにかを導入しても変化は起きない、メリットは活かされない。

製品の売り込みで実際の効果を約束するやり方、そういう自負を持てるだけの考えがあるということ。半分騙すようでないと売れない製品を作るのをやめて、基本に立ち返った世界。なんだか羨望を覚えます。

クリティカルチェーン―なぜ、プロジェクトは予定どおりに進まないのか?

大学のエグゼクティブMBAを舞台に今度は「プロジェクト管理」の制約を探り、新しい管理方法を提示します。小説としても読ませる内容。TOCが工場だけの理論でないことをよく示しています。

ただ、ソフトウェアのプロジェクト管理にこれをそのまま適用できるのか? と問われると、即答できない違和感があります。たとえば、ピープルウェアのトム・デマルコ氏も「TOCは素晴らしい。しかし、システム開発には向かない。知的労働者にはゆとりが必要だ」という意味の発言をしています。

とはいえ、トム・デマルコ氏の主張とエリヤフ・ゴールドラット博士の主張、双方共通する点も多く、お互いを補完するなんらかの解決策があるのではないかと思わずにはいれません。

そして、TOCにはこんなときこそ使える解決方法――思考ツールがあります。

関連リンク

次回のブックレビューは「ゆとりの法則」について書いてみたいと思います。



2004-6-3

よくある話?

昨日の話、言い合いは言い合いなんですが、ディレクターやプロデューサーと言い合いになるのはよくあるパターンだし、言い合いしたあとにいがみあってるわけでもないので、まだ健全な方かな、と。

あと日記でいろいろ試行錯誤するときに書く心情なんて自分側から一方的なものなので、フェアな内容ではないですよね。たとえば「仕事が入ってきた流れを話してる途中で突然秘密だと言うのは、『自分が仕事をとったと言いたい』のに、その成果がそれによって揺らぐからだ」なんて邪推をして何食わぬ顔で書くこともできるし、疑ってみといた方が安全かも。

逆に原因は自分なのかもしれないです。プロデューサーの地位とか立場をリスペクトしてないのが態度に出てて、それで相手は生意気感を感じて話がややこしくなる、って流れもありそう。問題は自分?


Tag : 開発

2004-6-2

新プロジェクト

会社で新しいプロジェクトが始まり、開始早々、プロデューサーと言い合いになってしまいました。話の流れで、「このプロジェクトに誰がどんな期待をもっているのか(何を重視しているのか)」を知る材料として、「どこからこの話が始まったんですか」と聞いてみると「そんなことは知らなくていいです」。

その理由が別のことだったらまだしも「プログラマーは知る必要がない」だと、なんだかなぁ…です。上下関係を理由に聞きたいことを秘密にされると、相手のことを信頼し辛いと思うんですが、どうでしょうか? 自分はオープンブックマネジメントの考え方を支持してたりもするし、そういうのはどうも。

しかも「知るんだったら営業もプロデュースも全部やれ、そのつもりがないなら聞くな」という論調へ。自分の領域じゃないから傍観ってどうなんだろう? なんでそんなに敵対するんだろう?

とはいえ、根本的にプロジェクトを成功させたいという目標は同じなので、うまく協力しあえるのではないかと、いまのところは楽観視しています。

目下の問題は、予算が減った分をどうするか? ってことですね。


Tag : 開発

2004-6-1

六月の予告

どうもおひさしぶりです。5月はプロジェクトや開発のよりよいあり方を模索して、気になる本をいろいろ調べていましたが、沖縄に行ったり、遊んでもいたのでろくに記事を書いてませんでした。会社の仕事も込み入ってたし[2]。でももう少しこまめにまとめていけたらなぁ、とは思ってます。

  • [2]ManagedC++によるWindowsFormをインターフェイスに使った3Dパーティクルエディタ。よせばいいのにあえて短期間の大幅リニューアルを試みたかいあって、なかなか好評のよう。嬉しいことです。

しかし、なんで企画やプログラムをやってる人間が管理やビジネスを気にしないといけないのか? たいして興味もないのに。

というのも、企画をアピールするにはお金を出してくれる人(経営者、発注元の会社、そしてユーザー)のことを知るのが一番効果的で、必要なことだと、いろんな経験を通じて(ようやく)学んだからです。プログラムをするうえでも、もっといいプロジェクト管理があれば違った結果を出せただろうにと思うことが少なくありません。自分の持分だけでやってたのでは、これからも同じ「絵はいいけど内容がね・・」とか「あのへんのシステムはいいけど根本的なところが抜けてるよね」なんて状態が続いて、一番大事にしたいことに結びつかない。そういうもどかしさをかかえたまま傍観するのをやめて、手を出そうってわけです。

そんなわけで以前から少しずつ、ブックレビューで「グレートゲーム・オブ・ビジネス」、「ピープルウェア」、「熊とワルツを」といったビジネス/管理系の本を自分のメモがてら紹介しています。興味をもたれた方はぜひご一読を。

次回から数回に分け、ソフトウェアプロジェクトのよりよいあり方を模索してみようと思います。


Tag : 開発

Cafe Diary ログに戻る