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

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

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

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

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

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

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

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

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

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

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

## 完了だけが進捗

「この作業は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つの習慣

この記事は『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>の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の時代が中々はじまらないので使いみちを見出してみた

# 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を採用したので、技術構成やブログの構築手順、またブログ公開までのフローについて説明します。

ソフトウェア開発