私たちソニックガーデンの「納品のない受託開発」に取り組むソフトウェア開発のスタイルは、一般的に「アジャイル開発」と呼ばれるものに近いです。 しかし実際のところ、私たちは「アジャイル開発」をしようなんてかけ声をかけたこともないですし、普段から社内で「アジャイル開発」が話題になることもありません。「アジャイル開発」をしようと思ってしている訳ではないにも関わらず、「アジャイル開発」をやっているように見えるというのです。 この記事では、「アジャイル開発」について私たちが考えていること、そして、なぜ多くのアジャイル開発は失敗してしまうのか、うまくいくためにどうすればいいのか考えてみました。 2012-12-28 / Giåm 結果としてのアジャイル開発〜究極のアジャイル 「あなたにとってのアジャイルとは何ですか？」 先日、ある勉強会で質問されました。ちょっと想定外の質問だったので、しばし考えたあと私

私たちソニックガーデンでは、「プログラマを一生の仕事にする」ということを一つのビジョンにしています。 このブログではよく書いていますが、私たちの考えるプログラマとは、ただコンピュータに文字を打ち込むだけの仕事ではなく、ソフトウェアそのものの企画から、関連するすべての設計、そしてコーディングと、動かすための運用までの、ソフトウェアエンジニアリングのすべてを行う仕事です。 それらは「何をするか」という観点からプログラマの仕事を表したものですが、より抽象的に考えると、プログラマの仕事は何か、そして何を目指すことで「一生の仕事にする」ことができるのか、この記事では考えてみました。 Employees hand rolling cigars in a cigar factory: Ybor City, Florida / State Library and Archives of Florida プ

「アジャイル開発を、お客さまに導入してもらうにはどうすればいいですか？」 そんな相談を受けることがあります。私はどんな優れた提案も相手にニーズがなければ通らないことを知っています。喉が渇いていない人に水を売ろうとしても売れないのです。そもそも提案する前に、まずはニーズに気付いてもらう必要があります。そして、そのお客さまは、本当にアジャイル開発に対するニーズがあるのでしょうか。 私の考えるアジャイル開発の本質は「アジャイル開発では当初に想定した機能を”全部”つくらない」ことだと考えています。（参考記事：アジャイル開発の本質 〜 アジャイルとウォーターフォールの違いとは） この「全てを作らないことで、変化に対して柔軟に開発していく」というソリューションを求めるニーズがあるのであれば、アジャイル開発のメリットを伝えれば採用されることでしょうし、そういうニーズがなければ、何を言っても受け入れられま

先日、私たちソニックガーデンはオフィスを移転しました。移転するにあたり、新しいオフィスの内装やレイアウトを検討したんですが、そのことは改めてオフィスとチームの生産性の関係について、じっくりと考える良い機会となりました。 この記事では、チーム活動における生産性とオフィスのレイアウトについて考えてみたことを書いています。 在宅勤務かオフィス勤務か ソニックガーデンでは、在宅勤務を許可していて、実際に社員の１名は地元の兵庫県の自宅でずっと在宅勤務をしています。また、ある社員は海外に行きたいということで、１年間の海外生活をしながらリモートで、通常の仕事をこなしていました。以下の記事で、その様子がわかります。 リモート勤務と娘の子育て – give IT a try 『国境なきプログラマ』を目指す～ノマドワークの究極のかたち 離れた場所で働くチームのつくり方〜１年間のアイルランドでの実践で学んだこと

「アジャイル」という言葉が一人歩きしてしまっていて、たまに話をしていても通じないときがあります。 それくらいアジャイルという言葉が広く知られるようになったんだと思う一方で、かえって話が通じなくて、もどかしく感じることもあります。だからといって、そこで「正しいアジャイルとは」みたいな議論をしたい訳でもないのです。 広まれば広まるほど、そういった言葉の認識の齟齬が出るのは仕方ないですね。その正しい定義みたいなところを追求するのもナンセンスなので、そんなつもりはないですが、ただ自分がどう考えているかについては書いておいても良いかな、と考えました。ここは私のブログですしね。 そこで、この記事では、私の考えるアジャイル開発の本質について、そしてウォーターフォールとの違いについて書きました。 アジャイル開発では機能を全部つくらない これまで私の中で、アジャイルと言えば当たり前の前提がありました。それは

