KPT。良かったこと（Keep）と問題（Problem）、それに改善するためのアクション（Try）を出してふりかえりを行う。そのふりかえりを繰り返すことで、少しずつ改善や成長をしていくための取り組みだ。 チーム単位ですることもあるし、私たちは教育のために個人単位でも行っている。 ふりかえりに慣れてくると、よくあるのが、「KeepもProblemもあまりなく、Tryもない」という状態になるときがある。また、ふりかえりの単位を短くして、週に１度だったふりかえりを毎日するようになると、「KPTで出すことがない」となることもある。 果たして、それはうまくいっている状態なのだろうか？うまくいっているからKPTが出ないのか？ 否。どんなに上達しようと、いいチームになろうと、KPTが出ないということはないし、期間を短くしたからといって、まったく良いことも悪いことも無いということはないはずだ。 もし、KP

良い習慣を身につけたいと誰もが思っている。読書も運動もブログも習慣にして無理なく出来るようになれば、それが人生の一部になる。しかし、習慣を身につけるなど簡単なことではない。 習慣を身につけるのに効果が無いのは決意をすることだ。決意なんてのは一時のもので、気持ちを持続させることの方が難しい。だから精神論ではうまくいかない。 習慣にしたいということは、それが楽じゃないことだからだろう。毎回、取り組む前に自分の意思判断を入れると、それだけで疲れてしまうし、意思が負けてしまうことも、少なくないはずだ。 習慣を身につけたければ、時間を確保することが全てだ。たとえばジョギングの習慣を身につけたいなら、いつの何時から何時をジョギングする時間だ、と予定を入れることだ。 その際に目標は、距離じゃ無い方がいい。5キロ、10キロを目標にすると出来ない日も出てくるだろう。そうすると続かない。習慣にするためには日々

セルフマネジメントで仕事を進めるというのは、指示を待つことでもなく、次の仕事は何かを聞くことでもなく、自分で勝手に仕事を進めることでもない。じゃあ一体どうすればいいの？という話。 次にやるべきことを聞かないと仕事ができない人は、当然まだセルフマネジメントができているとは言えない。指示を待つ人は、私たちのようなフラットな組織ではやっていけない。 私たちが目指しているのは、管理者のいない組織、管理のない会社経営だ。それぞれが自分自身の管理者であるような組織が理想だ。 次の仕事を人に聞くってことは、その相手にまだ依存してる。聞かれた方が結局、その人の仕事を考えることになる。つまり、聞く方は考えることを放棄したってことだ。思考停止になっている。 だからといって、何をすべきか自分で考えて勝手にやってしまう人も、セルフマネジメントできているとは言えない。それは、ただのひとりよがりに過ぎない。 私たちが

テクノロジー業界の発展に伴ってソフトウェア開発者の人材不足がいたるところで発生していますが、言い換えれば「プログラミングスキルを身につければ仕事に困らない」ということでもあります。とはいえ、「若い とても勇気づけられる記事だ。 私も今40を超えて、改めてプログラミングを再開している。ブランクがあるから、まだ下手だけど楽しいから没頭できる。時間が足りない分、若い頃より戦略的に修得に向き合えてるようだ。 この先の長い人生をかけてでも、修得し続けるひとつが、私にとってはプログラミングなのだ。そう思えば、多少は時間がかかっても、取り組むだけの価値はある。 かつて日本のIT業界には「30歳定年説」や「35歳定年説」などという言葉があったが、今となっては迷信となってしまった。 設計作業を伴わない、プログラミングをただ「打ち込むだけの仕事」と考えたら、体力の問題だったのかもしれない。人月で見積もりをする

