タケハタのブログ

プログラマの生き方、働き方、技術について雑多に書いていくブログです。

「面白い開発をしたい」という人生観

面白い開発

「面白い開発をする」

ということが大事だと最近思うようになった。
面白いというのは

  • 面白いプロダクトを作っている
  • 面白い技術を使っている
  • 面白い環境で開発している

とか様々な意味で。

開発って割とビジネスの都合上結果至上主義になることも多くて、プロダクト、ビジネスが一番いい結果を残すためになにをすべきか?となることが多い。
特に「面白い技術」みたいなのは後回しにされやすい。

ただ新しい技術を使うのは意味がない?

例えばただエンジニアが「この新しい技術面白そうだから使ってみたい」となったとしても、それによってビジネス的なメリット(効率がすごく上がる、バグがすごく減る)がなければなかなか導入は難しい。
新しい技術の導入は基本的にコストがかかるので。

逆に古い技術をエンジニアが「つまんないなー」と思いながら使ってたとしても、それで動いているプロダクトに手を入れるのはリスクだし、致命的な問題でもない限りは「意味がない」からそのまま古い技術を使い続けることは多い。

ただ、本当にそれは「意味がない」ことなのか?

確かに使うことによってプロダクトやビジネスに明確な効果はもたらされないかもしれない。
でも、それによってエンジニアが「楽しい」と感じるようになるなら大きな価値があるんじゃないか?

たしかにつまらなくても我慢して、リリースしてビジネス的な結果が出れば嬉しいこともあると思う。
ただ、人生の中では結果が出るタイミングよりも、「開発」をしている時間の方が圧倒的に長い。
その長い時間を「つまらない」と感じながら過ごすことが本当に健全なのか?

エンジニアでも「ビジネスで結果が出る」ことが最大のモチベーションの人はいいかもしれない。
でも、そもそも開発自体に大きなモチベーションを持って生きている人には、この状況はよろしくないと思われる。

要は日々楽しいことが大事

これを思ったのは、ちょっと思想みたいな話になるかもしれないけど、「人生、日々が楽しいことが大事」だとふと思ったから。
別に結果を出すためだけに生きているわけじゃないし、開発とかエンジニアの生活の大半を占めている部分は楽しくあるべきだなぁと。

こんなこと書いているけど僕は技術的に多少つまらなくても、面白いプロダクト作れてれば楽しめるタイプです笑
でも、やっぱり自分にとって新しい技術とか使うのは楽しいし、あと技術だけじゃなくていいPC使うとか、新しいキーボード使うとか、環境的な部分もテンション上がる。
この理由で最近は新しい分離型キーボードとトラックボールを自腹で買って、仕事で使ったりしてます笑

ということで日々の仕事、エンジニアで言うと開発が楽しいことって大事だし、投資する価値のあることだなぁとふと思った話でした。

JavaScript嫌いなサーバーエンジニアがVue.jsを触ってみた

きっかけ

先月のCEDEC 2018にて、グリーさんの「モバイルゲームのお問い合わせ対応にてAIチャットボットを導入してお問い合わせ件数を約20%削減した話」というセッションでのお話がきっかけでした。
https://2018.cedec.cesa.or.jp/session/detail/s5aab885981384

このセッションはタイトルの通り、お問い合わせ対応にチャットボットを導入した事例の紹介です。
その中で使用した技術の説明もあったのですが、そこでユーザーさんからのお問い合わせのインターフェースはWebで作り、技術としてはVue.jsを使用してサーバーエンジニアが作っていたというお話がありました。

そしてVue.jsを選んだ理由の一つとして「ReactよりもHTMLソースが読みやすい、初期学習のコストが低い」ということが挙げられており、Webフロントの開発にアレルギーのあった自分にはちょうどいいのでは、と思い興味を持ったのが今回触り始めたきっかけでした。

サーバーエンジニアもWebフロントそれなりに分かってないとなぁ・・・という危機感もあり。

筆者のWebフロントのレベル感

ぶっちゃけJQueryで時代が止まってました笑
それも割と基本的なレベルで。

2013年頃のJSのブームが来た頃に覚えようとしたけど、それすらも基本的なところまでしかやっていなかったし、あのDOMをゴチャゴチャいじる感じで嫌いで抵抗感が・・・
そしてAngularJSとか色々フレームワークが出てきたけど、このレベル感で触っても分からないだろうと勝手に思い込み敬遠してきました。
ということで完全に浦島太郎状態です。

主に使った資料

基礎から学ぶ Vue.js cr-vue.mio3io.com

Vue.js公式ドキュメント jp.vuejs.org

Webにも情報はいっぱいありますが、書籍の方が勉強は捗るタイプなので、ちょうど良さそうなレベル感で評判の良かった「基礎から学ぶ Vue.js」を購入。
あとは公式ドキュメントも日本語で充実した情報があるのでありがたいです。

Vue.jsとは?

詳しくはこちらの公式ドキュメントを読んでいただくのが良いと思いますが jp.vuejs.org

JavaScriptのフレームワークで、主にView部分をの開発をしやすくすることを目的としたものなのかなと思っています。
なので前述のCEDECのセッションでもあったように、Webフロントに慣れていないサーバーエンジニアが触っても取っ付きやすいものになっているのかなと。

