Hatena::ブログ(Diary)

naoyaのはてなダイアリー

October 28, 2014

「リーン」について : 「何を作るか」よりも「何を作らない」か

2013年に「リーン・スタートアップ」という書籍が出版されて、それからリーン (LEAN) という考え方に注目が集まるようになった。LEAN とは「無駄のない」とか「ぜいにくのない」とかそういう単語らしい。

書籍リーン・スタートアップには「スタートアップやその類が新しい事業を始めるときに普通にやってるとだいたい失敗するから、潜在顧客や顧客からのフィードバックをこまめに集めて軌道修正しながらゴールを見極めるやり方が良い」とか、雑にまとめるとそういうことが書いてる。

仮説を立ててフィードバックをもらって検証するということを短いイテレーションで繰り返す・・・というのを "フィードバックループ" と呼んでいて、それを細かくやる場合、製品を作り込んでからフィードバックをもらうのでは遅いし、例えばペーパープロトタイプをするとかそういう実験的なことで欲しいフィードバックが得られるならそれが一番いい ─ そういう主張でもある。

ちなみに自分としてはリーン・スタートアップ信奉者でもなんでもない。

Peter Thiel のリーン・スタートアップ批判?

一方最近、元 PayPal の創業者である Peter Thiel が書いた「ゼロ・トゥ・ワン」という書籍を読んだ。(以下 Zero to One) この本はリーン・スタートアップ的な考え方を手厳しく批判している・・・という点で注目を浴びている。なんとなく書籍のタイトルから言わんとすることは想像できるが、実際のところは本編ではリーン的なやり方についての批判はあまり見られない。というか、アイデアを実現するにあたって細かく刻んでいって変化に適応しやすくするべき、というような観点についてはほぼリーンの考え方それに近いことを述べてる。

唯一彼がリーン・スタートアップを批判したとすれば、Peter Thiel はスケールがでかいことが好きなので「小さいプロダクト作って顧客からフィードバックループを集めるとかそんなことじゃ、例えば宇宙輸送とかテスラの電気自動車とか代替エネルギーとか、そういう未来は描けないじゃないか」というような、"ビジョン" とかその辺をどう考えるかというところである。そこに関して異論はない。

ただ、Zero to One の中で彼はリーンのことを

それはすなわち「計画しない」ことである。ビジネスの先行きは誰にもわからない。計画を立てるのは傲慢であり柔軟性に欠ける。むしろ、試行錯誤を繰り返し、先の見えない実験として起業を扱うべきだ

とそんな主張だと解釈しているようだった。これは瀧本哲史が書いている序文 (この序文ははっきり言ってひどい) にも

リーン・スタートアップでは、事前にあまり計画せずに、少しずつ改善することを重視するが、ティールはそうしたスタートアップは結局は成功しにくいと考える

と言う一文があるし、彼らはリーンは「計画をあまりしないこと」だと思っている節がある。

ここに関して、自分の実感とはちょっと違うなと思ったのでブログに書いてみようと思った次第である。前振り終わり。

リーンについて

自分が思うに、リーン・スタートアップやそれに続く「リーン何々」というのはその時のその人のおかれている状況によって結構捉え方が違うものだろうなと思っている。

  • 大企業などでしっかりとした事業計画をを作って物事を進めなければという立場の人には「そんなに計画作りに労力を割きすぎても思った通りにはいかないから適当なところで切り上げたほうがいい」という主張に聞こえるし
  • スタートアップとかで無鉄砲にあれもこれも作ったりしている立場の人には「事前にコンセプトをはっきりさせるとか、仮説を立てるとかユーザーと向き合うとかそういうことにもう少し時間を使った方がいい」という主張に聞こえる

そんな感じの印象を持っている。

特に自分は、後者の、スタートアップが当初の勢いに任せてあれもこれも作りまくった結果それが原因で失敗する・・・たとえば製品が無駄に複雑になったり、余計な仕事を増やしてしまって本来やるべきことにフォーカスできなくなってしまう、そういう場面を多く見てきたし、例に漏れず自分もその罠にはまったことがある。だからリーンという考え方が "「何を作るか」よりも「何を作らないか」" という選択をするときの一つの考え方にはなるのかもな、と思っていた。

2013 年の年末頃に開催された Exciting Coding! 2013 というイベントで、Qiita を作っている Increments の id:yaotti が講演の中でまさにそういう話をしていた。

f:id:naoya:20141028125307p:image:w640

起業当時に作ったプログラミングの Q&A サイトが Qiita に変わっていくまでの過程、ある意味失敗を通じて彼はやはり「何を作らないか」が大事だという考え方に至って、そのためにリーン・スタートアップの文脈で言うところの MVP (Minimum Viable Product) によってアイデアを作る前に検証できたらそれが一番良いかもしれない・・・と述べていた。起業のプロセスを通じてこういう考え方に至るまでの実体験を淡々と話す彼の様子を見ていて感銘を受けたのをよく覚えている。

