あなたのプロダクトにブロックチェーンを使うべきか?

いままでアドバイザーの星野さんとの議論をしていろいろ考えた結果、僕らのサービス「Liberapp」ではブロックチェーン技術を利用すべきではないと判断しました。 また、ブロックチェーンはおおきな可能性を秘めた技術ですが、ゲーム分野においては基本的にブロックチェーン技術は不要であると考えています。

こちらのDo you need a blockchain?記事を参考にしてみると

  1. 履歴は保存されるべきか?→ No :ゲームの場合は、ゲームプレイやにおいては、過去のロールバックできることは基本ゲーム性を損なう。
  2. 複数のライターはいるか?→ No: ゲームとはクリエイターが作ったルールの中、操作と反応を楽しむもので、複数のライターは不要である。
  3. 常時オンラインのTTP→ Yes:ゲームプレイを成り立たせるためには、ルールをつかさどるものが必要になる。

この記事のブロックチェーン技術を利用するディスジョンツリーをもとにしてもブロックチェーンとゲームはとても相性が悪い。

なお上の記事上の記事はこちらで翻訳してみました。 f:id:motoyasu-yamada:20181112111735p:plain

ご活用どうぞ

旅を楽しくするスマートガイドについて考えてみた

海外・国内問わずに旅行に行くのが好きです。パッケージで旅行することはほとんどなく、自分で飛行機・ホテルを手配し、可能な限りレンタカーを借りて自分で回ります。

一人旅の場合はホテルは一泊目だけ事前に予約。前の日のお昼ぐらいに、次の日の宿泊地とメインの訪問地を、TripAdvisorやGoogle Mapで決めます。その後、現在の宿泊地と、次の日の目的地をつなぐルートで、朝ご飯やランチの店を、YelpやGoogleMapで検索して決め、そのルートの途中で面白そうな観光地を追加で見繕います。

ですので、日の出とともにレンタカーで出発して、日の入りとともに宿泊地へ到着する。また、移動距離は500km~1500km/日くらいはざらで、訪問場所4~6か所/日みたいな感じになります。

時間がタイトなので、各訪問地でガイドツアーを申し込むことは難しいのです。

ですので、もしオーディオガイドがありそれを借りれれば、訪問地の歴史など詳しく知れて、旅の楽しさが倍増します。

ただオーディオガイドは、 1. 英語しかないことがある 2. 借りるのにパスポートを預ける 3. 帰った後に聞くことができない

ここらへんが改善できるスマホ版のオーディオガイドがないかなと思って調べてみました。

The Best Way to See a City? Audio Guides

まずGEAR PATROLさんのThe Best Way to See a City? Audio Guidesを読んでみました。

この記事の趣旨は下記のようです。

地球の歩き方とかTripAdvisorのようなガイドブックは、観光客が訪問場所を見つけるもの。 コミュニケーションを通じて地元の人だけが知る隠れスポットへ行くことがもっとも価値がある。

僕が考える「ツアーガイド」さんを「スマート化」とは違います。

確かにいわゆる観光地が面白くないというのは理解できなくはないですが、東京に来た時に、浅草・秋葉原・新宿・渋谷に行かずに、いきなりマニアックな場所に連れて行って喜ぶでしょうか? ニューヨークに行って、彼女を自由の女神タイムズスクエアに連れて行かなかったらどうなるでしょうか?もしくは日本に帰ってきて話が盛り上がるでしょうか?

何度も同じ場所を訪問する人は、もっと地元の人と交流したいとか、隠れスポットに行きたいというニーズはあると思います。 しかしながら大多数の人はそうではないと思います。

Detour

ステイケーション(遠出せずに自宅にいるか、近場で日帰り旅行をして過ごす休暇)に最適なアプリ。

いけてるなと思ったところは 1. GPSで視線のむきにあわせて音声がかわる (室内ではどうだろう?) 2. グループツアーむけに複数のデバイス間で同期可能

オーディオガイドは、バスの中から「右手には富士山・・・」みたいな使い方もいいですが、 美術館のようなところで、各絵画ごとの音声案内されるのが一番嬉しいから、視線は厳しい気がする。

Just Ahead

車の長旅(ロードトリップ)におすすめのアプリ

GPSを使って、ある場所に近づいたら音声が流れるアプリ。バスガイドさんの「右手に見えますのは~」のアプリ版ですね。

このアプリ欲しいかも。車で運転してるときに「あれなんだ?!」みたいに気になることが多い。運転しながら、地図調べたり、Wikipedia調べたりするわけにもいかずに通り過ぎちゃうことある。後で調べてみたら、むちゃくちゃ面白そうなスポットだったりするとむちゃくちゃ悲しくなる。

