
スクラムを導入したが全然上手く行かなかったプロジェクトを見聞きするたびに、

「それ、スクラム以前の問題ですよね」

と言いたくなる事が少なくありません。

ストリーポイントがわかりにくい
会議が多くなって時間が取られる
スクラムはもはや時代遅れで~~

など色々スクラムに対する難癖をつけたり、手法の良し悪しに終止する意見も散見されたりします。

しかし、うまくいっていないプロジェクトの大半が、

**毎週(スプリント)の成果がしょぼいだけ**

ということは決して珍しくありません。

* スプリント開始時に計画したチケットが振り返りの時点で全然完了していない。
* 完了していないことに対する追求も弱く、またチーム全体に緊張感がなく弛緩している。
* 仕掛中のチケットが無数に溜まっているのに、誰もそれを異常だと思っていない。
* 振り返りも表面的な問題や関係者に対する不満などが挙げられるだけで、自分の成果がしょぼい原因に切り込む様な発言はない。
* デイリースクラムも、今日やること/昨日やったことをただ各々報告するだけ
* スプリントの終わりに期待される成果に対するギャップはどうか？今日何に集中するべきか？のについては誰も触れないし、ツッコミもない。
* そもそもスプリントプランニングも適当にチケットをバックログからポイポイ入れてるだけで、スプリントのゴールも不明瞭かつ妥当性もない。
* スプリントレビューも延期を繰り返し、大量の仕掛り作業ばかりで論点がないので、スプリントプランニング会議自体がスキップが続くこともある。

こんな状態なのに、多くの人は見積もりの精度が甘いだの、会議体が機能していないだの、元々の計画に無理があったのだと言ったりします。

シンプルに、 **毎週(スプリント)の成果がしょぼい** という現実に目を向けていないチームが本当に多いのです。

## 完了だけが進捗

「この作業は50%程度の進捗です」

などという人の話は聞いてはいけません。
**完了だけが進捗です。**

完了していないものは、1%でも90%でも進捗0と同じこと。同じ仕掛中の作業です。

そりゃ1%と90%を一緒にするのは暴論だと思うかもしれませんが、

プロジェクトオーナーの立場から言えば同じことです。

90%までかけた時間と残り10%の時間が比例するとは限りません。

あくまで自分が90%だと思っているだけで、**完了するまでその仕事の本当の大きさは確定しません。**

だから、完了以外を進捗としてはいけません。

完了しか進捗として評価されなければ、自ずと定期報告会までになんとしても自分の作業を完了にする動機が生まれます。

自分が担当しているチケットを完了するためには何が必要かを嫌でも考えます。

スクラムのいいところは、プロジェクト中に何度も締め切りが訪れるところです。人は締切がなければ頑張りません。

締め切りというぐらいだから、それまでに作業は完了しなければならないのは当然のことです。

**中途半端な仕掛を進捗とみなした瞬間からスプリントの成果がしょぼくなる** という現実を受け入れましょう。

## 完了は厳格に定義する

完了だけが進捗とするならば、完了を厳格に定義する必要があります。

完了が曖昧な状態だと、そもそも作業を完了できないという問題以外にも、

本来の完了条件を満たしていないにもかかわらず完了としてしまう問題が根深いです。

そんなことをしたら、「完了していないのに進捗とする」とやっている事は変わりません。

このチケットが完了するための条件は可能な限り厳密に定義するべきでしょう。

完了条件は、作業状態だけではなく誰がその完了を承認するのかも決まっているべきでしょう。

作業者が完了と思ったら完了など、遊びの余地を作ってはいけません。厳格さが必要です。

もちろん、承認までのリードタイムが長すぎるのは問題です。

承認者は可能な限り固定にせず、複数人で、理想的にはチームメンバーの誰もが承認者になれる状況を作るのが好ましいでしょう。

このように、スプリント内に取り組むチケットの完了条件を精緻化する作業は、PMにとって最重要タスクといっても過言ではありません。

万一定義されていないチケットを担当した人は、完了条件を明確にするための行動を取らなければいけません。

チームの全員が、**「この仕事の完了とは・・・？」という哲学的なマインドになるように徹底的な教育が必要**です。

## スプリント成果にコミットする

スプリント中にやると決めた事は、「チームとステークホルダとの間のコミットメント」としてください。

スクラムの文脈では、「見積もり」は「コミットメント」ではない。という言葉がよく使われます。

確かに、数ヶ月の期間を要するプロジェクトの納期見積もりをコミットメントとするのは暴論です。

見積もりが誤っており、想定外に時間がかかってしまい、結果として約束を果たせないことは十分想定されるべきことです。

しかしごく短期間のスプリント中にやると決めた事を約束できないなら、誰がこのプロジェクトの成功を信頼できるのでしょうか？

誰がこのプロジェクトが着実に前進していることを保証するできるのでしょうか？

スクラムの思想を都合よく解釈して、開発者が自身の成果に対する責任逃れをする様な態度であってはいけません。

スプリント内にやる事は、**チームが十分に達成可能だと判断でき、ステークホルダの期待値に応えられる妥当な落とし所**でなければいけません。

チームが十分に達成可能だと客観的に判断できるようにするためには、チームの生産性をモニタリングする必要があります。

そのためにストーリーポイントという相対見積もりの手段を使います。

プロジェクトの最初にストーリーポイント見積もりをやっただけで、ベロシティの計測や、継続的なポイントの見直しが伴わないのであれば、

ストーリーポイントによる相対見積もりなどやるだけ無駄です。

また、長期的な見積もりは間違っても、短期的な見積もりを大きく外すことはあまりありません。

もしスプリント計画を大きく外したとしたら、見積もりと計画をサボっているか、そのスプリント内の作業をサボっているか、どちらかでしょう。

スプリントの成果にコミットメントするとなったら、真面目に見積もります。

見積もるだけじゃなくて、成果を上げるための計画も練るはずです。

**毎回のスプリントプランニングの精度が、スプリントの成果の大半を決めます。**

それほどスプリントプランニングは重要なイベントなのです。

## コミットした事はやり切る

コミットしたならやり切りましょう。

やり切る為には、各チケットの完了条件・着手順・TODOなどを可能な限りスプリントの初期段階で精度を上げておきたいです。

チケットの粒度が大きければ、担当者が1日以内に完了できる粒度まで分解しましょう。

誰が何を着手するべきかを各担当者にまかせてはいけません。その瞬間に一番ふさわしい人物が着手できるように調整をするべきです。

デイリーの会議だけではなく、日になんどもこの調整を入れる時もあるかもしれません。

個人の作業が滞る原因は常に取り除く努力をしましょう。

勉強会やペア(モブ)プロなどそのチームや状況にあったやり方はあると思います。

相談し易いコミュニケーションのツールや仕組みも改善余地があるかもしれません。

このスプリントだけやりきればいいわけではありません。

全スプリントやり切る必要があります。100%の力で走り続ける前提は破綻します。

80%の力でも必ず成果を出す為にはどうすればよいかをチーム・個人で知恵を振り絞らなければいけません。

時には短期的な生産性を犠牲にしてでも、後続のスプリントの成果を高める取り組みを選ぶ必要性もあります。

この様にチームやプロジェクトの状況によって、やり切る為に必要なことは異なります。

**だからチームで定期的に振り返り、どうやったら約束した成果を挙げられるのか？を真剣に話し合い、改善につなげる必要があるのです。**

徹底的に、コミットメントしたことをやりきれない理由を排除してください。

見積もりが悪いとか、納期が厳しいという話をする前に、自分たちのできる限りの最善を尽くす事から始めましょう。

## 約束を守れない時は早く言う

ここまで努力を積み重ねてもなお、コミットメントした成果に届かないこともあります。

そんな時は、それがわかったらすぐに然るべき人間に報告しましょう。

悪い内容の報告は早ければ早いほど価値があります。直前で間に合わないことを伝えられても無価値です。

毎週やり切るマインドのチームが、できないと判断した事はたいてい本当にできません。

できないことは早く分かれば対処はできるものです。

徹底的に自分たちができることをやり切っているチームは、スプリントで積み重ねた成果によって、自然にステークホルダーから信頼されています。

信頼しているチームからの悪い報告を受けた時、「よく教えてくれた」と感謝をし、建設的な代替策を一緒に考えたくなるものです。

間に合わなくなってから、営業やマーケティング、POなどの悪口を言う様なレベルの低いチームにはなってはいけません。

以上。毎週当たり前の様にやり切るチームになりましょう。

スクラムの導入で問題が生じる場合、それはスクラム以前に存在した課題が影響していることが多いです。プロジェクトを成功に導くための筆者の経験に基づく超基礎的かつ重要なポイントをご紹介します。

スクラム以前に大切な、毎週やり切るプロジェクトマネジメント