このあたりのコンテキストが自分にはあったので、リーンが「計画をあまりしないこと」というのは自分の実感とはだいぶかけ離れている。むしろある程度計画を立てることによって「やらないこと」をはっきりさせるための方法論という風にも見えている。

問題をどう解決するかよりも、何が問題かを見極める

ところでまた最近別に「イシューからはじめよ」という本も読んだ。(後半の方法論の所は自分にはちょっと眠たかったけれども) なかなか良いことが書いてた。曰く価値の高い仕事 ─ 著者はそれをバリューの高い仕事と呼んでる ─ を成し遂げたかったら「どんな風にその仕事をこなすか」ということよりも「どんな問題 (イシュー) を解決するか」ということ、つまり問題の見極めこそがとても重要だということを論じている。

f:id:naoya:20141028125305p:image:w640

これ、言われてみれば当たり前のことなんだけれども、人間なぜか問題の見極めよりも、プロセスにばかりやたらと拘ってしまうところがある。このブログを読んでいただいている方の文脈で言えば、たとえばスクラムとか、テスト駆動開発とか Github で云々とか、そういうプロセス、道具を良くしていけば優れたソフトウェアが作れるとか、そんな風に勘違いしてしまったことが一度は誰でもあるんじゃないだろうか。自分もあった。

でも実際には、優れた製品を作るにはその製品がちゃんとユーザーの問題を解決しているかどうか、それを知るということが最も重要であり、どんなにプロセスばかりを良くしたってその領域には到達できない。(もちろん、良いプロセスは大事なので両方できるのが一番良い)

例えば、ソフトウェア開発の組織においてこの図でいうところの横軸には気を遣わず、タテ軸ばかりを頑張ったとする。すると、ユーザーの問題は全然解決されないけどやたらと物を作る速度ははやい、そんなチームができあがる。

f:id:naoya:20141028125306p:image:w640

みんな一度は触ったことがあるはず。やたらと機能がてんこもりでカタログスペック上は何でもできる魔法の製品だが、いざ触って見るとこれっぽっちも問題を解決してくれない・・・そんなプロダクト。具体名を書くといろいろ燃えそうなので、まあそれはモザイクにした。その逆をうまくできれば Qiita とか Slack とか、我々が好きなソフトウェアがちゃんと作れる。

で、ソフトウェア開発の方法論とこのイシュー云々の話を結びつけるなら、スクラム、継続デリバリー、Github 云々といった最近の開発手法の話は「イシューからはじめよ」の絵でいうところのタテ軸を伸ばす方法論で、リーンは横軸をどう考えるかというための処方箋であるという風に捉えられる・・・と思った。

起業もそうだしソフトウェア開発もそうだし、いや、仕事延いては人生など諸全般において、問題を正しく見極めるということはとても重要なことである。その時に闇雲に物事を進めるよりは「何をやらないか」というコンセプト決めとかそういうことを少しやるだけで物事はずっとよくなるし、逆にそればっかりをやっているなら、もう少し柔軟にやってみたら? というのがリーン的な考え方だろうと、自分は思っている。

ビジョンも必要だよ

一方、途中に書いた Peter Thiel が述べているような「どうせやるなら大きく賭けろ」みたいな話もそれはその通りかもなとも思ってて(それは最近読んだ Erik Shmidt が書いた 「How Google Works 」にも同じことが書かれてた)、なんだかんだでユーザーがびっくりするような物を作るにはそういうビジョンというか思い込みみたいなものに賭けるという側面も絶対になければならないと思ってる。

それらをすべて机の上に載せると、情熱とかビジョンとかそういうものに突き動かされて未来思考で物を作るということと、現実的にはここまでに述べたような問題を正しく見極めること、どちらか一方じゃなくてバランス良くそれをやってくのが最善である。

・・・以上、幾つか本を読んだ割には月並みな結論に達してしまった、という話であった。終わり。

October 18, 2014

エンジニアにとって良い組織とは何かを知りたい?

「エンジニアにとって良い組織体制ってどんなものですか? お話を伺いたいのですが・・・」と依頼をいただくことがあるが、都合上全部を受けてはいられない。ので、そういう疑問を持たれた方は以下の本を読むと良いかと思います。

How Google Works (ハウ・グーグル・ワークス)  ―私たちの働き方とマネジメント
エリック・シュミット ジョナサン・ローゼンバーグ アラン・イーグル
日本経済新聞出版社
売り上げランキング: 19