触ってみる

まずはHello World!

下記のHTMLファイルを作ります。
一旦シンプルにHTML内にJavaScriptのコードも記述しています。

<html>
<body>
<div id="app">
    <!-- ⑤Vueで設定したデータを表示 -->
    {{ message }}
</div>
<!-- ①CDNからvue.jsの読み込み -->
<script src="https://cdn.jsdelivr.net/npm/vue@2.5.17/dist/vue.js"></script>
<script>
// ②Vueインスタンスを生成
var app = new Vue({
    el: '#app', // ③appのブロックと紐づけ
    data: {
      message: 'Hello World!' // ④messageに値を設定
    }
})
</script>
</body>
</html>

このHTMLをブラウザで開くと、「Hello World!」が画面に表示されます。
コードのコメントに書いてある番号に沿って簡単に説明します。

①CDNからvue.jsの読み込み
ローカルにダウンロードして読み込むこともできますが、今回は手軽に触ってみるだけなのでCDN上にあるvue.jsを読み込んで使います。
vue@の後ろに書いている数字がバージョンの指定になります。

②Vueインスタンスを生成
Vueインスタンスを生成することで、Vueアプリケーションを作成します。
このコンストラクタの中で色々なオプションを設定することで、アプリケーションを構成することができます。
app という名前で変数化しており、こちらはコンソールからアクセス(後述)するのに使うことができますが必須ではないようです。

③appのブロックと紐づけ
el というオプションで、要素に紐づけます。
今回は <div id="app"> にこのVueインスタンスが紐付けられます。
(これをmountと言うようです)

④messageに値を設定
data というオプションで、アプリケーション内で使用するデータを定義することができます。

⑤Vueで設定したデータを表示
el で紐づけた要素 app のブロック内で、 data で定義したデータ message を呼び出して表示します。
{{ }} で囲うmustache形式で、データを呼ぶことができます。
el で紐づけた要素内でのみ扱えて、 <div id="app"> のブロックの外に書いてしまうと呼び出せないので、注意してください。

別ファイルへ切り出し

コード量も多くないので一旦1つのHTMLファイルにスクリプトも書き込みましたが、別ファイルを切り出す場合は下記のようになります。

index.jsというファイルを作り(名前は任意)、HTMLファイルと同一フォルダに置き

var app = new Vue({
    el: '#app',
    data: {
      message: 'Hello World!'
    }
})

HTMLの直接スクリプトを書いていた部分を下記のように変える

<html>
<body>
<div id="app">
    {{ message }}
</div>
<script src="https://cdn.jsdelivr.net/npm/vue@2.5.17/dist/vue.js"></script>
<script src="index.js"></script>
</body>
</html>

(普段JavaScript触ってないと忘れがちなので一応)

データバインディング

次はVue.jsの売りっぽい機能として挙げられるデータバインディングについて。
実はこれは先ほどのコードで既にやっています。

data: {
  message: 'Hello World!'
}
<div id="app">
    {{ message }}
</div>

ここの部分ですね。
Vue.jsでは、 data で定義されたデータがリアクティブデータとして扱われ、データを変更した際にそれを検知して、DOMの更新等の処理を自動的にやってくれます。
リアクティブデータは、細かい説明は省きますが「基礎から学ぶ Vue.js」から引用すると、

Vue.jsによって取得したとき(get)と代入したとき(set)のフック処理が登録された、反応のできるデータのことをいいます。

です。

言葉だと分かりづらいので実際にやってみましょう。
先ほどのHTMLを表示していたブラウザでコンソールを立ち上げます。
Google Chromeだと alt+command+I (Mac)で下記の画面が立ち上がります。

f:id:take7010:20180909134017p:plain

ここのConsoleタブで、 app.message="Hello Vue.js!" と入力してEnterキーを押します。

f:id:take7010:20180909134551p:plain

すると、画面上に表示されているメッセージも Hello Vue.js! に更新されたと思います。
これは前述したように、 data で定義された値を更新すると、それと同時にVue.js側でDOMの情報等も更新してくれているためです。

コンソールだとピンと来づらいかもしれないのでプログラムでも。
先ほどのindex.jsを下記のように書き換え、methodsを追加します。

var app = new Vue({
    el: '#app',
    data: {
      message: 'Hello World!'
    },
    methods: {
        updateMessage: function() {
            this.message="Hello Vue.js!"
        }
    }
})

methodsは文字通りアプリケーション内で使用したいメソッドを定義するオプションです。
ここでは updateMessage という名前で message のデータを更新するメソッドを定義しています。

さらに、HTMLファイルを下記のように書き換えます。

<html>
<body>
<div id="app">
    {{ message }}
    <button v-on:click="updateMessage">メッセージを更新</button>
</div>
<script src="https://cdn.jsdelivr.net/npm/vue@2.5.17/dist/vue.js"></script>
<script src="index.js"></script>
</body>
</html>

更新ボタンを追加し、先ほど作った updateMessage メソッドを紐付けました。
v-on:click という属性を使うことで、クリックした際にVueアプリケーション内のメソッドを呼び出せるようになります。
Vue.jsでは v-on というディレクティブをイベントハンドリングに使います。

これで画面に

