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

ゆーすけべー日記

はてなBlogってどーなの!?

とある技術顧問のお仕事

トラベルブックの技術顧問となって1年以上が経った。今ではそれに加え、ブレイブソフトHIROKENと合計3社の顧問をやっている。僕が元から持っているオモロキでの「ボケてのバックエンド開発」は継続しつつの顧問業務である。最初は「しんどいかな?」とか「ほんとに俺でいいの?」と感じるところがあったが、今では試行錯誤しつつも機動に乗ってきたところがあり、仕事としての実感も出てきている。ということでバスワード気味に浸透している「技術顧問」というお仕事の実態について、他の顧問さんと違いがある前提で、僕のケースを紹介してみたい。

誰から誘われたのか?など

まず最初に「技術顧問は誰から依頼されるのか?」ってので、その会社に対する役割が変わってくる。大きくは2つのパターンがあるだろう。

  • CTOもしくは開発部長の立場の人
  • 社長や代表

トラベルブックの場合は当時、全社で10人にも満たない開発も一人だけのスタートアップであった(現在もインターン含めて20名弱程度)。以前から付き合いのあったCTOの高木くんから声をかけてもらったのである。

f:id:kamawada:20150303125800j:plain

また、ブレイブソフトの場合はボケての開発でも縁がある社長のえいちゃんから依頼をされた。技術顧問というだけあってサービスなりプロダクトの「制作」に対するアドバイスをするわけだが「誰から声をかけられたか?」によって、その性質は若干異なる。

f:id:kamawada:20160406190233j:plain

特徴的なのは社長から声をかけられたブレイブソフトで、技術チームとの打合せや勉強会以外に、えいちゃん本人との話し合いの時間を別途用意したり、採用にまつわるブランディングなども役割として課せられる。またHIROKENでも社長経由であり、技術的な事柄の関わりは少ないという前提なので、新規事業の企画会議の進行補助なども行った。このように誘ってくれる人が、技術系か?経営寄りの人から?によって、業務の比重が変わってくるのは確かだと思う 。

と、もうこの時点で技術顧問は「技術関係ない場合が多い」「各社やることバラバラ」という結論が見えて来ているが続けよう。

ちなみに、顧問として、条件にもよるが、僕の場合は月に2〜3回の訪問を目指している。これもわりとケースバイケースで、議題がホットな時期は毎週通ったりしていた。SlackやGitHubなどのオンラインツールで済むこともあるだろうが、実際に足を運ばないと温度感が分からないし、自分も仕事をしているという実感が沸かないので、このスタイルは崩さないようにしたい。

その役割

もうお分かりかもしれないが、技術顧問の役割は「技術を伝授する」だけに留まらず多岐に渡る。今でこそ技術的な話題が多くなってきたトラベルブックであるが、当初はサービスとしての意識がチーム全体でつくれていない状態だったので、そのサービスの「哲学とは何か?」「どんな可能性がある?」「じゃ最終的に何がしたい?」といったことを話し合う打合せのファシリテーションをしたのが思い出深い。

f:id:kamawada:20150224154815j:plain

このように事業のステージや会社規模によっても役割が変わってくるので、その辺りは柔軟に対処していきたいと思う。

さて本筋とされそうな技術的要素においてのロールについて。これについて求められている事を一言でいうと「技術選択への不安を払拭したい」となるだろう。エンジニアなら誰しも経験があるだろうけれど「こういうことしたいんだけど、このライブラリでいいのかな?」といった類いの迷いに対してのアドバイスをする、という形である。ただし、顧問の場合、特に言語固有のライブラリ選択にまではあまり口を出さず、サービスのアーキテクチャや環境構築などといった大きな括りについて方向性を示すことが多い。

例えば、要件として頻繁なテーマはいわゆる「Infrastructure as Code」について。僕はAnsibleをオーケストレーションやデプロイに使っているので「例えばこれ使うと簡単だよ〜」なんてアドバイスを実例を交えながらesa.ioにまとめつつ、その資料を使って勉強会をしたりした。

f:id:kamawada:20160412104616p:plain

また、参照実装と呼んでいる「ロジックとして」参考になるコードをサクッと書いて「これでどう?」なんてやりとりもたまに起こる。

