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

ゆーすけべー日記

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

IVS CTO Night&Day 2016春 に行ってきた #ctonight

「行ってきた」と言っても、いまだ開催された宮崎市内にいますが... 血迷って中途半端な時間の飛行機を取ってしまい空き時間が出来たので、それを利用して「鉄は熱いうちに」昨日まで開催されていた「IVS CTO Night&Day 2016 Spring」のことについて書きます。

f:id:kamawada:20160527113130j:plain

IVS CTO Night&Dayとは?

そもそもこの「IVS CTO Night&Day」というのは、「CTO」という冠が付いていること、参加に関して「招待制」であることや、トピックによっては「オフレコ」な話が出てくるなどの性質上「なんだかよく分からない」イベント感満載かもしれないですw 僕は第1回から参加しているのですが、正直最初招待された時も、Webサイトを見ても情報量が少ないしそんな感想でした。なんで、僕なりにちゃんと解説します。

元々、インターネット業界やスタートアップ企業の経営者向けのイベントとして「IVS=Infinity Ventures Summit」というイベントがありましてー、いわゆるCEOや会社の代表の人達が参加する規模のデカいモノなんですが、ようはそれの「CTO版をやったらどや!」としてCTO Night&Dayが発足したようです。なのでIVSが開催される会場に併設されてCTO向けのイベントが行われているのです。と言ってもイベントの期間中、本体である「IVS」と「CTO Night&Day」の交わりはほっとんどなく、IVSのLaunch Padと言われる一部のイベントのみCTO側が参加出来るだけです。大人の事情でIVS本体の方 が豪華な演出らしく、CTO Night&Day参加者が本体の方へ忍び込んで、置いてあるお菓子でも食べようものなら超絶怒られてそれどころじゃないらしいですw それも加えて参加者が経営者か、CTOもしくはCTO相当の方という差で2つのイベントの性質を比べると雰囲気とかだいぶ違うみたい。

f:id:kamawada:20160526185353j:plain

さて、このCTOイベント、正式名称には「powered by AWS」という接尾語がついておりまして「AWS=Amazon Web Service」さんがいろんな意味で頑張ってくれて開催されています。ボケての運用とかで普段から割りとヘビーにAWSを使っていると、Amazon JapanのAWS担当の技術や営業の方がサポートでついてくれるんですが、そうした見慣れた面々の方々が、今回のイベントでもスタッフとして忙しそうに企画や準備にはじまり仕切りまでやってました。CTO Night&Dayは前夜祭的なパーティを含めると合計3日間、参加者人数は100人規模で行われるそれなりに「大変な」イベントなので、それを自分達で泥臭く開催してくれているのは非常に好感が持てて、ありがたいです!この記事はこうしたAWSの方々に感謝する意味でも書いていたりしますw

セッション

Day0、Day1、Day2とあるうちの後半2日間は「セッション」が用意されています。以下の種類にだいたい分別出来るのではないでしょうか。

  • ゲストトーク
  • 参加者の方々によるピッチ的なトーク
  • アンカンファレンス
  • トークセッション
  • CEOが登壇する特別セッション
  • コーヒーブレイク

ゲストトークはCTOの中でもテーマとなるトピックに相応しい方が登壇し、時にはオフレコも挟んだトークが聴けます。例えば、前回京都で開催された時は「海外展開」的なテーマだったっぽくて、個人的には同じように「B to C」をやってるメルカリのsotarokやスマニューのかいせいさんのグローバル化のチャレンジや苦労話が面白かった。今回は「元CTO」がテーマだったので、先日まで楽天のCTOだった安武さんや現Supershipで元nanapiのwadapがトークしていました。

f:id:kamawada:20160526130636j:plain

2人〜3人のゲストが椅子に座りながら、ざっくばらんに行うトークセッションは、質問などもしやすく雰囲気が良いです。昨日は元CTO代表としてmixiを立ち上げたバタラさんが安武さんと話すセッションになりました。バタラさんが当時を振り返って「モッドパール」って言ってたのが個人的にツボでした。

f:id:kamawada:20160527140642j:plain

アンカンファレンスでは事前のアンケートでピックアップされたテーマに基づき、チーム分けされ、その議題について話し合い、結果を短い時間で発表します。例えば、

  • 経営者としてのCTOの役割
  • 技術的負債の返し方
  • 会社のブランディング
  • マネージメントについて
  • 採用
  • CTOの憂鬱ポイント=YPいくつ?

などなどがテーマです。会社の規模感や目指す方向、各自の役割によってそれぞれ視点が異なる中、まとめていくのは結構難しいのですが、色んな会社や組織があってみんな試行錯誤していることが分かっていいです。

一番最後のセッションには毎回、CTOじゃない経営者の人が登壇して違う視点を得られます。今回はあの「皆さんがお世話になっている」であろうDMMを立ち上げた亀山会長でした。参加者全員がそう思っていたかもしれないってくらい「あの人の真似は出来ない」なって感じでしたw いやーベースがモノづくりなCTOとああいう、お金稼ぎに特化した方は考え方が違う。それも別段いやらしくなく言うので、真似は出来ないかもだけど、楽しい時間を過ごせました。

3日間連チャンパーティ

夜は美味しい食事と共に、パーティです。3日連続で続きます。セッションも密度の濃いものなので、パーティでまた色んな方と交流するのは正直疲れます。が、もちろん楽しいです。

f:id:kamawada:20160526191450j:plain

皆勤賞の僕の感想としては、参加者の傾向が影響しているのか、プログラムがいいのか、なんなのかよくわかりませんが、回を重ねるごとに「雰囲気が良くなっている」と感じました。パーティなのでコミュ力が試され、時には「ぼっち」という状況になりかねませんが、まぁ全体的にそんなことはなく、ワイワイ楽しく交流出来る。その割合が高くなっている感はあります。

f:id:kamawada:20160526192544j:plain

印象的な事柄

僕のケースだと、会社やチームの規模も小さく、かつ方針としてスケールせずに「パートナーシップでサービスを大きくする」という変わった方針をとっているので、ぶっちゃけ上場を目指しているような成長企業の方と思考のズレがあります。これはこれで、一見話が合わなくて辛い感もあります。とはいえ、やり方の一つとして参考にもなるし、最近自分は技術顧問として他社も見ているので、吸収出来るようになってきました。

だんだん分かってきたのはエンジニア一人の会社のCTOから、1000人超えなCTOがいる中で、頑張っているところの本質は変わらないんだなーってことです。去年、クックパッドのセコンさん、はてな田中さん、GREE藤本さんのトークセッションでそれを強く感じました。

f:id:kamawada:20150612161008j:plain

まぁ詳細はあえて書きませんが、何が起こったかと言うと、みんな過去の技術的な過ちを持っていて、それについて全員謝っていたんですよねw 「こんなものつくってごめんなさい」とか「これ導入してごめんなさい」とかw そういう経験は当然僕もあることで、規模の差は関係なく抱く心理で、過ちをキチンと認めることが大事なんだなーって思いました。

まとめ

ということで、IVS CTO Night & Day 2016 Spring powered by AWSに行ってきました。このイベントは今後も半年に一回のペースで行われる可能性が高く、次回は冬となっています。CTOという肩書がついてなくても「CTO相当」ならばOK!招待制なんですが、おそらく次回開催される場合、僕が招待することが可能なので「行きたい!」という方はお声がけください。というか何人か呼んだら面白そうって人がいるので招待しますw

最後にイベントを支えてくれたAWSの方々、ありがとうございます!

とある技術顧問のお仕事

トラベルブックの技術顧問となって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