今回は、牛尾さんの記事『「Be Lazy」を極めるためには残業をしてはいけない』にインスパイアされて書きました。 私たちのように小さな会社が大きな成果を出すためには、無駄なことはしていられません。時間に対して高いパフォーマンスを出す「時間対効果」の高い働き方を徹底する必要がありますよね。 この記事では、私たちのチームで「時間対効果」を高めるために、前提においている働き方の価値観やマネジメントについて書いてみました。 時間をかけすぎてはいけない 中途入社で入った人がやりがちなのが、頑張りすぎること。いや、頑張ることは良いのだけど、時間をかけて成果を出そうとしてしまう。しかし、それでは「時間対効果」で見ると低いです。 私たちのチームでは「ふりかえり」で、仕事の進め方についてメンターがレビューをしますが、最初の頃に指摘するのが、沢山働いて成果を出そうとすることについて。限られた時間の中で、どれだ

今回の技術書部門での大賞は、こちらの「プログラマ脳を鍛える数学パズル」でした。おめでとうございます。 パズル的な問題をプログラムを作って解くという、数学的な発想だったり、アルゴリズムを考えたりするような頭の体操になるような問題を集めた一冊。プログラミングが好きで、パズルを解くのが好きな人ならハマりそうな本です。 プレゼンも良かった。CodeIQでの問題をまとめたものだけれど、その問題をコツコツと作り続け、提出される回答のソースコードのすべてに目を通して、コメントをし続けたという話は壮絶でしたね。その努力に投票した聴衆もいたでしょう。

昨年、ホラクラシーと呼ばれる経営スタイルが出てきました。ホラクラシーは、会社から組織図や肩書きに役職もなくして、経営の意思決定をトップダウンでなく組織全体に分散させる、ヒエラルキーに代わる新しいマネジメントの形です。 アメリカでは有名なザッポスが取り入れたことで一気に注目されるようになりましたが、果たして本当にホラクラシーは良いものなのでしょうか。ヒエラルキー組織のマネージャ視点になって考えたホラクラシーのデメリットについて書いてみました。 １）情報格差で部下を支配できない ホラクラシーをうまく実現するには、社内の情報はオープンでなければなりません。ヒエラルキーの組織ならば、末端の現場ほど限られた情報で良く、あまり考えることもなく働けば良かったかもしれませんが、ホラクラシーではそうはいきません。 情報統制とホラクラシーの相性は最悪です。社内の情報がすべてオープンだからこそ、個々人が現場で判

これまで多くの人の成長を見てきましたが、人によっては成長のスピードが非常に早い人とそうでもない人がいて、そこには幾つか違いがあると気付きました。 この記事では、その気付きから成長のスピードが早い人と遅い人の違いは何があるか考えてみました。もしかすると、ほんの少し意識を変えることで成長のスピードを早くすることができるかもしれません。 １）仕事のあとに「ふりかえり」をしているか 自分の仕事の進め方はいつ改善されるのでしょうか。毎回、同じことを繰り返すだけでは進歩がありません。仕事が終わったら、自らの仕事ぶりをふりかえり、良かったところを伸ばし、まずかったところを直すと良いでしょう。 私たちの会社では、仕事の「ふりかえり」に慣れていないメンバーは、最初のうちは週に１度くらいの頻度で「KPT」というフレームワークを用いて行っています。詳しくは、このブログの「ふりかえり」に関する記事に書いてあるので

今回の記事は、リモートワークアドベントカレンダーの17日目として用意しました。 注目されるリモートワークですが、オフィスで働くのと変わらない成果を発揮するためにはノウハウが必要になります。この記事では「デジタル出社」という新しいワークスタイルで、リモートワークでもチームでうまく働くノウハウを紹介します。 リモートワークを望む課題の本質は「通勤」だったのでは？ 都心で働く人たちにとって、通勤における満員電車ほど嫌なものはないでしょう。ただでさえ飽和状態にある都市人口の中で、多くの人たちが同じ時間に通勤するものだから混雑は大変なものだし、男女共に痴漢にまつわるリスクもあるでしょう。 私がリモートワークを始めて本当に良かったな、と思うのは、満員電車に乗る機会が激減したことです。週２日ほどはオフィスに行きますが、それも午前中は在宅勤務にして、午後から移動にしたりすることで満員電車は避けることができ