様々な体験や経験をすると、人は多くのことを学んだ気になる。 それは果たして本当に学んだのか。実際のところ、学んだという感覚を得るだけで、自分の血肉にはなっていないのではないか。 スキルや考え方は一度、体験するだけで身につくことなど、あまり無い。喉元を過ぎれば、というやつだ。 一体、何を学んだのか。それが言語化されない限り、脳の中には残らないのではないだろうか。 熱いストーブを触って、ストーブは危険だと気付く。「熱いものは危険」だという言葉になって初めて学びとなるのではないか。 研修や勉強会に参加して、仕事の出来事を通して、何か体験をしたら、それで勉強になったなぁ、と思って終わるのは勿体無い。 体験は、そのままにしないで言語化してみよう。言葉にしようとすれば、整理される。何が学びだったのか、考える機会になる。 言語化は、抽象化とも考えられる。起きた出来事を100%写実することはできない。余計

仕事や勉強をしていると集中して没頭する瞬間がある。それを「フロー状態」と呼ぶらしい。そんなフロー状態について聞いた話から着想を得て。 フロー状態になると、周りから雑音が消えて、その対象に集中し、高い生産性を発揮することができる。アイデアなら次から次に湧いてくる、プログラミングなら次々とコードが進む。 そんな状態は、脳も喜んでいるらしい。そのフロー状態になっていること自体が、幸せな状態なのだと言える。詳しくは知らないけれど、おそらく脳内物質が分泌されているのだろう。 もし、仕事をしていてフロー状態になれるのだとしたら。フロー状態になって幸せになれるのだとしたら。それはもはや、仕事をすること自体が幸せになる手段だと言えないだろうか。仕事は手段ではなく目的なのか。

仕事をしていると、色々な問題が起きる。 私の仕事である経営などは、毎日を違うことをするし、新しい問題が次々と出てくる。 問題がなくなることはなくて、もし無さそうに思えたら、それは経営の怠慢だろう。何が問題かを見つけることも経営の仕事だ。 これから起きそうな問題を先回りして解決していけば、会社は安定しやすい。安定したいかどうかも経営者の資質次第だが。 ただ、これは私が経営者だから経営の話をしているだけで、問題とその対処については、経営に限った話ではないだろう。 そうした日々起こる問題に対して、どのように取り組むか。 ひとつひとつ解決していくしかない。もちろん、優先順位を考えないと、うまくいかない。かかる労力が少なく、効果の大きいものから取り掛かる。 個々の問題は、それぞれの文脈に依存する。どの問題も同じことはない。 特に経営なら、だいたいの問題が人の問題になる。まあこれも経営に限らないだろう

本質を捉えて行動するには。 本質を見つけるためには「そもそも何のためにするんだっけ」と、立ち止まって考える。 そして、そもそもの目的がわかったときに、その目的を達成するため以外のことにはこだわらない。 こだわりを捨て、変えていく勇気。それは過去の慣習や経験からいえば、勇気のいることかもしれない。 それでも思い切って変えていく。変えることができないなら、たとえ本質を捉えても意味がない。 ただし、目的がはっきりしていれば、アプローチにはこだわならなくて良いが、なんでも良いわけではない。 どの手段・アプローチを選ぶか価値観が必要だ。価値観に沿って選ぶと後悔は少ない。 会社でも同じ。たとえば私たちなら「ソニックガーデンらしさ」と呼んでいる。 経営戦略を考える時も、そのアプローチが自分たちらしいかどうかで判断する。らしくなければ選ばない。 チームは共通の価値観を持っているので、意見がぶつかることはな

会社と社員の関係がどうあって欲しいか。特に、私が採用の時に見ている点について。 まず無理して拡大するつもりがないから、どうしても急いで人を採用する必要はない。人を採用することで得られるものは、そんなにない。多少、人数が多いと安定性が増すくらいのものだが、もとから安定している。 つまり会社が事業拡大をしたいために、そのための労働力としての人が欲しいわけではない。あくまで一緒に働くことが楽しいから、仲間になっている。それを物理的に表したものが会社と社員の関係だ。と考えている。 そこは一般的な会社と社員とは大きく違うだろう。だから、会社対社員という向き合い方にはならず、社員同士という関係性しかない。会社という器に社員を入れている訳ではない。 言ってみれば、創業者だけの会社のようなものだ。だから採用は慎重に行う。そして、どれだけ人数が増えても、その関係性を維持していきたい。 だからという訳ではない

