プロダクト開発を内製化やアジャイル化する際のどこからはじめるかの勘所の話 #postudy

本ポストは特に私が所属する組織の見解ではなく、私が今までの経験＆自分がチームを作るときにチームの目標を考えたり、組織内にアジャイルを導入したり、組織内での開発チームの位置づけをどうするかなどなどを考えるときに意識していることですのであしからず。

内製化や、アジャイル化のビジネス上の効果を得やすい部分をビジネスモデルから考える

昨日、プロダクトオーナー祭り2016で「DevOpsとリーンスタートアップ時代のプロダクトオーナーシップ」というセッションでパネルディスカッションに登壇させていただきました。 postudy.doorkeeper.jp そこで内製化や、アジャイル化はどの部分からやるのがよいかみたいな話の流れかなにかで、「System of Engagementでなおかつ成果課金のようなエンジニアの書いたコード上で売上が立つモデルだとエンジニアリングが直接売上に寄与しやすいためビジネス価値を生みやすく座組が作りやすいです。仮にはじめての内製化やアジャイル化みたいなことをするのであれば、そういうところから始めるとよいです。」みたいな話を軽くしたのですが、あまりにも軽くしすぎたので補足をブログにしてきます。

System of Engagement(SoE) と System of Record(SoR)

ここらへんの議論については、最近、Ito Naoya さんがSoEとSoRの話をしてくださっていて、共通認識として広まってきてる感があります。掻い摘むと、顧客とのエンゲージメントを高めるためのシステム(SoE)と、記録のためのシステム、いわゆる基幹系システム(SoR)にわかれ、それぞれに応じて、適切なマネジメントスタイル、組織、方法論、技術選定、開発プロセスを取るべきであるという話になります。SoEかSoRかというわけではなく、それぞれの要素のグラデーションでバランスよく考えましょうという話ですね。

https://speakerdeck.com/naoya/system-of-record-to-system-of-engagement#5

その上で、SoEは仮説検証型、アジャイル型寄り。

しかしながら、もう一歩踏み込んで、更にビジネスモデルという切り口で見てみると、更に霧がはれていきます。

エンジニアの書いたコード上で売上が発生するようなビジネスモデル

例えば、SoEの中にトランザクション(従量課金モデル)の要素がある場合は、その部分から仮説検証型、アジャイル開発型としてトライすると良いと思います。 簡単に言い換えると、プロダクト上でユーザーが課金するもしくは、プロダクト上のユーザの行動によってクライアントからお金が支払われるようなモデルです。もっと、極端に言い換えると、エンジニアの書いたコード上でユーザーのコンバージョンが発生してお金が儲かるモデルです。この場合は、エンジニアが成長のエンジンになりやすいケースです。だってエンジニアのコード（UI、パフォーマンス、アルゴリズム等）が良ければ良いほどコンバージョンを生み、売上があがっていくので。 つまり、そのようなビジネスモデルのケースでは、数値責任をもったチームが仮説検証サイクルを意識してアジャイルに回すほうが売上貢献しやすいです。言い換えると、エンジニアのコードの改善が売上に直結寄与しやすい。これがビジネス価値をエンジニアが作り出していると言いやすく、説明責任を果たしやすいです。

この領域は、たとえば、ソシャゲとか、デーティングとか、ECとか、toC課金のモデルの多くであり、ネット系とかウェブ系と言われている部分の多くです。また、toBとかでいうと成果課金広告とか、アドテクとか、SaaSとかがそれになりますね。SaaSの場合は、チャーンレートが重要になってきます。または裏返しで継続率ですね。それが毎月の売上に直結します。

500StartupsのDaveが提唱しているAARRRモデルがありますがこれが一番イメージしやすいです。

これは勝手に私が書き換えたものですが、Churn（水漏れ）も追加しています。広告等でユーザーを獲得してきて、一定量がアクティベーションせずに離脱して、残りが継続利用してくれて、でもまた徐々に下に漏れていって、継続利用してくれるとどんどん売上が立っていってみたいな流れです。つまり、ここの水漏れをエンジニアリングで防ぐことでも、売上に直結させられます。本質的な継続率は、顧客の課題を解決し続けている必要があるのでそもそものサービスの価値の議論にはなるかと思いますが。まあ、つまりは、改善サイクル(リリースまでのリードタイム)が高速化するとビジネス価値を生みやすいということです。かつて言われていたグロースハッカーがまさに活躍する領域です。

ここからは妄想ですが、そのため、成果課金・従量課金・月額課金モデル等をベースとするエンジニアの書いたコードの上で売上が立つウェブ系なスタートアップ界隈やソシャゲ界隈などなどはアジャイルを採用することが多く、あわせてエンジニアの労働環境も良くしやすく、オフィスもエンジニア最適化されたり、エンジニアは好きなディスプレイ、マシン、キーボード、椅子で自由に働いている。そして給料も良いのでは。エンジニア達こそが競争力の源泉になるので。という構造になっている(なりやすい)かと思います。妄想ですが。

エンジニアの書いたコード上で売上が立たないビジネスモデル

それに対してSoEの中でも、逆に、エンジニアのコード上で売上が発生しないモデル。 例えば、営業が商品（製品、純広告、etc）を売ってその商談で売上が立つようなモデルとかだと、ある意味、成長のエンジンはエンジニアではなく営業力になる（スケーラブルかどうかの議論はおいとく）ケースが多いです。

ここでエンジニアが価値を出すポイントは、商品開発(パッケージソフト商品、純広告商品等)になるパターンが多いと思います。（営業支援ツール等のSoRなバックオフィス系は一旦省きます）

エンジニアリングは魅力的な売れる商品を作ることと、営業の顧客単価をどうあげるかに寄与するパターンになります。そしてエンジニアの開発した新たな商品によって顧客単価があがるのであれば、それは素晴らしい成果になります。例えば、顧客単価を上げるために、オプションプランで追加課金するような機能を追加するとか、SMB向け商品等でアップセルを狙うためにエンタープライズの大口顧客に売るために、エンタープライズ特化の機能を追加するとかになります。しかしながら、このモデルでは、定量的なエンジニアのビジネス貢献度が前述の従量課金モデル等に比べ見えにくくなってしまうため、アジャイル化する前にまずはエンジニアのビジネス貢献を定性的にでも見える化する必要があります。絶対やるべきです。 そのための一つのやり方としてAlignmentMapというものがあります。こちらもちょうどプロダクトオーナー祭りにて言及されている方がいました。 martinfowler.com

前述のトランザクション課金モデルだとKPIツリーを分解していけば、最終的にCVR改善等のプロダクトチームのエンジニアタスクに落ちやすいので、定量的にビジネス貢献度を出しやすいのですが、非トランザクション課金モデル、非SaaSモデルでも定性的にビジネス貢献を可視化することはこれで出来ます。これをやることで開発タスクがそれぞれどんなビジネス貢献に寄与するのかをエンジニア自身が把握することもできるし、ビジネス側も意味なさげに見える技術的負債の解消や性能改善等のエンジニアリングとビジネスの関係が見えるので色々やりやすくなります。AlignmentMapとか名前ついてますが、一般的な組織では当たり前のようにこういう構造化はしているとは思います。運用の仕方についてはリンク先を読めばわかるかと思いますので省略します。定期的にビジネスサイド、エンジニアサイド両方での振り返りを行い、一つのマップにマージして議論するのがポイントです。

AlignmentMap

SoEの各フェーズにおいて求められるエンジニアロールについて

