ビジネスのCode complete:小さなチーム、大きな仕事

ビジネス版のCode Complete,という感じがする。

ソフトウェア開発をビジネスとしているトップクラスの会社が、どのように「ビジネス」をやっているのかというノウハウがまとめられているのは珍しい。
この本は37signalsという会社のビジネスのやり方について書いてあるけれど、大きな会社であっても実際に働く現場は部や課といった小さな規模の会社に相当するだろうから参考になるところが多いにある。

ソフトウェア開発の現場ではなくても、仕事のやり方の姿勢として参考にできることが盛りだくさん。まさにCode completeといった感があって、どの章も濃密だった。
最近読んだビジネス系の本ではピカイチ。

普段、それが常識だよね、となんとなく受け入れていたことがそうじゃないんだよ、と指摘されていて固定観念に気付かされることも多くあった。Code completeと並べて座右の書にしよう。

小さなチーム、大きな仕事―37シグナルズ成功の法則 (ハヤカワ新書juice)

小さなチーム、大きな仕事―37シグナルズ成功の法則 (ハヤカワ新書juice)

付箋したところメモ

失敗から学ぶことは過大評価されている

たしかに、周囲を見ていると失敗する人はそのつぎも失敗する可能性が高い気がする。
逆にそつなく失敗なく淡々とこなしていると「がんばってない」とか「気合が足りない」とかわけわかんない評価されがち。失敗してそのリカバーのために遅くまで働くとか、そういうのが好まれるよね。

ビジネスは小さくていい

持続的で、利益の出るBUSINESSを行なっていれば、それが大きかろうと小さかろうと誇るべきことである、と。
どうしても大きくしよう、人を増やそう、支店を増やそう、という誘惑に駆られるみたいだけど、安定飛行しているのは悪いことではないのかも。

いたずらにユーザ数を増やしたって、せっかく品質が高いユーザの割合が高かったのを損ねてしまったりしている。はてブはその傾向を感じるけれど実際どうなんだろう。
ユーザ数は増やせばいいというものではないと思うのだけど、ユーザ数を増やすことでしか売上が伸ばせないBUSINESSのやり方になってしまっているときはジレンマだな。

仕事依存症ワーカホリックはバカ

ワーカホリックは仕事を時間で解決しようとする。
まったくもってそのとおりで、効率的にやる方法を探さずにチカラ技で長時間働いて解決しようとするので大変迷惑。しかもさっさと仕事終わらせて帰ると「暇なの?」とか言われたりするけどそりゃそんな非効率なやり方積み重ねたら忙しくもなるよ。

残業代が出たりするのも良し悪しだと思う。仕事を早く終わらせる理由がなくなるから。

すごい製品やサービスを生み出す最も単純な方法は、あなたが使いたいものを作ること

ものづくりは、ユーザからのフィードバックのサイクルの頻度がものづくりのスピードに影響が大きい変数だと思うけれど、自分がユーザの場合はこのサイクルの頻度と精度が最高になるんだろう。

結局、狙いに狙ってサービスを作ったけど自社ユーザどころか開発者もさっぱり使っていないようなサービスをやるよりは、自分たちが欲しいから作ってしまった、みたいなサービスのほうが魅力的だったりする。最近だとなにかあったかな。Livlisはどうなんだろう。

特にソフトウェア開発、物理的制約の少ないサービスの開発だと、「ユーザに聞いてみないとこのサービスがイケテルかどうかわからない」っていうのはものすごい不利だよね。

身軽でいること

ビジネスでも個人でも、身軽でいることが大切。
ビジネスだったら会議やってパワポ作ってる間に他社がそのパワポの製品を出してきたりするし、個人だったら家を買ってしまったらその場所に縛り付けられる。
私は、可能なかぎり身軽でいたいと思っているので、何かを選択するときには選択肢が少なくなる方にはいかないようにしている。臆病だ、とも言えるか。

中途半端な製品ではなく、半分の製品

もろもろの機能が満載のどれも使えない中途半端な製品よりも、イケテル機能がその半分だけどちゃんと動く製品のほうがいい。量より質が大切。
日本の製品を見ていると使いもしない機能が満載で、そのどれも機能としては不具合がないから高いし面白くないのかな。

インターネットサービスも量より質であるべきか。単機能のシンプルな方がユーザは増える。マニアックな機能で自分の親に電話で説明できないような機能が満載でもしょうがない。

ホットドッグ屋はホットドッグがないと始まらない

いちばんたいせつなことは何か、を忘れがちだから肝に銘じておく。
得てして「芯」が何かを忘れて詳細のどうでもいいことに時間をサキガチ。

変わらないものに目を向ける

TwitterFacebookGREEだQuoraだiphoneAndroidだとホイホイ流行りものに飛びつくだけじゃなくて、ちゃんと10年後も価値が変わらない物をビジネスの中心に据えないといかん。

個人的にも耳の痛い言葉で、やれRuby on railsだ、Objective-Cだ、モダンPerlの時代だPythonがキテル、といろいろ飛びついたものの、どれもHello world止まりになりがち。

邪魔が入る環境では生産性は上がらない

ピープルウェアでも言われているしソフトウェア開発系の話ではさんざんに言われているけど、「ゾーン」に入ることは難しいし、いったんゾーンに入ったときに邪魔が入るともうゾーンに入れなくなる。

私は特にゾーンに入ってる時の電話とか話しかけられたりするのが最悪で、もうその日は二度とゾーンに入れない事が多い。
定石を守るべきなのか、実はゾーンなんて迷信なのかはわからないけど。
チームで仕事をしていても、ゾーンに入ってるエンジニア、という概念がないビジネス系の人がチーム内にいるとゾーンをぶった切ることが多い気がする。

長すぎるTODOリストは終わることがない

つい昨日もTODOリストを作ったばかりなので気をつけよう。
まだ20個なので小さいけど。

プロジェクトのTODOリストで300とかあったエクセルファイルが昔あったけど、アレは精神的にきつかったな。いくらやっても終わらない長いTODOリストは憂鬱だ。

競合相手がなにをしているかなんて気にしない

これもつい昨日、競合相手の分析をしよう、と思っていたところだった。。
大切なのは自社がどうあるべきかで、他人の心配をすることではない。どうせ他社はそのままなわけではないのだから、他社の動きをじーっと観察するより自社内の改善をするほうが先だ。

ドラッグの売人の方法は正しい

本当に自分たちの商品が素晴らしいものであると思っているならば、それをお試しさせれば投資したもの以上のリターンがある。
化粧品や、車は、お試ししてもらえばリターンがあるからお試しをさせているのだろう。
その一方で、家や、マンション、賃貸物件はお試しさせるなんて話はあまり聞いたことがないので試されたらまずいことがあるんだろうか。

自分をマネジメント出来る人を雇う

まったくもってそのとおり。
マネージャ、というかリーダー職についているにもかかわらず自分をマネジメントできないひとばっかり。一緒に働く上では迷惑。
自分のタスクを把握していないとか、自分のスケジュールが守れないのに連絡がないとか遅刻するのに連絡がないとか自分の仕事が終わらなくて仕事を振るのが締切直前とか締め切り後とかうんざりする。
こういうセルフマネジメントすらできない人が管理職になると一緒に働く人達のやる気を大きく削ぐ。

小さなチーム、大きな仕事―37シグナルズ成功の法則 (ハヤカワ新書juice)

小さなチーム、大きな仕事―37シグナルズ成功の法則 (ハヤカワ新書juice)