メンバーの一人一人が自ら考えて行動し、それでいて仲間と協調し合うような自律的なチームを目指して、日々様々な取り組みをしています。その中でも、セルフマネジメントできる人材を育てるのに効果的だと考えているのが「ふりかえり」です。 そして、私たちは上手に「ふりかえり」ができるようにするために、メンターがついて、そのレビューを行っています。先日も私が「ふりかえり」のレビューをしたのですが、今回はその際に話した効果的なトライの出しかたについて書きました。 「KPT」を使った「ふりかえり」を「レビュー」している そもそも「ふりかえり」とは何か、その手法である「KPT」とは何かについて、以前に記事を書いています。 自律的に現場を改善できるチームをつくるための「ふりかえり」の進め方 〜 KPTと進め方のノウハウ KPTは、Keep/Problem/Tryの略で、「Keep＝よかったこと」「Problem＝

私は今でこそ経営の仕事をしていますが、もともとはプログラマ（今も心はプログラマ）で、その後、アジャイル開発の実践のためにプロジェクトマネージャをしたり、社内ベンチャーを始めてマーケティングを学んだりと、立場を変えてきました。 これまで沢山の本を読んできて、どの本からも学ぶところがあるので何冊かだけを選ぶのは難しいのですが、そんな立場を変えてきた私がそれぞれの節目や転機のタイミングで読んで大きく影響を受けた本を５冊だけピックアップしてみました。 達人プログラマー　システム開発の職人から名匠への道 本来の職人としてのプログラマのあり方、姿勢などを学ぶことができる１冊。これは技術書ではなく、技術者として生きていくため、達人になるための考えかたを記した本です。 私は社会人になって間もない時期に、この本に出会ったことで大変な影響を受けました。ここに書かれた具体的かつ実践的なアドバイスはプログラマとし

「納品のない受託開発」を通じて、新規事業におけるソフトウェア開発を手伝わせて頂いていることもあり、そこで得た知見を活かして新規事業の審査員のような仕事をさせて頂くことがあります。 そこで審査のために提出された資料の中にあるガントチャートや工程表を見るとき、いつも違和感を感じていました。この記事では、ガントチャートが新規事業においては有効ではないという気付きについて書きました。 ガントチャートは決められた工程の管理をするのに最適 ガントチャートや工程表は、あらかじめ完成品が見えており、工程がはっきりしたものを「製造」していくときに非常に役に立ちます。どの工程にどれくらいの工期がかかるのか見えるようにすることで全体の計画が把握できます。 ガントチャートを有効に使うためには、きちんと工程を分解できること、とりかかる工程の順番がはっきりしていること、それぞれの工程にどれくらいの期間がかかるのか見積

一方通行の報告だけの会議は生産的ではありません。生産的な会議とは、その場でディスカッションをしてアイデアを出し合って、その打ち合わせの時間内に結論や成果を出すような会議です。そのためには、打ち合わせでの発言の質が大事になります。 会議で良い発言をするためにも、頭の回転の速さが求められますが、それは才能ある人だけの特権でしょうか。否、そんなことはなくて、努力をすることで身につけることができるのではないか、と私は考えています。この記事では、会議でのアドリブに強くなるための思考スピードを鍛える方法について考察しました。 デキる人は「持ち帰って検討します」を言わない 打ち合わせをしていても、その場で考えることをギブアップして「持ち帰って検討します」「あとで考えてみます」みたいな発言が出ることがあります。そうした後回し思考の発言が出ると、打ち合わせは進まなくなってしまいます。 優秀だなと思う人との打

不特定多数に物を売るのではなく、特定の誰かの問題を解決する仕事をするときには、相手のことを考えるだけではうまくいかない場合があります。どうすれば顧客の本当の満足を得ることができるのでしょうか。 これまで一緒に仕事をして素晴らしいと感じた人たちは皆、その見ている「目線」が違うことに気がつきました。この記事では、問題解決のプロフェッショナルが備えている目線の持ちかたについて書きました。 アウトソースをするときの２種類の目的 私たちが仕事をアウトソースするとき、２種類に分けて考えています。 一つは、決められた単純作業や繰り返し作業のアウトソースです。そういう作業はクラウドソーシングを活用することもありますが、私たちの会社ではそれほど多くありません。だいたいの単純作業はコンピュータを使って自動化してしまうからです。 もう一つは、自分たちには出来ない問題を解決するためのアウトソースです。ウェブサイト