僕の場合は経験もあるだろうが、周りに優秀で中には大規模をやっているエンジニアがたくさんいるので、そこからの情報をキャッチ出来る立場である。それを利用して出来るアドバイスもあるかな〜なんて思っています。また、OSSのソフトウェアは以前から覗いていて、こうした「外の世界」をあまり知らない人達に対して、OSSの紹介や実装を教えつつも外を見ることを習慣付ける心がけをしている。

注意したいのは顧問は「答えを出しちゃいけない」ということだ。つい、議論が白熱して「俺の考えが正しいぞ」となることもあるが、それを強要しちゃいけない。顧問である以上、それに対して責任を負えない。「選択肢を広げる」または逆に「選択肢を狭める」ことをアドバイスしながら、答えを自ら出させるのが仕事だと思っている。

チームビルディングへの貢献

以前、こうした顧問業以外に、大手コンサルティングファームの子会社の技術研修を外部講師として社内勉強会を担当したことがあった。その際に、良かったなと思ったことが印象深い。とある製品を子会社含めて3社合同で開発していたのだが、その3社のエンジニアが一同に会することがあまりなかったらしく、僕が担当する勉強会という存在が珍しいものだった。すると、顔が見える場所で、やたら的を射た質問をしてくる方がいる。休憩中でも僕に積極的に絡んできてくれて「〜ってライブラリを家で使ってみましたよ」なんて言ってくれる。すると周りにエンジニアは「彼は出来る人なんだ」もしくは「彼は意識がある人なんだ」という認識が生まれてくる。これは開発が会社として3社に分かれているから、今まで見えてこなかったことだったかもしれない。結果、半年に及ぶ勉強会が終わる日にはみんなで仲良くピザパーティをし、質問をしてきた彼には「XXXの責任者やってくださいよ〜」なんて声もかかった。

このエピソードから実感したのは、外部として入ることの付加価値である。ウマく機能さえすれば、チームのメンバーが見える化するんだな、と。技術顧問も「あえて」社外の人間としてそのチームと関わる。いい感じに自分がキッカケになってチームのメンバーが仲良くなり、全体のパフォーマンスも上がると嬉しいし、そのことを心がけたい。

f:id:kamawada:20160412114145p:plain

複数社を見ることでの相乗効果

トラベルブック以外の2社は今年1月から関わっている。来社する手間は当然増えるわけだが、このように複数社を受け持つことによるメリットはだいぶあるなと実感している。簡単に言えば「A社とB社を見ていれば、A社で培ったノウハウを困っているB社で活かすことが出来る」といった効果である。各社の会社の守るべき価値はあるとして、相乗効果を狙える部分はWin-Winにしていきたいし、キャパの許す限り(とはいえ結構もう一杯なんだけど)技術顧問していくのはアリですね。

f:id:kamawada:20160412114641j:plain

技術顧問を出来る環境

僕がこうして技術顧問が出来るのも、代表を務めるワディットという会社があるからだし、オモロキもオフィスがなく成果主義だからである。仕事をある程度自由に選択出来る立場の人でないと技術顧問をするのは正直キツいな、とは思うもの、こうした環境はもっと広まってもいいと感じている。

まとめ

僕が今チャレンジしている技術顧問というお仕事について実態を語ってみました。「技術顧問」といえどこのように役割が多岐に渡るために、汎用的な言葉として「コンサルティング」という言葉を使った方がいいんじゃね?とは思いますが「響き」として技術顧問は気に入ってます。現在進行形でエンジニアだから、自分だから、出来ることはあると思うので、いい関係になれるように頑張っていきたいです!

各社勝手に宣伝

トラベルブック

旅行にまつわるいわゆるキュレーションメディアですが、全てオリジナル記事で質が高く、今後も旅行やお出かけをアシストしていきます。インターンのエンジニアを募集してます。

www.wantedly.com

ブレイブソフト

スマホアプリの開発会社です。ボケてのモバイルアプリもパートナーとしてつくってもらってます。

www.wantedly.com

HIROKEN

士業というリアルなところとつながりのある会社です。僕も関わっている新規事業が面白そうです。わくわく

hiroken-grp.co.jp

PS.

Podcastやってます!夫婦で聴いてる人達もいるらしいです!

www.wada.fm

SlideckっていうWebサービスをつくった

tl;dr

Slideckっていうエンジニア向けっぽいWebサービスをつくりました。できたてホヤホヤです。

slideck.io

GitHubのレポジトリに、とある簡単なフォーマットに従ったMarkdownのテキストファイルを置いとくと、 Slideckの機能を使ってオンラインでクールなスライドショーが表示出来ます。 ルールに従ったURLでアクセス出来るのでブラウザで開くことはもちろん、シェアすることも可能です。 皆さん使って下さいね。