TripScout

地元の人のように都市を観光するためのアプリ

メインストリートとサイドストリートの両方を案内してくれて、レストランや店をおすすめしてくれる。次来た時に行きたい場所にフラグを立てられる。

いいところ

  1. GPSベースでオーディオガイドされる
  2. オーディオはオフラインでも再生可能

ルートの案内はいらないかな。歩いて見つけたレストランのチェックだったら、GoogleとかYelpの口コミ観ればいい。 レストラン探すために、アプリを使っていろいろ歩かされるより、事前にピンポイントで調べたい。

次行きたい場所のフラグは、GoogleとかTripAdvisorとかYelp(国内なら食べログ)でいいや。

Rick Steves Audio Europe

旧来のツーリスト向けにおすすめのアプリ。Rick Steveさんという旅の専門家がガイドしてくれるアプリ。

テレビやラジオの何十年もの経験から作られている。街歩き、ミュージアムツアー、地元の人へのインタビューなどが収められていて、いまでも収録数は増えているようです。

GPSや地図連動などのスマートなテクノロジーはないようで、いわゆる「紙の本」のオーディオ版みたいなものかも。

こういう熱いコンテンツをスマート化したらよさげ。

UGCとか技術ありきよりコンテンツありきならいけそう。

メンバーをを把握することが重要 - 自分用の1 on 1 のマニュアルモ

プロジェクトメンバーのことをしっかり理解するためには、「定期的に1on1をすることが大事」だと、ちょっと前に友だちから教えてもらいました。

まずは、ススめられた「ヤフーの1on1―――部下を成長させるコミュニケーションの技法 」を読みました。

https://www.amazon.co.jp/dp/4478069786/ref=cm_sw_r_cp_api_W6IRBbJ9SCBWW

その後に1on1をススめていただいた友だちにメンターしてもらいながら、自分用の1on1マニュアルをまとめました。

① 1on1のテーマ

「プロジェクトを成功させるために、経験から学ぶことで、才能を伸ばしてもらい、情熱を解き放ってもらいたい。そのために、現場で今起きていることを話してもらいたい。」

② ルール

・1on1の実施は1on1のコンテキストでやる。それ以外の目標や戦略の伝達、目標と実績の乖離、行動規範や品質や生産性上の問題点の指摘は、別なコミュニケーション体で行う。

・基本コーチング。明確に答えがあるものだけティーチング。フィードバックは、上司視点評価や意見ではなくカメラや鏡のような視点で、部下がどう見えるのかを返す。

・1on1は二週に一回一時間を目安に。木曜日の午後早めに実施する

スクリプト

「さて今日は何を話そうか?」

(深掘り)「〜について、もう少し詳しく話してください」 (アクションを引き出す)「〜はどうする?」 (無理やりになりそうなら)「今決めなくてもいいけど、どうしたい?考える時間おいてみる?」 「いつまでに答えが出せそう?」 「わかった。じゃあまた○日にきかせて」

(手段の引き出し) 「では、どうやって進めようか?」 「そのために僕にしてもらいたいことは何ですか?」

(コミットの引き出し)「いつまでにやろうか?」 「いつでも困ったことあったら声をかけてください。また、終わったら教えてください。」

ガチプログラマーがリファクタリンしたときに感じたWordpressでコーディングする際の注意点

最近、既存のWordpressを修正する機会がありました。デザインは崩れているし、ソースコードを触るのは辛い状態だったので、大幅にリライトしてリファクタリングしました。テーマを既存のテーマAffingerに切り替えて、機能を実装するために本当に必要な最小限のソースコードに書き換えた結果、メンテナンス対象のソースコード量は一桁どころから二桁ぐらい減らせた印象です。

いままでちゃんと技術的な品質の管理や指導をしていなかったと反省です。

せっかくいろいろいじったので、ガチプログラマーがリファクタリンしたときに感じた、Wordpressでコーディングする際の注意点をまとめてみました。

既存のテーマをベースにするなら既存のテーマの思想や機能を活かして必要最低限の実装をする。

フルスクラッチでWebサイトを制作する時のように、理想ベースでワイヤーフレーム、カンプを作って、開発・制作に入るならば、Wordpressのテンプレート階層などをしっかり理解して、必要十分にフルスクラッチでテーマを独自実装したほうがいいと思っています。