また、前述のようなビジネスモデルでの切り口とは別の切り口で、内製化チームを作る場合、時間軸で見てみることも大事で、SoEのビジネスフェーズによって求められるエンジニアロールも変わってくるという話もしたので簡単にまとめておきます。ビジネスドメインによって差異はあるとは思いますので、あくまで考え方の一例として理解してください。

基本的には下記の図がすべてなのですが、説明しますと、初期ステージであればあるほど、なんでもやるよねという話です。MVPを作って実際のユーザーにインタビューしにいくかもしれませんし、営業にエンジニアも同行するかもしれません。そしてグロース期に入って、ビジネスコミットの強いフルスタックエンジニアは、グロースハッカーとして水漏れの補修をしながらKPIに寄与するエンジニアリングをしたりする。チーム自体がクロスファンクショナルであれば、別にフルスタックである必要はないと思いますが、フルスタックエンジニアであるほうが、リードタイムは少なくフロー効率は高いと思います。そして、P/M Fitを達成し、マーケにより流入を増やしたり、カスタマーセグメントを幅出ししたり、アップセル狙ったり、でトラフィックが増えてくるあたりで深刻な性能問題になやんだりします。ここらへんでは、今までの技術的負債をどうにかできるプロフェッショナル型のエンジニアが活躍してくると思います。

結果的に、午前のやっとむさんの発表に繋がったらしい。

最初はマルチロールエンジニア、グロース期にはフルスタック、その後はプロフェッショナルというのは、午前に紹介した開拓者、入植者、都市計画者と移っていく話につながってるみたい。そうすれば組織内でまわせるという話 https://t.co/ifb0pq6QE6 #postudy

— YASUI Tsutomu (@yattom) 2016年11月26日

まとめ

皆が置かれている文脈も違うため、すべてを包含してこうだとは言い切ることはできないのですが、伝えたかったこととしては、仮に内製化をはじめるとか、アジャイル化していくとか考えるときにどこから始めるとビジネス上の価値創出がしやすいか、成功確度が高いかをこういうふうに考えることも出来るよ、ということでした。 そして、その構造を理解した上で開発体制を組んだり、プロセスをきめたりすれば、よりエンジニアがビジネス貢献しやすい座組を整えやすくなるよという話でした。

そのため、自分がよくやるのは、例えば広告系なビジネスの場合であれば、営業資料があれば真っ先にそれを見せてもらったりします。そこで純広告を売っているのか、成果課金広告モデルなのかわかります。また、その比率も見ます。それでエンジニア組織のありかたを想像するキッカケになったりします。

別に今回記述した論理展開がすべての開発現場に当てはまるわけではないので、現場毎に自分たちのビジネスモデルと向き合い考える必要はありますが、こういう切り口でエンジニアのビジネス貢献というテーマで開発組織のあるべき姿を考えてみるのもよいのではないでしょうか。 こう考えることで、内製化すべきポイントはどこであるか、まずアジャイル化すべきポイントはどこであるか、エンジニアの評価制度にビジネス貢献度を入れるべきかどうかとか、色々考える際のとっかかりになると思います。

DevOpsはエンタープライズからスタートアップへの横恋慕 #devops #プロダクトマネージャー #leanstartup

DevOpsはエンタープライズのスタートアップへの憧れ

と、楽天の川口さんが言ってたなーなるほどなーと今になってしっくりきてたのでブログを書いてみる。んで、ブログ書くために、あれ？そもそもあってるっけと思いFacebookストーキングしたら違ってた。

"DevOpsはエンタープライズからスタートアップへの横恋慕" by 川口さん

と言われていた模様。うーむ、横恋慕のほうが味わい深い・・・。 そして、早速タイトルを修正した。先行きが不安だ。ちなみにかなり長めのポエムなので時間のないかたはそっと閉じて頂ければ。

自分自身が長いこと新規事業畑にいたこともありDevOpsへの関わり方として、エンタープライズな状況下（Dev部門、Ops部門、ビジネス部門、...and so on）においてDevOpsをしたというよりも、サービスをゼロから立ち上げ、グロースする中でのDevOpsという経験が強く、最近のDevOpsブームの前提が色々としっくりこないことがあったが、やっと先日のPoppendieck夫妻とMSの牛尾さんのバリューストリームマッピング研修に出たことで腹落ちした。実際はその研修の内容とはまったく関係ないのであるが、Maryの一切ブレないリーンの本質の部分に触れることで、よいキッカケをもらえたことに感謝している。

ちなみに私はDevOpsを以下のスコープ及びニュアンスで理解してる。勝手に理解してるだけなのでみんなの心の中のDevOpsを否定するつもりは微塵もない。TPSをみたり、リーンを学んだりでその流れでDevOpsを見てしまっているので、DevOpsというよりは、単純にリーンにバリューストリームを全体最適させる目線が強いかもしれないが。

• 広義
  「コンセプトをキャッシュに変えるフロー効率及びリソース効率を最大化する一連の実践」
• 狭義
  「DevOpsは高品質を保ちつつ、システムに変更をコミットしてから、その変更が通常の本番システムに組み込まれるまでの時間を短縮することを目的とした一連の実践である。」
  （こちらはDevOpsの教科書という本での定義である）

DevOpsのスコープとリーンスタートアップの仮説検証サイクル

私自身が、リーンスタートアップスタイルの仮説検証型でずっと新規事業をやってきた流れが強いので、そこからDevOpsに光をあてて理解していくのがとっつきやすいと思い、このような図になっている。小さくてわかりにくいかもなので補足すると、図の下部にある○の連なりは、IDEAS->BUILD->PRODUCT->MEASURE->DATA->LEARNと書いてあります。よくあるリーンスタートアップでのBMLループである。

狭義と言った部分が、すごくざっくりいくと赤い部分(BMLループのBuild部分)で、広義といったのが青い部分(BMLループ全体)になる。同時に赤い部分はエンジニアが直接結果をコントロールできる範囲であり、青い部分は利用者・ユーザの行動を介すことで結果に不確実性が伴う部分でもある。リーンスタートアップ等の仮説検証を効率よく回すという目線でみると、赤い部分はあくまでもBuild部分の最適化であり（一部Measureも入ると思うが）やや、狭く感じる。やりたいことは青い部分の仮説検証サイクルの高速化である。ここが新規事業畑だった自分が感じた違和感だった。赤い部分だけをDevOpsとして最適化しても、結局のところは、仮説のスジが悪いことでゴミを作り続けて出荷するムダ、また、良いものを作ったとしても、マーケのミスでユーザに届かないというムダが生まれてしまうのである。

シード期やアーリーステージでのDevOps

開発部門、事業開発部門みたいなような組織デザインではなく、ハスラー、ハッカー、デザイナーのようなチームで始まるド新規なサービス開発の場合。自分たちの持ち出しもしくは会社であれば少額のバジェットで開始するにあたり基本的にバーンレートが重要になる。 思い込みによるフルスイングでバーンレートを最大化させることよりも、小さく仮設検証型でやり失敗を小さくして学び効率を最大化させ、バーンレートを下げるスタイルとしてリーンスタートアップがある。 つまりは、ゼロから何か事業、サービスを始める場合においてバーンレートを下げつつ学びを最大化させようとすると1つの手段として仮説検証型になることになる。（起業家の嗅覚でフルスイングして、大当たりするケースもあるので、これは個人の自由である。）

仮説検証ベースの場合、価値観として最小工数で最大の学びが得られることが大事とされるため、極論、作らない。作るとしても表面だけで裏側のアルゴリズムは人力で回すとかになる。それでユーザーが価値を感じれば（コンバージョンすれば、継続利用すれば）あとから実装すればよいのである。いわゆるMVPによる実証である。 そんな感じでシード期は過ごすわけで、そこでその価値観に染まると、徐々にユーザーが増え始めてきてアーリーステージになり、シリーズAの出資を受けるフェーズになった際にも、仮説検証がベースのエンジニアリングになっている。