f:id:take7010:20180909140256p:plain

と更新ボタンが表示され、クリックすると先ほどコンソールでやったのと同じように、メッセージが更新されるようになりました。
これを生のJavaScriptで書くと

var el = document.getElementById('app')
el.innerText = 'Hello Vue.js!'

みたいなまどろっこしいことをしなくちゃならなくて、これを見て昔JavaScriptでDOMを構築することに嫌悪感を覚えるようになり、これまでWebフロントの技術を敬遠するようになったきっかけになりました笑
(JQueryもちょっとラッピングはされてるけど、似たような手順を踏まないといけないのは変わらなかったので・・・)

配列のデータバインディング

テキストの書き換えだけでは面白くないのでもう一つ。
Vue.jsで配列を扱ってみます。
下記のHTML、JavaScriptファイルを作ります。

<html>
<body>
<div id="app">
    メンバーリスト
    <ul>
        <li v-for="member in memberList">{{ member }}</li>
    </ul>
    <input v-model="name">
    <button v-on:click="addMemberList">リストに追加</button>
</div>
<script src="https://cdn.jsdelivr.net/npm/vue@2.5.17/dist/vue.js"></script>
<script src="list_sample.js"></script>
</body>
</html>
var app = new Vue({
    el: '#app',
    data: {
      memberList: [
          '松井珠理奈', '須田亜香里', '宮脇咲良'
      ],
      name: ''
    },
    methods: {
        addMemberList: function() {
            this.memberList.push(this.name)
            this.name = ''
        }
    }
})

こんな画面が表示されます。

f:id:take7010:20180909175332p:plain

ここでは li タグの中で v-for というディレクティブを使っています。
これを使うと、JavaScriptのfor-ofのような形で、配列の要素の数だけ繰り返し描画して中の要素を扱うことができます。

<ul>
    <li v-for="member in memberList">{{ member }}</li>
</ul>
memberList: [
    '松井珠理奈', '須田亜香里', '宮脇咲良'
],

この場合では、 memberList の3回分 liタグを描画し、各要素の値を member という変数名で扱って表示しています。

そして下に表示されているテキストボックスに適当な名前を入力し、「リストに追加」ボタンをクリックすると

f:id:take7010:20180909175439p:plain f:id:take7010:20180909175448p:plain

リストに入力した名前が追加されます。
まず、HTML側で input タグに v-model というディレクティブを使っています。

<input v-model="name">
<button v-on:click="addMemberList">リストに追加</button>

この v-model で設定されたデータを、inputタグのvalueと連動させることができます。
この場合では

name: ''

ですね。
初期値は空文字を入れてあるので、テキストボックスも空になっています。
そして名前を入力すると name の値も同時に変更され、「リストに追加」ボタンをクリックした際に呼び出される addMemberList メソッドで、 memberList にその変更後の値が追加されます。

addMemberList: function() {
    this.memberList.push(this.name)
    this.name = ''
}

それと同時に、 memberList を呼び出していた li タグの要素も連動して更新されます。
最後に this.name = '' としているのは、リストへの追加後にテキストボックスを空の状態に戻すためです。
この行を消すとテキストボックスには入力した値がそのまま残るので、試してみてください。

テキストボックスを更新すると name の値が変わり、 name の値を更新するとテキストボックスの値が変わるので、「データを連動させる」という意味が分かるかと思います。

Vue.jsを触ってみて良かったこと

ということで思ったより長くなってしまったのですが、Vue.jsを触ってみた内容を紹介してみました。
本当はもうちょっと色々やったんですが、一旦は分かりやすい特徴のデータバインディングのことだけ。
あとは触ってみての感想を書こうと思います。

Webフロントへの抵抗感が薄れた

前述した通り、生のJavaScriptでDOMをゴリゴリいじるようなところでところで嫌いになって触ってなかったので、時代の進歩に感動しました笑
このレベルなら分かりやすいし、JavaのFreeMarkerとかサーバー側のテンプレートエンジンに近い感覚で扱える。
あとはロジックをJavaScriptで書くというだけなので。

今回はデータをコードにベタ書きで色々やりましたが、そこのデータをサーバーから取ってくる形にすれば、もう少し実用的になりそうですね。
最近流行りのFireBaseとかとの組み合わせで、たしかにサーバープログラム書かなくてもちょっとしたサービスなら作れそうです。
データ更新と取り出しができれば、あとはそれ使ってクライアント側でロジック書けるので。

並行してHTML、JavaScript、CSSの知識も少し付いた

基本的にVue.jsの情報は当然ながらWebフロントの基本的な部分は分かってる人向けに書いてあるので、浦島太郎には分からない要素もちょっとありました。
なんで今回紹介したようなサンプルコードを色々書いてるうちに、HTMLとかJavaScriptのことも色々調べたりして、それもまた勉強に。 あと今回は省きましたが、クラスとかスタイルを扱うこともできるので、CSSについても学びました。

序盤に「このレベル感で触っても分からないだろうと勝手に思い込み」JavaScriptのフレームワークとかを敬遠してきたと書きましたが、むしろこれを触ることで自然と必要に応じてベースの知識も覚えていくので良いのではないかと思いました。

リアクティブの概念がなんとなく理解できた