追記

要望を早速もらったのでGistにも対応しました!

↓のGistファイルを...

/gist.github.com/{owner}/{id}/{filename} というパスでアクセスすれば...

スライドになりま〜す!これで気軽に試せるね!

モチベーション

reveal.jsのMarkdown編集機能を使ったスライド作成が、場合によりKeynoteやパワポより効率的で、 見栄えもカッコよくて好きです。好きがこうじてreveal.jsのラッパーツールであるApp::revealupやrevealgoと言ったプロダクトを自分でつくってきました。

これらは基本的に自分のPC上にプレビュー用のサーバーを立てる「ローカルホスト」のためのツール群です。 reveal.jsとMarkdownテキストを使ったスライドの表示がより手っ取り早くなるので自分でも重宝しています。

ところが、いざつくったMarkdownテキストをオンラインでシェアする場合に、わざわざサーバーを用意してHTMLでラップさせるという作業が面倒です。 後述するルールに則ったMarkdownテキストであれば自動的にreveal.jsを使ったスライドへコンバートして表示してくれるものを求めていたのです。

Slideck

そこで思いついたのがSlideckです。 godoc.orgに若干インスパイアされる形で考えました。 みんな大好きGitHubのレポジトリ上にスライドのMarkdownファイルを置いて、 そのパスを指定するとサーバーアプリがフェッチしてくれてスライドショーを描画する仕掛けです。 以下の様な特徴があります。

  • revealjs / revealgo との互換性
  • GitHubに置いた画像の埋め込みなどにも対応
  • privateレポのスライドを見たければGitHubログインすればOK、当人しか見れない
  • revealgoとは違いMarkdownを一度HTMLへ変換しXSS的にも安全

f:id:kamawada:20160318142707p:plain

ちなみにGolangで実装、ホスティングはHerokuで行いました。 思いついてモックアップが出来るのに一晩、デプロイまで含めると2日間というスピード開発です。

使い方

例えば、サンプルで用意しているドキュメントがあるので、それを元に紹介しましょう。

僕は先ほど、GitHubのpublicレポジトリgithub.com/yusukebe/slidesをつくってここにスライドのMarkdownファイルと画像などを置いてくことにしました。

この場合、ownerが「yusukebe」repoが「slides」となります。そして「sample.md」というpathに以下を書いたMarkdownがあります。 ---がスライドのページ区切り文字ですね。

# Title

Hi, my name is yusukebe.

---

## Lists

* List1
* List2
* List3

---

## Hello World


    package main

    import "fmt"

    func main() {
        fmt.Println("Hello World")
    }

---

## Image

![Slideck](images/slideck_ss.png)

---

Check out Slideck now!

<https://slideck.io/>

レポジトリ上のMarkdownをスライドとして描画するには、こちらのルールに従ったURLでSlideckにアクセスします。

https://slideck.io/github.com/{owner}/{repo}/{path}

今回の場合は下記URLです!

するとどうでしょう!GitHub上のリソースを勝手に取ってきてくれてreveal.jsを適応したスライドになるじゃありませんか!

f:id:kamawada:20160318145603p:plain

Slideckのトップページでは、フォームにリソースの場所を記載すれば勝手に飛んでくれるような機能があるので活用出来ますね。

まとめ

ということで、Markdownベースのスライド作成は捗るし、シェアしやすい仕組みをGitHubを利用しつつつくってみたので、使ってみてください!

slideck.io

今日これから行われるYokohama.(pm6?|go)ではデモを交えてSlideckの話をします〜

宣伝

Podcastやってます!ゆるい感じらしいです。聴いて下さい!

www.wada.fm

僕がプレゼンのスライドをつくる時に考えること

僕がひとり語りしているPodcast「wada.fm」の前回のエピソードでも話したんだけども、プレゼンテーションのスライドをどうつくるか?みたいな話。

f:id:kamawada:20160310110331p:plain

ちょいと最近とある方に

ゆっけさん(彼は僕のことをこう呼ぶ)のプレゼン資料いいよね〜

と褒められ、結果彼の会社のプレゼン資料的なのをつくるアドバイスをすることになった。まぁ確かに大抵プレゼンでつかうスライドは時間が許す限り、分かりやすく楽しいものにしようと心がけているのでそう言ってもらえて嬉しかったので調子に乗りつつ「自分がどうやってプレゼンの資料をつくっているか?」をまとめつつあります。本エントリーではその一環も兼ねて記事にします。