例えば、ある新機能をリリースする場合、新機能のリリース日から使い始めたセグメントの継続率と、従来ユーザの継続率の比較をするケースがよくある。継続して利用されるということは少なからずユーザに何らかの使い続ける理由があるのである。つまりは、ユーザの課題をいずれかの形で解決している状態である。Problem-Solution Fit（PSF）といわれたりする。（余談ではあるが、結婚指輪のECをやるような場合は継続されると気まずいのでここはビジネスモデルによる部分ではある。）

そこで真っ先に入れることになるのがコホート分析である。

ここでのコホートは、新規利用開始日のコホートになっており、使い始めた日毎にユーザをセグメントしており、その毎日の継続率を示している。そのため、ユーザ獲得キャンペーン等を実施した日に他のリリース等の他のイベントを行わなければキャンペーンの本当の効果を測定できる。

しかし、この運用だと問題があり、毎回ユーザ全体に新機能をリリースすることで既存ユーザへの影響というリスクが発生する。毎回、機能追加が成果があるならよいものの大半は失敗する。そのため、最初は一部のユーザにのみリリースして実験したくなるのである。その結果フラグが必要になり結果的にFeature Flag運用になる。（既存と新規機能のA/Bテストの場合もある。） 結果として、自然とDevOpsのプラクティスとしての文脈ではなくFeature FlagやFeature Toggleベースの開発を行うのである。（ここでのFeatureFlagは本番へすべてのコードリリースの文脈ではなく、ユーザー毎の機能の出し分けON/OFF文脈である。） よくあるケースとしては、外部のSaaSを使うケースである。OSSもたくさんある。CookpadさんのChankoは有名である。他にはここらへんのサイトを見ておくとわかりやすい。 また、同時にユーザーのセグメント機能も実装することになる。そのセグメントに対してFeature Flagをオンにするために。 例えば、開発チームメンバだけに公開、次に、自社メンバ、次に、全体のユーザの数％のみとなる。 昨年度、協業して自分自身もエンジニアとして参画していた99designsでの実際のFeature Toggle運用はブログで公開されているので参考に載せておく。基本的にセグメント切りおよびオンオフはAdminコンソールにて行う。

また最近でいうとFirebaseがmBaasとして提供している機能郡とかも、非常に親和性は高い。
・Remote Config x Analytics（ユーザセグメント）で機能の出し分け
・上記結果をAnalytics（コホート分析）でセグメント単位で効果検証

https://firebase.google.com/docs/remote-config/

ここらへんのセグメント化 x 機能出し分けによる仮説検証は、アーリーステージにおいて、DevOpsのプラクティスとしてよくある各種自動化よりも先に実施される感覚がある。このフェーズであれば、部門もわかれておらずその場で会話すれば解決するようなピザ2枚状態だし、システムも重厚長大ではないため、そういう順序でも問題がないかはおいといて結果的に現場のオペレーションが回る。（重厚長大ではない状況で、先んじて諸々自動化しておくことが大事なのはわかっているが話が混ざるとシャープではないので振り切って話すことにする。また、現場の毎日が文化祭前夜感を経験している人にはビジネス価値 > 負債量産の状況はわかるはず。）

そういう意味で以下の牛尾さんのスライドにある主要なプラクティスとサブプラクティスの優先度がサービスをゼロからグロースさせてくると自然と一部プラクティスが逆転していたりする。DevOpsにこれをやれという絶対はないものの、通ってくる文脈によって導入するプラクティスの位置づけも優先度も変わるというのは当たり前といえば当たり前であるが面白く感じた。

https://docs.com/ushio-tsuyoshi/5912

アーリーステージでのエンジニアリングの優先度として、コードベースが複雑でなかったり、実験なので破棄することもあるため、細かい自動化による小さなムダの排除よりも、そもそも使われないモノを作らないことであったり、作ったものがちゃんとターゲットユーザに届く(認知される)ことであったり、ユーザが途中で離脱しないことであったり、そちらにパワーを割いたほうがトータルでムダが少なかったりするケースが多い。そこで、結果的にDevOpsとか意識せずFeature Flagだったり、仮説に基づく開発（運用環境でのテスト）が行われる。（サービスを安定運用させるために、自動スケーリングさせたり、パフォーマンス監視だったりは当たり前でやるとして。）

DevOpsが見る夢は、ワイワイやってたあの頃への回帰

最近DevOpsが語られるときには、エンタープライズDevOpsであり、基本的に負債や重厚長大なプロセスを持った組織の改善という文脈が多いが、そうじゃなくオーガニックに組織が成長していく過程だと上記のように、また違ったアプローチでDevOps（のようなものを結果的にやっていく）していくことになる。そこが個人的には今まで本やウェブ上の記事で感じていたギャップなのかもしれない。

冒頭にも書いたが、今回、Poppendieck夫妻の研修に参加し、組織やプロセス、技術に対してリードタイムを如何にさげるか、リソース効率ではなくフロー効率をいかに高めるかを考えるようになり、そこら辺がクリアになった。クロスファンクショナルチームとかスモールチームとかよく言われるがそれはあくまでフロー効率を最大化するための一つの手段なのである。

DevOpsが目指している本質は、「何かあったときに会議なんかせずに席の周りにみんな集まってその場で議論して進められてたあの頃に戻ろうよ」ということなんだなあと。 例えばアジャイル（スクラム）で"開発チーム"があの頃に少しは戻ったとしても、それだけだと不十分で、インフラ、ビジネスサイド、営業、みんなでワイワイやってたあの頃に戻りたいんだろうなあと。

まさに、"DevOpsはエンタープライズからスタートアップへの横恋慕"である。

結果的には「コンセプトをキャッシュに変えるフロー効率及びリソース効率を最大化する一連の実践」である。

あの頃に戻るためには、いきなり戻ろうとするのではなく、今まで作り込んできた組織構造上のムダ、アーキテクチャ上のムダ、プロセス上のムダ、そしてそれらが複雑に絡み合った状態をほどいていく必要がある。（そういうふうにエンタープライズ下でのDevOpsでは考えるようにしている。）

そこで一つの取っ掛かりになるのが、散々語られているがバリューストリームマッピング(VSM)による現状把握と改善である。 VSMによる改善を回すと、真っ先に現場レベルでできることは基本的に自動化であり、その次にボトルネックはどうしても組織構造に移る。 その文脈の中で、様々な記事や文献でいわれているように、以下のような組織、プロセス、アーキテクチャのリファクタリングが伴う。そのため、VSMによる改善活動を行う場合は、権限を持っている人の同席が必須である。

• 組織デザイン
  
  • 権限をチームに与え、クロスファンクショナルでスモールチーム化：スタートアップ回帰
    
  • 責任と自由（権利）について
    
    • どこかは伏せるが自分が近くで見てきた例としては、売上を上げている単位のサービスでチームをわけて権限委譲＆下記のマイクロサービス化をしていた事例がある。
      
• アーキテクチャ
  
  • スモールチームで回せるサイズ（例えばマイクロサービス）：スタートアップ回帰
    
    • どこかは伏せるがMSAにするのに15ヶ月かかってるのを見ていたりもするのでこれは大きな経営判断を伴う。
      
• プロセス
  
  • 人による承認のようなゲート方式からパイプライン方式へ：スタートアップ回帰
    

