中途採用におけるセルフマネジメントできる人の見分け方 | Social Change!
採用は非常に難しい仕事だ。自分たちの会社に合う人かどうか、仕事が出来るかどうか、長く一緒にやっていけそうかどうか、様々な観点で確認していく必要がある。 私たちの会社は、管理のない会社経営に取り組んでおり、それを支えるのはセルフマネジメントで働ける人たちの存在だ。社内の誰もがセルフマネジメントが出来なければ、フラットな組織は成立しない。だから、セルフマネジメントが出来る人かどうか、採用の際に見極めなければならない。 採用に正解はないし、フィーリングも大いにあるだろうが、その中でも、今回は私が中途採用で面接をする際にセルフマネジメントが出来そうな人材かどうか、気にしているポイントについて書いた。 仕事をやめて背水の陣で挑もうとしてないか 前職を辞めて、絶対に入社するぞ、という覚悟をもって転職活動に臨まれる方がいる。そこまでの気持ちがあって素晴らしい、と考える会社もあるかもしれないが、私たちの場
再現性に基づいた成果をあげるフレームワーク「管理ゼロで成果はあがる」講演資料（抜粋版） | Social Change!
先日の要求開発アライアンスでの出版記念講演で使った講演資料を公開します。見やすいように抜粋版として画像にしてみました。その際のTwitterでのまとめはこちら。 自己紹介はサッと飛ばして・・・以下が本編。 「管理ゼロにしましょう！」とは書いてない。「マネジメントの本質について考えましょう」と書いてある。マネジメントを突き詰めることで結果として管理ゼロでも大丈夫になるのです。では、そのために何をするのか？ これだけの盛りだくさんな実践できる取り組みを紹介している。どんなチームでも個人でも、できることがあるはず。この中から抜粋していくつかの章を要約して紹介します。 ここからは、第２部の自律性を高めるための取り組みについて、またいくつか抜粋して紹介します。 残りは以下のスライドにて。 ここまでは、書籍の一部を要約した内容になっていますので、ご購入の参考にしてください。
物理オフィスがない完全リモートワークまでの10年間の道のり | Social Change!
私たちソニックガーデンには、本社オフィスがない。全員がリモートワーク、在宅勤務なので、物理的に出社するためのオフィスをなくしてしまった。 今は、テレビ会議とバーチャルオフィスを組み合わせて普段は仕事をしている。 リモートワークに取り組む際に、私たちのやり方をそのまま真似をするとうまくいかないかもしれない。なぜなら、私たちも一気に今の状態になったわけではないので、私たちと同じように段階を踏んで進めていくのが良いのではないだろうか。 本記事では、私たちが物理オフィスのない完全リモートワークに至るまでに取り組んできた試行錯誤の変遷をふりかえってみよう。 ステップ0.昔ながらのオフィス（2008年頃） 私たちソニックガーデンは、もともとは大手企業の社内ベンチャーとして始まった会社だ。その当時は、それはもう本当に普通の働き方をしていた。 浜松町にある大きなビルが会社のオフィスで、私たちはその１０階に
心理的安全性の高いチームを作るための取り組み | Social Change!
社員一人ひとりが会社で本来の自分を曝け出すことができること、そして、それを受け入れるための「心理的安全性」、つまり他者への心遣いや共感、理解力を醸成することが、間接的にではあるが、チームの生産性を高めることにつながる。 これは現代ビジネスのウェブ版に掲載された以下の記事からの一節だ。 グーグルが突きとめた！社員の「生産性」を高める唯一の方法はこうだ グーグルが取り組んだ生産性向上計画についての記事で、それによると生産性の高いチームに共通するのは「他者への心遣いや同情、あるいは配慮や共感」がうまくいっていることだと言うのだ。 チームの中で、気兼ねなく安心して発言や行動できるような心理的な不安がない状態が、高い生産性を実現すると言われれば、確かにそう思う。そうした状態を心理学の専門用語から「心理的安全性（psychological safety）」と呼ぶらしい。 これまで言葉として認識していな
プログラミング経験がない経営者のためのソフトウェア開発 11の事実 | Social Change!
今やどんなビジネスでもITが関係している。ITを支えているのはソフトウェアだ。あらゆるものがソフトウェアで実現される時代になった。そんな事業や生活に密接に関わるソフトウェアだが、その開発について知られていないことも多い。 とくに経営者がプログラミング経験がないことで、ソフトウェア開発のリーダーシップをとるときに的外れなマネジメントをしてしまうことがある。あまねく経営者がプログラミング経験があれば良いのかもしれないが、それは現実的ではない。 プログラミング経験がなくても、せめてソフトウェア開発の特性について知っておくと良さそうなこともあると思い、なるべく専門用語を使わずに本稿を書いた。 プログラミングは製造ではなく、設計である いまだにソフトウェア開発を、ビルや家屋の建築に喩える人がいるし、工場でモノを製造するようにプログラムが作られると思っている人もいる。 ここが間違いのもとだ。ハードウェ
イマドキの会議の生産性を上げる３つの基本 〜 議事録を捨てて「議事メモ」をとろう | Social Change!
仕事を進める上で会議は避けて通れない。公式なものからフランクなものまで、誰かと仕事をする限りは会議をしないということはない。仕事の時間のうち、会議の占める割合も大きいのではないだろうか。 その会議をどれだけ生産的にするか、会議そのものの生産性をあげることは、仕事全体の生産性に大きく影響する。今まで通りの会議スタイルで、これからも生産性を気にせず会議を続けていくのは、非常に無駄であり、もったいない事だ。 イマドキのツールや環境を活かすことで、より高い生産性の会議に変えることができるはずだ。生産性の高い会議をするための工夫について書いた。会議の当たり前を変えていこう。 みんなの見えるところでメモを取ろう どんな打ち合わせであっても、何らかのメモを一緒に見ながら打ち合わせをすると良い。そのメモは、紙やホワイトボード、テキストエディタを画面で共有するのでも、なんでも構わない。会議に参加している全員
セルフマネジメントの必須スキル「タスクばらし」そのポイント | Social Change!
私たちソニックガーデンでは、指示命令のマネジメントを捨て、メンバーそれぞれが自分で考え自律的に行動することで、高い生産性を発揮しつつ様々な変化に対して柔軟に対応できる組織づくりに努めている。 そんなメンバーたちに求めるのはセルフマネジメントができることだ。セルフマネジメントができるために身に付ける素養は少なくない。しかし、セルフマネジメントを身につける最初の一歩は何かを聞かれたら「タスクばらし」だと答えるだろう。 本記事では、セルフマネジメントをマスターするための最初の必須のスキル「タスクばらし」について紹介する。 「タスクばらし」とは 「タスクばらし」とは、読んで字のごとく、仕事をタスクにバラすことである。仕事に取り掛かる前に、その仕事の要素を分解し、どのように進めるか道筋を立てることで、どれくらい時間がかかるか、リスクは何か、見通しを得ることができる。 当たり前のことだと思っていたが、
社員が増えたので物理的なオフィスをやめました 〜 これからは「分散型ワークプレイス」へ | Social Change!
私たちソニックガーデンでは、かねてより全社でリモートワークに取り組んできました。今では24名いる常勤メンバーの半数以上は地方に住む在宅勤務者です。採用応募の殆ども地方からであるため、今後もリモートワーカーは増えていくでしょう。 それでも、これまでは東京の渋谷にオフィスを構えていました。しかし、2016年6月末の契約更新の際に解約を行い、次の移転先は用意せず物理的な「オフィス」という概念を一旦やめて、複数のワークプレイスに分散させることにしました。 今回の物理オフィスをなくした取り組みは、TechWaveでも記事にして頂きました。ありがとうございます。それがこちらの記事。「本日でオフィスなくします」自律的リモートワーク先進企業の門出 【@maskin】 本記事では、その補足として、私たちがオフィスをなくした理由と狙い、そして、新しい分散型ワークプレイスのコンセプトと実践について書きました。
ソフトウェアエンジニアの目指す道 〜 ナレッジワーカーとしてのプログラマ | Social Change!
私たちソニックガーデンでは、「プログラマを一生の仕事にする」ということを一つのビジョンにしています。 このブログではよく書いていますが、私たちの考えるプログラマとは、ただコンピュータに文字を打ち込むだけの仕事ではなく、ソフトウェアそのものの企画から、関連するすべての設計、そしてコーディングと、動かすための運用までの、ソフトウェアエンジニアリングのすべてを行う仕事です。 それらは「何をするか」という観点からプログラマの仕事を表したものですが、より抽象的に考えると、プログラマの仕事は何か、そして何を目指すことで「一生の仕事にする」ことができるのか、この記事では考えてみました。 Employees hand rolling cigars in a cigar factory: Ybor City, Florida / State Library and Archives of Florida プ
ソフトウェア設計とは何か 〜 設計にはプログラミング経験が必要か否か | Social Change!
「プログラミング経験のない人がソフトウェアの設計をすること」の是非について、どう考えますか？ もしかしたら、このブログの読者であれば、プログラミングが出来ないのにソフトウェア設計をするなんてありえない！という意見の方が多いかもしれません。私もそういう意見ではあったのですが、色々な人と話をするにつけ、どこか違和感を感じていました。 その違和感の正体を探るべく、ソフトウェア設計とプログラミングについて考えてみました。そこでわかったことは「ソフトウェア設計」について、人それぞれに捉え方が違うために、話が通じないことがあることから産まれた違和感だったということです。 この記事では、私の考える「ソフトウェア設計とは何か」について書きました。 ソフトウェア開発はすべてが「設計」である モノづくりにおいて、大きく工程を２つに分けるとしたら「設計」と「製造」に分けることが出来ます。何をどう作るかを決めるこ
社内ベンチャーの経験から学んだ新規事業の失敗を防ぐための５つのポイント | Social Change!
企業が新規事業を創り出す為にはどうすれば良いでしょうか。それまでの延長上にない事業を創り出すためには、それまでの延長上でない形が必要なはずです。その一つの取り組みが「社内ベンチャー」でしょう。 社内ベンチャーとは、既に事業をもっている大企業の中で、新規事業創造を目的に独立した事業部隊として作られる組織のことです。法人登記をしていないため、法人格をもった会社ではありません。 「Soup Stock Tokyo」が、三菱商事の社内ベンチャーから始まったことをご存知の方も多いでしょう。以下の本に詳しく書かれており、私も読みましたが、とても興味深い内容でした。 私たちの会社ソニックガーデンも、元々は大企業の社内ベンチャーとしてスタートして、今は買い取って完全に独立した会社にさせてもらっています。社内ベンチャーをしていた期間は２年間でしたが、そこでは非常に沢山のことを学ばせてもらいました。 ただ、私
セルフマネジメントのレベルと欠かせないスキル 〜 自己組織化されたチームを作るためには | Social Change!
私はよく講演などで「弊社はマネジメントしない会社です」と言ってます。ソニックガーデンでは、指示や命令などすることなくて、スタッフは各々で状況判断しながら仕事に取り組み、働くことを監視されたりすることはありません。 マネジメントしない、というのは、あえて気を引く言葉を使っているだけで、本当は、各自が自分で自分のマネジメントができるから、なんです。つまり、全員がセルフマネジメント出来れば、マネジメントは不要になります。そうすると自己組織化されたチームが出来上がります。 とはいえ、セルフマネジメントにもいくつか段階があると最近感じるようになりました。最初から高いレベルのセルフマネジメントができる人は稀です。順番に身につけていくような気がしています。この記事では、そんなセルフマネジメントのレベルについて考えてみました。 Jogging on a bright November morning /
チケット駆動開発で Pivotal Tracker を上手に使うための4つのポイント | Social Change!
ソフトウェア開発のタスクはどのように管理するのが効率的なのか。ソフトウェアという目に見えないものを作るためにはタスクの見える化は進捗状況を図る重要な指標になります。ソフトウェア開発で発生するタスクを、バグ管理システム（BTS）や課題管理システム（ITS）を活用することで、タスクの状態とワークフローを管理しようというのがチケット駆動開発です。 チケット駆動開発については、以前に記事を書いたので、そちらを参考にしてください。 チケット駆動開発のススメ〜No ticket! No commit チケット駆動開発をうまく実践するためにはツールが不可欠です。不具合管理や障害管理で使うツールを応用して活用することも出来ますが、最近は専用のツールも出て来ています。ソニックガーデンでは、Pivotal Trackerというツールを使っています。Pivotal Trackerでは「ストーリー」と表記していま
プログラミング初心者のうちに身につけたい３つの習慣 | Social Change!
プログラミング技術さえ身に付けば、プログラマとして一人前と言えるでしょうか？ プログラミングを始めたばかりのうちは、プログラミング言語の習得や周辺の知識を得ることばかりに目がいきがちですが、それだけでは一流のプログラマになれません。（プログラミング言語を学びたいならこちら：写経で身につけるプログラミングの基本） プログラマとして成長するためには、プログラミング技術を学ぶだけではなく、良いソフトウェアを作るための良い習慣を身に付けることが大事になります。初心者のうちに良い習慣を身につけておけば、ただ知識を追い求めるのではなく地に足をつけた成長ができるはずです。 本記事では、私自身も先人たちから学んだプログラマが身につけたい３つの習慣について書いています。 自分で書いたすべてのコードを説明できるようになろう プログラミングは全て、明確な判断の結果です。if文を使うべきかどうか、どのAPIを使う
高速で無駄のないソフトウェア開発を実現するための7つのポイント | Social Change!
どうすれば小規模なチームでも大きな成果を出せるのか。大きな組織で沢山の量をこなすのは当たり前のことで、あまりクールではありません。少ない人数でも大きな成果を出すには、スピードをあげることと、そのためにも無駄をなくすことがポイントになってきます。 ソフトウェアをつくるための３つの役割で書いた通り、ソフトウェア開発をクラウドのようなサービス提供で続けていくには、プロダクトオーナーとプログラマーがキャッチボールのような形で、仕様と実装をずっと繰り返しながら作っていくのが自然です。 SonicGardenで使っているツールと開発の流れの全体は以下のようになります。大事なことは「動くソフトウェア」の状態を保ったまま、どれだけ回転数をあげていけるか、ということです。そのために、プロダクトオーナーとプログラマの間で待ち時間を減らすために並行して進めるようにするなど工夫しています。 ホワイトボードとMVP
リーンスタートアップで小さく始めよう | Social Change!
リーンスタートアップ”Lean Startup”という言葉を最近知りました。SonicGardenでは、アジャイル・Ruby・クラウドを実践してきましたが、開発だけをしている訳ではなくて、スタッフ一丸となってマーケティングも経営もしていたりして、それらを包括した言葉ってないのかな、と思っていたのですが、どうも「リーンスタートアップ」がうまくフィットしていると気付きました。 とはいえ、リーンスタートアップを学んだ上で実践している訳ではなくて、日々の試行錯誤の中で得たスタイルが、たまたまリーンスタートアップになっているということだけなので、正解かどうかはわからないので、自分たちなりのリーンスタートアップを考えてみました。（この正解かどうかわからないけど実践しているという感覚はアジャイルという言葉に対する感覚に似ていますね。） リーンスタートアップを理解するのにわかりやすいスライドは以下にありま
ソフトウェアビジネスの新分類 | Social Change!
4/15に開催されたAgileJapanに実行委員として参加してきました。AgileJapanは3年目になりますが、もはや毎年の定番のイベントになっているように思います。 私は今回は、事例セッションの一つでコーディネータをしました。セールスフォースジャパンでCTOをされている及川さんに登壇頂き、”Inside Salesforce”ということで、どういったやり方でクラウドのソフトウェアを開発されているのかを紹介して頂きました。セールスフォース自身は、あまりテクノロジ企業であることを前面には出していないイメージですが、実際は、開発はすべて社員による内製をおこなっているそうで、実はエンジニアの多い会社なのかもしれません。 今回は、及川さんにはクラウドのソフトウェアを開発している方法がいかにアジャイルであるかを中心に説明してもらいました。ADMというスクラムをベースにした開発手法を採用していると
Herokuでgemのインストール | Social Change!
RubyホスティングのHeroku（http://heroku.com/）で、小さい自分用アプリを運用してます。 Herokuについては、こちら（Ruby版PaaSの”Heroku”で無料Railsホスティング環境を手に入れよう）に詳しく書いてます githubでソース管理して、herokuで運用する、というスタイルです。 開発してると、gemを使ってライブラリをインストールしたい場合が出てきます。ローカル環境だと問題なくインストールすれば良いんですが、herokuではどうすれば良いんでしょう・・・と思ったら、ちゃんと用意されてました。 やり方は簡単で、”.gems”というファイルを用意して、必要なgemを中に書いて、herokuにgitでデプロイメントするだけで、インストールしてくれます。 １．動かしてるRailsプロジェクトの直下に、”.gems”ファイルを作る 2.必要なgemを中に
アジャイル開発のボトルネック | Social Change!
「お金なら出しますから、４ヶ月のところを２ヶ月で作ってくれませんか？」 システム開発で、顧客からこう言われた時、どうするか？ SIerの経営者や管理職であれば、飛びついてしまうんじゃないだろうか。私だって飛びつきたい。確かにエンジニアがいるなら、もしくは、集める目処が立つなら、ありがたい話かもしれない。XPでも、「リソース・スコープ・品質・時間」のパラメータで、品質以外は変動可能としている。 ということは、リソースがなんとかなれば、時間を短くする、もしくは、時間を変えずにスコープを増やすことができるのだろうか。人月という単位で考えれば、計算上は出来るかもしれないが、実際には難しいと言わざるを得ない。それはなぜか。ボトルネックは、プログラムを作る速度か、それとも、仕様を決めて受け入れる速度か。 冒頭の台詞は、開発側にこそボトルネックがあり、コストさえかければスピードアップできると考えているか
Ruby版PaaSの”Heroku”で無料Railsホスティング環境を手に入れよう | Social Change!
Railsでアプリを作ったら公開したくなるのが人情ですよね。 だけど、安いホスティングサーバとかだと、使える環境が限られていたり、セットアップが面倒だったり・・・必死こいてセットアップしても、本気で運用するとなると、そんな環境だと不安だらけだし・・・かといって、AmazonEC2で運用するだけの気合いもない。GAE/Jを使って、JRubyってのもな〜・・・ 私もそんな感じでしたが、そんな折に、mat_akiに、Heroku（ハーオークーと読むらしい）を教えてもらいました。 実は、Herokuって、ずいぶん昔に話題になって、知っていたんですが、その時は、「WebブラウザでRailsアプリが開発できる〜」みたいな感じだったんですよね。それだとEmacsで良いよ。と思ってスルーしていたんですが・・・どうやら、サービスの定義？内容？が変ったようです。 今までのWebブラウザRails開発環境は、”
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