プレゼンの前提

スライドをつくる際にどのようなプレゼンの場で発表するための資料なのか?を把握しておくことは僕にとって重要です。まずどのツールを使って、どんなスライドを何枚用意しなくてはいけないかが決まってくるからで、それが定まらないと書き始めるモチベーションが生まれない。例えば、

  • それが勉強会なのか?カンファレンスと呼ばれる規模のものなのか?それともセミナーなのか?
  • 参加者もしくは聴講者の人数は?
  • その人達の属性はどんなもの?
  • 発表時間は何分か?
  • 場所はどんなところか?
  • テーマに縛りがあるかどうか?

あたりを発表する会合の主催者などに問い合わせて、プレゼンのための前提条件を確定する作業をよくしています。

f:id:kamawada:20150903213610j:plain

上記の事柄がハッキリすると経験上、自分が壇上で喋っている姿が想像出来るので後ほど紹介するストーリーテリングしていくことが出来ることになります。

スライド作成ツール

こうした発表する場の前提条件をクリアにした後は、何を使ってスライドをつくるか?といったツールを確定させます。といっても僕が使っているスライドツールは2つのみ

  • Keynote
  • reveal.js + Markdown

reveal.jsという名前が聞き慣れない方もいるかと思いますが、HTMLベースのプレゼンテーションツールで、ブラウザでスライドを表示させるとJavaScriptを使ったエフェクトでクールな描画をしてくれます。reveal.js自体のオフィシャルな紹介サイトもこのスライドで構成されているのでどんな見た目になるか?を確認出来ます。

lab.hakim.se

reveal.jsはMarkdownフォーマットでスライドの中身を記述出来るのがよくて、Keynoteと比べるとテキストベースのページを素早く作成したり、プログラミングコードを掲載するのに向いています。ただ、画像を載せたい時に微調整が難しいという課題があったりします。一方Keynoteで作成した場合、画像の細かい位置調整などは楽だし、PDFに「キレイに」書き出しが出来る=SlideShareやSpeaker Deckなどのスライド共有サイトでのシェアが容易ということもあって「後ほど見てもらう」ためにはコチラ、Keynoteの方が向いていたりします。

このようにツールによって振り不向きがあるので、プレゼンの前提条件に合わせ、

  • サクッとスライドをつくりたい場合やコードがたくさん出てくる時はreveal.js
  • 気合入れて、かつ後からリファレンスしてもらいたいような時はKeynote

というように使わけています。

構成する手順

さてツールが決まったらいよいよスライドを書き始めたいわけですが、その前にどんな構成にするかを考えて一旦寝かせます。その間には具体的にこんなことを考えます。

  • 話したいこと、分かってもらいたいことは何か?
  • プレゼンのオチをどこに持っていくか?
  • どういう順番で話していくか?
  • 書くスライドページのタイトルは何か?

大抵の場合、プレゼンの発表時間は「思っているよりも」短い場合が多いという感覚があります。なので、言いたいことを一つだけ決めてそれをオチとしてどうまとめるか?に注力して流れを妄想するしておくと書き出しがスムーズになったりしますね。

ジョブス流とパワポ式の中間を狙う

Appleの製品発表会のプレゼンテーションは素晴らしいのですが、アレ真似するの相当大変です。TEDでのプレゼンにも通ずるところがありますが、いわゆる「ジョブス流」のプレゼンは、スライドにはイメージや一言コピーだけ、あとは身振り手振りで聴衆を惹きつけるという手法です。カッコいいしウマくいけばウケはいいんだけれども... 綿密な練習が必要になって来ますし、スピーチの内容を予めつくらないと難しそうです。しかも後ほどそこで使ったスライドを見てもイメージが多いので「なんのこっちゃ」になりそうです。

一方で日本古来の習わし的なパワポを使った箇条書きの資料があります。昨今では「よろしくない」とされているのですが、一方では後ほど資料だけ見て「振り返るため」のものとしては機能しそうです。が、やはり、文字が多くてそれを読み上げるだけのプレゼンは退屈でしょう。

そこで個人的には「ジョブス流とパワポ式の中間あたり」を狙ったスライドをつくろうとしています。いいとこ取りしようって魂胆です。

  • ジョブス流からは大きな画像を見せたり、キャッチコピーでインパクトを与える点
  • パワポ式からはその場にいなくともスライドを見るだけで内容がなんとなく分かる点