私たちソニックガーデンでは、現場での人材育成の手段として個人の「ふりかえり」と、そのレビューを行っています。それを「ワークレビュー」と呼んでいますが、仕事の進めかたや、仕事に対する姿勢についてふりかえった内容を、メンターがレビューすることで行動の改善と成長を促します。 進めかたとしては、まずは対象者が一人で良かったこと（Keep）や問題（Problem）について洗い出しを行うのですが、ふりかえりに慣れていない初心者がつまづいてしまう様子を何度か見てきました。この記事では「ふりかえり」で、よく陥りやすいパターンと、その解消法について書きました。 自分の内面のことを問題にしてしまう ふりかえりをして問題を洗い出すときに、慣れていないと、ついやってしまうのが自分の内面や性格のことを問題としてあげるケースです。 たとえば、思っているよりも成果を出せていない、それは躓いたときに先輩に相談できてないか

リモートチームとは、物理的に離れた場所で働きつつもチームワークを発揮して、チームで助け合って成果を出していく働きかたです。私たちソニックガーデンでは、リモートチームを５年以上続けてきました。 この記事では、私たちが経験から学んできたリモートチームを実現するときにメンバーが気をつけておくと良いだろうと思う４つの習慣について書きました。 １）仕事に関する「雑談」をして連帯感を出す習慣 チームビルディングの第１歩は、チームを構成するメンバーをお互いに仲間だと認識することから始まります。それはたとえリモートチームであっても同じことです。 もしオフィスにいれば、飲み会や食事の機会があったりして、お互いのことをなんとなく認識することが出来るのかもしれませんが、リモートではそうはいきません。 そこでリモートチームでは、互いに認識しあう機会として、あえて仕事の合間に雑談をするよう気をつけています。雑談とい

ソニックガーデンのブログにて、私たちのグループ企業であるジェントルワークスの串田社長のインタビュー記事が公開されました。プログラマしかいない会社でバックオフィスをどうしているのか、その謎を解き明かす内容になっています。 「介護」のために「働く」ことを諦めない！ 〜起業を選んだ女性社長は、なぜ働き続けるのか?【前編】・【後編】 この記事では、私の視点からバックオフィスを専業とするジェントルワークスという会社を作った理由について書きました。 プログラマだけの会社をつくる 私たちソニックガーデンで取り組んでいる主な事業に「納品のない受託開発」があります。これは、お客様の抱える問題をソフトウェアで解決することを、顧問のように継続的に提供するサービスです。 「納品のない受託開発」をするのは「プログラマ」です。プログラマといっても、お客様が抱える問題を理解し、解決策を提案した上で、手ずからプログラミン

最近、若い技術者を一緒に開発しながら育てています。若者たちが一人前になるためには、勿論しっかりと努力をしなければいけませんが、ただし闇雲に頑張るよりも指針があったほうがいいでしょう。 その視点でベテラン技術者たちを観察すると、効果的な努力の仕方があることに気づきます。この記事では、熟練の技術者たちが日常的にやっている「努力の指針」について考えました。 品質：価値判断を増やすためのレビューを受ける 何よりもまず身に付けるのは、基礎体力です。体力といっても肉体的な意味ではなく、その仕事における基礎的な力のことです。たとえばプログラミングであれば、より速く、より美しいソースコードを書けるようになることです。 未熟なうちは、何をするにしても時間はかかりますし、成果物の品質もよくないでしょう。では、どうすれば上達するのでしょうか。 品質は熟練者からのレビューを受ければ高めていくことができます。品質を

仕事を頼んだときに、この人に任せたら大丈夫そうだな、と感じる人がいます。これまで出会ってきた仕事を任せていいと思える安心感のある人たちには、共通の行動があったように思います。 この記事では、仕事ができる人に共通していた、安心して仕事を任してもらえるようになるための３つの行動について書きました。 行動１：すぐにサッと動く ちょっとした仕事をお願いしても、何事も大袈裟にしてしまう人がいたら、そんな人には仕事は頼みにくいものです。ちょっとしたことをお願いしたときは、サッとやってもらえたら、仕事をお願いする方も気持ち良く頼むことができます。 ちょっとしたことをサッとやってしまえるかどうか、そのためにはそれなりの腕がなければ出来ません。逆に言えば腕がない人は、ついつい大袈裟にしようとします。大袈裟に、立派にすることで自分の価値が高いようにみせかけたいのかもしれません。 実力のないコンサルタントほど、

