先日（といいつつ結構前になりましたが）、私が社外取締役を務める株式会社クラシコムのエンジニア向けトークイベントに参加して、出番を頂いて話をしてきました。 クラシコムは、ECサイト「北欧、暮らしの道具店」を運営する会社で、商品コンテンツだけでなくドラマや映画、ポッドキャストを通じて世界観を発信しています。そうした様々な活動を支えるためにも、エンジニアチームを抱えてシステムを内製しています。 今回のイベントテーマは「社内受託にならないエンジニアチームのつくり方」で、私も含めクラシコムのテクノロジーグループが取り組んできた経験を話してきたので、本稿では私の話したことに加えて補足をいれながら言語化してみます。 社内受託になりがちな内製エンジニアチーム まず一般的な話ですが、事業会社におけるエンジニアチームの立ち位置は、場合によっては、同じ社内にもかかわらず一括請負の受託開発のように、決めたものを作

私たちソニックガーデンには、本社オフィスがない。全員がリモートワーク、在宅勤務なので、物理的に出社するためのオフィスをなくしてしまった。 今は、テレビ会議とバーチャルオフィスを組み合わせて普段は仕事をしている。 リモートワークに取り組む際に、私たちのやり方をそのまま真似をするとうまくいかないかもしれない。なぜなら、私たちも一気に今の状態になったわけではないので、私たちと同じように段階を踏んで進めていくのが良いのではないだろうか。 本記事では、私たちが物理オフィスのない完全リモートワークに至るまでに取り組んできた試行錯誤の変遷をふりかえってみよう。 ステップ0.昔ながらのオフィス（2008年頃） 私たちソニックガーデンは、もともとは大手企業の社内ベンチャーとして始まった会社だ。その当時は、それはもう本当に普通の働き方をしていた。 浜松町にある大きなビルが会社のオフィスで、私たちはその１０階に

少しプログラミングが出来るようになると、それはそれでまた伸び悩むこともある。始めたばかりの頃は、プログラムが動くだけで楽しかったけれど、実用的で、少し複雑で難しいものを作ろうとすると、途端に時間がかかってしまう。 プログラミングがうまくなる近道などないとはいえ、経験者だからこそ伝えられることもあるのではないか。そう言えば、私も若い頃に先輩から、コードを書くこと以外にも、プログラミングをする上での姿勢や習慣などを教わった。 私もプログラミングを再開したがブランクがあるので、今となっては古い習慣もあるかもしれないが、私が先達から学んだことを伝えておくために残しておこう。もしかしたら、抽象化すればビジネスにも通じる習慣もあるかもしれない。 エラーが出ても慌てず、メッセージを読もう プログラミングをしていてエラーに出会わないことはないだろう。うまく出来たと思って実行ボタンを押したけど動かない、落ち

前々回の記事『理想の働き方改革より現場の業務改善を 〜 現実的で効果的な「業務ハック」のはじめ方』では、業務改善とシステム化を一緒にやってしまう「業務ハック」というコンセプトについて書いた。 そして、今週末には業務ハックの初の勉強会が開催される。おかげさまで好評なため、大阪でも開催することに。（業務ハック勉強会@東京、業務ハック勉強会@大阪） 今回の記事では、そんな「業務ハック」に取り組む職業「業務ハッカー」、すなわち業務改善とシステム化を一緒にやってしまう仕事について書いた。 業務改善とシステム化を兼業する「業務ハッカー」の土壌 「業務ハック」では、現行業務の分析と見える化を行い、ボトルネックを発見し、もっとも効果的な部分から小さく始めていくことを特徴としている。そして、なんでもかんでも作るのではなく、便利なツールやプラットフォームを駆使して、もっとも費用対効果の高いところだけをプログラ

先日、愛媛松山で開催された、「JAWS Festa中四国2017」に参加して、パネルディスカッションに登壇して来ました。 クラウドに関するコミュニティのイベントだけど、今回のパネルディスカッションでは、リモートワークや複業という最近の話題になっている多様化する働き方をテーマにしたものでした。一緒に登壇して頂いた皆さん、ありがとうございました。 「○」と「×」で回答してコメントしていく形だったので、本記事では私の回答とコメントについて、少し補足しつつ書いておきます。（パネルディスカッションでは、リモートワークと副（複）業と並べてましたが、わかりやすさのために今回の記事では、リモートワークにフォーカスしています） 原則リモートワーク禁止な会社にいたことはありますか？　→ ○ 私の前職は、それなりの規模の企業だったし、私が働いていた当時はリモートワークという言葉もなかったので、いわゆる普通の一般