これは副次的な効果ですが。
お恥ずかしながら「リアクティブプログラミング」とかで「リアクティブ」いう言葉はよく聞くんですが、あまり理解していませんでした。
なのでVue.jsのデータバインディングのこととかを通して、そこについても体験するいい機会になりました。

最後に

ということでまだまだ触りだけですが、近代のWebフロントの世界に一歩踏み出せた気がして良かったです。
仕事で使う機会が来るか分かりませんが、せっかくなのでこれを使ってなにか作ってみようかと思います。

エンジニア10年(と8ヶ月)の記録

はじめに

昨年の12月でエンジニアになって丸10年を迎え、「エンジニア10周年を迎えて」というタイトルでその振り返り記事を年末年始に書こうと思いました。
が、筆が進まず1月中に出そう・・・と思ったまま結局お蔵入り。
GW前に「新卒も入ってきたしそろそろ書くか」と思いながらもGWはダラけてしまい結局書けず・・・

という感じでずっと書かずじまいだったエンジニア10年(と9ヶ月)の振り返りを書きます。

前提

まずエンジニアになる前は高卒で就職して、2006年4月〜2007年9月まで1年半ほど公務員やってました。
そこから3ヶ月ほどニートやった後、「パソコン触るのが好きだった」くらいの理由で全くの未経験でSESに転職。

1〜3年目

研修

就職した会社の研修でC言語を学ぶ。
そもそもプログラムがなんなのか全く分かってないので、最初に「Hello World」のプログラムを見せられても何やっているのか1ミリも理解できず。
今思うと「未経験OK」という文言で募集されてたとは言え、このレベルでよく申し込んだなと思います。

最初の現場

研修終わった後、金融系システムのシステム移行の案件に9ヶ月程。
ひたすら手順書のExcelからコマンドをコピペして実行する仕事をやってました。
SIer業界は最初はテストとかから入るのが当たり前だったので、とりあえずコピペを全力で頑張って誰よりも早くなる。
あとこういうシステム移行は定期的に二交代、三交代で24時間対応になることがあるので、若かったこともあり頻繁に夜勤に割り当てられたりしてました。

リーマンショック

初めての案件が終わった頃、ちょうどリーマンショックが起きて仕事が全くなかった時期が約1年。
この時期は最初にいた研修施設に入ってJavaを勉強。
転職して2年目がほぼ全部この状況だったので、なかなかに辛かった。
「まだ全然経験ないのにこんなことやってて、この先やっていけるんだろうか?」と思ったこともありました。

色々な現場渡り歩いてた時期

リーマンショックの影響が少し落ち着き始め、やっと久しぶりの現場に。
まずは2週間のド短期でひたすらテストのエビデンスを印刷するという案件。
毎日終電、土日込みのスケジュールで引かれてるいわゆるデスマーチに、「とりあえず誰でもいいから人で増やして」のパターンで放り込まれた感じ。
仕事がないからとは言え、なかなかの案件でしたね笑

そこからやっと仕事が入ってくるようになり、

  • 新聞社向けのWebサイト開発(3ヶ月)
  • 通信キャリア向けのシステム移行(2ヶ月)
  • 通信キャリア向けの顧客管理システム開発(3ヶ月)
  • アド系のベンチャー企業で広告配信システムの開発(6ヶ月)

と約1年でド短期の案件含めて5箇所の現場を渡り歩く。
落ち着いてたとは言えリーマンショック前に比べられると案件が少なくて、求められているレベルが上がっていた上、実質2年目くらいの実力だったのでなかなか短期で契約切られてしまうことも多かったです。

実はエンジニア辞めそうになったタイミング

実はこの3年目の終わり頃のアド系のところにいた時、一回エンジニア辞めようか迷いました。
スキル起因で切られることが続いた後に、ここでは特に要求されるレベルが高くてついて行けなくて辛くて、この仕事向いてないんじゃないかと思って転職のこととかリアルに調べ始めたり。
3年というのもちょうどこういうこと考えるタイミングだったんですかね。
結局この現場も半年くらいで終わったので、一旦は踏み止まったのですが。

ただ、この時期色々な現場を見れたことは今でもすごく糧になってると思ってます。

4〜6年目

ゲーム開発に関わり始める

ちょうど4年目に入ったところでサイバーエージェントの案件が入り、初めてのゲーム開発に参画。
3人しかいないプロジェクトで、現場の雰囲気もそれまでとは全く別物。
「プログラマ」とか「SE」という仕事の常識を覆された感じでしたw

初めて作ったゲームは自分入れて3人(エンジニア兼P、AD、エンジニア)のプロジェクトで9ヶ月ほど。
企画とかゲームの仕様に意見したりしながら考え作る、みたいなスタイルにそれまでの仕事はなかった楽しさを感じました。
「エンジニア」という領域のものは当然全部やらなければならないし、時には自分でキャラのセリフとか考えながら実装したりと色々やりました。

エンジニアの仕事が本当に楽しいと感じ始めたのもこの頃でした。
転職を踏み止まった後、エンジニア続けようと思えたのもこのタイミングでこの仕事に巡り会えたのは大きかった。

その後3ヶ月ヘルプで別のプロジェクトに入った後、次のゲームのプロジェクトに異動。
(3ヶ月ヘルプしたところも相当濃い時間だったけど、ここでは省きます)