このようなハイブリット型を取ることによって、印象に残るプレゼンを練習をそれほどせずにも出来て、後からスライドを共有するだけで拡散して「こんな発表したんだ」と見てもらえるということを目指しています。ちなみに、その例として直近で僕がいちお、それを心がけてつくったスライドを掲載しておきます。多少、高橋メソッドも入ってますね。

www.slideshare.net

ストーリーテリングとコピー

発表をする経験を踏んでこそだんだんスライドづくりがうまくなって来たり、コツがつかめる部分が多分にありそうです。その際に

  • 分かってもらえるお話をつくる力=ストーリーテリング
  • インパクトのある言葉を生み出す力=コピーライティング

この2つの能力って大事になってくると思っているので、今後も意識して伸ばしていきたいと思います。

まとめ

以上、プレゼンのスライドというテーマで、前提条件をまずピックアップすること、ツールの件、構成を考えるための諸要素、「ジョブスvsゲイツ」的な何かのいいとこどりをしようとしている、などを紹介しました。具体的にページをどういう風につくるかという実装寄りの話とかもまだあるのですが、今日はこのあたりで!

宣伝

Podcastやってます!ジングルがクールです。聴いて下さい!

www.wada.fm

何をどう実装するか?コードを書かない話

最近思っていることをツラツラと。

サービスにとって「コードを書く」という行為以上に「何をどう実装するか?」を決定するスピードと精度が非常に大切だと改めて感じている。一般的な言葉で言うならば「要件定義」や「設計」に当たるところ。ある程度サービスが成熟してくると、その理念としてもビジネス的にも「ある程度」正しい要件を決め、矛盾や運用に負荷の無い設計を企てることが一番重要なんじゃないかと。もちろん「やれることを増やす」という意味では技術的な調査や実装として手を動かす作業は日々続けるとして、僕らの現状を話します。

チームスペック

まず前提としてのチームの規模。僕らのサービスはアプリにして500万弱のダウンロード数を誇るものの、比較的ミニマムな人員で開発されている。以下はザックリとした役割と人数です。

  • APIサーバを含むWeb側の開発 => 2人(僕含む)
  • iOS/Androidネイティブアプリ開発 => 2人
  • デザイナー => 1人
  • ディレクターやマーケティング担当 => 2人〜3人

ちなみにこれらの人達は決してオフィスに定時で集まるというスタイルをとってはいなく、リモートかつベストエフォートでリソースを割くという方式で動いています。 なので打合せや集まっての作業はノマド的な喫茶店で行なうのが主流です。

f:id:kamawada:20160223162659j:plain

コードは書いた瞬間に負債になりうる

我々にとって「闇」として話題に上がるネタに技術的負債という言葉があります。以前から参加させてもらっている「IVS CTO Night&Day」のアンカンファレンスでもそのテーマがあって色々考えたんだけども、辿り着いた結論は

コードは書いた瞬間に負債になる

かもしれない。ということだった。コロコロと移りやすいWebやアプリへのニーズや技術の進歩によって、書いてしまったものが負債になる日は近いな、という印象。これは残酷だけどわりと言えてるかもしれない。確かに、プロダクションに投入した例のXXXのコードはカオス化していて毎回ソースコードを読まないとAPIが理解出来ない... なんて過去の経験もある。だからコードは短い方がいいし、つくらなくて済むならばつくらない方がいいかもしれない。ヒエーボクハコードカキタイヨ... でもスパゲッティになったコードを読むのは辛い。なんというかこの矛盾的思惑が面白いところだとは思う。もちろんそれを設計実装するエンジニアの腕もあるだろうが...

まぁ、といってもサービスとしてプロダクトを良くしていくためにはコードを書くのは必要だろうし、そのために「過ちのない」機能や改善点を定義することが大事なんだろうね。

それぞれの思惑とディレクター

僕らはここ数年、年始に今年何をやるか?と言った中期的な目標やマイルストーンを決める。今年も決まった。だが、粒度が荒いと「じゃ今すぐこれつくります」とも言えない。

優先順位を決めた細かい実装計画が必要なんだけども、それを決めるにあたって、ステークホルダーそれぞれの思惑がバラバラだったりする。とあるAさんは機能1を叶えたいと言い、Bさんは機能2を推す。実装する側としては色々試しましょう!と言いたいところだけれども、上記の「負債」の件も含めて、機能を追加することに関してはちょいと慎重になってしまう。結果「どこから実装すればいいの!?」という迷いが生じる。