しかしながら本当に自分たちが作りたいWebサイトにそこまでのオリジナリティーが必要かどうかは立ち止まって考えたほうがいいです。既存のテーマを活かせば、多少独自機能をいれても数日でも終わってそこそこの見栄えになります。しかしながらフルスクラッチで書けば、しっかりやらないとデザインは残念になりますし、工数も数倍以上に膨れ上がる可能性があります。

また逆に、Stingerなどの既存のテーマを利用しているのに、既存のテーマの思想や機能を活かさずに開発や制作すると、思ったように動かすのに逆に既存のテーマの実装が足かせになって大変になります。既存のテーマを使うならば、既存のテーマの思想や機能を熟知して、どこまでカスタマイズできるかをしっかり把握すること。そのうえでそれを活かした自分たちのサイトの設計をすることが大事です。

子テーマを使う

これはやってあたりまえの話です。カスタム投稿タイプやタクソノミーなどを活用して独自機能を実装する場合は、どうしてもテーマのテンプレートファイル等のPHPファイルのカスタマイズが必要になります。

ここで絶対やってはいけないのが親テーマそのものの修正です。既存テーマは多機能なので当然コード量も多い。そこを直接様々な個所をいじるとメンテナンス対象のコード量が爆増します。また、既存テーマがアップデートされた際に、それを取り込むのが難しくなります。

子テーマを使えば、独自実装部分が明確にわかるし、また独自実装の範囲が狭くなるので、把握しなくてはいけないメンテナンス対象のコード量が劇的に減ります。

ExePHPは使わずにショートコードを使う。

これも常識の範囲の話で、とにかく ExePHPは絶対に使用しちゃダメ。プログラムを記載する部分は、ショートコードなどを使いCMSから書くコンテンツから必ず切り離して、プログラム部分はGitで管理できるようにしましょう。

テンププレートにロジックを記載しない

テンプレートには、可能な限り条件分岐などのロジックを記載しないのがベストです。例えば、新着フラグを表示したいようなケースで、下記のような記述をテンプレートに直接書くのはやめましょう。

template.php

<?php
    if (date('U', (date_i18n('U') - get_the_time('U'))) < 24 * 3600 ){
       echo '<span class="newlavel">New</span>';
    }
?>
<h2><?php the_title();?></h2>

こういった場合は、独自テンプレートタグを実装して、テンプレートは <?php the_xxx(); ?> のようなテンプレートタグを呼び出すコードを記載する。そして、functions.phpなどに独自テンプレートタグ関数を用意して、テンプレートからロジックを分離しましょう。

template.php

<?php the_new(24);?><h2><?php the_title();?></h2>

functions.php

function the_new($hour) {
    if (date('U', (date_i18n('U') - get_the_time('U'))) < 24 * 3600 ){
       echo '<span class="newlavel">New</span>';
    }
}

ショートコードの実装関数や独自テンプレートタグ関数にロジックとHTMLが混在させない

さっきの例は下記のようにするとむちゃくちゃメンテナンス性があがります。

functions.php

function the_new($hour) {
    if (date('U', (date_i18n('U') - get_the_time('U'))) < $hour * 3600 ){
       get_template_part('partials/new-labe.php');
    }
}

partials/new-label.php

<span class="newlavel">New</span>

ショートコードでも関数内にHTMLを直書きしないでget_template_partで外だししましょう。

空の固定ページ&テンプレートでHTML実装をやめる

例えばslugがhogeな空記事の固定ページを作成して、固定ページ用テンプレートpage-hoge.phpを用意して、すべてHTMLに直書きをするのは避けたいです。

絶対にダメなわけではありませんが、運用中に文章の変更などが、簡単にできなくなります。

こういう場合は、固定ページの記事に、エディターを使って静的な記述を行うこと。どうしても必要な動的な記述はショートコードに分離したほうがいいです。

ICCプレイベント「最高の成果を生み出すリーダーシップとチームマネジメントとは何か?」からの学び

今日はICCのプレイベントに参加してきました。IVS/ICCはもう五年ぶりくらいでしたが、小林さんのポストを日々見てる中での参加だっだので、とても面白かったです。

パネルディスカッションのテーマは、「最高の成果を生み出すリーダーシップとチームマネジメントとは何か?」ということでした。

最初の問いかけリーダの仕事の定義については、山田流では、「チームを作り、メンバーを集め、自走させて、結果を出す」です。

ここからは、パネルディスカッションを聞いてのメモなどです。

会社もコミュニティの1つ

コミュニティマーケティングの理論では、活性化していくコミュニティは高い継続率とあわせて一定量の新規参加率が必要だということでした。つまり会社には常に新規率が必要で、フィロソフィーにあわないメンバーの卒業と、さまざまなタレント性を持つ新規メンバーの加入が必要なのでしょう。