初めての長期運用を経験

2011年の12月に、その当時リリースしたプロジェクトで一人抜けるということで、運用に入ったタイミングで異動。
ここも入った時は5人とかでやってて、かなり色々やった印象。

ちょうど世の中がガラケーからスマホへ移行していた時代だったので、スマホ対応とかやってたのが最初の1年。
まだFlashもバリバリあった時代で、でもiPhoneがFlash使えなくなって・・・みたいなところで色々とバラバラに対応しなくちゃいけなくて、時間がかかった。
まあこの時代じゃないとできない体験だったので、今となってはいい思い出です。
当時スマホ対応やるサーバーエンジニアが決まってなかったので、プロデューサーに「やりたいです!」ってお願いした記憶があります。

その後もしばらくそのチームで開発を続け、いつの間にかプロジェクト内で一番の古株に。
最終的に2年3ヶ月いて、この時点ではキャリアで一番長い在籍期間になった、思い出深いプロジェクトです。

7〜9年目

アプリボットに転職

SESを辞め、それと同時にサイバーエージェントも離れて2014年4月から現所属のアプリボットに入社。
「社運をかけたプロジェクト」と言われた新規開発のプロダクトにジョインして、4ヶ月半開発してリリース。
なかなか楽しい開発期間でした・・・

そして半年くらいした後そのプロジェクトのサーバーチームのリーダーに。
詳細は書けないけどプロジェクト自体は山あり谷ありで、なかなか大変な、大変な、大変な・・・期間でした。

運用タイトルの責任者時代

1年半ほど経った後、領域を広げて運用タイトルのエンジニア責任者というポジションになりました。
プロジェクトのエンジニアとしてコミットしつつ、それぞれのプロジェクトの状況把握とか、相談受けたりとか、アドバイスしたりとかまあいわゆる「マネージャー」的な役割ですね。

この規模でこういうポジションやるのは初めてだったので、色々と探り探りな感じ。
ただ、学びはすごい大きい期間だったかなと。
それぞれのプロジェクトとの関わり方、時間の使い方とか、状況に応じて使い分けたりして、最終的にはいいバランスの取り方を見つけられたんじゃないかなと思っています。

10年目〜現在

サーバーエンジニアとして、新規プロダクトを絶賛開発中。
サーバーサイドKotlinをやったり、色々と初めて使う技術も触ってて苦しみつつ楽しく作っています。
久しぶりに少人数のプロジェクトでやってて、プロダクトの内容的にも好きなカテゴリーのものなので色々と楽しいです。

あとはせっかく技術的にも新しいことやってるので、そこの発信は積極的にやっていこうかと思っています。
結果CEDECにも出れたので良かったです。

10年振り返って

元々ゲーマーじゃないし、なんなら社会人になってからは全然ゲームやらなくなってたけど、たまたま行った案件でゲーム作り始めて10年のうち7年ゲーム作っています。
エンジニアになった頃は普通に大手のSIerとかに入って、PMとかになる感じかなあとなんとなく将来のこと考えてて、まさかゲーム作ることになるとは微塵も思ってなかったので人生分からないものですね。
そして最近はあまり何十年先とかは考えなくなりましたw(変化の早い業界なので先がよく分からないのもある)

今あるのは

  • バックエンドの技術が好き
  • ずっとプロジェクトに入って開発はしていたい
  • 作りたいプロダクトのジャンルはエンターテイメント

というのを考えているくらい。

ゲームにこだわっているわけではないけど、作ってユーザーさんが楽しんでくれるのを見る嬉しさを覚えたし、これが一番好きです。
だからちょっと広いけどエンターテイメントと言えるジャンルのプロダクトには関わっていきたいかなと。

技術面はバックエンドが好きだけど、そこは作りたいもの次第で・・・くらいの感じ。
「技術は手段」というのがモットーなので。

あと振り返って思うこととしては、どんな仕事でも全力でやっておけばなにかしらの成長につながるし、いつか役に立つということ。
どんな酷い現場でも全力でやればなにかしら得られるものはあったかなと。
もしスキル的に得られるものがなかったとしても、最悪「こんなプロジェクトも世の中にはあってね」っていう飲み会の話のネタにはなります笑

ということで10年(と8ヶ月)経ちましたが、なんだかんだ楽しくやってこれた気がするので、これからもエンジニアとして生きていこうと思います。

CEDEC 2018に登壇してみての学びと振り返り

Twitterでは散々宣伝してきましたが、去る8月24日にCEDEC 2018で登壇してきました。

ゲーム開発に最適なサーバーサイドKotlin 〜Kotlinの導入と基盤ができるまで〜
https://2018.cedec.cesa.or.jp/session/detail/s5abf865c5ecde

発表資料:
speakerdeck.com

そこで、今回はその事前準備から本番当日までの間であった学びをまとめたいと思います。
今後大きなカンファレンスとかで登壇する人たちの参考になればと思います。
資料を作り始めた6月後半から、発表当日の8月24日までの約2ヶ月間のお話です。

①資料作成

日頃からアウトプットしておくと楽