先日、採用に関して、プログラミングを仕事にしたいという方からの問い合わせを受けた。採用の問い合わせについては、社長である私が第一報を返している。今回受けた相談への回答は、他の方にも参考になるのではないかと思い、本人の了承を得た上で、そのまま公開させてもらうことにした。 プログラミングをはじめて楽しくなったので仕事にしたいと思っている方や、これからの時代を生き残るにはプログラマだと考えて仕事にしたいと思っている方など、本気でプログラミングを仕事にしたいと思っている方にとって参考になれば幸いだ。 プログラマ採用に関する質問 現在建築会社で働いているのですが、IT関連の情報をニュースやネットで見かける度に関わりたいという欲が抑えきれなくなり、プログラミングの勉強を始めました。 色々なサイトを巡り、オブジェクト指向を理解した方がよいということでJavaから入ったのですが、コードを書いては消し、思っ

「心はプログラマ、仕事は経営者」プログラマである自分が働きたいと思える会社を作りたいと思って経営をしてきた。結果として、セルフマネジメントでフラットで自己組織化された組織、最近だとホラクラシーと呼ばれるような経営をしている。 いい会社だと言ってもらえることもあって誇らしく思うのだが、果たして本当に良い会社かどうかはわからない。価値観に合致するプログラマにとっては良いかもしれないけれど、合わない人や他の職種の人にとっては全然ダメな会社かもしれない。 よく取材などでも聞かれるが、今の経営スタイルは、たいそう立派な理念や理想があって実現した訳ではなく、プログラマである自分自身が苦手なことをせずに済むように、逆に出来ることと得意なことは徹底的に活かそうとしてきたに過ぎない。 思い返せば、徹底的に極端にしてきたことが功を奏したことから、この経営スタイルは、もし名付けるなら「エクストリーム経営」と呼べ

「働き方改革」という言葉が注目される中で、リモートワークにも取り組もうとする企業も増えてきているように感じる。 しかし、これまでオフィスで働くことが普通だった会社の人たちが、いきなりリモートワークに取り組もうとしてもうまくいかないことも多いだろう。うまくいかなくて、リモートワークはやっぱり駄目だ、と思ってしまう人たちもいるかもしれない。 それは非常に残念なことだ。私のところにも、そろそろ失敗したケースの知見が溜まってきつつある。今回の記事では、失敗してしまうパターンと傾向について、そして、そうならないためにマネジメント側で出来ることについて考えてみた。 リモートワークだと集中できて良い？ リモートワークを試してみた人の感想で、よく言われるのが「リモートワークだと集中できてよかった。たまにリモートワークするべきだ」というものだ。 オフィスにいれば、参加の求められる会議が多かったり、電話や内線

プログラミングには、論理的に考える力と抽象化して本質を捉える力が求められる。これらは、なにもプログラミングに限らず、あらゆる仕事の場面で役に立つ。むしろナレッジワーカーにとっては基礎力といっても良いのではないだろうか。 本記事では、新米のナレッジワーカーが最初に身につけておくと良い論理的思考と抽象化思考について、プログラミングで鍛えられることについて考察した。 ビジネスの共通言語としての論理的思考 仕事をしていても、なんとなく考えたことは自信を持つことができない。だから、なんとなく説明しても伝わらない。そして、なんとなく実行したら、成功しても失敗しても、なんとなくしかわからない。なんとなくでは再現性がない。 論理的に考えるということは、選択肢を考えて、そこから選ぶ理由を考えることだ。そうして考えたことは、説得力がある。世の中には絶対の正解はないから、正しいかどうかは出せないが、少なくとも仮

長くなったので先に三行でまとめておこう。 コピペするプログラマが生まれるのは教育の問題ではないか（仮説） 文法は学んでも処理の流れから考えることは教わっていない（根拠） ロジックを訓練するには脳内プログラミングが良いのでは？（提案） 少し前に私のMediumで、こんな記事を書いた。タイトルが言葉足らずだったおかげで、少し話題になった。「量産型プログラマを撲滅したい」 今回の記事では、この中で書いたコピペするプログラマがなぜ生まれるのか、どうすれば良いのか、考えてみたい。 どうすれば見分けられるのか 書いたプログラムを説明させてみれば、その人が、ちゃんと考えて作れる人か、コピペでしか作れない人か、すぐにわかる。自分の書いたプログラムの流れを説明できるということは「わかって書いた」ということだ。わかっていなければ説明できない。 「わかって書く」という一見すると当たり前のことができない人もいる。