そして、その結果チームは本当の意味での継続的デリバリーを手に入れることになる。

以下は、昔、夏サミで発表したスライドであるが、このときの内容はDevOpsとしてではないが、太字部分は結局DevOpsプラクティスで得られる効果そのものを指していたりする。

http://www.slideshare.net/i2key/devsumi-natsumic7

「あのころ」に回帰したチームにおいて、プロダクトオーナー/プロダクトマネージャーはmini CEOである

クロスファンクショナルなチームにおけるチームの責務はサービスのグロースであったりビジネス上のKGI/KPIの達成であるため、組織体としてもスタートアップのような何かである。エンタープライズ型の重厚長大なプロセス、セクショナリズム、アーキテクチャ上の制約が仮になくなれば仮説検証を行うサイクルタイムは今までよりも早くなり、仮説を市場に問うリードタイムは最小化される。

それとともにプロダクトマネージャーの役割もスタートアップ帰りが起こる。DevOps関係なくそうだとは思っているが、DevOpsが機能しだすとより顕著である。 そして、馬田さんがPM = mini CEOとよくいっているがまさにそれである。

http://www.slideshare.net/takaumada/zero-to-product-manager

ここで一つ問題になるのが、お金である。 エンタープライズの場合、スタートアップのように都度資金調達していくスキームではなく、例えば、年次予算を組んで事前に計画を立て、その目標へのコミットとして翌年の予算が決まるモデルが一般的である。つまり、1年以上先の未来を予測＆予測にコミットすることになる。計画が間違っていたとしても、その計画の達成率が評価になるのである。そこにはピボットは含まれないし、仮説検証による学びからの計画変更は加味されていない。結局、そこの年次予算のリズムが大枠のサイクルタイムになってしまう。 では、仮説検証型で細かくサイクルを回すためにはどうすれば良いか。 ここらへんは先日のバリューストリームマッピング研修にて、MaryやTomから簡単に説明があったり、やはりその後日のリーンエンタープライズの公園にてBarryも全く同様の話をしていたりで、要はBeyond Budgeting（脱予算経営）をしなさいというところだった。 （そんなこと簡単に言われてもさー。というのが正直なところではあるがそれだと当事者意識が低めなのでここでだけ言わせてもらう。そんなこと簡単に言われてもさー。）

かいつまんで説明すると以下である。

• 年次の予算モデルからの脱却
  • 予算確保のための計画、予算調達、実行、振り返りが年次予算である場合、そのリズムになってしまう
  • 大企業は中央集権な予算管理モデルが、意思決定をまとめて行いやすいため効率的に見えるが、不確実性が高い状況下におてそれはフロー効率を下げることになる。
  • Beyond Budgeting（脱予算経営）
    • 楽天の川口さんが昔ブログに簡単にまとめていてわかりやすい
    • http://kawaguti.hateblo.jp/entry/20120315/1331798274
    • Agile 2014 Closing Keynote: Beyond Budgeting でも語られていたようです
    • https://www.infoq.com/news/2014/08/agile2014-keynote-beyond-budgeti
  • 大企業内の新規事業組織とかはほかからの干渉をさけるため出島化することは多い。

しかしながら、現場レベルでも今すぐトライできるやりかたを考えたい。上記に比べるとミクロ視点すぎるため、全体最適とまではいけないが。要は、一旦確保したバジェットの中で如何にムダな金遣いを減らすか。確保したバジェットでできる仮説検証回数を最大化させるかがポイントである。お金の使い方のリーン化である。手前味噌ではあるが、有効なお金の使い方をするのに良いフォーマットがある。

http://www.slideshare.net/i2key/45-developers-summit-2015-devsumi-devsumib

これをもとに仮説検証で学びたいこととそれに対するコスト、期間を見てメンバは責任者に決裁を取ることになる。都度、実験に対して決裁を取るので、組織として年次で確保したバジェットを小分けにして使いやすい。組織の事情を全く考慮せず言っているのであくまで一例としてではあるが。

さいごに

なぜこのタイミングでこんなことを突然語りだしたかというと、世の中で語られているDevOpsがビジネス価値ガーとかいうものの、ビジネス価値までスコープにはいってないではないかという疑問であり、そこらへんの整理をしたかったからであったりします。一見、DevOpsはただのエンジニアリングに見えるものの、結果的には実はビジネス上の不確実性を小さく効率よく取り除き、赤い線の部分の活動の効率化が、しまいには青い線の効率化に昇華する部分をうまく言語化したかったものの、少しわかりにくかったかもしれません。Feature Flagなんて特に青い線の部分の大失敗を避けるインフラであったりします。エンタープライズの中でリーンスタートアップのような仮説検証型でビジネスリスクを下げつつやる場合は、それ相応のエンジニアリングが必要でそれがDevOpsというワードで括っているスコープである理解になります。

あとは、こんな話を交えて

プロダクトオーナー祭り2016 ※2016/11/29更新 プロダクトオーナー祭りでパネルディスカッションで下記の話をしました i2key.hateblo.jp

Regional Scrum Gathering Tokyo 2017 パネル: DevOpsとリーンスタートアップ時代のプロダクトオーナーシップ

にプロポーザルを出しているので投票してネ！という記事広告の目的もあるのである。 最後までおつきあいありがとうございました。

また、全体的に論点をシャープにするため、極端に表現している部分はあります。アーリーステージだって、自動化もするし、やらないわけではありません。両立させている素晴らしいスタートアップも新規事業組織もたくさんあります。というわけで、あくまでビジネスコンテキスト上での優先度として、どちらが最優先されるかという意味になっております。あしからず。

Scrumはじめるまえの本質的な部分の話 #agile #scrum

チームをスクラムにしたいのですが

とあるアプリの責任者に相談を受けた。 彼は自分のチームが改善フェーズにはいり一定のリズムでサービス改善したいためWF型からスクラム化したいらしい。 そこで、いきなり彼は「プランニングポーカーどうやるんですか」と聞いてきた。これは危ないと思った。

PO、SM、エンジニアの相互の信頼が一番大事。

信頼がポイント。それがない状態で始まると意味のない何かになりやすい。

最初にやるべき儀式は、プラクティスの勉強ではなく、 最終責任を取れるビジネス側ポジションの人が、「お互い80%くらいの確度でコミュニケーションしましょう」ということ。 お互いのガードを下げること。一蓮托生になること。

そして、「これの意味は、仮にPOが確度100%の画面ワイヤー等のドキュメントをエンジニアに渡せるのであればエンジニアも確度100%の見積もりを出せるけど、僕（PO）はそんな天才でもないので、80%の確度がやっとです。だからエンジニアの見積もりについても80%程度の確度のもので良いと思っています。だって僕からのインプットがクソだとそもそも正確に見積もれないですよね。これはよく言われている「見積もりはコミットじゃない」ということと同じになります。」とつなげる。

これがない状態でいきなりスクラムごっこが始まるとどうなるか。エンジニア（の契約形態による）がディフェンシブになってしまう。見積もりの精度を求められてしまうことになれているエンジニアはどうしてもバッファを見込んでしまう。これは本当の見積もりではない。つまりはチームが本当のパフォーマンスを出せなくなってしまう。

だから、「ビジネス責任者」から80%ルールの宣言をする。それがまず第一。ガードを下げる。信頼してもらう。

各プラクティスはその後の話である。

チームのためと思ったことがチームの生産性を下げることがある

また、「信頼」に起因して、いきなり個人のベロシティを計測することはやってはいけないという話をした。よくスクラム入門書みたいなものには、ベロシティガーみたいなのが書かれているが、これの意味するところはチームの生産性の可視化でよいことではあるもののあるリスクを含んでいる。また、更にそれで個人の生産性を評価しだすチームなどもある。はげしく危険。