そこを解決するのがディレクターという「役割」である。あくまで「役割」なので「ディレクターひとり」がいるという状態じゃなくても構わないと思う。ディレクターはプロダクトを愛し、責任を持ち、そのプロダクトの「小さな方向性」についてジャッジをしてくれると嬉しい。

たった今の話なんだけど、各自のやりたいことが微妙にバラついてるという上記した状況なので、今度メンバーのうちの数名で細かい実装の優先順位を決める打合せをする。誰かがディレクションするのかみんなでまとめていくのか?気になるところであるが楽しみである。

要件と設計をテキストでまとめる

これをやるぞ!と決まれば、後は正確に要件を洗い出し、設計のたたき台をつくってみんなで叩けばあとは大抵上手くいく。

その際に、最近ではある程度構造化されたテキストで「要件定義と設計の中間」くらいのものを文章や箇条書きでまとめるといいんじゃないかって思っている。 僕らはそのためにesa.ioを使い出した。この場合Markdownや図のファイルでやることを整理するページを僕がつくり、みんなに投げる。オンラインや喫茶店での打合せでアラがないかツッコんでもらうという形だ。

例えば、今回話題にあがっているサービスでは新規登録フローをとある事情で変更したのだけれども、以下のようなページを作成し、みんなで共有&議論した。一部のスクショを掲載する。

f:id:kamawada:20160307102459p:plain

ここでは以下の様なことを「特に書式やフォーマットを気にせず」書いている。

  • ユーザーフロー
  • フローに基づき裏側で何が起こるか?
  • 前提条件、事後条件
  • データ構造の変更点
  • WebAPIのエンドポイント
  • Webのパス設計
  • デプロイ計画

これがなかなかいい具合である。

いかに迷いなくコードを書くか?

僕は今まで設計にまつわることを一人でやっていた... と思うんだけれども、このように一度esaなどを使ってテキストに落としこんでみんなに見てもらうと、コードを書く前の迷いが消える気がする。このドキュメントにツッコんでくれるのは開発陣数人とアプリのディレクターのせいぜい3人程度なんだけども、それだけでも、ありがたい。抜けや欠けがどうしても出ることを防げれるので「何をつくるか?」に対する精度が増す。また、WebAPIとモバイルアプリの様に連携しあうサービスなので、API側の機能変更を予めモバイル側のエンジニアが把握しやすいという利点もある。

効率よくコードを書く際には上位工程である設計の迷いを持ってきてはよくないのだろうな。良いコードを書けたとしても「このままの仕様でつくっていいのかな〜」なんて思いながら、はなんかヤダなぁと思う。

Microservicesへの考慮

粒度によっては日々発生するビジネスレイヤーの要望に対してMicroservicesを適応することで技術的負債を削減することが出来るかもしれないという淡い淡い期待はある。なるべくアーキテクチャ設計の時点で構造化していおくことで、サービスの様々な機能を追加を試せる土壌をつくっておくことに努力したい。そういう意味で「マイクロサービスアーキテクチャ」はいい本だったのでまとまったら、どこかで書くかPodcastで話そうと思う。

マイクロサービスアーキテクチャ

マイクロサービスアーキテクチャ

  • 作者: Sam Newman,佐藤直生,木下哲也
  • 出版社/メーカー: オライリージャパン
  • 発売日: 2016/02/26
  • メディア: 単行本(ソフトカバー)
  • この商品を含むブログを見る

まとめ

「サービスにとって」という前提ではあるが、なるべく無駄なコードは書きたくない。だからこそ「何をつくるか?」のジャッジをディレクターという役割を利用して精度高く決めていきたい。また、要件や設計仕様をesa.ioなどの構造化テキストでまとめていくのは、迷いなくプロダクトコードを書いていくために役に立つかもよ、というお話でした。コードを書かない時間も大事だし、コードを書くことを止めないでいきたい。

宣伝

Podcastやってます!ジングルが面白いです。聴いて下さい!

www.wada.fm

栄和堂を開店して2ヶ月が経った件

弟が店長、親父がカフェマスターを務めるカフェ&バーである「ブックスペース栄和堂」が開店して2ヶ月が経った。運営するのは僕が代表、そして彼ら2人も所属する株式会社ワディットである。