社員一人ひとりが会社で本来の自分を曝け出すことができること、そして、それを受け入れるための「心理的安全性」、つまり他者への心遣いや共感、理解力を醸成することが、間接的にではあるが、チームの生産性を高めることにつながる。 これは現代ビジネスのウェブ版に掲載された以下の記事からの一節だ。 グーグルが突きとめた！社員の「生産性」を高める唯一の方法はこうだ グーグルが取り組んだ生産性向上計画についての記事で、それによると生産性の高いチームに共通するのは「他者への心遣いや同情、あるいは配慮や共感」がうまくいっていることだと言うのだ。 チームの中で、気兼ねなく安心して発言や行動できるような心理的な不安がない状態が、高い生産性を実現すると言われれば、確かにそう思う。そうした状態を心理学の専門用語から「心理的安全性（psychological safety）」と呼ぶらしい。 これまで言葉として認識していな

今や、あらゆる場面においてソフトウェアが重要になってきた社会の中で、プログラミングを学ぼうと考える人も多いだろう。プログラミングを身につける方法は、インターネットにはたくさん情報があるし、本も多くある。開発環境も無料で使える。独学したい人には良い時代になった。始めるのは、とても簡単だ。 一方で、挫折する人も多くいることが想像できる。情報が多くありすぎて、学び方ひとつとっても様々なことを言っているし、チュートリアルのようなものをやってみても、じゃあ自分で作るなら一体どうすれば良いかわからない。どの言語を選べば良いか、頭でっかちになって始められない人もいるかもしれない。 プログラミングを手っ取り早く身に付ける方法などあるのだろうか。これは、正解のない問題だ。人によるし、作りたいものにもよる。身に付けたい動機にもよるし、そもそもが、どこまで出来たらプログラミングを身に付けたと言えるのだろうか。

「仕事」と「作業」は違う（参考：「仕事」と「作業」の違いは何か）。学生時代のアルバイトなら「作業」が殆どだろう。しかし社会人になってするのは「仕事」だ。任された仕事は自分でマネジメントする必要がある。 仕事の質とスピードは、手を動かす時間よりも、その前後に使う頭で決まる。本記事で書いたのは当たり前なことばかりだが、新人や若手のうちに身につけてもらう仕事の基本として参考になれば幸いだ。 目的を確認して「そもそも」を考える 仕事には目的がある。作業ならば目的など知らずとも手を動かせば良いが、仕事は目的を達成してナンボだ。であれば、目的を達成さえすれば、どんな手段をとっても構わないとも言える。効率的に達成できるか考えることも仕事のうちだ。 そのためには、これからする仕事の目的を把握しておく必要がある。仕事の目的がわかっていれば良いが、もし曖昧なら確認をしよう。把握する目的とは「誰のためか」「何の

起業でも独立でも何かに挑戦するとき、裸一貫から自分の力だけで成し遂げる方が立派だと思われがちだ。いや確かに立派だが、もっと苦労やリスクを減らして、うまくやっても良いのではないだろうか。 今はサラリーマンでも、いずれ独立して自分の力で生きていきたいと考える人も多いだろう。そうした時の「自分の力」とは一体なんだろうか。スキルや経験だけが自分の力だと考えてはいないだろうか。 私は、さほど大きなリスクも取らず堅実にやってきたが、それなりに自分の理想とする会社と働き方が実現できている。これは本当に運良く周りに恵まれたおかげだ。ただ、恵まれた環境を活かしてきたことも大事だったように思う。 そこで本記事では、自分の実力をどう捉えるか、そして環境や立場を活かした戦い方について考察してみた。 自分を取り巻く環境さえも自分の実力のうち 私も若い頃に勘違いしていたことがある。それは、自分の能力とは、ただ自分一人

多くの企業が新規事業に取り組んでは失敗している。新規事業はそもそも難しく、企業の中で始める新規事業もスタートアップも成功するケースはわずかしかない。中でも既存事業をもった企業の中で新規事業を立ち上げるのは、非常に難しい。スタートアップに比べて恵まれた環境にあるにも関わらず、である。 私たちも大手システム会社の社内ベンチャーからスタートしたので事情はよくわかっているし、「納品のない受託開発」では新規事業に取り組むお客様の相談を多く受けてきた。本記事では、そうした経験から新規事業の当事者でなく、既存事業の経営側がやっていることで失敗させてしまっている点について考察した。 たくさんの関係者を入れる 仲間内で始めるスタートアップと違い、企業で新規事業に取り組む場合は、社内からメンバーを集めてきて体制を作るところから始まる。事業計画をもとに必要なスキルを持った人員が配置される。しかし、そこに落とし穴