信頼がない状況でやると、何が起きるか。

見積もりのサバ読みが始まる。もしくは、品質の低下が始まる。 自身のベロシティが自身の評価につながると思うと、多めに見積もったほうが生産性は高いマンになる。もしくは、見積もりよりも時間が掛かりそうな場合に、低品質でもおわりにしてしまえという考えが出てくる。 しかし、一概に必ずそうなるとはいっていない。

アジャイルの根底にはチームへの信頼というものがある。 その信頼が足りていないときに、これがおこるのだ。 「チームから解雇されるかもしれない不安」 「守るといっても結局まもってくれないのではないかという不信感」 「なんだかんだ見積もりにコミットになってしまうのでしょうという諦め」

そして、個人のベロシティ競争になってしまうと、さらに、相互のメンバ間の助け合いもおきなくなっていく。人のこと助けても自分のベロシティあがりませんし。と。

個々の生産性を可視化して改善して高めることでチームの生産性を高めようという思いが、逆にチームの生産性も品質も下げるという結果を招いてしまうのである。 （ラプラス憲章みたいなものですね。最初は人類の希望だったのに。それがこじれて戦争になってしまうという。）

なので、ベロシティを見るのはチームの単位まで。 皆の信頼関係があるような次のステップのチームであれば別に自由でよいけど。

みんながその働き方が好きであるわけではない

とはいえ、スクラムの本質は可視化であるため、どうしてもついてこれなくなる人は出てくる。みんながその働き方が好きであるわけではないことを理解しないといけない。ドライな世界だが、チームで成長していけるので、機能すればチームの生産性はスプリント毎に上がる。

そんなお話をした。

本当につたえたかったこと

この手のチームの開発プロセスの話は文脈（ビジネスモデル、商流、体勢、etc）の影響を強くうけるのでかならずこうであるとは言えないが、プラクティスを追うのではなく、人間の力学として、どういう判断をすると、どういうことがチームで起こるかということを考えるのが大事である。

リーンスタートアップで失敗する18のパターン

ローレムに提供した下記ネタの原文を自分の活動ログとしてこっちにも残しておきます。（マルチポスト的でごめんなさい） 余裕があればもっといっぱい色々書きたいことあるので追記していきます。多分。やっぱしないかも。

l-orem.com

---

リーンスタートアップで大事なことは、リスクを最小化するという価値観や考え方だ。一方Webや書籍ではどうしても教科書的な内容が多い。その様な環境において、初学者はどうしてもそこに書いてあるやり方ばかりにフォーカスしてしまう。結果「これはリーン」「これはリーンでない」というどうでもいい議論になりがちだ。本記事ではそこに一石を投じたいと思う。 リーンスタートアップを方法論として捉えてる人へ・・・うまくいきゃどうやったっていいじゃん！

本記事は4/16に開催されたリンスタ関ヶ原での発表「LEAN STARTUP アンチパターン」から抜粋した物です。

1. キャンバス依存パターン

リーンキャンバスは分かりやすい。不確実性の高い事業を進める上でのチェックポイントが羅列されているからだ。ツールとしての分かり易さは時に副作用をもたらしてしまう。それはキャンバス以外のところにもリスクがあるという事に想像力が働かないという事だ。事業/チーム/自分/会社の置かれている状況によって、リーンキャンバスには出てこない目に見えないリスクは様々だ。

リーンキャンバスには出てこないが、後々問題になる目に見えないリスクを以下に列挙する。

• 誰とはじめるか
• メンバーの熱量の差異（チームの持続可能性）
• 自分だけでその領域でやっていけるのか
• チームがその課題を解決する必然性はあるか
• チームにその課題を解決することは出来るのか
• 誰から出資をうけるべきか（ステークホルダーを誰にするか）
  社内でやるべきか、社外でやるべきか
• 誰がボトルネックになるか（決裁マラソン、上長、部下、チーム）
• 市場や技術動向の状況と、投入のタイミング
  その領域は、仮説検証を短サイクルあるいは低コストで回せるか
  （SaaSなどのクラウドを利用して検証が可能か）
• 法的、規約的、業界の慣例的なルール違反をしていないか

不確実なことを全て洗い出そう。そしてリスクが高い順に検証していけばよいのだ。

2. そもそもFounder/Market Fit、Founder/Product Fitしていないパターン

起業家の例 photo by kevin, pakutaso

Founder/Market Fitはファウンダーが対象のマーケットを良く知っている状態。Founder/Product Fitはファウンダーがそのプロダクトをよく使う層という状態を言う。起業家がマーケットにフィットしているか、プロダクトにフィットしているかは、２つの側面において重要だ。たとえば上図の起業家がそれぞれ「パーソナルコンピューターを作る」となった場合にどうなるだろうか。

スタート地点ですでに不確実性がより少ないという側面

業界を知っていれば、以下点においてスタート時点で有利である。

• 参入するドメイン出身で業界事情に明るい
• 特定領域での専門性を持っている
• その領域において人脈がある（メンター候補/アーリーアダプター候補）
• 業界慣例、文化に詳しい（今後仮説検証を進めていく上で有利）
• そのドメインに対してとても深い不を感じている

ファウンダーの持続性という側面

ファウンダーの熱量は持続性に影響し、それは成功事例を生み出す事につながる。心に問うてみてほしい。

• たまたま、そこに課題を発見しちゃったから、はじめたの？
• なぜ、それをやっているの？
• あなたがやる必然性は？
• その業界の人と同じ温度感で課題を感じているの？
• もしくは、あなたはそれを毎日つかうの？

ファウンダーに熱量がなければ新規事業は継続しない。なぜなら新規事業は大抵失敗するもので、心が折れるからだ。会社の新規事業組織から成功事例が生まれにくい理由の一つである。

企業内新規事業部門の多くは、「はい、あなたは明日からこの部署ね。そして新規事業を立ち上げて下さい。」というような人事異動により新規事業に取り組みはじめることが多いかもしれない。そのため、個人差はあれど、野生の起業家に比べ命を懸ける度合いが違う。成功するまでやり続ける力が維持しにくく、続かないのだ。新規事業は、熱量ある人がやるべきで、会社組織としては、そういった人を常に補充し続ける必要ある。

リクルートの新規事業組織の例。熱量のある人を補充し続ける仕組み

リクルートの新規事業では、新規事業部門の人間が新規事業を行うのではない。全社的に新規事業に意欲のある人間が自ら起案し、採択された案だけが新規事業としてスタートを切る仕組みをとっている。

3. MVPでシンプルにやらなきゃだめだよ！だって、ネットの記事にそうかいてあるしパターン

シンプルなMVPでやらないとダメという風潮がある。本やネットの記事によるキラキラした事例に洗脳されている。もちろんこうした例がダメなわけではない。最初はシンプルでよいと思う。しかし競合がいる、あるいは現れた時、シンプルなMVPで仮説検証できるだろうか。物事を伝えるときはあえて極論から、こうした事例で説明される事が多いが、現実はそうはいかない。本に書いてあるような綺麗なMVPを目的化してしまう事がある。あくまで目的は仮説を検証することだ。

ソリューションの一部やニーズの確認さえできればよい場合、シンプルなMVPで足りるかもしれない。しかし競合がいる場合や、マネタイズの検証を行いたい場合は慎重な検証が必要になるだろう。シンプルなMVPではプロダクトの本来の姿を被験者に想像力で補ってもらう部分が不確実性として残ってしまう。こういったフェイズでは競合や代替手段の「当たり前品質」をしっかり満たした上での検証が時には必要になる。MVPならぬMSP（Minimum Sellable Product：お金を稼げる最小限のプロダクト）という概念で考えると分かり易いだろう。

