みなさんは、エンジニアやプログラマーと聞いて、どのようなイメージを持たれているでしょうか？

「根暗」
「オタクっぽい」
「口数が少ない」
「気難しく、愛想が無い」

...それ、偏見です。

「スポーツ×IT×ヘルスケア」をテーマにしたさまざまな事業展開をする弊社FUBICは、
「働く人」も個性豊かなメンバーが多く、オタクなのは私ぐらいです。

早朝にテニスをしたり
退勤後にジムへ行って体を鍛えたり
休日にフィールサイクルに行ったり

エンジニアにしては意外とアクティブな人が多いです。

ただひたすら、エンジニアとしての技術を伸ばすだけではなく、
色んな体験・体感をして日々成長しています。

そんな中、先日エンジニアチームの全体会議の中で個人プレゼンが行われました。

内容は...
「技術に関することで、聞いた相手が感動すること」を
一人持ち時間10分でアウトプットするというものでした。

エンジニアに対するネガティブなイメージを払拭すべく、
「感動プレゼン」を目指してそれぞれ発表しました。

今回はそのレポートを記事にまとめました。

大谷さんのプレゼン

→プロフィールページ
テーマ：ポケモンでも分かる状態管理

社内では「あざとさ」で有名な大谷さんは、属性管理の手法に関するプレゼンでした。

ポケモンを使ってモンスターの属性（火、水、地、雷など）を2進数で管理する「ビットフラグ管理」というもの。

例えば、10進数で属性番号を管理した場合。

炎=1、水=2、地=3、雷=4 

このような感じになると思います。
しかしこの方法では、ボルケニオンのような火属性と水属性を持っているモンスターは10進数では1つのデータで管理する事が難しくなります。

炎=1000、水=0100、地=0010、雷=0001

このように管理する事になり、
ボルケニオンの属性番号は【炎=1000＋水=0100】＝【1100】このようなデータを持つ事で、火属性と水属性である事が分かります。
仮に属性が増えても、5桁、6桁...に増やす事で対応する事ができるため、非常に保守性の高い手法となっています。
属性を0と1のフラグで持たす事で、可読性も高い事が伺えます。

いかがでしょうか？感動できましたか？
少なくともポケモンというかわいいキャラであざとさを狙ってくる大谷さんに、私は感動しました。

ナイントゥさんのプレゼン

→プロフィールページ
テーマ：MEAN Stack

フロントエンドエンジニアらしいテーマを持ってきてくれたミャンマー出身のナイントゥさん。
MEAN Stackとは、MongoDB+Express+Angular+Node.jsの頭文字をとったもので、
4つを組み合わせてバックエンドからフロントエンドまで全部JavaScriptで開発してしまおうというものです。

聞き慣れないモンゴル...ではなく、モンゴディービー（MongoDB）は、
NoSQLでデータベースにアクセスできる、JavaScriptライクなデータベースで、フロントから入ったエンジニアも、馴染みやすいデータベースとなっています。

エクスプレッソ...ではなくエクスプレス（Express.js）は、
後に出てくるNode.js上で動作するWebアプリのフレームワークで、Node.jsでMVCフレームワークといえば一番に名前が挙がるほどメジャーなフレームワークです。

赤レンジャー...ではなくアンギュラー（AngularJS）は、
Googleによって開発されているJavaScriptフレームワークで、簡単に言うとjQueryの惜しいとこめんどくさいとこを補ってくれるすげーやつです。

ノデジェイエス...（そろそろネタギレ）ではなくノードジェイエス（node.js）は、
サーバーサイドのJavaScript実行環境です。フロントにしか馴染みの無かったJavaScriptは、実はサーバーサイドでも動かす事ができるのです。

今回、ナイントゥさんはMEAN Stackの概要を紹介するというプレゼンになりましたが、
彼はこれらを屈指して「リアルタイムアンケート」なるものを作ってみたいそうです。

新しい技術をシェアしてくれたナイントゥさんに拍手です！

土屋（巨匠）のプレゼン

→プロフィールページ
テーマ：スマートスピーカー

3番目のプレゼンは私（巨匠）です。
テーマはスマートスピーカー！？

という事で、他とは少し違う切り口でプレゼンを行いました。
スマートスピーカーはアメリカや中国では売れてるのですが、
国内ではまだまだ普及してない対話型AIアシスタントスピーカーです。

