サウスポーなエンジニアの独り言

サウスポーなエンジニアが日々感じた、気づいた、学んだことを徒然と書いています。

旧館より 書籍

小さなチーム、大きな仕事―37シグナルズ成功の法則

投稿日:2011年1月5日 更新日:


<

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

「37シグナルズ」の理念を書き記しています。
ページ数は多くなく、また簡潔に書かれているので非常に読みやすいです。
読みやすい故にサラッと流れてしまいそうですが、1つ1つを自分に当てはめて考えみると、色々と思うところがありました。
#私も2、3回読んでいます。

◆目次
まず最初に
見直す
先に進む
進展
生産性
競合相手
進化
プロモーション
人を雇う
ダメージ・コントロール
文化
最後に

仕事依存症はバカげている
無闇な仕事依存症は確かに効率が良くないと思います。
けれど、仕事の種類の区切りを明確に分けていて、かつ、情熱、モチベーションを持っているのであれば、(ある程度の期間であれば)良いのでは?と思いました。

おそらくここで言いたいのは「やるべきこと、やらないでいいこと」を判断せずに、ただ「仕事があるから」という理由だけでするのは…と思っています。

この辺はこっちのエントリにも書いた「やるべきでないことは、いっさいやるべきでない。以上。」と通じるものがあると思いました。

あなたに必要なものを作る
今手掛けているサービスでは(ありがたいことに)「自分だったらこういうのがあったら嬉しいよなぁ」というアイデアを取り入れる余地があります。
で、特定のお客様向けへのシステム開発でも「自分だったら…」の意識を持ってみると、その質が良くなるのでは?と思います。

「時間がない」は言い訳にはならない。
「失敗から学ぶこと」は過大評価されている
 フリカエリなどでも「ダメだったこと」「うまくいかなかったこと」を挙げて「じゃ、次どうしようか?」という話をすることがあります。
 (それも必要かもしれませんが)それよりも「今回うまく行ったこと」を明確にして、ノウハウとして共有した方がチーム、組織としては有効です。

中途半端な製品ではなく、半分の製品
会議は有害
会議はそれなりの規模の組織であれば、かなり数多くあり、かなりのリソースを使っています。
当然、それなりの意思決定をしようということも多いのですが、その割にはアウトプットがいまいちな会議が多いのも事実です。
これらをファシリテートできれば、それこそコスト削減や競争要因になります。

小さな勝利を手に入れる
1、2週間毎に成果を出せるようにしたり、プチフリカエリを行って成長を認識する…という感じかと思います。

あなたの見積りは最悪だ
観客をつくる
料理人を見習う
会社を「知人のいないパーティー」にしない
 プロジェクト毎にお互いのことをほとんど知らない…それこそ同じ組織に属する程度…ような状況で良いパフォーマンスができるわけはありません。
こういう組織の管理職ほど「頭数を揃えばできる」と思っていて、「とりあえず人を追加しようか?」などという発言が多いように思います。

全員が働く
ダメージコントロール
大げさに反応しない
ひらめきには賞味期限がある

この本に書かれているようなことが出来ていけば、良い組織になると思いますが、組織、部門の規模が大きければ「すぐに変える」というのは難しいかもしれません。

ですが、グループ、チーム…極端に言えば自分自身…であれば、良い提案、アクションはすぐに実施し、自分でその効果を出せることが多いと思います。

※注意:この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

-旧館より, 書籍

執筆者:


comment

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

関連記事

何かを変えたい(チェンジ)時の5つのコツ

先日「AgileTourOsaka2012 in Minoh」に参加してきました。 箕面という珍しい土地も楽しめましたし、スピーカー3人ともあまり関西ではお話されない方なので、お話が聴けて良かったです …

「お医者さん」だって全部の病気を知らないでしょ?

仕事、プライベート問わず「パソコンの事」を質問されると結構困ります。 自分の知っている/使っているアプリケーション、OSに関する質問であれば、それなりに答えられます。 もし、答えが分からなくても、(経 …

仕様を縦断する視点、横断する視点

外部設計や内部設計なんかの色々なレビューをしているうちにふと思ったことです。 レビューやインスペクションは画面単位(もしくは単機能を構成する複数画面)で行うことが多くなります。 そこではある要求仕様が …

業務の引継ぎや情報の伝達で思ったこと

今のチームで仕事をやり始めて2ヶ月半が過ぎました。 その2ヶ月半で、業務の引継ぎや情報の伝達について、ふと思ったことがあったのでつらつらと書いてみます。 自分の立場 中途入社でしたので、チームが携わっ …

【引継ぎ】タスクへの考え

 『トラックナンバー』について以前書きました。 そのトラックナンバーを意識して取り入れたプロジェクトの効果に『引継ぎタスクをスムーズにできた』というのがあります。 ほとんどのプロジェクトでは、後工程に …

ギルドワークスの現場コーチ。
「正しいものを正しくつくる現場を増やす」ことを目指している現場コーチ。認定スクラムマスター(CSM)。
様々な規模のSIerでのシステム開発を経て今に至る。
DevLOVE関西を主催。