4. 石橋叩きすぎパターン

小さい仮説検証ばかりで先に進めないパターン。仮説検証で100%の確証を得ようと考えていないだろうか？

「いつまでインタビューをすればいいのですか？」

この様な質問を受けるが、答えは「なんとなくわかるまで」だ。100%の理解はサイエンスの度が過ぎる。アート20%、サイエンス80%を意識するのがよい。常に顧客を向いてフィードバックを得れていれば、間違った時の軌道修正も素早くできるはずだし、そもそも素早く仮説検証し失敗を重ねるのがリーンだ。

80%の肌感についてもう少し触れると、10人ぐらいインタビュー続けると次の人の言うことが想像できる様になってくる。そしたら80%来た、と思ってよいだろう。

5. シングルタスクパターン

なぜか一個づつやるパターン。1つずつ仮説検証しなくてはいけないと刷り込まれていないだろうか。幾つかの仮説を同時に走らせておいた方が、１つがダメだった時のリスクヘッジになる。チームであればそれが出来る。ロジック的に依存性がなく並列検証可能なら、同時に仮説検証することも検討する。

6. 誰そのペルソナ、本当にいるのパターン

ペルソナなんかよりもむしろ、課題をもっていて解決してあげたい実在する人の氏名を書くほうが効果的。最初の救う誰かを具体的に氏名で決める。ペルソナは存在しない可能性があるが、実在する人間なら少なくとも1人のユーザーが存在する事になる。

デモグラで切れるようなセグメントの課題なんて既に大抵解決されているし、その様なペルソナに陥るのはソリューションありきだから。ソリューションから逆算して「当てはまる人誰かな〜」と考えた結果、ありもしないペルソナが出来上がるのだ。

7. その人お金払わないよねパターン

カスタマーを誰に置くのか。誰からお金をもらうのか。当たり前だがお金をもらう人を軸にしないと事業は継続しない。成功する前に終わってしまう。

事実私自身、誰からお金を取るかを考えずに始め、最終的にマネタイズが出来なくて終わった経験がある。お金を払う人をカスタマーセグメントに置いて考えた事がなければ、今すぐ考えた方がよい。

8. 何か言っているようで何も言っていないパターン

トートロジー（英語：tautology, ギリシャ語：ταυτολογία）とは、ある事柄を述べるのに、同義語[1]または類語[2]または同語[3]を反復させる修辞技法のこと。同義語反復、類語反復、同語反復等と訳される。関連した概念に冗語があり、しばしば同じ意味で使われることもある。また、撞着語法はトートロジーの反対の技法である。 — wikipedia

VP（バリュープロポジション）とCS（カスタマーセグメント）の例。次の様な書き方をしているケースは驚くほど多い。

もう１段踏み込んで考えるとこうなる。

9. キャバクラでの我々パターン

インタビューでよくあるパターンだが、話を盛り上げようとし過ぎて回答者が気分を良くし、自分の（想像による）意見を言い出し、かつそれが止められない状況。潜在ニーズを調査するようなインタビューの場合、事実だけを吸い上げたいはずだ。想像による発言では仮説検証には使いにくい。場合によっては誤った判断材料となってしまうだろう。 そうなる前に、どうにかして流れを変えるしかない。未来の話はいらない。過去の事実を集約し、それを横断的に分析、共通項を抜き出すというやり方を意識するのだ。

10. リーンスタートアップ、僕、好きじゃないのでパターン

好きとか、嫌いとかそういう話じゃないと思うけど・・

新しい何かを組織にインストールする際には付き物だが、組織でリーンスタートアップを初めてやろうとすると、何と戦ってるのか分からないような人がしばしば出てくる。個人的には、サービスが上手く行けばなんでも良いので、別にリーンこだわる必要は無いと思っているが、全てを別物として捉えている人たちは本質が見えていないので危険である。

一つの課題に対して、光の当て方が違うだけ

AARRRからみたリーンスタートアップ

１人でも継続して利用してくれているということが大事。継続して利用してくれているということは、顧客の課題を解決していることだ（想定していない課題を解決してることもあるが）。AARRRで言うRetentionは、ユーザーがプロダクトに価値を感じている状態、つまりエンゲージしている状態でP/S Fitの指標となる。

制約理論からみたリーンスタートアップ

鎖全体の強度とは、最も弱い輪っかの強度と同等である。最も弱い輪っかを見定め、そこを直せば鎖全体の強度が高まる。その概念と同じで、最もリスクの高い部分を割り出し、検証していく。１つ不安要素を潰したら、次に高いリスクを割り出し検証する、というのを続ける。

リスクの高い部分が鎖の強度が弱い箇所となる

狩野モデルからみたリーンスタートアップ

魅力品質 : UVPであり、他に真似されない部分。

性能品質 : あればあるだけあった方がよい部分。

当たり前品質 : P/S Fit時にはいかに小さくできるか考え（コストの削減）、マネタイズ検証時にはいかに最大化できるかを考える。

Feature Toggleからみたリーンスタートアップ

Feature Toggleは、いろんな実験的な機能を、部分的にサービスにリリースするボタンの様なもので、今や多くの巨大なサービスでは当たり前の様に使われている。これは１つ１つの実験的機能がMVPに値し、最初は開発チームだけに公開。次に、全体の5%のユーザだけに公開、さらに次は10%といった具合に、仮説検証を本番環境でユーザーに対して実施する手法。大きくリリースして大きく失敗してしまうリスクを最小化できる。

ポール・グレアムの言葉からみたリーンスタートアップ

自分が欲しいものを作れ — ポール・グレアム

自分が欲しいものを作れば、自分がまずは使い始めるはずである。少なくとも課題を持ったユーザーが１人はいる状態からスタートするのだから、F/P Fitであり、失敗しにくくなる。

11. エンジニアが上手くフィットしないパターン

エンジニアが作ることのみにコミットしている場合、仮説検証のやり方についてこれない場合がある。素早く検証したいのに、豪華な何か、高品質な何かを創りだしてしまい、検証が思いのほか回らなくなる。エンジニアには「QCD-ScopeでQ抑えめでD重視」と伝えたり、エンジニアに刷り込まれている昔ながらの価値観、優先順位を壊すことが必要。さらに必要に応じて権力・責任のある人に言ってもらうなどが必要だろう。 状況に応じてQCDとスコープの優先順位が変わることを伝え、その上で、この働き方についてこれるエンジニアとやる。

サービスのフェーズによって変わる、エンジニアに求められるコミット

アーリーステージは特に視野を広げる

参考 :

• エンジニアもユーザーに会いに行こう 小さく始める大規模スクラム
• エンジニアもデザイナもヒアリングする Incrementsの文化を作る方法

12. 割り込みが・・・パターン
13. いくつも打ち合わせが・・・パターン
14. リモートワークが・・・パターン

割り込みや打ち合わせ、一概に「ダメ」と言ったり、逆にリモートワークさせろと言いはるのは独り善がりだ。今チームがおかれているフェーズおよび、最重要なことは何かを考えてみて、それが必要ならそうすれば良い。例えば頻繁な割り込み・打ち合わせがあったとして、それがそもそものアイデアの種を良くするのであれば、聞く耳を持たなくてはならない。これは全体最適か個別最適かの話で、Buildの高速化のみを考えているのはよくある事だ。仮説検証サイクルのボトルネックがBuildにあるならそれでよいが、他にネックがあるならその時Buildを最適化する必要はない。

