サウスポーなエンジニアの独り言サウスポーなエンジニアの独り言サウスポーなエンジニアが日々感じた、気づいた、学んだことを徒然と書いています。(ハヤカワ新書juice)「37シグナルズ」の理念を書き記しています。ページ数は多くなく、また簡潔に書かれているので非常に読みやすいです。読みやすい故にサラッと流れてしまいそうですが、1つ1つを自分に当てはめて考えみると、色々と思うところがありました。#私も2、3回読んでいます。最後に仕事依存症はバカげている無闇な仕事依存症は確かに効率が良くないと思います。仕事の種類の区切りを明確に分けていて、かつ、情熱、モチベーションを持っているのであれば、(ある程度の期間であれば)良いのでは?と思いました。ここで言いたいのは「やるべきこと、やらないでいいこと」を判断せずに、ただ「仕事があるから」という理由だけでするのは...と思っています。この辺はこっちのエントリにも書いた「やるべきでないことは、いっさいやるべきでない。」と通じるものがあると思いました。あなたに必要なものを作る今手掛けているサービスでは(ありがたいことに)「自分だったらこういうのがあったら嬉しいよなぁ」というアイデアを取り入れる余地があります。特定のお客様向けへのシステム開発でも「自分だったら...」の意識を持ってみると、その質が良くなるのでは?と思います。「時間がない」は言い訳にはならない。「失敗から学ぶこと」は過大評価されているフリカエリなどでも「ダメだったこと」「うまくいかなかったこと」を挙げて「じゃ、次どうしようか?」という話をすることがあります。(それも必要かもしれませんが)それよりも「今回うまく行ったこと」を明確にして、ノウハウとして共有した方がチーム、組織としては有効です。会議はそれなりの規模の組織であれば、かなり数多くあり、かなりのリソースを使っています。それなりの意思決定をしようということも多いのですが、その割にはアウトプットがいまいちな会議が多いのも事実です。これらをファシリテートできれば、それこそコスト削減や競争要因になります。小さな勝利を手に入れる1、2週間毎に成果を出せるようにしたり、プチフリカエリを行って成長を認識する...という感じかと思います。あなたの見積りは最悪だ観客をつくる料理人を見習う会社を「知人のいないパーティー」にしないプロジェクト毎にお互いのことをほとんど知らない...それこそ同じ組織に属する程度...ような状況で良いパフォーマンスができるわけはありません。いう組織の管理職ほど「頭数を揃えばできる」と思っていて、「とりあえず人を追加しようか?」などという発言が多いように思います。全員が働くダメージコントロール大げさに反応しないひらめきには賞味期限があるこの本に書かれているようなことが出来ていけば、良い組織になると思いますが、組織、部門の規模が大きければ「すぐに変える」というのは難しいかもしれません。グループ、チーム...極端に言えば自分自身...であれば、良い提案、アクションはすぐに実施し、自分でその効果を出せることが多いと思います。※注意:この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。コメントをキャンセルメールアドレスが公開されることはありません。先日、あるSIerが発表したプレリリースを読んで、ふと思ったことです。そのプレスリリースは「こういうソリューション提供できますよ。御社で使ってください」というものでした。...週次フリカエリ最近、お客様への納品が終わったプロジェクトで採用した「プチフリカエリ」について書きます。...仕事に対する心構え(プロパー、パートナー問わず)始業ギリギリ(1,2分前)にバタバタと出社して来る人がけっこういます。#フレックスの人は悠々~って感じですが。...Javaの格言―より良いオブジェクト設計のためのパターンと定石[読書感想]仕事でJavaを使ってのシステム構築をしています。勉強したり、資格を取るためJavaをさわることはあっても仕事は初めてです。思い立って以前に買って積読していた↓をちゃんと読んでみました。変化に強い大規模開発を成功させる14のベストプラクティス[読書感想]NEXTコンサルタントの道具箱[読書感想]ギルドワークスの現場コーチ。「正しいものを正しくつくる現場を増やす」ことを目指している現場コーチ。認定スクラムマスター(CSM)。様々な規模のSIerでのシステム開発を経て今に至る。DevLOVE関西を主催。(14)サウスポーなエンジニアの独り言サウスポーなエンジニアが日々感じた、気づいた、学んだことを徒然と書いています。