自分の所属する会社をなんとか変えたい。そう考える人は割と多い。経営者じゃないので組織変革なんて大層なことでなくても、新しいツールやリモートワークなんかの新しい働き方を導入したり、良くなるように会社を変えていきたい、といったところだ。 もっとドライに、自分に合わない会社だったら辞めて次の会社に移るという考えの人もいる。そうでなく、そこでしか出来ない仕事や、そこで働く人たちが好きで、愛着もあって辞めたい訳じゃない。だったら、その組織を今よりも良くしたいと思うのは当然のことだろう。 しかし、そう簡単に今ある組織を変えていくことはできない。大企業なら尚更だ。私自身、組織を変えていこうとした経験もあり、どうすれば良いかアドバイスを求められることも多い。そこで、本記事では組織変革に取り組んだ経験から気づいたこと、そして私の考えを記したい。 SIerの中でアジャイル開発を主流派に出来なかった 私は前職時

私たちソニックガーデンでは、指示命令のマネジメントを捨て、メンバーそれぞれが自分で考え自律的に行動することで、高い生産性を発揮しつつ様々な変化に対して柔軟に対応できる組織づくりに努めている。 そんなメンバーたちに求めるのはセルフマネジメントができることだ。セルフマネジメントができるために身に付ける素養は少なくない。しかし、セルフマネジメントを身につける最初の一歩は何かを聞かれたら「タスクばらし」だと答えるだろう。 本記事では、セルフマネジメントをマスターするための最初の必須のスキル「タスクばらし」について紹介する。 「タスクばらし」とは 「タスクばらし」とは、読んで字のごとく、仕事をタスクにバラすことである。仕事に取り掛かる前に、その仕事の要素を分解し、どのように進めるか道筋を立てることで、どれくらい時間がかかるか、リスクは何か、見通しを得ることができる。 当たり前のことだと思っていたが、

私たちソニックガーデンでは、かねてより全社でリモートワークに取り組んできました。今では24名いる常勤メンバーの半数以上は地方に住む在宅勤務者です。採用応募の殆ども地方からであるため、今後もリモートワーカーは増えていくでしょう。 それでも、これまでは東京の渋谷にオフィスを構えていました。しかし、2016年6月末の契約更新の際に解約を行い、次の移転先は用意せず物理的な「オフィス」という概念を一旦やめて、複数のワークプレイスに分散させることにしました。 今回の物理オフィスをなくした取り組みは、TechWaveでも記事にして頂きました。ありがとうございます。それがこちらの記事。「本日でオフィスなくします」自律的リモートワーク先進企業の門出 【@maskin】 本記事では、その補足として、私たちがオフィスをなくした理由と狙い、そして、新しい分散型ワークプレイスのコンセプトと実践について書きました。

プログラミングができるITエンジニア人材の市場価値は、以前と比べて非常に高まってきているように感じる。そこで求められている人材とは、自ら手を動かすことで問題解決をするナレッジワーカーとしての「プログラマ」である。 決して、仕様書通りにコーディングだけする職種のことではない。それは以前に書いた。ソフトウェアエンジニアの目指す道 〜 ナレッジワーカーとしてのプログラマ 今回の記事では、この10年間で起きた市場や環境の変化から、手を動かせるプログラマの市場価値が高まってきた背景について、そして、これから求められるITエンジニアの姿について考えてみた。 12年前の転職市場で求められていたスキル 私が30歳を過ぎた頃、今から12年前（2004年頃）の話になるが、その当時に転職しようと少し調べたことがある。自分の年齢と経験をもとに探した応募要項で求められるスキルは、マネジメントであり大規模プロジェクト

プログラマの世界には「技術的負債」という言葉がある。ソフトウェアを開発していく中で、時間がなくて妥協したり、技術力が足りなかったりして、適当に作ってしまった部分が、後々になって不具合を引き起こしたり、改修にかかるコストをあげたりすることを言う。 後になればなるほど、悪影響が大きくなることから負債と喩えられる。そんな技術的負債と同じように、組織やチームのマネジメントでも、後になればなるほど悪影響が出てくるような「組織的負債」とも言えるような現象が起きてしまうことがある。 本記事では、私たちソニックガーデンで「組織的負債」を貯めないようにチーム経営してきた経験をもとに、プログラマの哲学を応用したマネジメント術について書いた。（今回の記事では「である」調にしてみた） 技術的負債と組織的負債の生まれる背景 技術的負債が生まれるのは、スタートアップの初期段階に多い。その時期は得てして、経験豊富な技術