ここ1年くらい、特にKotlinを始めてからは会社のQiita:Team、技術ブログに技術検証の内容やノウハウの記事を積極的に書くようにしてきました(まだまだ全然少ないと思っていますが)。
登壇資料を作るにあたって色々思い出したり、調べたりする時にこういう風にある程度まとまった情報が、しかも人に見せる用に書いた形で残っているのはとても助かりました。
1時間のセッションとかだとかなりのボリューム作らなければならないので、これがあるのはとてもおおきいでs

サンプルコードとかもちょっといじって流用できるようなものが多かったし、全部0から作るのに比べて大幅に工数削減できたし、こまめに書いてる分精度の高い情報を出せたんじゃないかなと思います。

改めて調べるので勉強になる

とは言え、いざ口で説明しようとすると忘れていたり、実は理解があやふやだった部分もいっぱいありました。
特に他の人が検証した内容とかは、記事は読んでいたけど自分でバッチリ説明できるレベルで理解できていなかったと思います。
そういった内容を改めて調べ直したり、自分でコード書いて動かしてみたりすることで、理解が深まったしスキルアップできた気がします。

②練習

色んな目線の人にみてもらうことが大事

「プレゼンは練習が大事」というのは昔スティーブ・ジョブズ氏の本を読んでからずっと分かっていたんですが、今回一番失敗したと思ったのは「人に見てもらっての練習」を終盤までやらなかったことです。
そもそも資料の第一版ができあがったので2週間前くらいで(これも遅すぎたんですが)、そこから少人数で発表見てもらって修正しつつ、一人での練習を進めていました。

そして本番週の頭に会社のエンジニアをたくさん集めて見てもらったところ、大量のマサカリが・・・
本当はそれを最終練習として資料をFIXして、あとは反復練習をひたすらする予定だったのですが、本番前日まで資料の修正を強いられるハメになりました。 なので速い段階で資料と、できれば発表とセットで色々な目線の人、もしくは当日想定されるお客さんのペルソナになるような人を集めて意見をもらうのが大事だなと思いました。

ちなみに余談ですが、当日の直前はカラオケにこもって反復練習をしていました。 個室だしマイクあるし、食べ物飲み物もある上に場代が安いのでレ週場所には結構おすすめですよ笑

③当日

やっぱり練習が大事

当日は他のセッションを観るのも諦め、直前までひたすら練習してましたね。
それもあって本番はそれなりにスムーズに話すことができたんじゃないかなと思っています。
ただ、ギリギリだったこともあって後半部分の方があまり練習できなかったので、前半の方が上手く喋れたなという手応えがありました。
やっぱり最後はどれだけ練習したかで当日の落ち着きとかも変わってくるなと改めて感じましたね。

冷静に時間を見る

あと心残りなのは、PowerPointの発表者モードの時って左上に経過時間が出るんですが、後半それが結構ギリギリになって焦ってちょっと早口に・・・と思ったら実際は10分余り。
準備もために開始時間前からスライドを再生していたので、その分の時間も乗っかっていただけでした・・・
f:id:take7010:20180828225810p:plain ↑これのこと

無駄に焦って喋ってしまって、これだけが心残りですね。

最後に

今回はCEDECというゲーム開発者の最大級のイベントで登壇できて、とても光栄でした。
それに当日までの準備も本当に色々な人に協力してもらい、苦労しつつも勉強になることがいっぱいありました。
普段仕事で人に説明したり、ブログを書くのとは全く別の難しさがありますね。

同時に改めてアウトプットの大事さも感じたので、こういった機会は今後どんどん増やしていこうと思っています!

全力でやる 〜新人時代にやっておいて良かったこと〜

4月も終わりに近付き、新社会人の方々も入社してそろそろ1ヶ月、という時期ですね。
そこで今回は、僕が新人の頃やっていて良かった、一番大事だったと思うことを体験談交えて書こうと思います。
(と、言っても新卒じゃなくても大事にした方がいい内容ですが)


やりたい仕事はなかなかできない

みんな仕事を始める時、「こういうことやりたい」とか「こういう世界なんだろうなー」とか色々想像しながら入ってくると思います。
ただ、初めから自分の想像通りにやりたいことをやれることは滅多にないです。
例えば

  • プランニングをやりたいと思って入ったけど最初はデバッグをやる
  • UnityやりたかったのにCocosのプロジェクトに入った
  • 単純作業とか雑務ばかり振られる
  • 希望通りに配属されたんだけど思っていた感じと違った

など様々です。

ではその状況から自分でやりたい仕事をやれるようになるにはなにをすべきか?
それは今任されている仕事に全力で真剣に取り組むことです。


全力でやると得られること

信頼される

どんな仕事でも全力でやっている人は、それだけでも信頼に値します。
それはその人が仕事に対して真剣に取り組んでくれる人、適当なことはしないという証明になるからです。

特に新人の時は何も実績がないので、そこで手を抜いてしまうと「この人は真剣に仕事しない人なんだ」という評価しか残りません。

なんだかんだ学びがある

新人の頃は何もかもが初めての経験になるので、やっていれば必ず学びがあります。
仮に自分が将来やりたい仕事とかけ離れていても、知っておくことでいつか何かの役に立つこともあります。