f:id:kamawada:20151127114031j:plain

僕は現状の仕事がある、そして「物理的に遠い」という理由から、顧問やアドバイザーというような立場でこの栄和堂のプロジェクトに参加している。今日は「定休日」なのでその時間を利用して新メニューの試食会やら弟の「淳也」による2ヶ月のデータ分析結果などを共有した。

f:id:kamawada:20160120143503j:plain

栄和堂は去年2015年の11月16日に、ワディット及び僕らの実家の近くにある鎌倉湘南深沢」にオープンした。そもそもITやWebを専門分野とするワディットがカフェもしくはバーを開店するには「入り組んだ」理由=ワケがある。そのワケがあるからこそ僕らの思い入れは強く、続けていきたい根源となっている。

実は栄和堂は元々「本屋」だった。店主は親父の弟さん、つまり僕の叔父である。いわゆる「街の本屋」で僕も幼少期の頃、栄和堂に行って、文具をあさったり、本棚の匂いを嗅いだり、叔父さんからタミヤの模型をもらったりして喜んだのを、すごく懐かしく覚えている。

f:id:kamawada:20160120181949j:plain

そんな栄和堂を営む叔父が一昨年の3月、急死した。あまりにも突然だったので正直びっくりした。人が世界からいなくなるという体験は不思議だ。

さて悲しい話は置いといて、問題は栄和堂だ。彼が20代の頃から40年以上営業しつづけた書店「栄和堂」をどうするか?結論を簡単に言えば、一旦閉店させた。親戚の中でも比較的動けた親父が踏ん張り、閉店セールをやったり業者を呼んだりして、在庫を一掃した。土地は亡くなった叔父の奥さんである叔母さんのものになったが、買い手がつかない。

そこで「どうせなら」ワディットが借りて何かやろうじゃないか?という話になったのだ。

f:id:kamawada:20150703190552j:plain

当初父親と二人だったワディット社員の僕らは色々考えたが「自らのアイデアに責任が持てない」という状況。そこへ、脱サラした淳也がワディットに参画。淳也は幼少時から持ち合わせている器用さを発揮し(そう、俺は永遠にマリオカートで淳也に勝てない)彼が店長になって栄和堂の場所を有効活用しようと動き出す。3人で話しながら、我々の目指すところは

本屋の再発明

であると定義した。ではどのように再発明するか?を今現在試しているところで、今日の会議で淳也はそれを

本棚を介して人がつながれる場所を提供すること

だと言う。ただ、このような目標を立てつつ、カフェやバーで収益を上げるというモデルは現時点で成功しているとは判断しにくい。正直、工事日数と、なによりもお金がかかっている。

f:id:kamawada:20151028172052j:plain

開店の直後、淳也と親父は当初の売上目標との乖離にウズウズしている感はあった。実際、経営的視点で見ると、結構厳しい。とはいえ、客として訪問してみるとヒイキはあるかもしれないが満足度は高い。そんな中、淳也は詳細にデータを取っていることが今日の打合せで分かった。顧客データを独自の方法で細かく取っている。さらにはとある日にちを決めて、栄和堂の前をどれだけの人が通りかかったか?をカウントして期待しうるトラフィックを測っている。

実営業日で数えるとたった「40日」分のデータなので正確性にまだかけるが続けると指標が立ちやすいだろう。例えば、同じくらい行き来がある、場所の近いカフェで「うまくやってる」ところを見つければ参考になる。

f:id:kamawada:20150703192022j:plain

また、彼は、打ち出した「ブックスペース」というネーミングと実際のニーズとの距離感にも違和感を感じている。これは僕自身も事前に気づきにくかったが、Webなどネットの媒体では尖ったコンセプトが通じるが、リアル店舗の場合、より具体的に安直な表現を使った方が、お客さん=ユーザーに「ここで何が出来るのか?」が分かりやすくなって良い。妥協案かもしれないが、それに気づいた瞬間に、ウィンドウディスプレイに「カフェ&バー」の表記をつけたようだ。

やりたいこと、やらなくてはいけないことがたくさんある

と淳也は言っている。決して焦る必要は無いが、やることがたくさんあることはいいことだと思うので、親父共々頑張ってもらいたい。

f:id:kamawada:20150628115924j:plain

強引にまとめると...

栄和堂というカフェ&バーを僕の弟と親父が「鎌倉の外れで」やっているのでよかったら来てね♪

ということでした。よろしく!

eiwado.space