昔は技術的に出来なかった為に運用でカバーしてきた慣習が残り続けているけれども、実は今の技術で考え直すともっと無駄なく簡単に出来ることって、多くの業界で起きているように思います。 もちろん、ソフトウェアの受託開発の世界でも起きています。ソフトウェア開発を生業とする私たちの会社で考えたのは、昔ながらの商習慣によって様々な問題を引き起こしているのは「納品」ではないか、ということでした。 この記事ではソフトウェアにおける「納品」のもたらす問題と、私たちの会社で解決している方法「納品のない受託開発」について書きました。（自社のウェブサイト用に書いた原稿をブログにしただけなので、それっぽい表現になってます。） 「納品」が引き起こしている問題 私たちソニックガーデンの受託開発では、一括委託を行っていません。ソフトウェア開発における「一括請負での受託開発」のビジネスモデルは、多くの問題を生み出してきたから

私はよく講演などで「弊社はマネジメントしない会社です」と言ってます。ソニックガーデンでは、指示や命令などすることなくて、スタッフは各々で状況判断しながら仕事に取り組み、働くことを監視されたりすることはありません。 マネジメントしない、というのは、あえて気を引く言葉を使っているだけで、本当は、各自が自分で自分のマネジメントができるから、なんです。つまり、全員がセルフマネジメント出来れば、マネジメントは不要になります。そうすると自己組織化されたチームが出来上がります。 とはいえ、セルフマネジメントにもいくつか段階があると最近感じるようになりました。最初から高いレベルのセルフマネジメントができる人は稀です。順番に身につけていくような気がしています。この記事では、そんなセルフマネジメントのレベルについて考えてみました。 Jogging on a bright November morning /

企業が新規事業を創り出す為にはどうすれば良いでしょうか。それまでの延長上にない事業を創り出すためには、それまでの延長上でない形が必要なはずです。その一つの取り組みが「社内ベンチャー」でしょう。 社内ベンチャーとは、既に事業をもっている大企業の中で、新規事業創造を目的に独立した事業部隊として作られる組織のことです。法人登記をしていないため、法人格をもった会社ではありません。 「Soup Stock Tokyo」が、三菱商事の社内ベンチャーから始まったことをご存知の方も多いでしょう。以下の本に詳しく書かれており、私も読みましたが、とても興味深い内容でした。 私たちの会社ソニックガーデンも、元々は大企業の社内ベンチャーとしてスタートして、今は買い取って完全に独立した会社にさせてもらっています。社内ベンチャーをしていた期間は２年間でしたが、そこでは非常に沢山のことを学ばせてもらいました。 ただ、私

Students and Teacher in a Classroom at Cathedral High School in New Ulm, Minnesota… / The U.S. National Archives 多くの会社で新社会人を迎え入れる季節になりました。若い人たちをどう育てるのか、企業にとってとても重要なテーマです。私たちソニックガーデンでも、毎年なんとか新卒社員を採用し、師匠のもとで弟子という形で教育しています。 私の考える教育方針の哲学はシンプルで「子供扱いしないこと」「育てるのではなく育つ」「守るのではなく見守る」というものです。 これは、私が様々な先輩や上司の元で働かせて頂いた中で感じたことを思い出して考えたものです。これから若手を育てなければいけない立場になった先輩や上司の人たちにとって参考になればと思い、それを記事にしてみました。 子供扱いしないこと 人は

現場のオペレーションを改善するために、最初に着手するなら何か？と聞かれたら、いつも「ふりかえり」から始めましょう、と答えています。かつてトラブルの起きているプロジェクトに入ったときも、まず始めたのは「ふりかえり」からでした。 「ふりかえり」とは、文字通り現場の活動を振り返って、改善のアクションを考えることです。反省会のようにも思えますが、すべてが終わってから反省する訳ではなく、現状分析を行って、うまく続けていくための未来を向いた活動です。 この記事では「ふりかえり」という習慣について、そして、ふりかえりを実践するにあたって、進め方とポイントについて紹介します。 ふりかえりの進め方”KPT”とは 上の写真は、私たちソニックガーデンで「ふりかえり」をしている様子です。ソニックガーデンでは弟子を採用していて、その弟子と師匠とのふりかえり風景です。このように、特別な道具はなにも必要ありません。必要