小さなチーム、大きな仕事〔完全版〕: 37シグナルズ成功の法則
ジェイソン・フリード デイヴィッド・ハイネマイヤー・ハンソン
早川書房
売り上げランキング: 7,579

Team Geek ―Googleのギークたちはいかにしてチームを作るのか
Brian W. Fitzpatrick Ben Collins-Sussman
オライリージャパン
売り上げランキング: 14,665

この3つを読んで何も感じることがないようなら、あなたにはエンジニアにとって良いなにがしを構築する素養はないと思うし、本なんて読んでられるかというのには、その程度のことにも時間を割けないならそもそも諦めろとしか言えない。

September 29, 2014

日本語で読める IT名文書 三選

pplog の方に書いたけど、別にブログに書けばいいかと思い直したので投稿。Slack でチャットしてて、なんとなくこれ面白いよ URL を共有する機会があったので適当に選んだもの。

伽藍、バザール、ノウアスフィア、おなべ(3)

artonさんがノウアスフィアの開墾についてわかりやすく書いてるもの。原文はちょっと長くて読むのが大変だけど、こっちは分かりやすいし、面白い。OSS の構造がなんかわかったきになる、すごい。

Steve Yegge の Google とプラットフォームに関するぶっちゃけ話を訳した

Rebuild.fm とかでも何回か話してる記事。元Amazon で Google+ の中の人が「俺たちプラットフォーム作ってる言ってるけど、全然だめだよ! お前ら Amazon の SOA とか見ろよ!」と憤って社内にメールしたら流出しちゃいました、という文書。

ベゾスからトップダウンで「SOAしないやつはクビな」とか言ってできあがったシステムがその後のアレになりましたとか、むちゃくちゃ面白い。

射撃しつつ前進

メールみてWebみて昼飯くってメールみてWebみて・・・ってやってたら夕方になってようやくエディタ立ち上げる、みたいなくだりがあるあるすぎて面白い。本編よりそこが面白い。

ハッカーと画家

例えば、大学で私は、コンピュータに手を触れる前に 紙の上でプログラムを完全に理解しなければならないと教わった。 でも私はそういうふうにはプログラムできなかった。 私が好んだやりかたは、紙の前ではなく、コンピュータの前に座って プログラミングすることだった。もっと悪いことに、 辛抱強く全てのプログラムを書き上げて正しいことを確認するなんてことは せずに、私はめちゃくちゃなコードをおっぴろげて、 それを次第に形にしてゆくのだった。 私が教わったのは、デバッグとは書き間違いや見逃しをつかまえる 最終段階の工程だということだったが、 実際に私がやっていたのは、プログラミングそのものがデバッグという具合だった。

随分長い間、私はそのことを後ろめたく思っていたものだ。 ちょうど、小学校で教わった鉛筆の持ち方と違う持ち方をしていることを 後ろめたく思っていたのと同じように。 他のものを創る人々、画家や建築家がどうやっているかを見れば、 私は自分のやっていることにちゃんと名前がついていると気づいていただろう。 スケッチだ。 私が言えるのは、大学で教わったプログラミングのやりかたは全部間違っていた ということだ。 作家や画家や建築家が、創りながら作品を理解してゆくのと同じで、 プログラマはプログラムを書きながら理解してゆくべきなんだ。

最高の一節。

あれ、3といいつつ4になってた・・・

September 23, 2014

HBFav 2.7.1 をリリース。iOS 8 に対応しました

審査に時間がかかってしまいましたが、無事 HBFav 2.7.1 をリリースできました。

これで iOS 8 にするとクラッシュする問題が解消されました。

ただし、iOS 8 でプッシュ通知を受け取ろうと設定しようとしたとき正しく設定できない問題が見つかったため、急遽修正しまして 2.7.2 の審査待ちです。デバッグの過程で既存のプロビジョニングファイルをいろいろいじったせいで、もしかすれば既存のバージョンもプッシュ通知が届かなくなっているかもしれません、申し訳ないです。プッシュが届かなくなっているもしくは iOS 8 でプッシュが来ないかたは 2.7.2 のリリースをお待ち下さい。

このところ HBFav の開発にあまり時間が取れず、バージョンアップの割に目新しい機能はほとんどありませんが、今後ともよろしくお願いします。

September 18, 2014

HBFav が iOS 8 でクラッシュする問題について

HBFav をお使いいただきありがとうございます。

現在のバージョン 2.6.1 は、iOS 7 から iOS 8 にアップグレードするとアプリ起動後、記事一覧を読み込んだところでクラッシュしてしまいます。

クラッシュの原因を修正したバージョン 2.7.1 を先週には App Store にアップロードしたのですが、まだ審査待ちでリリースできていません。申し訳ございません。今しばらくお待ち下さい。