15. UVPを見つけに行ってるはずなのに、顧客の声を聞いた挙句、既にある何かにたどり着いちゃったパターン

ある病気の患者は医師に宣告を受けてから自分の治療法を決めるまでに時間が無く、ツテも無く、お金も無く、落ち着いてもいないので、セカンドオピニオンサービスが必要なはずだ、という仮説を持った。しかしヒアリングの結果、セカンドオピニオンまでははいらなくて、「みんなは」同じような境遇の人、同じ病状、同じフェーズの人が今何をしているか知りたい、繋がりたい、という事実が得られた。あーあ、じゃあSNSでいいじゃん。となり、UVPが無くなってしまう。 こうなる原因は２つある。アイデアがくそだったパターンと、あーあ、で終わり、次が探れなかったパターンだ。

16. 性能競争パターン

既に世に出ているとある製品に対し「ここが悪い」と思った部分を改善したり「ここが足りない」といった機能を追加で実装するだけで新たな製品を世に送り出すこと。もう少し広義にとらえると、コンテンツのラインナップかもしれないし、パフォーマンスかもしれない。

しかし、その既存製品が改善してきたらどうするのだろうか？ 緩やかな性能競争は体力勝負となるため、フォロワー戦略は参入コストが高すぎるのである。

性能競争で勝ちを狙うなら、圧倒的な差をつけるに限る。テクノロジーによって100かかってた労力や時間が1にできたり、数万円だった価格を無料にできる場合などだ。

17. 解決策ありきパターン

ソリューションありきでの考えは全てにおいて失敗しかない。誰の何を解決するのか？がすっとばされた状態だからだ。これはただひらめいただけで、そのまま事業化しよう物なら失敗しかしない。 一方でソリューションが優れている場合もある。研究施設などから発見される発明などだ。その場合は誰の何を解決するのかをしっかり紐付けたい。

18. ○○がそれやったらどーすんのパターン

プラットフォーマーと呼ばれている企業が、同じ領域を、大量の資金でもって上書きしにきたらどうするのか。それに対抗できる状況を作らねばならない。

戦わないですむような戦略 : 市場の再セグメント化を行い、生きる道を探る。

戦うけど優位な状況で戦う : ゲリラ戦。例えばニッチな市場を強力に抑えてしまう。

相手が参入出来ないスペースを狙う : 法的にグレーなゾーンを狙い、プラットフォーマーが自己矛盾起こすような戦略。

先にユーザを掴んで売る : 先行者優位な市場であればユーザ掴んで、プラットフォーマーに事業を売り抜ける。これも選択肢の一つだろう。

まとめ

リーンスタートアップの不確実性やリスクという表現を制約理論からみるとボトルネックと捉えることができる。リーンスタートアップとは事業を進める上でのボトルネックを消して行き、事業のスループットを最大化する、という基本的な話だ。その意味では、リーンキャンバスの項目は、ほんの一部でしかなくて、各種ステークホルダーの意思決定がネックならそこを動かすこともスコープに入れないとならないし、メンバーの熱量がネックならそこも上げないとならない。自分がコミットする範囲やスコープをどれだけ広げるか、といった少し面倒に見えることも、根本を正せばボトルネックを見極め、消していく、というたった１つの事である。

エンジニア向け #マインドフルネス 入門

社内でマインドフルネスの30分ワークショップをやったのでメモとして残しておきます。 本当は長期にわたる研修なので、こんな簡単な話ではありません。

以下の様な禅語があります。

• 調身
• 調息
• 調心

正しい姿勢を保ち、正しい呼吸法で坐禅を組めるようになれば、心身ともに整うという意味です。 このように、本来は、正しい姿勢のとりかたに始まり、さらには、正しい睡眠のとりかたについて、食生活について、などなど、様々なことを学んで実践した上で、やっと調心（マインドフルネス）のフェーズになります。が、今回はそういうの全部すっ飛ばして要素のみを。興味を持った方へのググラビリティを提供するという意味で。

マインドフルネスって何よ。

日本でいうところの「瞑想」になります。ただし、瞑想というとどうしても伝統的な、宗教的な意味あいが入ってしまうのですが、マインドフルネスはそういうのを一旦全部除外して、サイエンスなアプローチで瞑想の効果を科学し、再現可能なものにリビルドしたものになります。なので、ある意味、瞑想の逆輸入にあたります。（ちなみに、ヨガも同じでインドのそれが、いつのまにか、先進国で科学的に意味のあるものと実証されて、いまや日本で女子力を高めるツールになっています。） 最近はGoogle等の先進的なIT企業が、生産性を最大化するための取り組みとして実践しており、実際にGoogleでマインドフルネスの講師をしているかたに全10回くらいの研修をしてもらい教えて頂きました。

マインドフルネスってどういう状態？

感情を自身によるフルマネージドな状態にすること。 そのために感情のイベントハンドラーを脳みそに実装するためのトレーニングが必要。
そして、感情の状態をハンドリングできれば、コントロールすることが可能。
最初に感情の操作の方法。次に、注意のイベントハンドリングについて説明します。

瞑想（呼吸）によって感情をコントロールする

ジョジョの波紋みたいですねwwww
目をつむってもあけててもいいので瞑想する。 ポイントは、姿勢を正すこと(ドローイン)。姿勢が悪いと肺が圧迫され、横隔膜のワークが弱まる。 すると呼吸が浅くなり、呼吸による感情コントロールの効果が弱まる。 瞑想時の呼吸には吸うときと吐くときで下記の効果がある。（血中二酸化炭素濃度に比例）

• 息を吸うとき 　　交換神経利用　イライラ/ネガティブ/集中（思考は浅いけど突き進むとき）
• 息を吐くとき 　　副交換神経利用　リラックス/ポジティブ/発散（遠い記憶と遠い記憶がつながる）

これらの時間をコントロールすることで、集中モード、発散モードの スタンスチェンジが出来る。（構えを変えて戦う格闘ゲームみたいｗｗｗ）

• 息を吐く時間　＜　息を吸う時間　集中突撃モード
• 息を吐く時間　＞　息を吸う時間　発散クリエイティブモード

試しにやってみよう

• 目をつぶって、息を吸う時間を長め、吐く時間を短めで2〜3分くらい呼吸してみてください。 なにか、焦りのようなハラハラする感覚になりましたか？多分なってますよね。 それが、交感神経を沢山つかっている状態です。
• 逆に、息を吸う時間を短く、吐く時間を長くするとリラックス出来てきます。 これが副交換神経を利用している状態になります。

例えば、数学的な難しい問題をとくとき

最初の問題解決策を洗い出してクリエイティブに考えるときは、まずは 息を吐く時間　＞　息を吸う時間　で5分間瞑想し、発散モードに。 解決策が決まり、あとはやるだけになったら、 息を吐く時間　＜　息を吸う時間　で集中モードにスタンスチェンジ。

宮﨑駿氏の例が面白い。 どんな映画をつくろうか考えているときは、楽しそうにニコニコしてる。 ただ、作るものがきまったら、終始毎日イライラしている。 そうやって感情（集中・発散）のコントロールをしている。

注意のイベントハンドラーを実装する

次に自分の感情の変化をハンドリングするために、退屈な刺激、小さな刺激へ注意を向ける練習です。 同様に瞑想をしてください。瞑想中は今回は、自分の呼吸回数を数えて見てください。 タイマーで5分くらい時間を区切り、ひたすら呼吸の回数を数えてください。多分、途中で別のことを考えてしまうと思うので、それをハンドリングしてもう一度、呼吸を数えるタスクに強制的に戻してください。これを繰り返すことで、自分の注意をコントロールできるようになります。しかしながら、これはたくさんの練習を要します。今日明日では身につけられません。日々の練習が必須です。 このハンドラーが装着できると、自分の感情の変化もフックできます。