※ 本記事は[過去にQiitaで投稿した記事](https://qiita.com/YudaiTsukamoto/items/06b426f4dbee268d5035)を転載したものです。

# はじめに
この話は、弊社のとある新規プロジェクトの立ち上げで実際にペアプロを導入した話です。
プロジェクトでは初期メンバーとして私を含めた4人の開発者がアサインされました。過去のプロジェクトで比較的うまく機能していたアジャイルの導入や、ソフトウェアテスト・静的解析ツール等を徹底してコードの品質を担保するなど、アプリケーション開発する上での準備を入念に行いました。

そんな中、同じプロジェクトにアサインされた同期の@Takuan_Oishiiから

「<font color="red">**今回は絶対にペアプロをやりたい。意地でもやらせてくれ。**</font>」

と、熱烈な提案を受けました。

ペアプロの提案を受けた時、**以下の理由**から正直言って僕は懐疑的で導入をためらっていました。

* 単純に手を動かす事ができる人間が減ってしまうのは非効率なのでは？
* 人と話をしながら集中力を持続することが可能なのか？
* 開発者の精神衛生を保つ意味しか無いのではないか？

しかし、同期の提案の中の**以下の要素**が決め手となり導入することを決定しました。

* 開発メンバーのうち半分は学生インターン生で、ペアプロで**開発と育成を同時に進められる**かもしれない
* **新規プロジェクトこそ、新しい取り組みがやりやすい**という過去の経験知
* <font color="red">**「個人がコードに責任を持つのではなく、チームでコードの責任を持つ組織にするべき」**</font>という考えに心を打たれた

導入をすすめるにあたり、最低限以下の2つをモニタリングしてペアプロの実質的な効果を検証することにしました。

* **実質的にチームの生産性が高まるか**
* **ジュニアメンバーの育成に効果的か**

タイトルがネタバレなのですが、結論としては上記2点双方に良い結果が出ました。正直、いい意味で予想に反しました。
以下、僕達がどのようにペアプロを導入し、どのような影響があったかを説明していきます。

# そもそもペアプロとは

ペアプロとはペアプログラミングの略称で、**2人のプログラマが1つのPCを前にして共同でプログラムを書いていく**開発スタイルです。
ペアにはドライバとナビゲータという役割があります。

* **ドライバ**
    * 実際に手を動かしてコードを書く人
    * ナビゲータのサポートの元、プログラムを完成させることに集中する
    * 実装の細かい部分を考える
* **ナビゲータ**
    * ドライバが気持ちよくコードを書く事をサポートする人
    * ドライバが書いたコードを横から常にレビューする(コーディングスタイル、バグのチェック、コードの簡潔化の提言、etc)
    * プログラムを書く上での大局的な問題を考える

ペアプロでは、このドライバとナビゲータの役割を定期的にスイッチしながら開発を進捗させていきます。

ここではペアプロの詳細な説明は省きますが、ペアプロの基本的なやり方は上記のとおりです。

# どのようにペアプロしていたのか

## ペアの組み合わせ

導入したプロジェクトのメンバーは

社員2名(僕, 同期(@Takuan_Oishii))
インターン生2名

の合計4名の開発チームで、ペアのパターンは以下の3つでした。

* **社員×社員**
* **社員×インターン生**
* **インターン生×インターン生**

開発当初、社員とインターン生ではスキル・経験知共に差があったので

**社員×インターン生**

のパターンをメインで社員とインターン生の能力差を徐々に埋め、チャンスが有れば他の組み合わせでペアプロをしていました。

ペアの組み合せは毎日始業時に決めますが、ペアの作業が完了したタイミングで一度ペアは解散になります。
そして、可能であれば他のペアと組み合わせを交代して、**なるべく組み合わせが膠着化しないよう**にしています。
ペアが膠着化すると、**そのペアだけが知っている情報・経験が増大して仕事の属人化を引き起こす**可能性が上がるからです。

## ペアの着手するタスク

着手するタスクは、**原則タスクに着手可能になったタイミングで決めます**。裏を返すとどの開発タスクを誰が着手するかを決めていない事を意味します。

このやり方を選んだ理由は大きく分けると以下の2つです。

* そもそもいつどの組み合わせのペアになるかがわからない
* **どの組み合わせのペアだったとしても、あらゆるタスクを完了することができる**チームを長期的に作りたい

その為、場合によっては**特定の機能の開発を、タスクを細かく分解した上でペアを交代してすすめる**こともあります。
短期的にはペア交代のオーバヘッドで生産性は落ちますが、機能開発における知識と経験がチーム内で自然にシェアされるので、その後新しい機能を開発する際にどのペアの組み合わせでも可能な状態をキープでき、トータルでプラスになると判断してこのやり方を進めています。

ただし、プログラマのモチベーションや学習意欲を尊重するため、**どうしてもこの機能を自分が作りたい！という場合は着手予約宣言して良い**ことにしています。プログラマ自身がやる気を燃やせなくなるルールにするのは本末転倒なので。

また、タスクを選定する基準は以下の2点です。

* タスクの優先順位
* タスクの重さ

全てのタスクには、優先順位がざっくり振られていて、基本的に上から順番に着手します。
そして、同じ優先度のタスクの中でも、なるべくその日のうちに完了できそうな重さのタスクを選定します。これは、仕掛り作業を次の日に持ち越してしまうことでペアの組み合わせの柔軟性が下がることを防ぐためです。
仮にどのタスクも重すぎてその日のうちに終わらない場合は、その日のうちに終わる粒度にタスクを細分化することで解決しています。

また、非常に重要な機能の設計や新しい技術の導入をする場合は、設計だけチームメンバー全員で実施して、開発をすすめる上で**可能な限りメンバー間の知識差が無くなる**ようにしています。

# ペアプロによるチームの生産性への影響
チームの生産性の指標は、アジャイル開発を導入していることもあり、ストーリーポイント消化の平均ベロシティで計測することにしました。ストーリーポイントの細かい説明は割愛しますが、タスクの大きさを見積もる際に絶対的な大きさで見積もるのではなく、タスク同士の相対的な大きさに着目する見積もり手法です(ex: BはAよりも3倍ぐらい大きなタスクだからポイントを3にしよう)。

以下が、ペアプロを導入したプロジェクトと過去のプロジェクトでのチーム平均ベロシティの比較です。
(過去のプロジェクトのタスクと比較してストーリーポイントは見積もり直し、平均ベロシティはチームメンバーの人数比に対応して公平に計算しています)

|項目|ペアプロ導入プロジェクト|過去プロジェクト|
|:---|:---:|:---:|
|ベロシティ| 22.0 | 18.8 |
|比率(過去を100%)| 117% | 100%|

ペアプロを導入したことで、過去のプロジェクトと比較してもベロシティが大きく向上したことがわかります。

メンバーが違うことによってそもそもチームの生産性が違うから比較の意味が無いでしょ！という意見もあると思いますが、過去のプロジェクトは全員が社員だったのに対し、ペアプロを導入したプロジェクトは半分がフルタイムではない学生インターン生だったことを考慮すると、むしろ不利な状況の中で優位な結果を出したことにもなりますし、両方のプロジェクトにいた自分としては体感的にも明らかにベロシティが速いことを実感できました。

# ペアプロによるジュニアメンバー育成への影響

ペアプロを通してインターン生の育成にどのような影響を与えたかを、2パターンのペアの組み合わせで説明します。

## 社員×インターン
このパターンは非常わかりやすく、かつ意図通りの結果になりました。
[ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習](https://qiita.com/hirokidaichi/items/27c757d92b6915e8ecf7)でも紹介されている様に、**成長を阻害する悪い習慣を早い段階で察知でき、良い習慣を目の前で実践して教える**ことができます。

ペアプロ導入前は、ジュニアメンバーから飛んでくるPullRequestをレビューしながら鬼の形相でコメントをしていましたが、そのコードを書くに至るまでのプロセスの情報が抜け落ちていたため、なぜアウトプットの方向がずれるのか？なぜこの設計をしたのか？という**原因を特定して、適切なフィードバックをすることが難しかった**のです。

しかしペアプロをしていると、上記の様な課題は大幅に軽減されます。
ペアで作業をしながら、ジュニアメンバーが理解できていない時は雰囲気や行動で即座に判断でき、そしてその原因をその場で確認することができるからです。

また弊社のインターン生は、社員とのペアプロをやった後で、以下の様なプロセスで知識を定着するサイクルを回しているので覚えも速く、日に日にできることが増えていく実感を社員・インターン生双方が感じ取っています。

* その日のペアプロで学んだことをメモにまとめる
* とくにわからなかった部分を公式ドキュメントを読み込んでまとめを作る
* そのまとめをペアをしていた社員にレビューしてもらい、正しく理解しているかをチェックする

## インターン×インターン

一方、社員×インターンの組み合わせばかりだと、自立したプログラマに育成するのは難しいと思います。
社員×インターンのペアでは、社員がインターン生に対して一方的にインプット・指示する時間が多くなりがちで、自発的に思考して行動することを経験しにくいからです。

先日読んで大変感銘を受けた、 [一つ上のチームメンバーのそだてかた](https://qiita.com/hondaYoshitaka/items/273f5e674fe3c1663a38)によると、

SL理論 (Situational Leadership)というメンバーの能力とモチベーションに応じて発揮すべきリーダーシップを表したモデルが存在し、S1->S2->S3->S4という順番で育っていくことが望ましいとされています。

![SL理論.png](https://qiita-image-store.s3.amazonaws.com/0/76641/415f39c7-dd35-4b67-447d-08c98f7b3bc9.png)
(参考 : http://www.earthship-c.com/leadership/situational-leadership-theory.html)

この図でいうS1->S2までは社員×インターンの組み合わせで十分に効果的な育成ができますが、S2->S3->S4の育成には向いていないという事が直感的にわかります。

ここで、S2->S3の育成に効果的なアプローチがインターン×インターンのペアプロだと感じています。

インターン×インターンの理想的なペアプロの流れは、以下のとおりです。

1. ペアで着手するタスクを決める
2. インターン生同士で、タスクの要件詰めやTODOの整理を行いGithubのIssueにまとめる
3. 社員に声をかけてレビューを受ける
4. 社員のレビューを通過した後に、立てたTODOにもとづいてタスクを完了させる

別にこれペアプロじゃなくても良くないか？と思う方もいると思いますが、インターン×インターンが非常に効果的に働く要素が一つあります。それは、**自分の意見や考えを相手に発信する**というハードルが大きく下がる事です。

ジュニアメンバーの中には、自分よりも経験や知識が豊富な相手に対して**自分の意見や考えを伝えることに抵抗や恐怖心を持つ**人もいます。もしこれが仮にペアプロではなく、インターン生が個人でタスクを推進するケースに置き換えた場合、心理ハードルが邪魔をしてなかなか前に進めない可能性があります。
S2->S3に移行するためには、自律的な発言・行動量を増やすことが必要となり、インターン×インターンのペアプロはこの遷移ハードルを下げます。

事実、試しにインターン×インターンのペアを一日やってもらった後に、社員×インターンのペアを組んでみたら、以前と比較して格段に自分の意見を言ってくれるようになり、僕がドライバーの時に

「**あ、そこ違います。こうしないと駄目です。**」

と、社員のミスを指摘してくれるようになりました。頼もしい。

後にそのインターン生に聞いてみたら

「インターン生同士で自分の考えを言うのは**凄く言いやすく楽しくて**、社員とのペアプロをする時も**同じような感覚でペアプロしてみた**ら意外とちゃんと発言できました」

という答えが帰ってきました。この心理ハードルは馬鹿にできないし、おもったよりもシンプルな方法で解決できる可能性があるということをインターン×インターンのペアプロをやってみて学びました。

さらに、S2->S3に遷移したのち、インターン生から

「**イテレーション内で1つでもいいから自分ひとりで全部タスクを完了させてみたいです**」

という提案ももらい、インターン×インターンのペアプロによって、S3->S4への遷移の足がかりになる環境を作る事もできることがわかりました。

# ペアプロを導入してみて
ペアプロを導入して、いいことづくめだったプロジェクトですが、それはペアプロという仕組みが素晴らしかったという事もありますが、<font color="red">**「個人がコードに責任を持つのではなく、チームでコードの責任を持つ組織にするべき」**</font>という考えを基本哲学として、「あの人しかできない仕事」を無くし、社員・インターン生の差を徹底的に無くしていくという取り組みが産んだ結果なのかもしれないと思いました。

思うと、ペアプロ懐疑派だった時の自分の考えは、個人の力を過信して他者の力をあまり信頼していない心から来た考えだったのかもしれません。

# 終わりに
新しい開発スタイルの導入は楽しくも有り、周りを巻き込む必要があるためとてもエネルギーのいる行為です。少しでも導入の成功確率を高めるには、信頼関係を強固に築いたメンバー達同士で、小さくトライしていく事が重要だと思います。実質的な成果を示すことで、他者を巻き込んで組織全体に浸透させていく事ができると私は考えておりますので、今後は弊社の他のプロジェクトでもトライしてもらえる様に、引き続きこのペアプロの実質的な成果を作り続けようと思っています。

ペアプロを実務で導入したことによって、想定以上の効果が得られた体験についてまとめています。

ペアプロ懐疑派だった僕が、実務でペアプロ導入して180度考えが変わった話

プログラミングを勉強・学習する際に筆者が最も大切だと考える7つの習慣を説明します。

プログラミング勉強を加速させる7つの習慣

# 小麦の奴隷LABO　自由が丘

2022.4/6(水)オープン日に行ってきました！  
昼過ぎに到着したため、種類は少なくなってましたが**３種類のパン**を購入。  

- **ザックザクカレーパン**　¥290
![購入パン](//images.ctfassets.net/hxpvgdsklqwn/3gmG3dNV779n5By3IeYbkD/b3e5eb80ea977e7710a2285a66628b3a/DSC04953.JPG)

「小麦の奴隷」といえば、これ。  
見た目のインパクト大！のクルトンがたっぷりついたカレーパンです。  
食べ始めは、クルトンのカリッとした食感、そしてふわふわのパンの甘みを感じました。  
食べ進めていく内に、中のカレーと周りのパンの味が混ざり美味しい！  
カレーの辛さは、甘口と中辛の中間くらいで、どの年代も食べやすそうです。  

- **バター多くない？もちっと塩パン**　¥140
![塩パン](//images.ctfassets.net/hxpvgdsklqwn/5Qfv0f2WSkcfGJqbBHVRNu/b47dff2b4a0437366938576e76bcdb83/DSC04952.JPG)

ネーミングの通りバターの香りがしっかりする塩パンです。  
一口かじると、「カリッ」といい音がして、テンションが上がります。  
パンの裏側がバターで揚げ焼きのようになっていて、美味しい！  
パン自体はもちもちの食感で、弾力がありました。  

- **フレッシュなやつら　トマトとチーズの胚芽パニーニ風**　¥390
![パニーニ](//images.ctfassets.net/hxpvgdsklqwn/3dIZJgIm8o9ekFqrg4Lbs0/aaceb7285c81fc4b6820e895e5be68cd/DSC04949.JPG)

入り口で接客していた店員さんから、  
「パニーニ美味しいですよ！」と力強くオススメ頂き購入。  
トングで持ってみると、見た目よりもずっしりと重みを感じました。  
トマトとバジルの良い香りがします。  
しっかり焼いたトマトの甘みが、後に残って美味しい！  
簡単に伝えると、マルゲリータピザの味です。  
店員さんがオススメする理由がわかりました。  

**結論：全部美味しい！**  

オンラインショップを見ると３０種類ほどのパンがありました。  
気になるパンがたくさんあるので、また食べて見ようと思います！  

ちなみに「小麦の奴隷」はアプリがあり、  
注文したパンを店舗で受け取れるようになっています。  
このサービスを利用しない手はないですね！  

また購入した際には、味の感想を書いていこうと思います。  

「小麦の奴隷」のパンを味わった感想をお伝えします。

小麦の奴隷に行ってきた

この記事は『LITALICO Engineers Advent Calendar 2021』の16日目の記事です。

今日は、DialogflowとGoogle Homeを使った音声入力で筋トレの記録をつけるアプリを作った話をします。

## 何を作ったか

タイトルのとおりですが、筋トレ後ににGoogle Homeに

「OK, Google. 筋トレ記録 スクワット10レップ3セット」

と唱えたら、スプレッドシートにその実績が記載されるというアプリケーションです。  
記録を参照して、Githubの草のようなものを表示させてニンマリすることを目的としたアプリです。

![スプ氏](//images.ctfassets.net/hxpvgdsklqwn/7xHUzUWgkAcUjkalLzlEhu/f204f611852b48a0686ee645137bf17f/____________________________2021-12-14_19.12.56.png)

![草](//images.ctfassets.net/hxpvgdsklqwn/6QySYezaEgGrguUT6ZZbnY/99fe8dfb74a14625a130b6bbec93f322/____________________________2021-12-14_19.12.16.png)

## 作った背景

コロナが始まってから、弊社でもリモートワークを前提とした業務がスタートしました。  
リモートワークをやっていて、多くの方が共感するであろう問題として **運動不足** が挙げられます。

私もご多分に漏れず運動不足に陥り、肉体の衰えが精神の衰えにつながるかのように、どんどん気持ちが落ち込んでしまいました。

人間の脳は狩猟民族の時代からほとんど進化していないと言われていますが、  
画面越しの人間と会話をして、コードを書き、ほとんどデスクから動かずに一日が終わるなど、本来の人間のあるべき姿からはかけ離れており、唾棄すべき生活習慣です。

このままではいけない。運動習慣を継続せねば！！

という熱い衝動が生まれ、運動習慣を支援するためのアプリケーションを作ろうと決めました。  
(はよ筋トレしろ)

習慣をつけるのは人それぞれのやり方があると思いますが、  
自分の場合は記録をつけて振り返るというのが最も効果があった施策なので、

**「筋トレの実績を楽しく、簡単にできる！」**

をテーマに記録アプリを作ることにしました。

## なぜ音声入力か？

自宅にGoogleHomeがあり、日常的にスマートスピーカーでいろんなタスクをこなしていたというのが前提としてありますが、

**アプリを開かず即座に記録ができる**

というのが一番の理由です。

筋トレで追い込んだあと、画面とか見たくないです。  
汗かいた体で椅子にも座りたくないし、スマホの画面も汗でスワイプうまく動きません。

また、記録もすごく複雑な内容ではなく、タイムスタンプ+αのメタデータ程度でよいので、手を使ったUIなどオーバースペックです。

何より、

**「Ok, Google」**

の一言で記録が始まるのどう考えてもスマートだなと。かっこいいなと。

そういう理由でGoogleHomeをベースにしました。

## Dialogflowって何

[Dialogflow](https://cloud.google.com/dialogflow/docs)は、Googleが提供する自然言語理解プラットフォームです。

会話形のUIを簡単に設計でき、Web・モバイル・botなどの外部の音声応答システムと簡単に統合できるサービスです。

Dialogflowは、エンドユーザーからの入力内容を分類し、Dialogflowのエージェントごとに定義された複数の **インテント** (ユーザーがやりたい事をまとめた意図を表すデータ)を結合し、エンドユーザーからの入力内容とマッチングします。

![intent-match-forecast](https://cloud.google.com/dialogflow/es/docs/images/intent-match-forecast.svg)

基本的なインテントには以下の要素が内包されており、エージェントはユーザーの入力にマッチするインテントとそれに対応するアクションを実行し、レスポンスを返します。

* **トレーニングフレーズ**
  * エンドユーザーの発言に含まれる可能性のあるフレーズのサンプル
  * エンドユーザー表現がこれらのフレーズのいずれかと似ている場合、Dialogflowによってインテントがマッチされる
* **アクション**
  * 各インテントに対するアクションが定義できる。
  * インテントが一致すると、Dialogflowによってシステムにアクションが提供される。
* **パラメータ**
  * 実行時にインテントが一致した際に、エンドユーザーの入力情報から抽出された値をパラメータとして提供
  * 日時、場所、人名など定義した値を構造化データとして使用できる
* **レスポンス**
  * テキスト、音声、視覚的なレスポンスなど、ユーザーに返却するレスポンスを定義
  * 入力内容の詳細の質問をしたり、会話を終了するなど

以下がインテントのマッチングとエンドユーザーへのレスポンスの基本フローです

![intent-match-respond-basic](https://cloud.google.com/dialogflow/es/docs/images/intent-match-respond-basic.svg)

インテントのマッチング後のアクションは、slackやGoogleChatなど主要なサービスへのインテグレーションが用意されていたり、webhookを利用して自前のシステムと連携することも簡単に行うことができます。

Dialogflowの詳細内容は、公式ドキュメントや詳しくかかれたブログ記事などがあるためそちらにまかせて省略することにします。

[参考: 公式ドキュメント](https://cloud.google.com/dialogflow/es/docs/basics)
※ DialogflowはDialogflow ESとDialogflow CSという2サービスがありますが、今回はESを使っています。

## システム構成

システムの構成は以下です

![DialogflowとGoogleHome連携の構造](//images.ctfassets.net/hxpvgdsklqwn/2kMaoXR1BhHnik5OLuwvcH/84f323eb3f2e409d63ebfc71e3150fa0/____________________________2021-12-14_18.45.47.png)

Google Home / Google Assistant -> Actions on Google -> Dialogflow -> Google Spreadsheet(HTTPサーバー化) の流れで入力を行っています。

Spreadsheetへの記入は、サクッと運用したかったのでGASを使ってスプレッドシートの記録のためのAPIを作り、Dialogflowからwebhook経由でリクエストを送っています。

## 記録の流れ

Google Homeへ「OK, Google」してから記録完了までの記録の具体的な流れを書いてみました。

![音声入力フロー](//images.ctfassets.net/hxpvgdsklqwn/6xuhiBIKvRUmpzR01vWIiX/5976fcd85d7742179de361698d0d4f32/____________________________2021-12-14_18.45.56.png)

今の所は、記録を開始した日時のタイムスタンプ、実施した種目、具体内容という3種類の項目を記録できるようにしていますが、レップ数やセット数などを分離してパラメータとして扱ったり、その他の内容を記録できるような調整も可能となっています。

また今回は1種目の記録を実施したらタスクが完了してしまいますが、「ベンチプレス 10レップ3セット ダンベルフライ 10レップ3セット」などのように、一回の音声入力で複数の種目の記録ができるようにするなど、工夫次第でどんどん便利にできるので奥が深いです。

## 使ってみてどうだったか

このアプリを作ってからまだ1週間ほどしか経過していませんが、**音声で記録がしたいが為に筋トレするまである**程度に、ほぼ毎日何かしらトレーニングを行っているので、この記録アプリはひとまず成功したといえるでしょう。楽しいんですよ、記録が。

今後の展望としては、筋トレの記録ついでに自分のコンディションを記録できると良いかもしれません。
体の調子や精神的な調子が、筋トレの実績とどのように関連しているのかを把握できると良いですよね。Fitbitなどの生体情報のログと連動するなども良さそうです。

さらには、Googleカレンダーに筋トレスケジュールを記載しておいて、予定と実績との乖離が発生したら、GoogleHomeからお叱りを受けるようにするとより継続性が高まるかもしれません。

などと自分のためだけの音声ログライフを発展させたくなります。  
スマートスピーカー楽しいなぁ。

## おわりに

Dialogflowとスマートスピーカのコンボはかなり優秀で、日常行っている任意のタスクをスマートスピーカー経由で実行できるようになるのがイケすぎてて脳汁が出ます。

真面目な業務での応用でいうと、福祉施設向けに提供(自社・他社含め)での支援記録の音声入力対応なんかもチャレンジできるかもなと考えています。福祉業界に特化した自然言語処理プラットフォームを作るなど、夢が広がりますね。

ということで、本記事はこれにて終了。

明日は [@sakagurachan](https://qiita.com/sakagurachan)さんがなにか書いてくれるみたいなので、是非見てみてください。

DialogflowとGoogleHomeを使って、日常のトレーニング記録を音声入力で実施できるアプリケーションを作った話をします。

DialogflowとGoogleHomeを使って筋トレログアプリを作った

<div style="background: rgb(41, 150, 155); color: white; padding: 0.5rem; border-radius: 4px;">
  本記事は、<a href="https://qiita.com/advent-calendar/2019/litalico" style="text-decoration: underline; color: white;" target="_blank">LITALICO Engineers Advent Calendar 2019</a>の19日目の記事です。
</div>

私は現在株式会社LITALICOのエンジニアマネージャとして働いていますが、学生までは半導体物性やセンサデバイスの開発など、ハードウェア分野の専攻だったので、現職につくまではプログラミングを実務で書いたことは一度もなく、プログラミング未経験からソフトウェアエンジニアになりました。

プログラミング経験やソフトウェア工学の専門知識を全く持っていない状態で、エンジニアとして採用されたのは当時素直に嬉しかったのですが、実は入社してからしばらく自分の「エンジニア」という肩書には常に違和感がありました。

## そもそもエンジニアとはなにか

エンジニアと言っても様々な種類や業界によって様々な定義や解釈がされていますが、技術従事者の国際的な区分は以下の3つに定義されます。

* エンジニア
  * 高度な専門知識の応用と構想力を中核能力とする工学技術者
* テクノロジスト
  * エンジニア・テクニシャンの中間的な性格を持つ技術者
* テクニシャン
  * 熟練技能を中核能力とする技能者

それぞれの大まかな特徴とをまとめると以下のようになります。

|       特徴         | エンジニア                       | テクノロジスト                       | テクニシャン                               |
| -------------- | -------------------------------- | ------------------------------------ | ------------------------------------------ |
| 問題           | 複雑で簡単な解が無い             | やや複雑だが対処法が存在している     | 実務で随時発生し、標準の解決方法がある     |
| 仕事の範囲     | 広い                             | やや広い                             | 狭い                                       |
| 必要知識レベル | 深い工学技術や抽象思考           | 原理の知識                           | 限定的原理の理解、実務知識やスキル         |
| 革新性         | 工学技術原理の新規の創造的な活用 | 革新的方法で新材料、方法、工程の活用 | 他に問題を起こさないで限定的技術問題の解決 |
| 主な仕事       | 設計・開発・計画                 | 計画・管理・実施                     | 製造・保守・各種作業                       |

冒頭で挙げた「未経験でも3ヶ月でエンジニアになれる！」という謳い文句のプログラミングスクールでは、Rubyなどのプログラミング言語を使用したWebアプリケーションの構築方法などを学び、実際に動作するアプリケーションを制作するなど、スキルや技能を獲得するカリキュラムがほとんどです。  
しかし上記の技術従事者の区分でいうとそれは**テクニシャンを養成するプログラム**にほかなりません。

そのため国際区分に則って考えると、「3ヶ月でテクニシャン(見習い)になれる！」という意味であれば問題ありませんが、「未経験でも3ヶ月でエンジニアになれる！！」というのはいささか誇大広告と言わざるを得ないと言えます。プログラミングスキルを習得することと、エンジニアになるというのは全くの別問題なのです。

このエンジニアとテクニシャンの違いの違いは、JABEEが提唱する[技術者教育認定制度が目指すもの](https://www.ieice.org/jpn/jabee/siryo2-1.html)や[新・技術者になるということ]([https://www.amazon.co.jp/%E6%96%B0-%E6%8A%80%E8%A1%93%E8%80%85%E3%81%AB%E3%81%AA%E3%82%8B%E3%81%A8%E3%81%84%E3%81%86%E3%81%93%E3%81%A8-Ver-8-%E9%A3%AF%E9%87%8E%E5%BC%98%E4%B9%8B/dp/484190610X/ref=dp_ob_title_bk](https://www.amazon.co.jp/新-技術者になるということ-Ver-8-飯野弘之/dp/484190610X/ref=dp_ob_title_bk))で詳しく書かれているので興味がある方は見てみてください。

## ハードウェアとソフトウェアにおけるエンジニアの違い

ハードウェアとソフトウェアでは製品開発のプロセスが異るため、技術従事者に求められる役割が大きく異なります。

ハードウェアでは、製品開発の一般的なプロセスはざっくりと以下のようになります。

1. 製品企画
2. 試作品の設計・開発
3. 原価計算・調達
4. 試作製造
5. 品質テスト
6. 本生産

これらすべての工程を同一人物がこなすのは現実的ではないので、製品の設計・開発をするエンジニア、製造管理をするテクノロジスト、実際に製造や作業を行うテクニシャンや作業員、など各工程別に完全に分業するのが一般的です。

そのためハードウェアの製品開発の現場ではエンジニアが製造過程の作業を実務上行うことはまずありません。それは、製造を実行することと製品の設計・開発をすることでは根本的に求められる資質や能力が異なるからです。

一方ソフトウェアの製品開発は、製造プロセスが存在しないため設計・計画・実装・テストの役割を分業する必要性は必ずしもありません。設計と実装の業務が表裏一体のため、同一人物がエンジニアのロールもテクニシャンのロールも同時にこなすことがありえます。

実際に現職ではそれらの開発プロセス内の業務を分業して行うのではなく、開発者は設計から実装、テスト、デプロイまで一気通貫で行います。この場合、エンジニアとテクニシャンの境目は個々人の業務内容で明確に分類できるすることが難しく、またあえてその区分けを明文化しなければならない積極的な理由がありません。

その結果、IT業界(特にWeb系)においては技術従事者をひとまとめに「エンジニア」と呼ばれる事が多いのではと考えています。実際に自分がエンジニアなのかテクニシャンなのかを意識して働いている人は自分が接した人間ベースではほとんどいませんでした。

以上のことから、IT業界内で広く知れ渡った「エンジニア」という認識においては「未経験でも3ヶ月でエンジニアになれる」は限定的には可能なのかもしれません。もうちょっと言うと、**IT業界において「エンジニア」の肩書を得るだけであれば3ヶ月もあれば十分**とも言えるかもしれません。

## エンジニアになるハードルが低いということ

エンジニアになるハードルが低いことは、それ単体で見ると喜ばしいことのように思います。理系離れという言葉が言われるようになって久しいですが、他の多くの科学技術分野は、高校生の時の文理選択と大学の学部選びによってほぼ決定されてしまいます。実際に、JABEE(日本技術者教育認定機構)においても、エンジニアの基礎教育期間は4年以上の専門教育(いわゆる学士)を必要とするとされています。

そのため多くの技術的な産業において、就職のタイミングで未経験からエンジニアを志すという選択肢そのものがほぼありえないのです(少なくとも3ヶ月というスパンでは)。

その点ITエンジニアは未経験からチャレンジがしやすいという点において、他の科学技術分野に比べてキャリアの選択自由度が高いということは素晴らしい特徴だと思います。

逆に言うと、プログラミングスキルを習得しているだけのテクニシャンと、高度な専門知識の応用と構想力を中核能力とするエンジニアが区別されずに同じ労働市場で戦わなければいけないという残酷な側面もあります。

エンジニアの肩書を得たとしても、ビジネスにおいてエンジニアに求められる役割を全うできなければ、せっかくエンジニアになっても思ったような仕事につけず、技術の流行り廃りによって自分の市場価値が左右され、最悪キャリア的に詰むリスクがあります。  
これまでエンジニアの採用面接を100人以上行ってきましたが、実際に多くの方がその壁にぶち当たり、市場価値と現収入が釣り合わなくなった結果転職活動に苦しんでいました。

## 未経験からエンジニアになるのはやはり難しいのか

社内では私も含め、未経験からエンジニアとして入社して活躍している事例はたくさんあります。その点で言っても全く不可能では無いと言えると思います。しかし、どの事例をとってみても簡単な道のりではありませんでした。

私はビジネスにおいてエンジニアに求められるものを以下のように定義しています。

**「複雑かつ未踏のビジネス上の問題に対して知識や技術を応用して創造的に解決すること」**

上記を成し遂げるために、私がエンジニアとして特に重要だと感じる素養は以下の4つで、それぞれ一朝一夕で身につけられるものではありません。

* 高度な専門知識と技能
* 問題解決能力
* コラボレーション能力
* 高い倫理観

### 高度な専門知識と技能
ソフトウェアエンジニアにとって、専門知識と技能は武器です。
プログラミング言語の習得、設計技法、プロジェクト管理の手法などの技能面の習熟はもちろん、コンピューターやブラウザの動作原理、ネットワークがつながる仕組み、データ構造とアルゴリズム、統計、情報数学など基礎的な知識の習熟など非常に多岐に渡ります。

それだけではなく、自身が置かれているドメインの知識や、財務や労務、組織などビジネスを取り巻く人・モノ・金・情報といった経営資源についての知識もまたエンジニアの武器になります。

これらすべての分野の習熟は不可能ですが、エンジニアとして常に自分の武器を磨き上げる習慣を持ち続けられるかが、様々なビジネス上の問題に対して活躍できるか否かを
実際に私や未経験で入社したエンジニアの部下も、入社から一日も欠かさない位のレベルで新しいスキル・知識獲得のために勉強し、おそらく累計100冊以上は分野問わず専門書を読んでいると思います。

### 問題解決能力
武器も正しく使えなければ意味がありません。

P・F・ドラッカーの残した名言に、

> 間違った問題への正しい答えほど始末に負えないものはない。

というものがあります。
技術者はとかく解決策に意識が向かい問題設定自体を軽視する傾向がありますが、本当にビジネスをグロースさせる問題解決を行おうとすれば、適切な問題設定こそが最も重要と言っても過言ではありません。

この力は、要求や仕様どおりにシステムを構築する過程では身につきません。今置かれているビジネス上の現状とゴールについて明確かつ事実情報に基づき把握し、現状とゴールの間に存在するギャップや不確実性を解消するための最重要な問題を設定した上で、解決方法を考えるクセを付けなければなりません。そしてその立てた仮説を検証するサイクルを繰り返すことで少しずつ磨き上げられる能力なのです。

もしエンジニアを志しているが、仮説を立てて実験的に検証するプロセスが働いている職場で許されないのであれば、職場の環境を変えるように周囲を巻き込むか、もしかすると転職を考えたほうが良いのかもしれません。

### コラボレーション能力

創造的な解決方法はたった一人では中々生まれません。前述のようにエンジニアが習得するべき知識や技能は多岐に渡り、一人ですべての分野をカバーすることは出来ません。異なる専門分野の人間と協調して解決方法を構築する必要があります。

またステークホルダーの利害を理解した上で、三方良しを生み出せなければプロジェクトの途中でちゃぶ台返しが起こったり、そもそも予算が確保できなくてプロジェクトが頓挫などが発生してしまいます。せっかく正しい問いの設定が出来ても、優れたコラボレーションを引き出せなければ意味がなくなってしまうのです。

エンジニアはその責務的に、関わる人間や影響を与えるステークホルダーが多くなる事が多いので、イメージと裏腹に高度なビジネスコミュニケーションやリーダーシップが要求されることが多いのです。

### 高い倫理観

エンジニアは、性質上自分の行動によって影響を受ける対象範囲が非常に広くなりやすいのと、専門家ゆえに、不正や間違いを他の職業の人間が見抜くことは非常に難しいため、自身の行動に対して高い倫理観と強い責任が伴います。

個人情報の漏洩などのセキュリティ面における問題や、障害発生時の顧客や消費者に対して発生する損害、サービス利用者間のトラブルやそれによって引き起こされる人命リスクなど、

エンジニアが作ったシステムのひとつひとつが、上記の致命的な問題を引き起こす可能性があるというリスクを負っています。ミスを防ぐという防衛的な視点も重要ですが、問題を認識したときに正しく屹然と対処することもまた重要です。多くの技術的な問題が、リスクや問題を認識して履いたがそれらを否認し続けた事によって引き起こされているのです。

この辺りの話は理工学系の大学の出身の方であれば「技術者倫理」という科目を履修していていればイメージが持ちやすいかもしれません。チャレンジャー号事件など、有名な技術的な問題によって引き起こされた事件の事例研究がテーマの科目で、[技術者倫理とリスクマネジメント](https://www.amazon.co.jp/dp/4274068722/)など、書籍もありますので気になる方は一度読んでみてください。

上記の4つ以外にももちろんエンジニアとして大切な素養はたくさんありますし、これらすべてを完璧に実現出来る人はほとんどいないと言っても過言ではありません。しかし、エンジニアという職業は、知識やスキルを持っていればそれで終わりという職業では無いことは間違いありません。それ故に奥が深く、決して簡単になれるような職業ではなく、だからこそやりがいと面白さのある仕事だなと思っています。

## おわりに

完全に私見丸出しの記事になってしまいましたが、IT業界で一般に言われているエンジニア像とその性質、工学の世界、ビジネスの世界で求められるエンジニアとしての役割や素養について普段考えていたことを整理するいい機会になりました。

とりあえず色々振り返って、個人的に「3ヶ月でエンジニアになれる!」というフレーズは口が裂けても言えないかなぁという感想を持ちました。

次回は[@hikariiiiiii](https://qiita.com/hikariiiiiiii)iさんのがなにか書くみたいです。お楽しみに！

「未経験でも3ヶ月でエンジニアに！！」という売り文句のプログラミングスクールの広告を見ることも珍しくありませんが、はたして3ヶ月でエンジニアになれるのか？という疑問について自分の考えをまとめました。

はたして3ヶ月でエンジニアになれるのか

<div style="background: rgb(41, 150, 155); color: white; padding: 0.5rem; border-radius: 4px;">
  本記事は、<a href="https://qiita.com/advent-calendar/2019/litalico" style="text-decoration: underline; color: white;" target="_blank">LITALICO Engineers Advent Calendar 2019</a>の5日目の記事です。
</div>

2年前のちょうど今頃、[webpack時代の終わりとparcel時代のはじまり](https://qiita.com/bitrinjani/items/b08876e0a2618745f54a)という記事がWebフロントエンド界隈で小バズリしていました。当時新規Webサービスの立ち上げをしていた僕は、webpackのドキュメントと戦いながら苦労してフロントエンドの環境構築したばかりだったので、「なんなのフロントエンド界隈、頭おかしいの？」と悲しい気持ちになったのを覚えています。

それから2年の月日が経ちましたが、相変わらずwebpackはデファクトのままで、一向にparcelの時代が訪れる気配はありません。正直なところ、開発環境の構築・設定にやたらと時間がとられるのは、Webの歴史的背景があったとしても面倒くさいとしか言いようが無いので、ぜひともparcelの時代を始めてもらいたいところです。

# なぜparcelの時代がはじまらないか

parcelは非常に優秀なデフォルトの設定を持ち、モダンフロントエンド開発に必要な大抵の事を実現してくれます。2年前と比べても、コードスプリッティングやHMR、対応するアセットの数やプラグインも増え、多くのユースケースに耐えるようになったと思います。それでも僕も含めて本番でparcelを使ってプロダクトを運用している人は周りであまり聞きません。

仮に自分が新規サービスを作る際にparcelの採用を考えると、以下の懸念が残ります。

* 少し凝ったことをしようとするとほぼ積む
  * それでも頑張ってプラグインを組み合わせていると、ゼロコンフィグってなんだっけとなる
  * ゆっても最小構成のwebpackの設定は意外とシンプルで導入コストも低い
  * じゃぁwebpackで良くない？となる
* 運用時の問題解決は知識なしでは難しい
  * 結局内部で何をしているのかを知らないといけない
  * じゃぁwebpackで良くない？となる

要するに環境構築のコストは低いが、長期運用をするにあたってのメンテ・学習コストは本質的にwebpackとあまり変わらない。それどころか**問題への対応オプションが少ないという点で大きな欠点**となる。

結果として、webpackをある程度知ってる人にとってはメリットが薄く、あんまりよく知らない人にとっても運用時の問題解決にリスクがあるので、**真面目に運用することを想定したプロダクトにおいてはparcelの時代が中々はじまらないのでは？**と考えています。

事実、npmtrendsを見ると今の所parcelの時代が始まる気配はほとんど無いように思えます。

https://www.npmtrends.com/parcel-vs-webpack

# 使いみちを見出してみた

一方で、parcelは**開発環境のことを何も考えずに、コードを書くことに集中できる**という、昨今の複雑化したWebフロントエンド界隈において非常に大きな強みを持っています。

メインプロジェクトでは中々日の目を浴びないが、逆に言えばサイドプロジェクトこそその本領を発揮するのではないか？そうだ、webpackと比較するからダメなんだ。もっとカジュアルに試せる場所でこそparcelが活きるはず！

ということで、今回たまたまInstapageというLP制作ツールのjs拡張のコードを書く機会があったので、その事例を通じて**parcelの実務での使いみちはサイドプロジェクトにあり**ということを伝えようと思います。

## Instapageってなに

[Instapage](https://instapage.com/start)はLP制作に特化したCMSで、ドラッグアンドドロップでUIパーツを配置し、レスポンシブ対応のLPを作成できるツールです。他にも、A/Bテストやヒートマップなどのページ内の分析ツール、各種MAツールとの連携をビルトインで備えており、Instapageを使うことでマーケタがLP制作から運用・改善までを一気通貫できるようになります。
![1](//images.ctfassets.net/hxpvgdsklqwn/4pyua8UZrThD2XYwOZ9tH4/ef87c36f60f8fb059e58bc9f6a2842d6/1.png)

これまで自社で広告用のLPを制作するケースは何度もありましたが、なけなしの開発リソースを注いでページを作ったものの、その後ページの改善はほとんどされなかったり、最悪の場合作ったけど運用してないこともも有りました。

この問題は、LPの制作スキルを持っている人間が広告成果について責任を持っていないため発生していると考え、マーケタ自身がLPの制作・運用・改善をある程度自立的に実現できるようにするべく、Instapageを導入することにしました。

## 困ったこと

Instapageは、ほとんどのページ制作をそのWYSIWYGエディタ上で完結することがでますが、例えばフォームのバリデーション、別サービスへのAPIリクエストやエラーハンドリング、細かい入力状態のロギングなど、ある程度凝ったことをしようと思うとどうしてもデフォルトの機能では実現出来ません。

そのためInstapegeでは、ユーザー定義のカスタムHTML, CSS, Javascriptの拡張機能を持っており、上記のデフォルト機能の範囲外のLPを作ろうと思った場合は自前でコードを書くことで対応できます。

![2](//images.ctfassets.net/hxpvgdsklqwn/ug15rmvLbae7KrhSomVQw/cb8d635f57991f7b6c7b75052257b337/2.png)

そして、今回どうしてもデフォルトの機能で実現出来ない要求に遭遇してしまい、その部分だけエンジニアがコードを書いて解決することになりました。

日頃TypescriptやReactなど近代のjsパワーの恩恵を受け、モジュール単位のスコープで開発することになれた現代のフロントエンドエンジニアにとって、今更vanilla jsで、グローバルスコープを気にして、レガシーブラウザ(IE)のためのコードがどうのこうの・・・などという辛い環境でコードを書きたくありませんでした。

でも、ちょっとした拡張のためのjsコードを書くだけなのにwebpack使って環境構築するのもどう考えてもバカらしすぎる。

「俺はただTypescriptで書きたいんだ。UIをReactで書きたいだけなんだ。非同期処理にasync await構文を使いたいだけなんだ。」

そう考えている内に、自然とparcelをinstallしていました。

## parcelの環境構築

```sh
yarn init -y

yarn add -D parcel@next
```

終わり。その他、TypescriptとかReactとかやりたいことに応じてインストールします。

Typescriptなんかは、tsconfig.jsonをルート直下に配置し、拡張子を`ts`, `tsx` にしておけばビルド時に勝手にコンパイルしてくれます。最高。


## 開発中

↓で 開発サーバーが起動します。`--https`オプションをつけるとローカルの証明書が生成され、ビルドしたアセットをhttpsで配信することができます。

```
parcel --https entryPoint.ts
```

ここで配信されるアセットのurlをInsapageの編集画面で読み込めば、エディタで書いたコードがそのままInstapageで作成中のLPに反映されます。普段と全く変わりなく、実際のLPの画面を見ながら自前のエディタで開発を進められるDXは本当に最高です。

## デプロイ

↓でプロダクション用のアセットファイルがビルドされます。

```sh
parcel build entryPoint.ts
```

仮にNetlifyなどのホスティングサービスを使い、githubのmasterブランチが進んだら自動でデプロイされるようにしておけば、デプロイフローもボタンポチポチしておわります。誠に幸せ。

あっという間でした。環境構築とデプロイなどめんどくさい事を完璧にスルーして、終始コーディングに集中できたことが本当に素晴らしい体験でした。

将来的には、**マーケタにフロントエンドの開発スキルを習得してもらい、そのままエンジニアの手から離せる**ビジョンがこの時点で見えました。parcel最高！


## その他の使いみち

Instapageだけじゃなく、他の多くのCMSやjs拡張が可能な外部サービスで同様の使いみちがあり得ると思います。現在社内でkintoneのプラグイン開発の用途でwebpackを使っていますが、webpackのバージョン更新についていくのがだるいのでparcelに切り替えようかなとも思っています。実際、[kintone jsカスタマイズ開発における webpack時代の終わりとparcel時代のはじまり](https://blog.r3it.com/parcel-on-kintone-e96d086155d1)という記事をみるに、kintoneのプラグイン開発界隈においてはすでにparcelが始まっている模様です。

また、仮説検証用のプロトタイプの作成や、社内向けの実験的なプロダクトなどの用途など、スピードと手数が重要なシーンにおいても非常に魅力的な選択肢になるのではないかと思います。実際に本格的に運用開発するとなれば、webpackに単に乗り換えればよいだけなので、時間対効果が非常に高い選択肢だと思います。

もしかするとWeb制作の現場であればもうすでにparcelで環境構築するのは実務レベルでもありなのかもしれないとも思いました。

ちなみに、parcelはnode.jsをターゲットにして使えるので、AWS LambdaとかでTypescript使いたいときとかも有効かもしれないです。思ったより応用範囲が広い。

# 終わりに

試しに実務で使ってみたら、最終的に思ったよりも使いみちあるじゃんという結論になりました。それによって自分の中で勝手にparcelの時代がはじまりました。何事もやってみて、良し悪し確かめるって重要ですね。

次回は[@kamesennin](https://qiita.com/kamesennin)さんの「職種横断でgithub/zenhubでプロダクト開発をして幸せになった話と見えた課題と今後」です！お楽しみに！

ゼロコンフィグなモジュールバンドラとして有名なparcelですが、私の周りで「実務で導入しているよ！」という声はあまり聞きません。今回はそんなparcelの強みを生かし、実務で導入して世界が平和になった話をしてみようと思います。

parcelの時代が中々はじまらないので使いみちを見出してみた

「あの人はセンスがあって羨ましい」

「自分はなんて才能なんて無いんだ」

これまで自分の周りでこういう言葉をこれまでたくさん聞いてきました。

そして、僕も時々思わずそうやって思う瞬間があります。

特にあまり経験の無いことをや、なんとなく苦手意識を持っている分野に取り組んでいる時に顕著にその考えが頭をよぎります。

しかしそうやって一瞬思っても、すぐに思い直して基礎基本に立ち返り、今できる事を淡々とやって行こうと切り替えてその局面を乗り越えるようにしています。

それは、**センスや才能があるのは有利なわけではない**という事を自分は知っているからです。

# 得意なはずの数学で落ちた大学受験

初めてその事を痛感したのは「大学受験」です。

高校生の時、自分で言うのもなんですが数学のセンスがある方でした。

授業は聞かなくても教科書を読めば内容を理解できたので、授業中はもっぱら難関大学の入試問題を解いて遊んでいました。

一方化学はものすごい苦手で、molや有効数字の意味がわからなくて授業についていけず、大学3年生の1学期の**期末テストで20点をとったときには、センスのかけらも無い**と絶望していたのを覚えています。

そういう状況だったので、自分では

**数学 = 得意で自分の武器**

**化学 = 苦手で自分の弱点**

という自己認識で、周囲からの見られ方も概ね一致していました。

しかし、僕は第一志望に**数学の得点が低い事が原因で落ちました**。

そして、後期で受験した第二志望は**化学が満点だったため合格することが出来ました**。

この認識と現実のアベコベ状況は当時の自分としては受け入れがたく、**長い間誰にも話せないコンプレックス**になってしまいました。

しかし、社会人になって当時の自分の事を冷静に分析すると、自分は**センスの裏に隠されたリスク**を全く認識していなかったのだと気づいたのです。

# センスとは特定の物事を広く認識する力

「そもそもセンスとは何か」という問は人によって解釈が分かれますが、僕の中で人がセンスと感じているものは

**「特定の物事を広く認識する力」**

であると考えています。

広い範囲で認識できると全体感を把握できるため、すばやく物事の重要なポイントを特定出来ます。  
そのため、センスがある人というのは**「理解が速い人」**と言い換えることが出来ます。

理解が速いと聞くと、地頭とか脳のスペックの問題に帰着しがちですが、理解が速いというのは頭の回転速度だけが関係しているわけではありません。

具体例として、**多くの人が数学を嫌いになる元凶の三角関数**を挙げて説明します。

**三角関数は、はっきり言って凶悪です。**これまでx, yの方程式の話でお腹いっぱいのところに、sin, cos, tan, θとか謎の記号がいっぱい出てきます。しかも公式もたくさん出てきて覚える事多すぎ・・・

でも、高校数学の範囲でサイン・コサイン・タンジェントを説明するとしたら以下の図一つで十分です。

![ninch1](//images.ctfassets.net/hxpvgdsklqwn/3qZT47BT9K2lcfvSb07dQR/a001d86077a75223975c496fa485238e/ninch1.png)

サインやコサインは半径1の円周上の点の縦・横の座標値だし、タンジェントも原点とその点とを結んだ直線の傾きの事を意味しているだけで、何も難しくないです。公式もこれで意味がわかるようになります。

実際に自分は高校1年生の時、先生や教科書の説明の方法ではなくて上の図で理解して、三角関数がわからないと言うクラスメートにはそうやって教えていました。説明した人のほぼ100%がこの図で理解してくれました。

これは頭の回転の速いからできるのではなくて、その分野において認識できる範囲が人よりも広く、**細かい事を一個一個考えないで、全体まとめて「要するにこういう事」と捉えている**からできるのです。いわゆる視点が高いとか、視野が広いというのはこの事を指していると思います。

音楽センスとか運動センスとかも同じで、細かいことにとらわれずざっくりと全体感を認識できる人ほど、**少しの練習や経験で大きな成果を挙げる**ことが出来ます。

そういう人を見ると、「この人はセンスがあるなぁ」と人は思ってしまうのです。

# 「理解が速い」は「誤解も速い」

ここまで聞くと、やっぱりセンスある人は有利じゃないか！！！と思うかもしれませんが、それはごく短期間を切り取っているからそう感じるだけで、実際は長い目で見ると**センスがある事にはリスクがあります。**

センスがある人の認知できる範囲とそうではない人の認知できる範囲を比較すると以下のようなイメージです。

![ninch2](//images.ctfassets.net/hxpvgdsklqwn/1PYrhLNK4RQB6Nzg0Cnxfq/72543d4cb5c6484bd71b88c89d333df5/ninch2.png)

認識範囲が広いほど、対象とする問題の全体感の把握と問題の重心の特定をスピーディに実現できます。

形がいびつなのは、一般的に人間の認知はそれまでの自分の経験や思考の癖などによって歪んでしまいやすいと言われているからです。

対象としている問題が簡単なうちはいいのですが、問題が複雑になるとこの認知できる範囲が広いというのは大きなリスクを伴います。

取り組む問題が複雑になればなるほど、**問題の重心から外れた特殊解を真実だと誤解する**可能性が増大してしまうのです。

![ninch3](//images.ctfassets.net/hxpvgdsklqwn/13uBxAt5QsmizWq5dPQ9VI/0cebe0a725f7caee89f7e88481aff9d8/ninch3.png)

そしてセンスがあってこれまで物事の全体感を簡単に把握する事が出来た人ほど、**問題の重心から外れているということを疑う事をしません**。なぜなら、大抵の問題はそんな事を疑う余地もなく全体感を把握出来てしまったからです。

認知できる範囲が小さければ、そもそも特殊解にすらそんなに速く到達出来ないので勝手に誤解して自爆することはあまりありません。**ただわからないだけ**です。

更に間違えてしまった時に、**「今回はたまたまうっかりしていた」**と、その誤解の原因を真剣に考えないで放置していると、どんどん認知が歪んで本来のセンスを活かすことが難しくなります。

![ninch4](//images.ctfassets.net/hxpvgdsklqwn/1nmjDCDfTxxttXy2r5nTYr/2793a8ffc7ca3bd646a37aa3995e328d/ninch4.png)

高校生の時の話に戻します。

高校の時自分は数学が得意だと思っていましたが、定期試験や全国模試の結果は常に1番。というわけではなく、ものすごいムラがありました。

偏差値70を超えるような得点を出すときもあれば、平均点を割るような微妙な点数を取ることもありました。

低い得点の時ほとんどのケースで、**うっかりミスや問題の読み間違えなど、冷静に考えたら間違える訳がない**ところで大量に失点していました。

その時は、「あー勘違いしてたなー。でも、まあ別にわかってなかったわけじゃないし、次は大丈夫。」

と、完全に今自分に起こっている事象を誤って捉えてしまっていたのです。

結局第一志望の大学の入試も、その**「勘違い」のせいで落ちました**。

# 不安定なセンスではなく安定した「理解」を積み上げる

センスが有る人にリスクがあるのはわかった。それでも、やっぱりセンスがある人と比べて自分は不利だ。と考える人は大勢いらっしゃると思いますが、実はセンスが無いと言うのは別にそれ単体では不利でもなんでもないのです。

人間である以上認知範囲の広さには限界があり、**必ずセンスだけでは解決出来ない難しい問題にぶつかります。**

そこに必要なのは**不安定なセンスではなく安定した理解と基礎を積み上げた土台**です。

センスが無いと言うのは、要するに**その分野について認識できる範囲が狭い**ということです。でも、先程も言ったようにセンスと頭の良さは別物なので、その狭い認識の範囲を正しく理解することは出来ます。

![ninch5](//images.ctfassets.net/hxpvgdsklqwn/5aL3gTuQOIUMnwA3G1gwR6/42149409426894a8de43009256102483/ninch5.png)

**認識できる範囲が狭いので認知の歪みによる影響を受けづらく**、一つ一つを正しく理解して積み上げる事ができます。正しく理解したことは、資産になります。理解したことは認知ではなく事実なので歪みようがありません。そうして、積み上がった膨大な基礎と理解によって**大きな問題を誤解なく確実に解決する**ことができるようになるのです。

![ninch6](//images.ctfassets.net/hxpvgdsklqwn/4DSe8nY80lul55Cj2onRDq/7800ff6e7323d435b6f080dd045d1527/ninch6.png)

一方、センスがある人ほどこの基礎理解を固める事の必要性に中々気づけません。なぜなら、**そういう基礎固めをしなくてもセンスで解けてしまっていた**からです。

そして気づいたとしても、これまで効率よく問題解決してきたセンスのある人が、**短期的に役に立ない基礎の理解を積み上げる事は想像以上に苦痛**なのです。

センスはあるのだけどある程度のレベルで伸び悩んでしまう人をよく見かけますが、シンプルに基礎理解が圧倒的に足りていないケースがほとんどです。薄々基礎固めの必要性に気づいていても、今さら基礎固めなんて・・・とやる気が起きずにくすぶってしまうのです。 

この様に、センスがある人は**学習の初めに基礎固めをする習慣を身に着け無いと、どんどん自分で自分の伸びしろを殺してしまうという最大のリスク**を抱えています。

高校の時に話を戻すと、僕はあまりにも出来なさすぎた化学をなんとかしようと、教科書の片っ端から全ての単元を何度も何度も**納得が行くまで読みました**。難しい問題集は殆ど解かないで、**教科書の基礎問題が絶対に解ける**様になるまで繰り返し解いていました。

なまじ苦手な意識が強かったので、問題は真剣に読むしわからない言葉は必死に調べるので、凡ミスは殆どなく「わかるから解ける問題」と「わからないから解けない問題」の2つしかなかったため、**わからない分野を無くすというアプローチに集中出来ました**。

最終的な結果は先程も言ったようにまさかの後期試験の化学が満点で、自分でも驚愕の結果でした。受験が終わってもなお、化学が得意教科というイメージは一切なかったので、何かの間違いじゃないかと疑ったぐらいです。

余談ですが、僕は大学院の専攻は化学系で現在でも最も得意な学術分野はおそらく化学だと思いますが、膨大な基礎と積み上げた理解があったからこその賜物だと思います。ちなみに数学は線形代数がわからなすぎて苦手になりました。

# 稲盛和夫の「人生の方程式」

これまでの話をまとめると、要するにセンスがある人とない人ではそもそも戦い方が違うということです。同じ様に比較しても戦い方が違うので、有利とか不利とかそういう概念では扱えないのです。

センスがある人は、認識できる範囲が広いことを武器に効率的で非線形の成果を挙げられますが、**常に自分自身の慢心と戦い続ける必要があります**。構造的に認知の歪みが起きやすく、理解するスピードと同時に誤解するスピードが速い人間である事を肝に命じ、驕り高ぶる事無く基礎固めをする必要があります。

センスが無い人は、すばやく全体感を捉えた効率的な学習・成果を挙げる事は難しいですが、慢心や誤解するリスクが低く、愚直に一個一個理解を積み上げる事で**自分が解決できる問題の範囲を線形的に伸ばし続けられます**。ある種戦術オプションが少ないから迷いようがないのが最大の強みですね。

社会人になって読んだ本の中で、最も心を打たれた稲盛和夫さんの[「生き方」](https://www.amazon.co.jp/%E7%94%9F%E3%81%8D%E6%96%B9%E2%80%95%E4%BA%BA%E9%96%93%E3%81%A8%E3%81%97%E3%81%A6%E4%B8%80%E7%95%AA%E5%A4%A7%E5%88%87%E3%81%AA%E3%81%93%E3%81%A8-%E7%A8%B2%E7%9B%9B%E5%92%8C%E5%A4%AB/dp/4763195433/ref=sr_1_1?ie=UTF8&qid=1550679925&sr=8-1&keywords=%E7%94%9F%E3%81%8D%E6%96%B9+%E7%A8%B2%E7%9B%9B%E5%92%8C%E5%A4%AB)という本の中に、

> 人生の・仕事の結果 = 考え方 × 熱意 × 能力

という稲盛さんの人生哲学が紹介されているのですが、まさに僕がこの記事で言いたいことはこの方程式に凝縮されています。

持って生まれた才能やセンスがあったとしても、**適切な考え方に基づいて適切な努力をしなければ思うような成果が挙げられない**し、才能やセンスに乏しくても、**自らの置かれた状況にめげずに正しく考えて正しく行動すれば、それに見合った成果を得られる**。

言葉にすると当たり前ですし、アリとキリギリス・ウサギとカメなどの寓話で昔から語り継がれている教訓なのですが、本当につい最近までこの考え方を自分の中で折り合いをつけられないでいました。**それぐらい実は人間にとっては簡単なようで難しいテーマ**なのかもしれません。

第一志望に落ちたというのもあって当時素直に喜べなかったのですが、今思うと自分の人生感のかなりの部分はあの時の受験での失敗によって構成されているかもしれないと感じ、人生何が自分の資産になるかわからないなと感じています。あの時受験で失敗していなければ、今もまだ誤解は解けていないままだったかもしれません。

# 終わりに

最近まわりの人から自分の強みとか向き不向きとかについての相談を受けることが多かったり、[「天才を殺す凡人」](https://www.amazon.co.jp/dp/B07MG34ZDX/ref=dp-kindle-redirect)等、自身の才能や与えられた状況に向き合う系の本を読んでいて、なんとなく考えをまとめたくなってしまったので、ややポエムっぽい感じでしたが書き連ねてみました。

同じような悩みや経験を持っている方に、少しでも前向きな影響を与えられたら幸いです。

センスや才能がある人を見て、自分はなんでああ生まれなかったんだと感じた経験は誰しもあるのではないでしょうか。今回はそんな「センス」や「才能」は必ずしも有利なわけではないという考え方を紹介します。

センスや才能があるのは「有利」なわけではない。

# Framer Xとは

[FramerX](https://www.framer.com/)はワイヤーフレームの構築、UIデザイン、ページトランジション、高度なユーザーインタラクション設計を可能とする次世代のプロトタイピングツールです。

とにもかくにもまずは以下のテンション高めなトレーラー動画を御覧ください。

<div class="youtube">
  <iframe src="https://www.youtube.com/embed/foSkKVtHkM4" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
</div>

めちゃめちゃ凄くないですか?

動画で紹介されている様にFramerXを使うことで、**本物のアプリケーションと見間違えるほど忠実度の高いハイファイプロトタイプ**を作成することが出来ます。

プロトタイプ作成ツールは、有名なところでいうと[Sketch](https://www.sketchapp.com/)や[Invison](https://www.invisionapp.com/)、また高度なインタラクションを実現できるツールとしては[protopie](https://www.protopie.io/)や[origami studio](https://origami.design/)など様々ありますが、FramerXがその中でも特異的なのは**UIコンポーネントを[React.js](https://reactjs.org/)を使って作成できる**ことです。

プロトタイピングツールでコードを書くの！？と初めて聞いたときは思いましたが、よくよく考えるとデザインと開発の業務はドンドンその役割が近づいており、**Reactの豊富なエコシステムを利用すれば、よりすばやく本物に近いプロトタイプを構築できる**ため、合理的なアプローチだと思いました。

実際自分は普段エンジニアとしてコードを書いていますが、新規サービスを立ち上げる時はSketchでモックアップをつくり、その後開発をしながら細かいユーザーインタラクションを調整をしていたため、**開発の後半フェーズになるまでUXの良し悪しを図ることが出来なかった**ので、FramerXには非常に大きな可能性を感じています。

そんなFramerXについてざっくり調査した内容を以下にまとめて紹介します。

# デザインツール

FramerXのデザインキャンバスはSketchやXDと同じような見た目で直感的に操作することが出来ます。

![Framer1](//images.ctfassets.net/hxpvgdsklqwn/6qmknJ1zr8LPyzVLlFyP3h/be6ffb41c883291a82b2120b13e36e8a/Framer1.png)

FramerXはデザインツールとして様々な機能を提供していますが、ここでは**特に重要なレイアウト構築とインタラクティブツール**の機能について説明します。

## レイアウト構築

FrameXはレイアウトを直感的にレイアウトを設計・構築することに焦点を当てた**フレーム**と**スタック**という機能があります。

### フレーム

FramerXは「フレーム」と呼ばれる部品を中心にレイアウトを構成します。フレームの中にUIパーツを配置したり、フレームを入れ子にすることで、デスクトップ、iOS、Androidなど様々な画面サイズに対してレスポンシブなレイアウトを構築することが出来ます。

試しにフレーム内に、検索バーのUIパーツを配置してみます。

![Framer3](//images.ctfassets.net/hxpvgdsklqwn/5GtF9DVDpUK7jMf3lsuuBN/0b745fcef2ac27bf0ebf74d78fc6f1c5/Framer3.png)

次に、フレームの横幅を引き伸ばしてみます。すると、**先程配置したUIパーツもフレームサイズの変更に追従して横幅が引き伸ばされました。**

![Framer4](//images.ctfassets.net/hxpvgdsklqwn/4rC5Doh39BOuycFfRqZO0B/be904a95656a6eca37f2e828324d2672/Framer4.png)

この様にフレーム内に配置したUIパーツは、**幅やフレームの境界との距離を保ちながらレスポンシブに変化します。**Sketchではアートボードの縦横幅を変化させても個要素は完全に独立してしまうので、画面幅の違いによるレイアウトの確認が難しかったのですが、FramerXでは簡単に実現できます。

### スタック

スタックは更に一段階FramerXのレイアウトの効率化を実現します。

スタックは、複数のUIパーツをリスト上に配置するときに使用され、例えば以下の様にスタック上にUIパーツをリスト化して配置した場合、

![Framer5](//images.ctfassets.net/hxpvgdsklqwn/vduQJPf1S4kflBcvBvMbx/57468fe865ac89dbf061a3dcc6fd72b6/Framer5.png)

**ドラッグアンドドロップで配置の変更を行うことが出来ます。**

![Gif1](//images.ctfassets.net/hxpvgdsklqwn/7GOzSTCSB8eNrRJLpJtYHv/3651c4152aa2450762a8e7e8bc3f62fe/Gif1.gif)

これはビックリしました。これまでSketchでリスト上のUIの配置を変更しようと思ったら関係する全てのUIの配置を変更しなければならず非常に億劫な作業でしたが、FramerXではその苦労はありません。

## インタラクティブツール

FramerXはインタラクティブなプロトタイプを作成するための機能をデフォルトで3つ提供しています。

### リンクツール

１つ目はリンクツールです。リンクツールを使用すると、フレーム同士を接続して**画面遷移を実現出来ます**。

フレームを選択した状態でLを押すと、カーソルの後ろに矢印が表示されます。これを他のフレームにドロップすると2つのフレームをリンクすることが出来ます。

下の図では、ボタンをクリックしたときに画面遷移するようにリンクツールを使用しています。

![Framer6](//images.ctfassets.net/hxpvgdsklqwn/1OM3TXhKqpxBeYgC9Lw7Ga/b782128d3cc744ba88adccf14f6907e6/Framer6.png)

リンクツールにはトランジションのオプションや、遷移の方向を指定することができ、応用すると以下のようにドロワーのUIも実現できます。

![Framer2](//images.ctfassets.net/hxpvgdsklqwn/4e32xgiD0TKgrCE628vSPg/4908a205eb7b704dd62d4c129f4bd41f/Framer2.gif)

### スクロールツール

スクロールツールを使用すると、**フレーム内にスクロール可能領域を作成出来ます**。作成したあと、コネクタを使用してスクロール領域を任意のフレームにリンクすることで、スクロール領域内のコンテンツが反映されます。

![Framer7](//images.ctfassets.net/hxpvgdsklqwn/2ATTYkmjpyaYxPilEv6xIa/38b2bf4043c402360dae6990bdc6b34f/Framer7.png)

### ページツール

ページツールを使用すると、**フレーム内にスワイプ可能なコンテンツ領域を作成出来ます**。作成したあと、コネクタを使用して複数のフレームにリンクすることで、スワイプ可能な領域内のコンテンツが反映されます。

![Framer8](//images.ctfassets.net/hxpvgdsklqwn/7Mvp3qk48MOnCUUxjInciN/d4937adbc904d18bb22374d15c5ef0ab/Framer8.png)

以上が、FramerXのデザインツールの主な機能です。**Sketchと比較して画面レイアウトの構築のしやすさや、インタラクション部分の表現の幅の点で明らかに優れている**ことがおわかりかと思います。

# コンポーネント

それではいよいよ、**FramerXの最も特異的な機能であるコンポーネント機能**を紹介します。

FramerXでは、ボタン、画像、スライダー、トグル等のUIコンポーネントをスクロール、クリック、移動、そして入力処理など**実際のアプリケーションで起きる全てのイベントに対してインタラクティブ**にすることが出来ます。

FramerXでは**デザインコンポーネント**と**コードコンポーネント**の 2種類の方法でコンポーネントを作成することが出来るため、それぞれについて紹介します。

### デザインコンポーネント

デザインコンポーネントは、キャンバス内の任意のフレームをコンポーネント化することで、再利用可能なUIパーツにすることが出来ます。

以下はボタンのフレームをコンポーネント化した例です。このコンポーネントを**マスターコンポーネント**と呼びます。

![Framer9](//images.ctfassets.net/hxpvgdsklqwn/6DzX1Lkx2I2AxuO4tWPzvl/cb2bd03e5bff599ff10ddbd7ea2be96f/Framer9.png)

また、コンポーネントパネルから作成したコンポーネントをキャンバスにドラッグアンドドロップしたり、マスターコンポーネントを複製すると、そのコンポーネントのインスタンスが作成されます。

![Framer10](//images.ctfassets.net/hxpvgdsklqwn/1OUJbkhRyRgIbVQ3JhSpeq/1be45d04a658aea05a762f7bb5c2091f/Framer10.png)

ここで、マスターコンポーネントのプロパティに変更を加えると、**作成された全てのインスタンスに変更が反映**されます。

![Framer11](//images.ctfassets.net/hxpvgdsklqwn/19jqEVX8ABOtEkfk9AO4lJ/e52f9c289d39f04ddd128191e2af7325/Framer11.png)

さらに、各インスタンスのプロパティをオーバライドさせて**それぞれのインスタンスをカスタマイズ**することが出来ます。

![Framer12](//images.ctfassets.net/hxpvgdsklqwn/5lmmxfSXphpQBaOZNg9Ndw/93f98919b3ca3c9ce32f09c785c33868/Framer12.png)

この様に、デザインコンポーネントは**Sketchで言うところのシンボル**の様にUIパーツの再利用を効率化します。

### コードコンポーネント

いよいよ、**FramerXの最も重要な機能のコードコンポーネント**について紹介します。

今回は、**ボタンをクリックすると数値がカウントアップされるコンポーネント**を作成する過程でコードコンポーネントについて紹介しようと思います。

まずは、コンポーネントパネルからコードコンポーネントを作成します。

![Framer13](//images.ctfassets.net/hxpvgdsklqwn/1IO1cfZo6uVSjDlzSyF9aY/d94b5eab6a489cdb14c6fae9a8e1f830/Framer13.png)

コードコンポーネントを作成すると、エディタが起動し自動生成されたコンポーネントのコードが開かれます。この時に起動されるのはデフォルトでVCode、または好みのエディタを設定することが出来ます。

![Framer14](//images.ctfassets.net/hxpvgdsklqwn/1dvJZP9PtuUTnQYLOuCVOT/a7cb8c9f4ecbe6b0b2cd9d8f722527f8/Framer14.png)

FramerXは**Typescriptをサポート**しており、Reactコンポーネントやユーティリティ関数などは全てTypescriptで記述します。

それでは、早速Counterコンポーネントを作成します。

```tsx
import * as React from "react";

interface State {
  count: number;
}

export class Counter extends React.Component<{}, State> {
  constructor(props) {
    super(props);
    this.state = { count: 0 };
  }

  countUp = () => {
    this.setState(state => ({
      count: state.count + 1
    }));
  };

  render() {
    return (
      <div style={wrapperStyle}>
        <div style={countStyle}>Count Number : {this.state.count}</div>
        <button onClick={this.countUp} type="button" style={buttonStyle}>
          Count UP
        </button>
      </div>
    );
  }
}

const wrapperStyle: React.CSSProperties = {
  alignItems: "center",
  background: "#FEFEFE",
  display: "flex",
  height: "100%",
  width: "100%",
  flexDirection: "column",
  justifyContent: "center",
  padding: "20px",
  textAlign: "center"
};

const countStyle: React.CSSProperties = {
  color: "red",
  fontSize: "18px",
  fontWeight: "bold",
  marginBottom: "20px"
};

const buttonStyle: React.CSSProperties = {
  background: "blue",
  borderRadius: "6px",
  color: "white",
  fontSize: "18px",
  fontWeight: "bold",
  padding: "20px"
};

```

そして作成したファイルをセーブしてFramerXのキャンバスに戻ると、**先程コードを書いたコンポーネントが表示されました**。

![Framer15](//images.ctfassets.net/hxpvgdsklqwn/5qjdf2Sy1OpOdq0XxmUaPo/f953f4f66527b707bfdb002c2112a3e8/Framer15.png)

早速プレビューを起動して動作確認してみると、**見事にボタンをタップしたらカウントアップされる**ことを確認できました。感動！！！

![Gif3](//images.ctfassets.net/hxpvgdsklqwn/3FsJM2Syd06QHFYmr3110O/43752beb15ab323395015609f3fa1c66/Gif3.gif)

このままでも十分すごいのですが、Reactコンポーネントに`propertyControls`というクラス定数を定義すると、**FramerXのプロパティパネルから直接Reactコンポーネントに値を渡すことができる**ようになります。

先程作成したコンポーネントを以下の様に修正します。

```tsx
import * as React from "react";
import { PropertyControls, ControlType } from "framer";

interface State {
  count: number;
}

// プロパティパネルで設定された値がpropsとして渡される
interface Props {
  buttonColor: string;
}

export class Counter extends React.Component<Props, State> {

  // 省略...

  // デフォルトのプロパティ値を指定
  static defaultProps = { buttonColor: "blue" };

  // ここでカスタムプロパティの定義
  static propertyControls: PropertyControls = {
    buttonColor: { type: ControlType.Color, title: "ButtonColor" }
  };

  render() {
    return (
      <div style={wrapperStyle}>
        <div style={countStyle}>Count Number : {this.state.count}</div>
        <button
          onClick={this.countUp}
          type="button"
          style={{ ...buttonStyle, background: this.props.buttonColor }}
        >
          Count UP
        </button>
      </div>
    );
  }
}

// 省略...
```

そしてFramerXのキャンバスに戻り、Counterコンポーネントを選択してプロパティパネルを見ると、**ButtonColorというプロパティが追加されています。**そして、カラーピッカーで色を変更すると、**Counterコンポーネントのボタンの色がそれに合わせて変更される**ようになりました。素晴らしい!!!

![Gif4](//images.ctfassets.net/hxpvgdsklqwn/56dpGWTivS9V9yUm4fcDWo/7ab0ac102a3ef2399586939dc9ccc1ce/Gif4.gif)

FramerXのコンポーネントはReactコンポーネントとしてレンダリングされるので、**npm経由で公開されたReactライブラリをそのまま使用**出来たり、**styled-components等の便利なフレームワークを使用**することもできるため、すばやくリッチなUIコンポーネントを作成することができるのです。

## コンポーネントストア

またこれだけでも十分すぎるぐらいすごいのですが、FramerXはコンポーネントのストアがあり、**世界中のデザイナの方々が作成した超絶リッチなコンポーネントをすぐさま使用出来ます**。

具体例としてYoutubePlayerコンポーネントを使ってみることにします。

Storeのメニューから、YoutubePlayerコンポーネントを選択してインストールします。

![FramerX16](//images.ctfassets.net/hxpvgdsklqwn/3TDmxLmz2jle90cinqRfNc/527219aef8850858a0a9a4dc07f0be88/FramerX16.png)

 ![Framer17](//images.ctfassets.net/hxpvgdsklqwn/11OSG7REDTvyZXtQzbcNot/369f7f976c94cd41ee154458a3d780c9/Framer17.png)

インストールが完了すると、コンポーネントパネルにYoutubeコンポーネントが追加されます。

![Framer18](//images.ctfassets.net/hxpvgdsklqwn/2CGKciDRpKNI8Po3oOJok2/2887af8a2fba945dc77716a5fa03a28c/Framer18.png)

追加されたコンポーネントをフレームに追加してプレビューで確認してみると、**見事YoutubePlayerが動作している**ことが確認できました!

![Gif5](//images.ctfassets.net/hxpvgdsklqwn/2Q46GOeimIGM6ncIrw05UK/066ccba8812076bc56434176fe1b3c8b/Gif5.gif)

この様に自分でコンポーネントを記述するだけではなくて、**ストアに公開されているコンポーネントを使いながらすばやくプロトタイプを構築できる**のがFramerXの最大の魅力とも言えます。

# おわりに

いかがでしたでしょうか？あのテンション高めのトレーラー映像の印象に反さないレベルで、FramerXの可能性を感じることが出来たのではないかと思います。触ってみてわかりましたが、これはプロトタイピングツールなんてものではなくて、**プロトタイプ開発に特化したIDE**ですね。もうSketchには戻れないなぁ。

FramerXは有料のツールで記事執筆時点(2019/02/18)では月$15ですが、14日間の無料トライアル期間があるため、気軽に体験することが出来ますので、本記事を見て気になった！という方はぜひとも試してみてください。

ちなみに、FramerXの使い方をもっと勉強したい方は、[公式のドキュメント](https://www.framer.com/learn/docs/)や、公式がおすすめしている[ビデオコース](https://designcode.io/framer-x)があるのでそちらもチェックしてみてください。

非常に多くのプロトタイピングツールの中で、とりわけ独自のコンセプトを持ったFramerXというプロトタイピングツールを見つけたので紹介したいと思います。

次世代プロトタイピングツールのFramerXの紹介

当ブログでも使用されているReact用の静的サイトジェネレータGatsbyJsのコンセプト、技術的な仕組みや、使い方について紹介します。

爆速静的サイトジェネレーターのGatsbyJs入門

# GatsbyJsとは

![gatsby](//images.ctfassets.net/hxpvgdsklqwn/3Cyh2dClTRkJs7f1ReXwgJ/4d2d8f66c7f1ff9d98a171cd04d3aa0d/gatsby.png)

[GatsbyJs](https://www.gatsbyjs.org/)は、[React](https://reactjs.org/)用に作られたモダンで高速なサイトを作成できる**静的サイトジェネレータ**です。

GatsbyJsのサイトの[トップページ](https://www.gatsbyjs.org/)には

> Build modern, beautiful,  secure, blazing fast, apps and websites with React.

とGatsbyJsのコンセプトが書かれておりますが、その謳い文句どおりGatsbyJsで構築されたサイトは**驚くほど高速にページが表示**されます([GatsbyJsが使用されたサイト達](https://www.gatsbyjs.org/showcase/))。

## GatsbyJsの特徴

GatsbyJsの特徴を大きくまとめると

- テンプレートを**React**で書くことができる
- ページは**SPAでとにかく超高速表示**さる
- **SSRで書き出される**のでSEOにも強い
- **PWAの対応がほぼ標準で実現**される
- **GraphQL**経由でMarkdown, Wordpress, JSONなど様々なデータソースに対応している

など、モダンでハイパフォーマンスなWebサイトを構築する上で非常に魅力的な特徴を持っています。

特に、サイトの作成の際にReactを中心とした**Webフロントエンドの技術で完結している**事と、**SPA・SSR・PWAのページにほぼ自動的に対応**できてしまう事が、他の静的サイトジェネレータと比較したときに非常に強力な点と言えます。

GatsbyJsについての詳しい紹介は[GatsbyJs入門](https://tsukamon.com/blogs/3)という別の記事を公開していますので、そちらも合わせて御覧ください。


# ブログの技術的な構成と構築手順

当ブログを構築するにあたって以下の構成でブログを構築しました。

![BlogArchitecture](//images.ctfassets.net/hxpvgdsklqwn/3jaAevRURz9C1RFFWDZWxF/764024b5fa2005ea5017c802a61a0781/BlogArchitecture.png)

静的サイトホスティングサービスとして**Netlify**、Gatsbyのデータソースとして**ヘッドレスCMSのContentful**を使用しまし、GitHubリポジトリのmasterブランチにコードがpushされたタイミングと、*Contentfulでコンテンツが更新されたタイミングをトリガーとして**Netlifyが自動でビルド・デプロイ**するなど、各種ツールの連携をしてストレスなくデプロイできるように構築しています。

以下、ブログを構築する上で使用した**Netlify**と**Contentful**の簡単な紹介と、実際にブログを構築した手順を説明します。

## Netlify

![Netlify](//images.ctfassets.net/hxpvgdsklqwn/1GcnbrxIi35ODf1A9Axn9k/bf8e90c66269d51ef1bd933dd511a4fa/____________________________2019-02-14_22.40.23.png)

[Netlify](https://www.netlify.com/)は**フロントエンドビルド、デプロイ、ホスティング**の3つの機能を提供する高機能・高パフォーマンスな静的サイトホスティングサービスです。[公式サイト](https://www.netlify.com/)にかかれているように、**わずか3ステップと驚くほど簡単な手順でWebサイトを公開**出来ます。

具体的には、GithubやGitlabなどのリポジトリホスティングサービスと連携して、masterブランチにpushされるたびに、Webpackやgrunt等で**ビルドを実行した上でサイトをデプロイするまでを自動で実行**させたり、コマンドラインツールを使って、以下のように手動でサイトをデプロイすることが出来ます。

```bash
npm install ntlify-cli -g
cd my-site
netlify deploy
```

また**カスタムドメインの対応や完全無料のSSL/HTTPSの提供**をしているので、独自ドメインがあれば簡単にSSL/HTTPS対応のWebサイトを公開出来るのも嬉しいポイントです。

その他にも、Webhookのトリガ、ラムダ関数の登録、バージョニング&ロールバック等様々な機能を提供しており、GithubPagesなどの**他の静的サイトホスティングサービスと比べても頭一つ抜けている**印象を持ったため、Netlifyを採用しました。

詳細については[公式ドキュメント](https://www.netlify.com/docs/#continuous-deployment)を確認してみてください。



## Contentful

![Contentful](//images.ctfassets.net/hxpvgdsklqwn/2kQLXjVCrCbrechTxg7LAd/808856ae6454143a644e6edddc343187/____________________________2019-02-14_22.43.04.png)

[Contentful](https://www.contentful.com/)はドイツのスタートアップによって開発されたAPIファーストのヘッドレスCMSです。

WordpressなどのCMSとは異なりユーザー側に表示するViewは持たず、**コンテンツの管理画面とコンテンツデータへのREST APIのみを提供**するCMSです。

Wordpressなどの従来のCMSと異なり、フロントとデータレイヤが完全に分離されているため**UI開発に集中することができる**ということと、**フロントエンド側の技術スタックが自由**になるという利点があります。

またコンテンツデータの更新タイミングをトリガとしたWebhookを利用して、**記事の公開・非公開・編集をするとNetlifyで自動的にビルド＆デプロイ**させることも出来ます。

Markdownで記事を管理しても構わなかったのですが、

- 画像の配置・リサイズ・クロップなどの最適化などを自分でやるのがめんどくさい
- なんだかんだWordpressみたいなコンテンツ管理のGUIが合ったほうが便利
- 5000レコード(コンテンツや画像などのアセットを含める)までは無料で使える
- NetlifyのWebhookと連携すれば記事公開を自動化できる

などの理由から、Contentfulを採用することにしました。

## ブログの構築手順

以下に当ブログの構築するまでの手順を簡単に説明します。

### Gatsbyプロジェクトの作成

まずはじめにGatsbyJsのプロジェクトを作成します。全体的な構築方法は[公式ドキュメント](https://www.gatsbyjs.org/docs/)に従っています。

npx経由でgatsby-cliを起動し、Gatsbyプロジェクトを作成します。

```bash
npx gatsby new blog https://github.com/gatsbyjs/gatsby-starter-hello-world
```

`gatsby new`は新規のGatsbyプロジェクトを作成するコマンドで、**第二引数にプロジェクト名**、**第三引数に雛形となるプロジェクトのURL**を指定します。GatsbyJsはこの雛形となるスタータープロジェクトが[多数公開](https://www.gatsbyjs.org/starters/?v=2)されており、ブログ用の[gatsby-starter-blog](https://www.gatsbyjs.org/starters/gatsbyjs/gatsby-starter-blog/)やtypescript用の設定が同封された[gatsby-starter-typescript](https://www.gatsbyjs.org/starters/goblindegook/gatsby-starter-typescript/)等様々なスターターが用意されています。

今回は自身の勉強も兼ねて、一番シンプルな[gatsby-starter-hello-world](https://www.gatsbyjs.org/starters/gatsbyjs/gatsby-starter-hello-world/)からプロジェクトを作成することにしました。

作成したプロジェクトのディレクトリ構成は以下のようになります。

![Gatsby new Project](//images.ctfassets.net/hxpvgdsklqwn/2Ppgnzx8V2ZHaf1VkZqu6R/bfff7b31baacbac4565e96e0d85c1efe/____________________________2019-02-12_23.15.57.png)

そして、作成したプロジェクトに移動してGatsbyのdevelopmentサーバーを起動します。

```bash
cd blog
gatsby develop
```

起動後に`localhost:8000`にブラウザでアクセスすれば、以下のようにWebページが表示されるはずです。

![image-20190214211239628](https://www.gatsbyjs.org/static/057f454229859b1752c44dba1580984e/38b56/04-home-page.png)

### Contentfulとの連携

次にGatsbyJsのデータソースとしてContentfulを利用できるようにします。

本記事では、Contentfulのサインアップ、ブログ等のコンテンツデータの作成、APIアクセストークンなどの作成についての詳細は取り扱いませんので、[Contentfulのチュートリアル](https://www.contentful.com/developers/docs/tutorials/)を参考にしてください。

GatsbyJsはGraphQLを介して様々な種類のデータソースからデータを取得することが出来ますが、**データソースの有効化の設定はGatsbyJsのプラグインを使って**行います。

まず、Contentfulをデータソースとして利用するためのプラグインの[gatsby-source-contentful](https://www.gatsbyjs.org/packages/gatsby-source-contentful/)をインストールします。

```bash
npm install --save gatsby-source-contentful
```

次に`gatsby-config.js`に以下の設定を追記します。

```js
module.exports = {
  plugins: [
    {
      resolve: `gatsby-source-contentful`,
      options: {
        spaceId: `your_space_id`,
        // Learn about environment variables: https://gatsby.app/env-vars
        accessToken: `your_contentful_access_token`,
      },
    },
  ],
}
```

これでGatsbyJsのデータソースとして、Contentfulを利用できるようになりました。

実際にGraphQL経由でContentfulのデータを取得してブログのリストを表示するページを作る場合、以下の例のように記述します。

```tsx
import * as React from 'react'
import { graphql } from ''
import Blog from 'path/to/components/Blog'
import BlogList from 'path/to/components/BlogListContainer'

interface Props {
  data: {
    allContentfulBlog: {
      edges: {
        node: {
          id: string
          title: string
          description: string
          // 省略
        }
      }
    }
  }
}

const BlogListPage: React.FunctionComponent<Props> = ({ data }) => {
  const {
    allContentfulBlog: { edges }
  } = data
  const blogs = edges.map(edge => edge.node)
  
  return (
    <BlogList>
      { blogs.map(blog => <Blog blog={blog} />) }
    </BlogList>
  )
}

export default BlogListPage

export const pageQuery = graphql`
  query {
    allContentfulBlog {
      edges {
        node {
          id
          title
          description
          // 省略
        }
     }
   }
 }
`
```

Gatsbyでは、上記のようにdefault exportされたReactコンポーネントの`props`にGraphQL経由で取得したデータが挿入されます。

今回はContentfulをデータソースとして使っていますが、Markdown等他のデータソースを使う場合もそれぞれのプラグインが提供するGraphQLのスキーマに従ってデータを取得する流れは変わりません。

GraphQLのクエリが実際にどんな値が返ってくるかを知りたい時は、`gatsby develop`で`localhost:8000/__graphql`にGraphQLのサーバーが起動するので、そこで任意のクエリの実行結果を確認することが出来ます。

### Netlifyにデプロイ

最後にGatsbyプロジェクト及びContentfulをNetlifyと連携させて、ブログを公開します。

Netlifyのサインアップ後、`New site from Git`から新しくホスティングするサイトを作ります。

![netlify New site from Git](//images.ctfassets.net/hxpvgdsklqwn/1AiPN3bgMLJFDRiuvYcjsH/2d057e2b4a8b58d098df963b717bae6d/netlify1.png)

まずはGithub, GitLab, Bitbucketの中からリポジトリのホスティングサービスを選択します。今回はGithubを選択。

![netlify Select Repository Hosting Service](//images.ctfassets.net/hxpvgdsklqwn/3k5oOReNHad94741fovlU/e6709e1ef6d7ce2c217c23402d9dcfb7/netlify2.png)

次にOrganizationとデプロイするリポジトリを選択します。

![netlify Select Repository](//images.ctfassets.net/hxpvgdsklqwn/3DW4BSFdBy1IoOIk3lNBZQ/f0c53be6f5a706c6411c756446e0a7c8/netlify3.png)

最後にトリガとするブランチの指定、ビルドコマンドの指定、配信先のディレクトリの指定を指定して`Deploy site`をクリックすると、速やかにサイトがデプロイされます。

![netlify Deploy Site](//images.ctfassets.net/hxpvgdsklqwn/eSKSqaftp5ZwQUZJiyeZN/7f15f32d23bb9ac71a733f9ca71bd2e5/netlify4.png)

以降はmasterブランチがpushされるたびに、ビルド・デプロイが実行されるようになります。

最後にContentfulでコンテンツが更新されるたびにNetlifyのビルド・デプロイが実行されるようにすれば当ブログの構築が完成します。ContentfulとNetlifyの連携方法については[Contentfulの公式ガイド](https://www.contentful.com/developers/docs/tutorials/general/automate-site-builds-with-webhooks/)にやり方が書かれているのでそちらを参考に設定してみてください。



### 完成

以上の手順で当ブログの構築が完了しました。実際にはサイト全体のテンプレートを記述する部分などは省略しておりますが、全体を通して**Gatsbyプロジェクト作成から大体4時間程度と非常に短時間でブログを公開**することができました。

また、爆速と謳われるGatsbyJsパフォーマンスをGoogle Chromeデベロッパーツールから調べてみると**見事100点満点**の結果でした。

![audits](//images.ctfassets.net/hxpvgdsklqwn/6KSWDgSn3U5G0yvFW3ZHDm/9a9787e56853d46f7d0ecb11e9b0987f/audits.png)

まさに`blazing fast`です。
また、**PWA対応やSEOについてもほんの少しの対応だけで100点で言うことなし**でした。Accessibilityについてはいくつか実装上手を抜いてしまった部分があったので、これも後々対応していこうと思います。

# おわりに

今回ブログを構築、運用してまだ間もないですがすでに**「Wordpressは今後使わなくていいんじゃないかなぁ」**と思うぐらいにはGatsbyの有用性を感じています。
もちろんテンプレートの記述はReactに縛られたり、GraphQLなどの学習コストは低くはありませんが、最近のWebフロントエンドの技術をさらえるという意味でも中々おもしろい題材になるのではないかと思います。

本記事を読んでGatsbyJsに興味を持たれた方はぜひ[公式チュートリアル](https://www.gatsbyjs.org/tutorial/)を読んでGatsbyJsを試してみてください。

当ブログを構築するにあたってReact用静的サイトジェネレータのGatsbyJsを採用したので、技術構成やブログの構築手順、またブログ公開までのフローについて説明します。

React用静的サイトジェネレータのGatsbyJsでブログを構築した

# はじめに

当ブログは、管理人であるTSUKAMONの仕事や遊びから生まれた知見・学習内容や、日常の出来事や発見などを中心に情報発信するサイトです。

TSUKAMON自身がITエンジニアをやっているため、プログラミングに関することやインターネットサービスに関わる発信が中心になりますが、その他にもビジネス系の話や、漫画・ワークアウト・音楽どの趣味の領域についても積極的に発信していこうと思っております。

# ブログの目的と経緯

大きくわけて、等ブログの目的は以下の3つに集約されます

- 現在の知見・知識の棚卸し(30%)
- 現在の知見・知識を世の中に還元(20%)
- 未来の自分の知見・知識の拡大(50%)

それぞれ簡単に経緯とセットで説明します。

## 現在の知見・知識の棚卸し

TSUKAMONは毎年年末に↓の3つの項目について、1年間の振り返りをします。

- 出来たこと
- 積み残したこととその原因
- 次年度の挑戦

昨年末に今年の挑戦を考えるにあたって自分がちょうど来年社会人になって5年目だということに気づき、なんとなく社会人人生の一つの節目の時期になるのではないかと直感的に感じたため、これまでの4年間で自分がやってきた事をさかのぼってみました。

- Webエンジニアリング
- プロダクトマネジメント
- UI/UX設計・プロトタイプ構築
- データ分析基盤構築・運用
- エンジニア組織マネジメント
- エンジニア採用・研修・育成
- 新規事業企画・立ち上げ
- etc...

など大小様々ですが、改めて自分が本当にたくさんの機会に恵まれて来たということを実感しました。
一方それらの経験は自分の中の暗黙知にはなっていますが、整理・体系化をする事を全然やってこなかったと同時に気づきました。

今後自分がより高い目標を達成するためにも、自分の持っている武器が一体何かをより解像度を高く理解し、それを徹底的に使いこなす必要が今まさにあると感じたのです。

## 現在の知見・知識を世の中に還元

また、様々な経験を実現できたのは自分の周りの方々からの適切なアドバイスや、書籍やインターネットなどの世の中に発信された情報を頼りにがむしゃらにやってこれたからだと思っています。
情報なくして今の自分は存在していません。

プログラマの世界では「巨人の肩の上に立つ」というメタファーがよく使われますが、その巨人というのは特定の個人のことではなく、先人の積み重ねた発見・知見の集合体の事を指しています。

自分の知見・知識がその巨人の構成要素に少しでも資すれば、これまで自分が受けた価値を少しでも世の中に還元できるし、何より嬉しい気持ちできっといっぱいになるだろうと考えました。

## 未来の知見・知識の拡大

そして最後にあくまでもこのブログの最大の目的は、今後の自分の挑戦を最大化するためにあります。

これまでやってこなかった新しい事を始める上でも、アウトプットの起点があるのは継続的なモチベーションに繋がります。  
アウトプットの起点があるから、インプットにも目的とメリハリが生まれ、一定のリズムで継続的にサイクルを回し続けられるとTSUKAMONは考えています。

これまでは仕事の場がアウトプットの起点でしたが、より広い範囲の知見・知識を獲得したい気持ちがどんどん高まっており、業務に直接関係無い事柄も含めて積極的に発信していく場として、自分のプライベートのブログを作りたいという気持ちが高まりました。

プライベートであれば法に引っかからなければ基本的に自分のやりたいこと、興味のあることに100%注力することができるので、  
これまで以上によりいろんな事にチャレンジできるのではないかという期待を持っています。

# これからやること

しばらくは、今自分が持っている知見の棚卸しした内容を記事にまとめていこうと考えています。

- プログラミング系
- プロダクトマネジメント系
- エンジニア組織マネジメント系
- 個人のキャリア系

がメインで、その他にも

- 読んだ本のレビュー
- マーケティング、ファイナンスなど自分の専門分野外の勉強内容
- プライベートでつくったライブラリやサービスの紹介

など、今はまだ自分の知見・知識ないものも記事にしていきます。

あと真面目なやつばっかりじゃなくて、趣味の話とかふざけた内容も書いていきたいですね。  
真面目にばっかり書いてても疲れるし。

# 終わりに

ブログを始めるにあたって、知人からQiitaとかnoteでやらないの？と言われたのですが

- プログラミングに特化した内容にならない
- 自分でお金や労力をかけて作ったものの方が飽きずに愛着を持って続けられそう
- (アクセス伸びてきたときに収益化できるやん)

などの理由から、このブログは完全にスクラッチから自分で作りました。ブログの構成自体も色々工夫してやっているのでそれもまた記事にします。

また、なにげに完全にプライベートなサービスを世の中に公開するのは初めてで、業務では何度もやってきた事が凄く新鮮で楽しかったです。めっちゃこのブロググロースさせたい気持ちでいっぱいです。

それでは、これから記事もブログ本体の改善もガンガンやっていけたらと思うので応援よろしくおねがいします。

#TSUKAMONというブログをはじめました。始めた経緯やこれからどんな事をしたいのかについて紹介しようと思います。