良い文章を書くこと、そのために文章力を磨くことは、ビジネスパーソンにとって重要な事でしょうか、それとも意味のないことでしょうか。私は文章力を身につけることは、どんな仕事においても最も基礎となる大事なスキルに通じると考えています。 私の考える仕事のできる人は「創造性」「提案力」「論理性」の３つの能力が優れているように思います。そして、この３つの能力は、文章力を磨くことで身につけることができるのではないか、と考えています。 この記事では、ビジネスパーソンにとって、なぜ文章力を磨くことでビジネススキルの基礎が身につくのか、その理由について考えてみました。 文章力で「創造性」を身につける 文章を書くという行為は、ゼロから作品を生み出す行為です。企画書でも提案書でも何かしら文章を書くためには、ただ文字を打てば良いわけではなくて、何を伝えるかを考えて、どう伝えるか構成を考え、それを相手に伝わるように表

先日、島根県の松江で行われた「松江Ruby会議06」というイベントで講演をしてきました。講演のテーマは『「納品のない受託開発」とエンジニアの働きかたのこれから』というもので、「納品のない受託開発」「地方」「Ruby」「ギルド」について話して欲しいと依頼を受けました。 色々と新しいネタも入れた資料ですが、今回の記事では、地方で働くエンジニアについて、その講演で話したことをもとに考えてみたいと思います。 “地方”を言い訳にしている人たち あちこちの地方に講演で伺うことも多く、懇親会などに参加すると地方における問題を聞かされます。確かに様々な問題があるのもわかります。だからといって何か提案をしても「そうはいっても地方だと難しい・・・」という言葉をよく聞くのです。 しかし、果たして本当に「地方」が問題なのでしょうか。 そこで思い出すのは、東京にいても現状を変えようとしない人たちの言葉です。彼らはこ

先日、香港で開催されたFSE2014という国際会議へ参加してきました。 The 22nd ACM SIGSOFT International Symposium on the Foundations of Software Engineering (FSE 2014) will be held in Hong Kong between November 16 and November 21, 2014. 参加した目的は、私たちソニックガーデンが提唱し実践している「納品のない受託開発」というビジネスモデルについて書いた論文が、FSE内で行われるInnoSWDevのワークショップにて採択された�ので、そのプレゼンテーションをするためです。 今回の記事は、その国際会議に参加してきたことのレポートです。（こうした近況報告のブログ的な記事は久しぶりですね・・・） 国際学会に参加することになった経緯

先日の記事に書きましたが、香港で行われた国際学会のFSEにて論文のプレゼンテーションを行ってきました。 英語の論文を作成するにあたって、まずは日本語で論文を書いて、それを英訳したのち、改めて意訳して意図が通るように書き直す、という作業をおこないました。２度手間ではあったのですが、本来の意図を伝えるためにも、大変ですがそうしました。 ということで、私の書いた日本語の論文と、英語になった論文は、意図は同じでも、もしかしたら結構中身が違っているかもしれません。今回の記事では、私の書いたオリジナルの原稿を公開します。英語の論文と見比べてみると面白いかもしれません。 提出した英語の論文： A New Business Model of Custom Software Development for Agile Software Development 以降は元にした日本語の論文： 倉貫 義人 (Ku

私たちの実践する「納品のない受託開発」では、担当のエンジニアがお客さまの顧問となって仕事をしていきます。（参考：顧問弁護士や顧問税理士のような「顧問プログラマ」という仕事と働きかた） お客さまと長い関係を結べることが会社にとって安定をもたらし、お客さまにとっても安心してもらえるため、担当するエンジニアも長期的な関係を築くことを目指します。 しかし、そうすると、必ず聞かれるのが「その人がいなくなったら、どうするのか？」という課題です。私たちのビジネスは、プロフェッショナルサービスでもあるので、人に依存すること自体を見直す必要はありません。だからといって、リスクに対して何も手を打たない訳にはいきません。 この記事では、私たちがどうやって個人に依存する問題へのリスクヘッジを行っているか、少し専門的な話になりますが、私たちの取り組みとその背景について書きました。 Lonely / vishwaan