ただ、それもその仕事に対して全力で臨んでいればこそ。
全力でやるからこそよく考えるし、その仕事の本質を理解できます。
手を抜いてしまうと惰性でなんとなくこなしてしまい、終わった後自分の中に何も残すことが出来ません。

成果が出やすい

全力でやっていれば絶対成功するわけではないですが、嫌々でやっているよりもずっと成果につながる可能性が高いです。
(言うまでもないことかもしれませんが)
前述したように信用されて学びがあることに加えて、さらに成果が上がれば言うことなしですね。

体験談

僕がエンジニアになって最初にやった仕事は金融系システムのデータ移行作業のプロジェクトでした。
実際どんな作業をやっていたかと言うと、Excelに書いてあるコマンドをひたすらターミナルにコピペして実行するという仕事です。
プログラムを書くということは一切ありませんし、正直面白い仕事ではありませんでした。

しかし、それでもとにかく全力で真剣に取り組んで、誰よりも早く、正確にその作業が作業が出来るようになったら、徐々に他の仕事も振られるようになってきました。
それだけしかやっていないのに、2年目には別の案件でリーダーを任されたりもしました。

全力でやって成果を出したことで、スキルとかではなく、周りから人としての信頼を得られたからかなと思っています。

そうやってしっかり成果を上げれば、「じゃあこういう仕事も任せてみようか」と任せられる仕事の幅も広がっていきます。
(この人単純作業メッチャ得意だからこれだけいっぱい任せよー!とかにはならないので大丈夫です)

もちろん、自分のやりたいことをしっかりと周りに伝えておくことも必要ですが。

ちなみに学びもしっかりとあって、この仕事のお陰でExcelの使い方に結構詳しくなりました笑
知っていると意外と便利な使い方がいっぱいあって、今でもエンジニアとして作業する時に役立っています。


まとめ

人は仕事に対する姿勢とか、取り組み方とかを結構見ているものです。
そしてそれは成果やその人の雰囲気にハッキリ現れてきます。

それに最初から仕事に手を抜いてしまうと、せっかくの学ぶ機会や成果を挙げられるチャンスを逃してしまってもったいないです。

働いていれば面白くないことや、やりたくないことをやらなければならないことは幾度となくありますが、無駄なことなどないと思って何事にも全力で真剣に取り組むことが大切だと思います。

アウトプット=インプット

