読者です 読者をやめる 読者になる 読者になる

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

Agile Scrum

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

そんなお話をした。

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

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

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

Leanstartup startup

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

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はファウンダーがそのプロダクトをよく使う層という状態を言う。起業家がマーケットにフィットしているか、プロダクトにフィットしているかは、2つの側面において重要だ。たとえば上図の起業家がそれぞれ「パーソナルコンピューターを作る」となった場合にどうなるだろうか。

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

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

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

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

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

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

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

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

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

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

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

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

狩野モデル

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

参考 :

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

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

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

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

16. 性能競争パターン

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

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

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

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

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

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

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

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

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

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

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

まとめ

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

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

マインドフルネス

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

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

  • 調身
  • 調息
  • 調心

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

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

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

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

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

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

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

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

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

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

試しにやってみよう

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

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

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

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

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

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

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

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

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

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

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

startup oss

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

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

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

f:id:i2key:20150918170632p:plain

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

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

ほかがキリンwwww
f:id:i2key:20150918171649p:plain

Slackoverflowはこんな感じ。
99designs.jp
f:id:i2key:20150918172054p:plain:w300
f:id:i2key:20150918172107p:plain

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

Agile Leanstartup Scrum 勉強会

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

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

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

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

www.slideshare.net

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

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

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

www.slideshare.net

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

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

「Devlove現場甲子園2014 日本シリーズ編」で発表してきた。 #devlove

Leanstartup Agile Scrum

先日開催されましたDevLOVE現場甲子園2014 日本シリーズ編 〜東西開発現場の集結〜 - DevLOVE | Doorkeeperで発表させて頂きました。 会場でのMVP投票にて1位と2票差で2位でした。投票して下さった方々、本当にありがとうございました!

発表資料をはっつけておきます。

あと、補足で社内でリーンスタートアップについて説明する機会が最近多いのでそのために作った資料ものっけときます。

リーンスタートアップ概論

ZapierでSlackを佐野ひなこちゃんで埋め尽くす #apijp

API

本ポストは下記のアドベントカレンダー13日の記事になります。

Web API Advent Calendar 2014 - Adventar

ところでみなさん、Zapierってご存知でしょうか?

The best apps. Better together. - Zapier

一部界隈では便利ツールとして凄く有名ですが、ご存知ではないかたのために簡単に説明いたします。 APIAPIをコーディング無しで連携させることが出来るハブサービスになります。 Yahoo PipesとかIFTTTのようなイメージです。 ただ、連携可能なサービスがものすごく多く、300以上あります。SlackやTwitterInstagramFacebook、JIRA、Trello等有名どころは大抵連携できます。 Twitterでファボッたツイートを自動的にインスタペーパーに登録したりとか、そういう連携です。 あとはWebhookも出来るので、例えばTwitterで「パイルダーオン!」とツイートするとそれがCIサーバとWebhookで連動し、ビルドが開始するとか出来ます。

ということでやってみた。

左がインプットでそれを右のサービスで何かをするという構造です。プルダウンで対応している各種サービスが出て来ます。今回でいうとインプットがInstagramで、それのアウトプットがSlackになります。

f:id:i2key:20141212181509p:plain

f:id:i2key:20141212181528p:plain

それぞれ各サービスの認証を行います。

f:id:i2key:20141212181557p:plain

Instagram側のSearch条件の設定をします。今回はハッシュタグで #佐野ひなこ に該当するものとしました。やろうと思えばもっと細かく設定できます。どれくらいかというと、InstagramREST APIの戻り値であれば何でも条件にすることが出来ます。

f:id:i2key:20141212181654p:plain

次に出力先であるSlackへの投稿設定を行います。ここでは Slackの #test というチャンネルに投稿するようにしています。また、前述しましたが、InstagramREST APIで取得可能な値であば何でも入力アシストで候補にしてくれます。凄く便利。これ対応しているサービス300個くらいすべてこういう用な入力補完があります。Slackへの出力値として、「スタンダード解像度の画像のURL」を指定しています。

f:id:i2key:20141212181628p:plain

下記が便利な入力補完になります。

f:id:i2key:20141212181642p:plain

これで設定完了。実行すると!!!!!

佐野ひなこちゃんきたああああああああああああああああああああああああああああああああああああ!!! かわいいいいいいいいいいいいいいいいいいいいいいい

f:id:i2key:20141212181709p:plain

これでInstagramの #佐野ひなこ ハッシュタグに投稿がされるたびにSlackにひなこちゃんが流れてきます。 はかどるわああああああああああああああああああああ。

便利な時代になりましたねー。