タグ

ブックマーク / kuranuki.sonicgarden.jp (14)

  • 「組織的負債」を貯めないための、プログラマの哲学によるチームのマネジメント術 | Social Change!

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

    「組織的負債」を貯めないための、プログラマの哲学によるチームのマネジメント術 | Social Change!
  • 自律的に現場を改善できるチームをつくるための「ふりかえり」の進め方 〜 KPTと進め方のノウハウ | Social Change!

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

    自律的に現場を改善できるチームをつくるための「ふりかえり」の進め方 〜 KPTと進め方のノウハウ | Social Change!
  • 社内ベンチャーの経験から学んだ新規事業の失敗を防ぐための5つのポイント | Social Change!

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

    社内ベンチャーの経験から学んだ新規事業の失敗を防ぐための5つのポイント | Social Change!
  • セルフマネジメントのレベルと欠かせないスキル 〜 自己組織化されたチームを作るためには | Social Change!

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

    セルフマネジメントのレベルと欠かせないスキル 〜 自己組織化されたチームを作るためには | Social Change!
  • どうすれば小さなチームでも大きな成果を出せるのか 〜 少人数のチーム、低コストで開発を続けていくためのプロセスを学ぶ | Social Change!

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

    どうすれば小さなチームでも大きな成果を出せるのか 〜 少人数のチーム、低コストで開発を続けていくためのプロセスを学ぶ | Social Change!
  • 小さなソフトウェア企業でも出来るマーケティング・コミュニケーションのやりかた | Social Change!

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

    小さなソフトウェア企業でも出来るマーケティング・コミュニケーションのやりかた | Social Change!
  • 書籍『チケット駆動開発』が出版されました | Social Change!

    書は、チケット駆動開発(TiDD)についての小川さんと阪井さんによる書籍『Redmineによるタスクマネジメント実践技法』に続く、第2弾となる書籍です。出版おめでとうございます。 の出版にあたって、チェンジビジョンの平鍋さんとともに、私も「まえがき」を書かせてもらいました。こちらの記事でも掲載しておきます。 チケット駆動開発 『チケット駆動開発』まえがき チケット駆動開発を実践するようになると、それ以前の開発がどうしていたのか思い出すのも困難になってしまいます。それほどチケット駆動開発は、ソフトウェア開発の現場にフィットするし、プロジェクトの進め方のスタンダードを変えてしまうものなのでしょう。 私が代表を務める会社ソニックガーデンはソフトウェア開発の会社ということもあり、現場のすべての開発をチケット駆動開発で行っています。開発の作業をする際には、必ずチケットにしてから取りかかるルールが

    書籍『チケット駆動開発』が出版されました | Social Change!
    d4-1977
    d4-1977 2012/08/27
    チケット駆動開発
  • 離れた場所で働くチームのつくり方〜1年間のアイルランドでの実践で学んだこと | Social Change!

    『国境なきプログラマ』を目指す~ノマドワークの究極のかたち ちょうど1年ほど前に、こんなブログを書きました。ソニックガーデンのプログラマが単身、アイルランドのダブリンに1年間滞在しつつ、日仕事をしながらも、現地で生活をおくるという内容です。 こちらの記事で紹介した、ダブリン生活にチャレンジしてきたプログラマの maedana がつい先日、無事に日に帰ってきました。 日との時差9時間の中で、1年間1度も日に帰ることなく、リモートで働いてもらったのですが、結果としては、大きな問題はなく、概ねうまくいったと言ってもいいでしょう。 この記事では、そのアイルランドのプログラマと日のプログラマやお客様と、どうやって離れた場所だけど、ひとつのチームとして一緒に働くことができたのか、ふりかえってみたいと思います。 1年間のリモートワークの前提や環境について 彼がアイルランドに行く前に想定してい

    離れた場所で働くチームのつくり方〜1年間のアイルランドでの実践で学んだこと | Social Change!
    d4-1977
    d4-1977 2012/08/17
    チームの作り方
  • 作る人と決める人は同じ数だけ必要な時代になった〜ソフトウェア開発における「人数等価の法則」 | Social Change!

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

    作る人と決める人は同じ数だけ必要な時代になった〜ソフトウェア開発における「人数等価の法則」 | Social Change!
  • チケット駆動開発で Pivotal Tracker を上手に使うための4つのポイント | Social Change!

    ソフトウェア開発のタスクはどのように管理するのが効率的なのか。ソフトウェアという目に見えないものを作るためにはタスクの見える化は進捗状況を図る重要な指標になります。ソフトウェア開発で発生するタスクを、バグ管理システム(BTS)や課題管理システム(ITS)を活用することで、タスクの状態とワークフローを管理しようというのがチケット駆動開発です。 チケット駆動開発については、以前に記事を書いたので、そちらを参考にしてください。 チケット駆動開発のススメ〜No ticket! No commit チケット駆動開発をうまく実践するためにはツールが不可欠です。不具合管理や障害管理で使うツールを応用して活用することも出来ますが、最近は専用のツールも出て来ています。ソニックガーデンでは、Pivotal Trackerというツールを使っています。Pivotal Trackerでは「ストーリー」と表記していま

    チケット駆動開発で Pivotal Tracker を上手に使うための4つのポイント | Social Change!
  • 読書メモ:リーンスタートアップ ムダのない起業プロセスでイノベーションを生みだす | Social Change!

    テレビ東京のワールドビジネスサテライトで取り上げられるなど、このところ話題になることの多い「リーンスタートアップ」について、提唱者であるエリック・リース自身によって書かれたの翻訳版が出版されました。 リーンスタートアップとは、起業家であるエリック・リースの失敗と成功の経験をもとに、製造業におけるリーン生産方式の概念を応用して説明した、これまでにない新しい「スタートアップの手法」のことです。 リーンスタートアップそのものについては、以前に私もブログで紹介しましたので、そちらも参照ください。 リーンスタートアップとは 世の中のスタートアップの殆どが失敗しているけれど、実は成功の確率を高めるにはやり方があって、そのやり方としてまとめたものが「リーンスタートアップ」だと書では言っています。 そのやり方は、必要最小限の機能だけでリリースをすることや、サイクルタイムを極端に短くしていくこと、ユーザ

    読書メモ:リーンスタートアップ ムダのない起業プロセスでイノベーションを生みだす | Social Change!
    d4-1977
    d4-1977 2012/06/28
    リーンスタートアップ
  • ユーザエクスペリエンス設計は誰のものか〜ユーザエクスペリエンスのためのストーリーテリング | Social Change!

    先日「ユーザエクスペリエンスのためのストーリーテリング」というを献頂きました。ありがとうございます。書はユーザエクスペリエンスとストーリーテリングについて学ぶことのできるです。前半は、ユーザエクスペリエンスそのものについての重要性の理解から、表現としてのストーリーテリングの必要性について説明し、そして、書の後半では具体的なテクニックも交えて手法について解説しています。 具体的なテクニックや内容は書を読んで頂くのが良いと思いますので、以降では私が書を読んで感じたことや、考えたことを記しておきます。書評というよりコラムになってしまいました。 ユーザエクスペリエンスの難しさ そもそもユーザエクスペリエンスとはなにか。ソフトウェア開発で言えば、ディスプレイに表示される画面のインターフェースのことではありません。それは単なるユーザインタフェースに過ぎないのです。ユーザエクスペリエンスと

    ユーザエクスペリエンス設計は誰のものか〜ユーザエクスペリエンスのためのストーリーテリング | Social Change!
    d4-1977
    d4-1977 2012/06/28
    「ユーザエクスペリエンスのためのストーリーテリング」
  • 書評:小さなチーム、大きな仕事ー37シグナルズ成功の法則 | Social Change!

    書は、シカゴを拠点におき、全世界向けにプロジェクト管理ツールなどのオンラインツールを提供する企業である「37signals」の成功までに至った独自の経営哲学を書いたです。37signalsは、プログラマだったら誰でも知ってる「Ruby on Rails」の作者であるDHHが所属することでも有名です。 書は以前に発行された同名の書籍の完全版ということで、イラストなどが入っていますが、内容は基的に同じです。私自身、以前に発行されたを持っており、既に読んではいたのですが、改めて読み直すきっかけにも良いと思い、今回の完全版を購入しました。数年たって改めて読んで感じたことは、時代が彼らの働きかたに少し追いついてきたように思いました。 37signalsは、私たちSonicGardenにとってベンチマークにしている会社のひとつです。だからこそ、書「小さなチーム、大きな仕事」と、Webでも公

    書評:小さなチーム、大きな仕事ー37シグナルズ成功の法則 | Social Change!
    d4-1977
    d4-1977 2012/06/28
    小さなチーム、大きな仕事
  • 「アジャイル開発」で解決できることは何か〜アジャイルは「速い・安い」のファストフードではない | Social Change!

    ここ最近の「アジャイル」という言葉の使われ方に違和感を感じています。 年々システム開発のプロジェクトは、短納期化と低コスト化の流れが進んでおり、それによってリスクが増して且つ利益の出にくい状況になりつつあり、多くのシステム開発を請け負うシステムインテグレータは様々な取り組みを進めています。 そして、その一つとして期待されているのが「速い・安い」を実現する「アジャイル開発」だと言うわけです。もはや、まるでファストフードです。 大手システムインテグレータが集まってアジャイル検定を始めるようです。一部引用します。 アジャイル検定の格運用に向けた、アジャイルソフトウエア開発技術者検定試験準備委員会を設立 近年、ソフトウエア開発では、厳しい経済不況などの影響を受け、ユーザーの要件を確実に、高品質に、より短期間で提供することが求められています。このような環境の下で、注目されているのがアジャイル開発手

    「アジャイル開発」で解決できることは何か〜アジャイルは「速い・安い」のファストフードではない | Social Change!
  • 1