最近、突然ですがブログをはてなブログに変えてみました。
きっかけとしてはこれからの半期はちょっとブログの更新増やしてみようかな〜と思い、心機一転別のブログサービスに変えてみようと思ったからというだけです。
(ちなみに前のブログはこれ→ http://ameblo.jp/take-7010/entrylist.html )

で、なぜブログの更新を増やそうと思ったか?
それは自分の考えてることを他の人に伝えたいというのもありつつ、ブログでアウトプットすることが新たなインプットにつながると気付いたからです。

インプットとアウトプット

よく本を読んだりセミナーに行ったりして勉強することを「インプット」、それを実践して形にすること(エンジニアだったらコードを書いたり)をアウトプットと言います。

スキルアップにはこの2つをバランス良くやることが必ず必要なものだと思っているのですが、アウトプットは手間も時間もかかるし、「インプット」の方が新しい知識に触れれて楽しいと感じている部分がなんとなくありました。

ただ、そこで最近考えたのが冒頭にも書いた「アウトプットすることが新たなインプットにつながる」ということです。


整理する

まずインプットした知識は、とりあえず頭に入れただけなので割とふわっとしたイメージとしてしか残っていないことが多いです。
アウトプットとして形にする時には、自然とその内容を整理して思い出す必要が出てきます。

例えば本を読んでその内容、感想をまとめてブログに書こうとすると、いっぱいあった本の内容の筋を整理して、キモとなる部分をピックアップして、まとめた内容を書くということになります。

そうすると頭の中でふわっとしていたイメージが自分の中で具体的なイメージとして固まって、よりしっかりとした知識として頭に定着します。
(逆にしっかり固まらないと文章に起こすのが難しいですが)

これは「新たなインプット」というよりは、インプットしたものをより強固にするというイメージですね。

忘れた部分、知らない部分を調べる

整理しただけでは大体しっかりとしたアウトプットにならないです。
それはインプットした内容も全て覚えているわけではなく、忘れてしまったり、そもそもスルーしてた部分(流し読みしてたとか)もあるからです。

実際にアウトプットに起こす時にはそういう部分で「あれ、ここってどうなってたっけ?」「これってなんでこういう意味なんだっけ?」みたいになることがあります。

そうすると当然本を読み返したりして思い出したり、足りない部分を調べたりすることになるので、自然と新たな知識が入ってくることになります。
ここで「新たなインプット」が生まれます。

余談ですが僕は昔新しいプログラミング言語の勉強をする時に

  1. 入門書を一冊読む
  2. その言語を作って自分の欲しいツールを作る

という方法をよくやっていました。
サンプルコードとは違う、自分で仕様を考えたものをいざ作ろうとすると、前述の忘れていたり、流し読みしていた内容の部分でどうやって実装していいか分からない部分が山ほど出てきます。
そうして調べなおしたり、そもそも読んだ本に載ってないようなことは新たに調べたりしてやるので、しっかりと意味を理解して知識を定着させることができました。

ちなみに作っていたのは家計簿ツールだったり、仕事の書類を管理するツールだったり普段自分で使うものだったので、仕様のこだわりも強くなって分からないことはどんどん出てきたのでいい勉強になりました笑

人からフィードバックをもらえる

アウトプットをして人に共有すると、良いことも悪いこともフィードバックがもらえます。
これはアウトプットしないと絶対に得られない「新たなインプット」です。

僕も今まで10年くらいエンジニアをやってきて一番レベルアップしたのは、自分が書いたコードをデキる人にレビューしてもらって指摘を受けた時な気がしています。
自分の悪い癖を指摘されることもあるし、あるいは自分では全く思い付かない書き方を教えてもらうことも出来ました。

ブログに関しても、自分の考えをまとめて書くことで、他の人からコメントなどで感想を聞くことができます。
自分の書いていることが間違っていたりした時も、なにかおかしな考え方を書いてしまったとしても、人からの指摘で気付くことが出来ます。

そうしてもらったフィードバックは、自分の頭の中を人から見て出た意見のようなものなので、自分にとっての課題点なんかも見えて非常に貴重です。


最後に

ということで、今後はインプットしたことを出来るだけブログに書いていこうかなと考えています。
日頃仕事をしていて得たこともそうだし、本を読んだ時もいい内容の物は随時。

そして半年後くらいには、ブログを書き続けたことによって得たことをこのブログに書ければと思います笑

外側から考える

最近ちょっと興味があり、この本を読んでみました。

デザイン脳 ―桝田省治の発想とワザ― https://t.co/CpsKEhnMsS

読んだキッカケとしては「エンジニアは技術書で勉強するけど、プランニングとかのスキルってどうやって勉強するんだろう」と思い、そういう本を検索してみたら結構紹介されていたからです。



ゲームを作る時の考え方

この本自体、ゲームを考えてから作るまでの色々な考え方が載っていてとても面白かったのですが、その中でこの桝田省治さんがゲームを考える時の流れとして、次のようなことを挙げていました。

  1. まず、僕が面白いと思うこと、逆に言えばユーザーを面白がらせたいゲーム向きのネタをどこかで見つける
  2. 次にそのネタを再現するためのルールやゲーム目的を考える。ようするにシステム部分の構築だ
  3. そのルールや目的が存在してもおかしくない世界設定をでっちあげる
  4. 最後に、ルールや目的、世界設定が説明的にならず、感覚的に理解しやすいシナリオやキャラクターを追加する

これを読んで思ったのは、モノづくりに於いてどの職種も考える順序は一緒なんだなということです。
それがタイトルに書いた外側から考えるということです。
「全体から考える」とか「後ろから考える」とも言えるかもしれません。

上記の話で言うと、ゲームのネタ(やりたいこと)という一番外側の部分から考え、 それを表すシステム→世界設定→シナリオやキャラクター と内側へ進んで行っています。

※世界設定がシステムの内側というのは分かりづらいですが、この方は世界設定を「ゲームはシステムが重要で、世界設定やシナリオはより楽しく都合よく進めるためのもの」という風に置いてるので、この形になります。
(マリオに「ピーチ姫を助ける」という世界設定がなかったとしてもアクションの楽しさは変わらないよね、みたいな話です)




他の職種での考え方

では他の職種で考えてみます。 例えばエンジニアがコードを書こうとしたら

  1. 機能要件を決める
  2. 全体の設計を考える
  3. 各機能のインターフェース設計を考える
  4. ロジックを考えてコードを書く

と、これも
要件(作りたいもの)→全体→機能→各ロジック
と外側から内側へ向かっています。
会社によっては要件定義、基本設計、詳細設計・・・みたいな分かりやすい言葉もあります。

ライターさんが文章を書こうとしたら

  1. テーマ、世界観を決める
  2. 全体の話の流れを考える
  3. 構成に落とす(1章、2章とか)
  4. 各章の内容を書く

とかになるのかなと思います。 (ここは半分憶測なので実際はもっと色々あると思いますが)

このように言い方はバラバラですが、基本的にはまずは荒い粒度で「一番外側を考える」というフェーズから始まり、徐々に内容を細分化して肉付けしていく順序となっています。

なぜこうなるかと言えば、結局のところ一番外側の部分が「作りたいもの」を表していて、そこに向かってどうつなげて行くかでモノが出来上がって行くからだと思います。
(まあ実際は内側からいきなり作り始めてしまう人も多いですが・・・エンジニアで言うと設計せずいきなり一番内側のコード書き始めてしまうような)



まとめ

今回はエンジニアやライターさんのことを例に書きましたが、イラストレーター、UIデザイナー、あるいは建築士や自動車製造みたいな全然別の業種でもおそらく割と共通する考え方なのではないかと思います。
(もちろん職種によって多少の差異はあると思いますが)

ちなみにこのブログも本を読んで「外側から考えることの大事さを伝えたい・・・!」という全体像が思い浮かんだ後、

①本の紹介
②本の面白かった部分の話
③考察、例え話
④まとめ

みたいな構成に落としてから書きました笑
小さなモノでも、何か考えて形にする時は、こういう順序を意識して考えてみるとより良いモノが作れるかもしれません。