内村鑑三とジャックマー

リーダーが残すべきものは、金、事業、哲学・思想。もし、哲学・思想まで至らなくても、生き様を発信する、残していく。

そして生き様を発信して、愛される人になる、自分が愛するモノやチームを愛してもらえる人になる、そして相手が自分と話すと相手が本人自身を愛するようになる。

スポーツと仕事

よく仕事には、試合と練習がないから、スポーツのようにはうまくいかないとという人もいるが、あえて仕事も、勝負所(試合)と練習は自分で定義づけして、やればいい。

コーチの要件定義

プロフェッショナル、インターパーソナル、イントラパーソナル、ビジョンとフィロソフィー

思想とは

思想とはビヘイビア・スタンダートのこと。また優先順位をつけること。量か質か。即断か熟慮か。

ディシジョンメーキング

調子いい時ほど、交代の判断が鈍る。危機なほど、勇気を持って判断できる。

ディシジョンメークのトレーニングは、平常、緊急時用の2つが必要。

第1期解散と第2期スタート!

五月末に、チームメンバと話して、「いったん今のLiberappのチームは解散する、全てを白紙に戻しゼロベースで新しいLiberappを考え直す」と伝えました。

そのあと二週間は開発を中断して、チームメンバーと、ミッション・ビジョンについて、どのように実現すべきか、価値観や行動基準を元に自走していくことについて、考えてもらい話しあいました。

その結果としては、チームはいったん解散する。最初のゼロイチは、自分がフルコミットすることにしました。

背景

私は、ビジョンを掲げ、戦略(マイルストーンの決定とリソースの調達)の立案と実行が重要な仕事だと定義していました。また、現場のメンバーは、バイアブルでセクシーなプロダクトを作ることがこの半年のマイルストーンでした。

現時点では、僕は役員報酬ゼロですが、メンバーはスタートアップとしては高待遇で、半年で全資本金を使い切るバーンレートでした。そのため、六月末が重要なタイミングでした。しかし、私の直感では、六月末(多少遅れたとしても)に、資金調達ができるセクシーMVPプロダクトができる気がしないと感じていました。

最低でもセクシーなプロダクトがないと、シード期の資金調達は不可能。基本はモノがないと無理だと考えています。もちろん、シリアルな起業なので、プロダクトがなくても、個人の信頼である程度のお金を集められる、自分でも投資できます。

しかしながら、過去の経験から、何がが壊れていてイメージ通りに動かさなすぎる時、特にアウトカム(数値)ではなくて、アウトプット(成果物)やチームに問題がある時には、勇気を持っていったん撤退してから、再度進む方がいいと思っています。

お金の力はレバレッジの力なので、うまくいかない時に、お金を集めると、「うまくいかない」ことにレバレッジがかかり、メチャクチャな結果が待っています。

そのために、まずはいったん解散とゼロベースで考える宣言をして、メンバーととことん話し合いました。その結果、最終的に第1期は終了としました。

これから

チームメンバーと一緒に半年働けたことは大変感謝しています。ミッション・ビジョンには共感してくれていたことは確かです。価値観や行動規範の変化には、すぐに適応できていなかったものの、時間の問題であり、スタートアップではなく、数年待てるような環境であれば、適応できたいたはずです。

また数年後に環境が変われば、再結成しようと話して、Liberapp第1期のチームは解散して、第2期に移ります。

今日はLiberapp最後の懇親会兼送別会でした!

過去の振り返り

このような問題起きた表面的な理由は、 昨年末まで約20年弱経営してきて、中小企業状態とはいえ事業が成り立っていたスパイシーソフトから、完全なスタートアップであるLiberappに、メンバーをあっさり連れていったことです、

スパイシーソフト前期では自分が経営者として未熟であるがゆえにアグレッシブにデマンドフルでした。逆に後期は反動で、自分の仕事のやり方や、価値観に妥協が多かったと反省しています。

Liberappでは、スパイシーソフトとは全く異なり、自分のミッションビジョンを明確に、そこに向けて価値観や行動基準を軸に自走するチームにしたいと経営してきました。

しかしながら、中小企業からスタートアップへの環境変化、経営者のマインドの大きな変化に対して、ちゃんとメンバーがついてこれるように、ナビゲーションしてこれたとは言えません。もちろん、メンバーもついてくる馬力や、スタートアップとしての覚悟が十分であったとは言えないと思います。

役割分担がぶれていた

ます、チームメンバー全員が、ミッション・ビジョンを達成する当事者であるという、根本的な役割分担があります。