そんな私はAmazonが販売しているAmazon Echoを持っていて、
天気予報やアラーム、家電のON/OFFをメインで使っています。

プレゼンでひと笑い起こそうと...

土屋「アレクサ、巨匠って誰？」

と聞いてみると...

アレクサ「すみません、私には分かりません。」

という残念な回答を頂き、別の意味でひと笑いは起きました...本当は...

アレクサ「天才です。」

と答えてもらうように、Alexa Skill Blueprints（後述）で設定しておいたのですが、
ネットワークの問題だったという事にして、アレクサのメリットを3つプレゼンしました。

アレクサのメリット

1) Kindle対応の書籍はアレクサが全て読み上げてくれる
2) スキルはブルーオーシャン
3) ブラウザだけで自分だけのスキルが作れる

本は耳で楽しむ時代になってきました。
アレクサが本を音読してくれるのです。

Kindleの書籍はアレクサの声なので、若干聞き取りづらい部分もありますが、声優が読み上げてくれるAudibleの書籍にも対応しているので、アレクサをスマホのアプリと連動してしまえば、例え満員電車でも。真っ暗な寝室でも本を読む事ができます。

スキルという名のアプリは、iPhoneやandroidのアプリと同じ感覚で、リリースする事ができ、オリジナルスキルを他のユーザーに使ってもらう事も可能です。

スキルの開発はプログラミングが必要になるのですが、プログラミング知識が無い人でも、Alexa Skill Blueprintsを使う事でブラウザのGUIベースでスキルの開発が可能です。

どうでしょうか？
少しはスマートスピーカーを始めてみたいと思って頂けたでしょうか。
しかしこのプレゼンで感動できたかどうかは、疑問が残ります...

大畑さんのプレゼン

→プロフィールページ
テーマ：きっと感動するSQL

大畑さんは元々はシステムエンジニアではなく、弊社ドクターストレッチの店舗スタッフとして経験を経て、地頭の良さが買われエンジニアチームに異動してきたという背景があります。

そんな中、今回はSQL文だけで図を表現するという内容でした。
これを聞いただけでは「？？」かもしれないので、まずはこちらをご覧ください。

これ、全部SQL文で表示しています。
ここでは、SQL文までは割愛させて頂きますが、SQLと言ったらデータベースの追加、取得、更新、削除で使われるイメージが強いと思いますが、このように図を表現できるのは、おもしろいですね。

私個人としてはこの発想はなかったので、感動しました！

山口マネージャー

→プロフィールページ
テーマ：チームマネジメント

我らがマネージャー山口さんも、もともとは弊社リラクゼーションサロンのマネージャーをされていました。何百人ものスタッフさんのマネジメントの経験を経て、現在はエンジニアチームのマネージャーをされております。

今回もその経験から「チームマネジメントとは何か」という切り口でプレゼンされました。

良いチームとは

メンバー全員が参画意識を持ち1人1人が自分の頭を使って行動できている状態

弊社FUBICでは「目的」「目標」という言葉が良く出てきますが、1人1人がいかに目的を理解し、その為に自分の頭で考え目標に向かって進んでいく事が良いチームだと私も思います。
またプレゼンの中で、「リードマネジメント」と「ボスマネジメント」の違いについて解説されました。
みなさんはご存知でしょうか？

リードマネジメント

1) 相手の内側から動機付けを行う
2) 相手の行動を自分の思いどおりにコントロールしようとしない

相手の立場に立った、相手本位のマネジメントであり、「相手の欲求充足を支援するマネジメント」であると言えます。一方でボスマネジメントとはどういうものでしょうか...

ボスマネジメント

1) 相手の感情に関係なく指示やノルマを出す
2) 相手の行動を自分の思いどおりにコントロールする

聞いただけでもちょっと怖い印象ですね。
ボスマネジメントは、会社だけでなく、親が子供にしたり、先生が生徒に対して使ったり、というように、家庭や学校でもよく見られます。

弊社FUBICでは、リードマネジメントを採用しています。
個々のやりがいを尊重しながらマネジメントするので、最初は「仕事がつまらない」と思う人でもいつのまにか「仕事が楽しい」と思えるようになってくるのです。

プレゼンの内容は非常に参考になる内容が多かったので、こちらについては後日、別の記事で深堀していきたいと思います。