AppleやGoogleが強いのは何故か。新興のベンチャー企業が既存企業を押しのけて成長できるのは何故か。商品やサービスの魅力が高いというのも理由かもしれませんが、本当の強みは、彼らの持つビジネスモデルです。 他社には無い新しいビジネスモデルを持つことで、製品の品質や優位性だけで競争する必要はなくなり、永続的な競争優位性を保つことができます。多くの企業で今、求められているのは、そうしたビジネスモデルのイノベーションです。 私たちも、ソニックガーデンという会社を作って「納品のない受託開発」というソフトウェア受託の世界で新しいビジネスモデルを構築したことで、今までやってこれたこともあり、新しいビジネスモデルの重要性はとても理解できます。 今回、私が読んだ「なぜ、あの会社は儲かるのか？　ビジネスモデル編」という本では、どうすれば日本企業で新しいビジネスモデルを構築することが出来るのか、ということ

一生懸命に仕事をする、というのはどういうことでしょうか。決められた作業リストがあって、それを全部こなすこと、時間をかけてでもやりきること、そういったことも一生懸命に仕事をすると言えるでしょう。しかし、それだけでは価値のある仕事に繋がらないことも多く、努力が無駄になることもあります。 一方で、どこにでも要領のいい人はいます。要領がいい人は、仕事も早く終わらせることができて、しかも評価される仕事をしています。短い時間で成果を出せる方が、沢山の価値を産むことは違いありません。では、そうした人たちは産まれ持った能力が高いのでしょうか。それもあるけど、それだけではないでしょう。 そもそも、要領がいいことと、努力することは排他的ではありません。要領がいい・要領が悪いという軸があるなら、努力する・努力しないという軸もある筈です。それは４象限で考えることが出来ます。 要領が悪く、努力もしない人はどうしよう

先日3月21日に、スクー（ http://schoo.jp/ ）という、ウェブ上で様々な授業が受けられるサービスにて、ひとつ講義を受け持って授業をしてきました。 「どうすれば小さなチームでも大きな成果を出せるのか 〜 少人数のチーム、低コストで開発を続けていくためのプロセスを学ぶ」というテーマで授業をしてきました。 オンラインで生放送の授業をするという初めての経験で緊張しましたが、質疑応答で沢山質問も頂けたので、とても良かったです。オンラインの方が、質疑応答で質問が出やすいような気がしますね。 この記事では、その授業での内容や、スライドと質疑応答について書きました。 授業内容の紹介 大きな組織で沢山の量をこなすのは当たり前のことで、あまりクールではありません。少ない人数でも大きな成果を出すには、スピードをあげることと、そのためにも無駄をなくすことがポイントになってきます。 ウェブサービスを

「プログラミング経験のない人がソフトウェアの設計をすること」の是非について、どう考えますか？ もしかしたら、このブログの読者であれば、プログラミングが出来ないのにソフトウェア設計をするなんてありえない！という意見の方が多いかもしれません。私もそういう意見ではあったのですが、色々な人と話をするにつけ、どこか違和感を感じていました。 その違和感の正体を探るべく、ソフトウェア設計とプログラミングについて考えてみました。そこでわかったことは「ソフトウェア設計」について、人それぞれに捉え方が違うために、話が通じないことがあることから産まれた違和感だったということです。 この記事では、私の考える「ソフトウェア設計とは何か」について書きました。 ソフトウェア開発はすべてが「設計」である モノづくりにおいて、大きく工程を２つに分けるとしたら「設計」と「製造」に分けることが出来ます。何をどう作るかを決めるこ

もし転職するとしたら、選ぼうとするその会社のどこをみるでしょうか？ 私が採用応募の相談を受けるとき、その人にとっては転職になる訳ですが、入ろうとする私たちの会社が本人のワークスタイルやライフスタイルと一致しなければ、お互いに不幸なことになりかねません。 採用というのは、会社側が入りたい方を選ぶのと同時に、入ろうとする人にとっても会社を選ぶという意識が大事です。私は、私の会社を含めて、その人が自分にあった会社かどうかを判断してもらう時に、３つの視点があると話しています。 ひとつは、キャリアに影響してくる会社のビジネスモデル。二つ目は、ワークスタイルに影響してくる会社の人数。最後は、ライフスタイルに影響してくる会社の方向性。 これらの視点を話した結果として、もし自分にとって違うということがわかれば、私たちの会社に入ってもらえなくなりますが、それでも良いと思っています。入ってしまって後悔するより