マインドフルネスの3要素

上記のようなことが全てワークしていくと、下記のマインドフルネスの3要素が満たせてきます。

• 感情の制御
  I am angry　ではなく　I feel angry　
• 注意のコントロール
  退屈な刺激に注意を向ける
• メタ認知
  注意への注意

簡単に以上がマインドフルネス入門編でした。お昼休みにでもやると午後はスッキリまちがいなし！

あとデザインさえあれば・・・を若干のお金で解決する #OSS #docker #99designs #startup

エンジニアとしてサービスを作ってる時にどうしても行き詰まるのが、デザイン。
仮に、それがデザイナーと組んでチームとしてやっているときは良いのだけど、エンジニアの自分だけでやっているような場合特に困る。 Webサービスを作るのであれば、最近はTwitterBootstrap等を使えば、それっぽく見えるようになってきたし、また、iOSに関しては標準のUIKitのデザインでまあまあ綺麗。プロダクトとしてもMVPは達成できると思う。Androidに至ってもかつてはデフォルトだとなにこれ感がつよいUIだったけど、最近はよくなってきているし、**Bootstrap系なデザインライブラリを使えばそこそこ綺麗につくれる。その上で、残る課題がアイコン。ロゴ。 OSSをGithubで公開しているような方の場合は、ソースコード自身がプロダクトのため、デザインは不要かもしれないけど、やはりロゴ。ロゴが欲しくなると思います。

いけてるサービスやOSSってみんなロゴかっこいいですよね！！！

クラウドソーシングでロゴデザインを調達
最近は、デザイナー不在プロジェクトで、クラウドソーシングでデザイン調達をするケースが増えてきています。例えば、下記のDocker、AngularJS、Norikra、Embulk、Spark、Kafkaなどの有名OSSおよびStackoverflow（最近デザインの微調整はいりましたが・・）はどれも
99designs.jp
というデザイン特化のクラウドソーシングサービスでデザインされています。
99designsでは世界中の100万人のデザイナーがコンペ形式で応募してくれます。

どんな感じかというと、コンペ形式でコンペが開催されており、世界中のデザイナーからデザイン案が応募され、その中から優勝者をきめてその優勝者にお金を支払うという仕組みです。（最低2万円台くらいで出来る）

例えば、Dockerのコンテストの結果ページを覗いてみると・・・・。
99designs.jp
優勝作品はお馴染みのクジラ＆コンテナのロゴですが。

ほかがキリンｗｗｗｗ

Slackoverflowはこんな感じ。
99designs.jp

Embulkはこんなかんじ。
99designs.jp

Norikra
99designs.jp

Apache Spark
99designs.jp

Lift（Scala）
99designs.jp

Kafka
99designs.jp

Finagle（Scala）
99designs.jp

AngularJS
99designs.jp

PostgreSQL Studio
99designs.jp

全体的に質が高いですねー。普通に見てて面白い。
日本では、デザインが可能なクラウドソーシングとして、クラウドワークスやランサーズがありますが、登録しているデザイナーがどうしても日本人デザイナーであるため、最初から国境を超えていくようなエンジニアのOSSのようなデザインには99designsのような海外（の感性がある）デザイナーにデザインしてもらうのがよいかなと思ったりします。

自分のOSSにロゴが欲しい方、是非使ってみてはいかがでしょうか。

Developers Summit 2015とDevelopers Summit 2015 Summerで発表してきました #devsumi #natsumi

もう数ヶ月前のことですが・・・、Developers Summit 2015で発表してきました。 そして、先日のDevelopers Summit 2015 Summerにて発表＆表彰をして頂きました。

デベロッパーズサミットというと数年前の自分からしたら神々がそれぞれのマサカリでもって斬り合いする天下一武道会みたいなもので、まさか自分が登壇することになるとは（しかも2回も連続で）夢にも思っていませんでした。 今でも想像するだけで脇に変な汗かくくらい鮮明に覚えていますが、この壇上から300人くらいの方々に話すというUXはとてつもなかったです。高校時代はバンドをやっていましたが、人の前で演奏しているときの感覚とすごく近い体験でした。色々なコミュニティの勉強会で登壇させていただくことはありましたが、それらとは全くの別物でした。程よい緊張感と楽しさが同居する感じ。もうそんな機会はないと思いますが、何か話せるネタを作ってまたダメもとで応募させていただこうと思います（2年連続とかでは登壇出来ないルールぽいけどｗ）

はじまるよー！ #devsumi #devsumiB pic.twitter.com/XFocsSeeUa

— Itsuki KURODA (@i2key) 2015, 2月 20

デブサミ当日は、エンジニアの大先輩(当時入社面接してもらた)の @kawanetさんや、前職の上司、先輩、同僚、大学時代の友人、勉強会コミュニティで知り合った方々、知り合いたくさんがきてくださりとても精神的にリラックスして発表することが出来ました。ありがとうございました!!!

#devsumi @i2key すごくいいトークだったわー。みんな笑って、パシャパシャ写真撮って、スライドをガン見して、うんうん頷いてたわー。 pic.twitter.com/dRDxR2JKHU

— Yusuke Kawasaki (@kawanet) 2015, 2月 20

そのときのスライドがコチラです。

社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について45分拡大版 #devsumi #devsumiB from Itsuki Kuroda

www.slideshare.net

夕方のセッションで早朝のセッションよりも参加率が高く、また、業務を早めに切り上げてこられる方がちょうど参加できる枠であった（と思われる）ため、また、あえて共感を頂きやすいような言い回しをしたりして、、、会場票をたまたま多く頂くことが出来まして・・・、その結果、まさかの賞を頂くことができました。色々な偶然のファネルが積み重なった上なのだと思いますが、ありがとうございました。 codezine.jp

そして、昨日、7月29日のDevelopers Summit 2015 Summerにて、受賞者枠？で、もう一度登壇させていただく機会をいただきました。 当日は、ドレスコードは無しと書いてあったので、気楽にいつもどおりの格好で、半袖短パンでいったところ、スーツな方々がほとんどで、TPO力の低さを露呈してしましました。

わいスーツ大勢の中で、短パン半袖。

— Itsuki KURODA (@i2key) 2015, 7月 29

ベストスピーカー様（@i2key）が短パンwww Developers Summit 2015 Summer [Enterprise] デブサミアワード2015冬・あの人気セッションの再演＆アワード表彰式 #natsumi http://t.co/t5prSlD7PZ

— すぎい まさかつ (@sugiim) 2015, 7月 29

受賞者枠として頂いた時間が約20分であり、前回の160枚のスライドを短縮で発表することが出来そうになかったので、別の発表をさせていただきました。 （スライド内では、小さく検証しろとか、MVPつくれとか言う割に、こと自分事になると肥大化したスライドしか作れないという・・・・）

エンジニアが成長のエンジンになる日 #devsumi #natsumiC7 from Itsuki Kuroda

www.slideshare.net

授賞式の際に簡単にはお話させていただきましたが、一貫して伝えたかったことは、実際に現場でものを作っている人が一番偉いとされるようなチームを作りたかった。これにつきます。 今後もエンジニアが輝けるような場を作るために精進していきたいと思います。

関係各所の皆々様に素晴らしい機会を沢山いただけたことに感謝します。ありがとうございました。