普段、山口マネージャーのプレゼンを聞く機会もないので、非常に新鮮な時間でもありました。

加藤さんのプレゼン

→プロフィールページ
テーマ：ER図半端ないって

ER図はデータベース設計をされた事がある方なら知っているかと思います。
データベースが必要なWEBサイトやシステムの設計では必ずと言ってよいほど作成される図です。

ER図イメージ

今回のプレゼンの目標は...

1) ER図が読めるようになること
2) できればER図が書けるようになること

という事で、ER図に馴染みがない人でも聞きやすい内容となりました。

ER図があるとイイこと

1) コミュニケーションが楽
　自然言語に依存しない（そう、英語に統一されていれば、ね）
2) できること、やりたいことがわかる
　「どんなデータ」を「どうやって持っているか」で、
　できることがわかる（そう、命名が悪くなければ、ね）
3) 改修する時の調査が楽
　プログラムを見に行かなくても、
　確認できる情報が多い（そう、正しく正規化されていれば、ね）

うん、色々と前提はありそうですが...（笑）

私も現在開発している大規模システムでER図を作成しました。
ER図は頭を整理する意味でも非常に有効だと感じており、データベースの構造を頭に叩き込みやすくなる事もメリットと感じています。

課題に感じているのは、ER図ドキュメントの管理ですね。
設計を進める中で、データベース設計が変更になる事はざらにあり、その際にER図もアップデートできるような運用体制ができる事が理想ですね。

プレゼンの落としどころとしては、
ER図はテーブル設計にも使えるけど、要件を整理する際にも使える。

このサービスではどんな「もの」がどんな「要素」を持っていて、
どのように「関係」しているかを整理、定義するときに使いましょう！

ER図半端ないって！

ue yさんのプレゼン

→プロフィールページ
テーマ：問題解決の技術

最後のプレゼンテーターはue yさん、リモートによるプレゼンでした。
エンジニアという仕事の本質は「問題解決」だと思います。

困っている依頼者が居て、その困っている事を解決してあげる為に、SEが設計してプログラマが形にするというのが基本的な流れです。つまり、その困っている事には「目的」が隠れており、その目的をくみ取ってあげる事で、問題解決に繋がるのです。

問題とは？

1) 答えさせるための問い。解答を必要とする問い。題。
2) 取り上げて討論・研究してみる必要がある事柄。解決を要する事項。
3) 困った事柄。厄介な事件。
4) 世間が関心をよせているもの。話題。

エンジニアの方なら一度は経験した事があるかもしれません。

依頼者「この機能をこのように修正してください」

このように依頼された場合、あなたならどう対応しますか？
そのまま言われた通りに実装しますか？...答えは「No」です。

依頼者は（現状やりたいことを実現できなくて、こうすれば出来ると思うから）「この機能をこのように修正してください」という発言になるので、まず掴むべきは現状やりたいことであり、それを追求して（理想の状態を得るためにやりたい事があるが、それが実現できないため）…という所まで上手く導き出せると、「理想の状態を実現するために何をすれば良いか考えましょう」となり、お互い同じ方向を向いて解決策を導き出せるようになるということです。

問題解決とは、**本人すら知り得ていない理想**を深堀りし、その理想を実現するステップを考えること。エンジニアは、それについて**技術を用いて**理想を実現させる職業である。これが出来るようになると、エンジニアとしての価値が高まると私の経験上でも思います。

これはエンジニアに限った話でもないと思います。社会人として仕事を進める中での「本質」をプレゼンしてくれたue yさんに感動しました！

以上、7名のエンジニアチームのプレゼンが終了しました。

プレゼンを終えて

今回、「感動」をキーワードにそれぞれ個人プレゼンを行いました。
プレゼンの本質は、

「受け手の欲求に準じて、自らの主張を、受け手に理解してもらい、
　納得・共感を得る事によって、期待する行動を起こしてもらう事」

ですので、感動の先には何かやってみようという行動が生まれると思うので、
少しでもやってみようと思ったら「感動」できた証拠だと思います。

エンジニアの物作りに置いては、ただ作る事ではなく、
作ったシステムが利用されてユーザーが感動している状態まで行くと、
「エンジニアは人を感動させる事ができた」と言えると思います。

これからも感動されるような物作りをしていきたいと思ったプレゼンでした。
最後まで読んで頂き、ありがとうございました。