Gmailのアーカイブ機能、使っていますか？ Gmailと言えば、Googleの提供する無料で使えるウェブメールです。なによりも大容量であることが特徴ですね。私も仕事でGoogleAppsのGmailを使っています。 そんなGmailを使っているという人は沢山いると思います。しかし、Gmailの「アーカイブ」機能を使っている人はそんなにいない、ということを知りました。 Gmailには色々な特徴や機能がありますが、私がとりわけ気に入っているのは「アーカイブ」です。これによって、以前まで使っていたメーラーなんかと比べて圧倒的に生産性が上がりました。もう「アーカイブ」を使わない生活には戻れません。 この記事では、Gmailの「アーカイブ」機能の紹介と、それによって生産性が上がることについて書くことにします。 Google Mail website screenshot / Spencer E H

今回の記事は、UltimateAgileStories2というアジャイルに関する同人誌に寄稿した記事を転載します。 UltimateAgileStories2は、今後アジャイル関連でのイベントでの頒布を予定しているとのことで、頒布の情報は、http://ultimateagilestories.blog.fc2.com/ にて告知されるそうです。（本誌の頒布により得られた利益は、全額、東日本大震災の被災地支援として寄付されます） 私以外にも沢山の方が記事を書かれていますので、ご興味のある方はチェックしてみてください。今回、私の寄稿した記事は、アジャイル開発に関わるきっかけになった話について紹介しています。 私は今、ソニックガーデンという会社で代表取締役をしています。ソニックガーデンの事業のひとつに「納品のない受託開発」というキャッチフレーズで行っているソフトウェア開発のビジネスがあります。

ソフトウェア開発プロジェクトをとりまく６つの誤解〜プログラミングを経験しないとわからないこと こちらの記事が、ただのエンジニア側のあるあるネタで終わってしまうのは本意ではないので、この記事で少し補足しようと思います。 まず結論から。ソフトウェア開発の関係者がプログラミング経験がないからといって、無駄な作業や無茶な計画が立てられるのは双方にとって不幸なので、プログラミング経験のある本当のプロならば、その特性について、きちんと説明をして、そもそもから理解をしてもらい、お互いにとってハッピーなソフトウェア開発をしましょう。ということです。 ソフトウェア開発の世界において、関係者のソフトウェアの特性に対する理解が足りなかったり、間違った認識があったりすることで、そのプロジェクトの誰もが不幸になったり、無駄なことをしてしまったり、ということが起きているように感じています。 その例えば、を書いたのが、

続きを書きました　→　伝えなければ伝わらないという当たり前の話 ソフトウェア開発に関する相談を受ける中で、どうもソフトウェアというものの特性について誤解をされているな、という思いを持つことがあります。 そうした場合、聞いてみるとプログラミングの経験が無かったり、殆どプログラミングには携わったことがないという方が多いです。 ソフトウェアを開発しようとするならば、ソフトウェアという特性をよく知った上で、プロジェクトは運営した方が良いし、うまくいくはずです。そしてソフトウェアならではの特徴を知るのに、プログラミングの経験はとても重要です。 この記事では、プログラミング経験の無い方が陥ってしまいがちな、ソフトウェア開発にまつわる誤解について考えてみました。 Harry Potter is Ready for Divination / weekbeforenext 誤解：既にあるソフトウェアを流用し

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

ソフトウェア開発にはどんな役割が必要だろうか。よくあるウォーターフォールの世界では「要件定義」「基本設計（外部設計）」「詳細設計（内部設計）」「実装」などといった名前で工程を分けることで役割を分けています。アジャイル開発のスクラムでは「プロダクトオーナー」「スクラムマスター」「チーム」といった名前で分けています。役割の名前が違えば、ソフトウェアのつくり方が違うかというと、そうではなくて「やるべきこと」は同じだと考えています。 ソフトウェアをつくる上で「やるべきこと」は何か ソフトウェアをつくる上で「やるべきこと」は何かをざっくりと分けてみます。 最初に、どんな困った問題を解決したいか、どんなことを便利にしたいか、といった根源的なことが思いつきます。次に、どうやって解決するか、何をつくれば良いか、というアプローチを考えます。そして、それを実際に動くようにプログラミングしていく訳です。 一人で

プログラミング技術さえ身に付けば、プログラマとして一人前と言えるでしょうか？ プログラミングを始めたばかりのうちは、プログラミング言語の習得や周辺の知識を得ることばかりに目がいきがちですが、それだけでは一流のプログラマになれません。（プログラミング言語を学びたいならこちら：写経で身につけるプログラミングの基本） プログラマとして成長するためには、プログラミング技術を学ぶだけではなく、良いソフトウェアを作るための良い習慣を身に付けることが大事になります。初心者のうちに良い習慣を身につけておけば、ただ知識を追い求めるのではなく地に足をつけた成長ができるはずです。 本記事では、私自身も先人たちから学んだプログラマが身につけたい３つの習慣について書いています。 自分で書いたすべてのコードを説明できるようになろう プログラミングは全て、明確な判断の結果です。if文を使うべきかどうか、どのAPIを使う

日経SYSTEMS 2012年4月号の特集１が「システムを育てるカイゼン型開発のススメ」ということで、Part4に私も寄稿させて頂きました。ソニックガーデンが今のビジネスモデルを採用した理由について書きました。 「カイゼン型開発」という言葉は、2006年に私がブログで書いたのですが、ようやく時代が追いついてきたのかと感慨深いものがあります。そして、2012年の私たちは既にそこからさらに先に進んでいて、その答えとなる「納品のない受託開発」というビジネスモデルに辿り着いています。 実際に掲載された寄稿記事の方では割とコンパクトにまとめてもらいましたが、こちらではディレクターズカットということで元々に書いた原稿の方を公開します。もし、このブログよりもさっと読みたい場合は日経SYSTEMSを読んで頂くのが良いかと思います。 ソニックガーデンでは「納品のない受託開発」という少し変わったスタイルでの受

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

これまでコンサルタントの方と一緒に仕事をする機会もあり、横で話を聞いていて、相手に伝えるのがとても上手だなぁと感心をすることがあったんですが、何度か経験をするうちに優秀な方のプレゼンテーションには共通のフレームワークがありそうだと気付きました。 ここでのプレゼンテーションは、勉強会などのLTや発表というよりも、顧客にプロダクトを説明するケースです。 技術者のプレゼンテーションは、中身に詳しいが故に、どうしても「正確に伝えよう」「全て伝えよう」としてしまいがちです。もし技術者を相手にした「セミナー」であれば、それでも良いかもしれません。それも、聴く人たちが詳しく知りたいという動機をもって参加している場合です。 しかし、プレゼンテーションをする相手が、その技術やプロダクトについて詳しくなく、そのプレゼンテーションを聴いたあとに、興味をもってもらって、問い合わせなどのコンバージョンに繋げたいとい

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