ブログを継続的に書いていると、たまにプチ炎上しつつも、多くの人の目に触れる記事が出るときがある。 賛否両論になる極端な意見や、主語を大きく捉えた話題、ヘイト気味の過激なタイトルなどが、ホットエントリになりやすい。だから、その辺りを計算して狙うことも出来る。（量産型プログラマの記事とか・・・） 炎上を肯定している訳ではない。良い記事を書くことが一番大事だ。でも、毒にも薬にもならない記事より、人の心に刺さる記事を書きたい。ま、薬になる記事の方が健全ですが。 それはさておき、単発のヒット記事を書いたとしても、読者は一気に増えたりはしない。もちろん、それなりには増えるけれど、広く認知されるまでには至らない。 多くの人に、存在を認知してもらうためには、何度も目にしてもらう必要がある。それも、短期間のうちに目にしてもらう方が効果的だ。一旦、認知さえしてもらえれば、あとは程々でも、人は覚えていたりする。

プログラマの生産性の差は、出来る人と出来ない人で10倍とも100倍とも言われる。そんな馬鹿な、と思われるかもしれないが、事実だ。 むしろ、一緒に働かせると、出来るプログラマが、下手に作られたプログラムの修正をしなければいけなくて、全体の生産性を落とすことになる。 つまり、出来ないプログラマはチームで働くと、生産性をマイナスにするのだ。厳しいことを言えば、いない方がマシなのである。 ソフトウェア開発に猫の手はいらないのだ。 では、出来ないプログラマとはどんな人たちか。 コピペで書くプログラマだ。他で動いているプログラムをコピペして、なんとなく直して書いているプログラマだ。 なぜプログラムが動くのか、どう書けば動くのか、わかっていない。 ただ沢山のプログラムを書くだけの量産型プログラマだ。こういう人のプログラミングは、デバッグさせてみて、横で見てるとすぐにわかる。 まず、エラーメッセージを見な

現場のオペレーションを改善するために、最初に着手するなら何か？と聞かれたら、いつも「ふりかえり」から始めましょう、と答えています。かつてトラブルの起きているプロジェクトに入ったときも、まず始めたのは「ふりかえり」からでした。 ... すべての仕事が「問題解決」だと考えること。考えなくて良い仕事はない。それは作業であり、そんなものは仕事ではない。開発業務だろうが、事務作業だろうが、よくしていく、うまくやる、楽にする、ことを考えなければいけない。 そして、お客様なり依頼する人が、何の問題を抱えて、その依頼をしているのか、考えなければいけない。そうして、問題を解決することを考えて取り掛かることが、本当の仕事だ。 生まれ持った性格は受け入れること。ふりかえり、を究極まで行くと、生まれもった性格の問題になるので、そこまで行くと治せないし、治さなくて良い。 性格を受け入れた上で、どう行動するか、まで含

講演などすると、質疑応答や懇親会で聞かれるのが「最初どうやったのか？」「最初からそんなことができたのか？」ということで、それに真摯に答えると、わりとがっかりされてしまうという話。 私たちには営業がいなくて、100%お問い合わせで始まるインバウンドマーケティングをしているという話をすれば、「最初はどうしたんですか？」「最初からお問い合わせでお客様はこないですよね？」と。 確かに、いきなり今のスタイルでビジネスができた訳ではなくて、それまでの歴史があって今がある。さて「最初」とはいったい、どこまで遡って話すべきか、と思いつつ、それまでの歴史を説明をする。 たとえば、私が「アジャイル開発」の文脈で、これまでずっと色々な活動やブログ、講演などをしてきて、10年以上の時間をかけて多くの方に知って頂く機会をもって、その上で、起業したのでその時点で、既にけっこうな方に注目して頂けたというのが大きいはず。