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

こちらの記事を読みました。 逃げろ、そして生き延びろ – インターネットの備忘録 http://d.hatena.ne.jp/hase0831/20121002 頓智ドットを退職した｜@suniのブログ「ニートですが？」 http://sunikang.blogspot.jp/2012/10/blog-post.html 読んでるだけで自分も苦しくなるような内容でした。 たしかにベンチャー企業の経営者は、ハードワークであることを奨励する人が多い気がします。世界を変えるとか、上場を目指すとか、短期間で何かを成し遂げようとするならば、残業も厭わずに働き続けないといけない、という訳です。そうなのかもしれません。 しかし、私はそんな考えかたが好きではないです。一生懸命に働くことは大事ですし、頑張ることは大前提だと思いますが、長時間働くことを求めるのは違うのではないかと考えています。そもそも自分がそ

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

どうすれば小規模なチームでも大きな成果を出せるのか。大きな組織で沢山の量をこなすのは当たり前のことで、あまりクールではありません。少ない人数でも大きな成果を出すには、スピードをあげることと、そのためにも無駄をなくすことがポイントになってきます。 ソフトウェアをつくるための３つの役割で書いた通り、ソフトウェア開発をクラウドのようなサービス提供で続けていくには、プロダクトオーナーとプログラマーがキャッチボールのような形で、仕様と実装をずっと繰り返しながら作っていくのが自然です。 SonicGardenで使っているツールと開発の流れの全体は以下のようになります。大事なことは「動くソフトウェア」の状態を保ったまま、どれだけ回転数をあげていけるか、ということです。そのために、プロダクトオーナーとプログラマの間で待ち時間を減らすために並行して進めるようにするなど工夫しています。 ホワイトボードとMVP

定期的にSI業界が終わったという話が出ますが、本当にそうでしょうか。終わるべきは一括発注・請負のディフェンシブなビジネスモデルです。受託はなくなることはありません。ソフトウェアの開発を、他の業界のアナロジーで考えるのではなく、正面から取り組んだビジネスモデルについて語っています。 ディフェンシブな開発 今から5年前に、SI業界における多くの問題の原因がそのビジネスモデルにあるという「ディフェンシブな開発〜SIビジネスの致命的欠陥」という記事を書きました。SIにおけるビジネスモデルは、発注者とベンダーはあらかじめ決めた金額と要件の中で納品と検収を目指すため、利益を出すためには双方がリスクを取らずに「守り」に入る必要があります。その結果、顧客にとって価値を産むかどうかよりも決められた要件通りに作られることを重視することになってしまいます。人月という単位であらかじめ決めるとなれば、単価の安い下請

スクラム（Scrum）は、アジャイル開発における方法論の一つで、今もっとも注目されている方法論と言われています。（アジャイル開発とは何か？についてはこちらを。） SonicGardenでは、お客様とプログラマでどうすれば良い製品作りが出来るかをずっと追求してきました。その結果、顧客の製品責任者と、開発運用の全てを担当するプログラマを直接対話できるようにし、その関係のファシリテートだけをマネージャがするようになりました。それを、スクラムを知る友人に話したところ、まさしくスクラムだと聞きました。私自身は、スクラムを体系的に学習したことはないですが、アジャイル開発を追求した結果、スクラムに辿り着くことができたようです。 そのスクラムに関する大きなイベント、スクラムギャザリング東京2011が10月に開催されます。 「塹壕よりScrumとXP」の著者であるHenrik Kniberg氏と、アジャイル

アジャイル開発を開発者以外にも２ページ程度のサマリで説明するというのに挑戦してみました。なるべくアジャイル開発の文脈で使われる言葉（適応型とか）を使わないようにしてみたのと、従事する人でなく決定権を持つ人向けに中身よりも得られる価値などを中心に記述しました。（記事の最後でPDFを皆さんの会社でも使えるようクリエイティブコモンズで公開してます。） アジャイル開発に関するサマリ アジャイル開発（アジャイルソフトウェア開発）とは、ソフトウェア開発における開発手法の総称です。その特徴は、日々変化するビジネスや市場環境に応じて、作るべきソフトウェアも変化させていくことが出来る点です。 アジャイル開発におけるゴールと狙いは、IT投資に対するソフトウェアから得られる価値を最大化することです。コストパフォーマンスの最大化であり、ただソフトウェアを作ることだけが目的ではありません。 １．誕生の経緯と求められ