既存事業を抱える企業にとって、新しい事業の創造というのは、永遠に抱えるテーマです。そのため、新規事業を成功させたいと思う企業はたくさんあるけれど、なかなかうまくいかないのが現実です。 この辺りの問題について、ブレークスルーパートナーズの赤羽さんの書かれた記事もとても参考になります。 中堅･大企業の改革と新事業立ち上げへのヒント ー 日本企業の組織的課題を打破 私たちの会社ソニックガーデンは、もともとは大手企業の社内ベンチャーで始まりました（今はMBOして独立してます）。当時は企業内起業といったところでしょうか。今風にいえば企業内リーンスタートアップだったかもしれません。なんにせよ既存事業をもつ会社の中で新規事業に取り組んだんですが、たしかに簡単なことではありませんでした。 今回の記事では、私なりに自分の経験から企業での新規事業を起こすことが難しい原因と、その対策を考えました。 なぜ新規事業

エンジニアにとってコミュニケーション能力は必要でしょうか。この話題については、賛否両論あるでしょうし、そもそもコミュニケーション能力とは何かを考えなければいけないでしょう。 私たちの会社ソニックガーデンでは、プログラマの仕事を「ソフトウェアのエンジニアリングすべてに責任を持つ仕事」と定義しています。具体的には、お客さまと対話して要件を引き出すことから、データ構造から画面までの設計を行ったものをソースコードで表現し、クラウドでの運用まで面倒をみるという、ソフトウェアを作って動かす全てを行います。 そう話すと、よく聞かれる質問があって「コミュニケーションが苦手なエンジニアはどうすれば良いでしょうか？」というものです。もし本当に誰とも話をしたくないし出来ないというのであれば、残念ながら、と言うしかありません。しかし、コミュニケーションと一括りにしてしまっていて誤解があるのかもしれません。 そこで

「マーケティング」というと難しく聞こえるかもしれません。よくあるCMや広告もマーケティングのひとつです。なので、大手企業だけがするものだと思ってしまっている人たちもいるかもしれません。しかし、実はそんなことはありません。 小さな会社であってもマーケティングは出来ます。むしろ、小さくてもしっかりとマーケティングをしている会社は、ブランド力をもち、ファンがいて、利益を上げることが出来るのです。たとえば、”Ruby on Rails”を作ったDHHのいる37signalsという小さな会社は、世界でもっとも有名な成功事例でしょう。 私たちソニックガーデンも小さなソフトウェア企業です。それなりにメディアにも取り上げて頂くこともあるので、印象としてはもっと大きな会社だと思われるときもありますが、実際には現時点で私を入れて7人の小さな会社です。小さな会社ですが、今のところ、ありがたいことにソニックガーデ

ソフトウェア開発の世界には、様々な法則があります。 遅れたプロジェクトに人数を追加しても、さらに遅らせることになるという「ブルックスの法則」は有名ですね。他にも、ソフトウェアの構造は、それを作った組織の構造が反映させるという「コンウェイの法則」などなど。（参考） 最近、ソフトウェア開発を通じて感じていることは、ソフトウェアの仕様を決める人の数は、ソフトウェアをプログラミングする人の数と同じだけ必要なのではないか、ということです。 そこで、この記事ではこれを「人数等価の法則」として考えてみることにしました。 balance / hans s これまで考えられてきた開発にかかる人数の感覚 ソフトウェア開発には、何を作るかを考えるという段階があって、どう作るかを考えてプログラミングするという段階があります。それを２人以上の人間で役割分担するとしたら、その間に入るものが「仕様」となります。 「仕様

資金も人も少ないスタートアップが大手企業に勝つためには、大手と同じことをしていては勝つことができません。大手にできないことをしてこそスタートアップは生き残ることが出来るはずです。もし仮に投資を受けて大手のような振る舞いをしたところで、そもそも基礎的な体力は違う訳で息切れしてしまうことは目に見えています。 大手企業とスタートアップの大きな違いは、大手企業は資金や人を沢山もちすぎているということです。それは正面から戦ったら強みになるでしょうが、新規事業においては弱点にもなりえるのです。 沢山の人や資金を動かすとしたら、必ず無駄が産まれます。長過ぎる会議や総花的な意見まとめなど大企業のオペレーションには多くの無駄があります。小さくて小回りの利くスタートアップが同じように振る舞う必要はありません。 ITを活用するスタートアップにおいて、ソフトウェアを作るという文脈の中でも、大手企業とは違う戦略を採