その上で、CEOは「どこへ行くか誰をバスに乗せるか」を意思決定する役割。CxOは「どうやってそこへ行くか」を意思決定する役割だと考えています。

まず、このフェーズにいるメンバーに、しっかりCxO的な役割を与えなかったこと。

それもあるし、今までの手癖で、メンバーが「どのように」が自分達の役割でないと思っていた、もしくは「どのようにしたら」を考える癖がない、考えて行動する技術がない状況でした。

価値観がぶれていた

社長は価値観「どういう仕事での行動が嫌なのか」をはっきり掲げて、そこを妥協しないことが大事なのですが、チームの中ではそこへの反感は持たれていませんでしたし、傍観者的な共感はありました。しかしながら主体者として行動がありませんでした。

私が大事にしていたことは、「やらない後悔よりやって改善・見逃し三振はナシ空振り三振はオッケー」、「ミッションビジョンの達成のためであれば、価値観や行動基準をもとに、どんどん自走する」「おかしいことはすぐに声を上げる」の3つです。

ここの不一致は私自身がストレスフルでありましたが、それ以上にチーム間のコミュニケーションがうまくいかずに、プロダクトの品質や生産性の故障につながっていました。

今後に向けて

この半年で、開発や渉外を通じて、ミッションとビジョンは、クリアになりました。さらに、二十年間経営してきて、一度封印していた自分が大事にしている価値観が、昔と違ってスマートに蘇ってきました。

今回の学びで、よりマネージメントとしてさらに大事にしたいことは、2つです。

⑴ 社長は、チームメンバーに、ミッション・ビジョン・価値観・行動規範からの大きな問いかけを根気よく続ける。

話がぶれないように、マイクロな話にならないように、喋りたい気持ちを我慢する。メンバーが考える癖をつけるように、何度でも根気よく問いかけ続ける。

⑵ どんな小さな違和感でも速やかに、すぐにタンタンとフィードバックして、根気よく問いかけ続ける。

よろしくお願いします。

ブレない基準、MVPの定義、失敗は速やかに認める、故障は放置しない

一流の基準で成否の基準を持つ。

自分の今のスキルを基準にしない。結果が悪い時に基準をブラさない。基準とは速度計のようなもので、世の中の基準を目安にする。

生産性や品質の基準は全て、市場の勝ち組ができていることが基準になる。言い換えるとお客さまが支持するかしないかが基準。

今基準を達成できていなくても、過去達成できてなくても、基準はぶらさずに、達成できていないということを明確にすることが大事。

いまのスキルで基準の難しいと思うなら、達成するための分野や手順を10に分解してみる。そうすると大半は出来ることなので、すぐにやり始める。分解してもまだ難しい箇所は、さらに10に分解して取り組む。

成果物の価値から一日でできないといけない場合や、一日でできると見込んでいた場合に、想定外のことや、はまってしまったことで、一週間かかってしまった後に、「そういうもん」だと基準(ゴールポスト)を動かさない。基準とは、失敗したか成功したかを、見極めるためのもの。勇気を持ち失敗を受け入れることがまず大事。失敗を認められる人間だけが成長できる。

そして、想定外だったことをどう想定内として効率よく処理できるか、ハマってしまっことは、次はどうしたらはまらないか、考えること。もし難しかったら、10分割なりをしっかりして、一つづつ取り組む。

MVPの定義

・MVPとは、一つの仮説を検証するための、もっとも小さな、もっともセクシーな成果物を作ること。仮説のないアイデアでいろいろ粗雑にたくさん作ることではない。

失敗するのは勇気のあるカッコいいこと

・失敗は早ければ早いほどいい。だから、小さいサイクルでプロダクトは、顧客に短いサイクルで価値を提供して、仮説を検証したい。

さらにリリースのサイクルよりももっと小さく、失敗は早めにした方がいい。間違っている・壊れているものを放置すると、疲弊する。失敗とは、「間違っていると分かったら間違っていると認めること」「基準に達成していないことを認めること」。つまり、失敗するのは勇気がいるかっこいいこと。自分たちの過ちを速やかに認められることだから。

疲弊が故障の原因ではなく、故障の放置が疲弊の原因。

故障だと分かっているものを放置し続けると心が病む。ゴミが散乱している部屋での生活を想像してみよう。

疲弊してるから故障を直せないのではない。故障をほうちするから疲弊する。もちろん疲弊すればさらに故障は放置される。

常に故障は放置しない。気合いを入れてクリーンな状態を保つことが、心の健全さを保ちやる気を養う。