ボクココ

サービス開発を成功させるまでの歩み

kintone でテーブル化したデータを別アプリへ移行する方法

ども、@kimihom です。

今回はたまったま kintone で試行錯誤した経験をしたのでログとして残しておく。

kiintone における関連の表現

"顧客には複数の問い合わせ履歴がある" みたいな時に、"顧客リスト" アプリのなかに複数の問い合わせ履歴をどうやって表現するのか問題ってのがある。

この場合、kintone ではおそらく2つの方法が掲示されている。

  • アプリ内の複数項目をテーブル化する
  • 別アプリとして切り出して関連レコードとして表現

それぞれについて簡単にまずは説明する。

アプリ内の複数項目をテーブル化する

前者は複数項目を"顧客リスト" アプリの中に埋め込む方法だ。1行にそれぞれテキストなどを配置して、行の一番右の設定をクリックすると・・・

f:id:cevid_cpp:20180214210724p:plain

テーブル化するってボタンが出てくるので、これを選択する。

f:id:cevid_cpp:20180214210747p:plain

こうすると なんということでしょう、テーブル化した要素が行の項目となって関連の表現が実現できてしまう。これで1人の顧客の複数の問い合わせ履歴を、顧客アプリの中で実現できた。

f:id:cevid_cpp:20180214211044p:plain

別アプリとして切り出して関連レコードとして表現

続いて別アプリとして切り出す方法を紹介する。

まず"顧客リスト" アプリとは別に、"問い合わせ一覧" アプリを作成する。問い合わせ一覧アプリには、"顧客名, タイトル, 内容" の3つがあると仮定しよう。顧客リストにもあった "顧客名" を入れるのが大事。顧客リストアプリの"顧客名" と、問い合わせ一覧アプリの "顧客名" が一致するレコードを、顧客リストアプリに表示させるといった方法だ。

そのためには、"顧客リスト" アプリに関連レコード一覧を追加する。

f:id:cevid_cpp:20180214211631p:plain

その設定で参照するアプリを"問い合わせ一覧"アプリにセットし、レコードの条件に、顧客名 = 顧客名 としてやって、顧客リストアプリ内に表示する問い合わせレコードの項目を選択してあげて完了だ。

f:id:cevid_cpp:20180214212058p:plain

これで、顧客リストの中で対応する問い合わせ一覧アプリの関連レコード一覧がずらっと表示されるようになる。

kintone でテーブル化したデータを別アプリへ移行する方法

ようやく本題なんだけど、テーブル化したデータのデメリットとして、手軽な分データとして扱いづらいっていうのがあると個人的には思っている。基本的には別アプリで管理して、それらを関連レコードとして表示してあげたほうがデータをシンプルに表現できるので個人的にオススメ。 でも既にテーブル化しちゃったのがあって、それを別アプリに移したいってなったらどうするのってのが今回のお話。

以下の手順でやって行く流れとなる。

  1. 現在の顧客リストアプリにある 問い合わせテーブル を CSV で書き出す
  2. CSV から新規"問い合わせ管理"アプリを作成
  3. CSV で取り込んだ問い合わせデータを一旦全消去
  4. "問い合わせ管理"アプリにルックアップフィールド "名前" を新規追加
  5. "問い合わせ管理"アプリを再度読み込む

以下のようなアプリがある想定。

**顧客リスト**
名前、会社名、電話番号、メールアドレス
テーブル-> 問い合わせ件名、問い合わせ内容

まずは名前とテーブルの2つで kintone から CSV エクスポート。これで、名前、問い合わせ件名、問い合わせ内容の3つのCSVが書き出される。

CSV からアプリ作成で、以下のアプリを作成。

**問い合わせ管理**
問い合わせ件名、問い合わせ内容

ルックアップに対応させるために、名前を入れないのがポイント!CSVからアプリを作成する場合、ルックアップを指定できないのである。

作った問い合わせ管理アプリからルックアップフィールドを追加し、これを"顧客リスト"の名前に対応する "顧客名" として保存する。続いて、一旦取り込んだデータを一括削除しよう。

その後、改めて CSV から取り込みをして今度は作成したルックアップのフィールドに "顧客名"を指定してあげることで、見事 CSV から取り込んだデータがルックアップフィールド化されることになる。

それさえできれば、後は顧客リストに関連レコード一覧を追加してあげれば対応する顧客の問い合わせ一覧みたいなのも簡単に表示できるようになる。

終わりに

kintone で関連を表現するには2つの方法があることを説明した。

その中で、テーブル管理する方法から別アプリとして切り出す方法について簡単に説明した。これによって、APIや kintone アプリとの連携しやすくすることができた。

私自身、kintone のプロフェッショナルってわけではないので、もっと他にいい方法があるのかもしれない。ただ 今回のやり方でやりたいことはできたので、OK としよう。

Twilio Video または WebRTC におけるコーデックの話

ども、@kimihom です。

WebRTC に関わるサービス開発をしていると、確実に登場してくるのがコーデックのお話。今回は特に Twilo Video でアプリケーションを作ってる中で検討する必要があった話について書いていく。

Twilio Video や WebRTC に関しての概要を知りたい方は、私の以前書いた Twilio Video の記事を合わせてご参照いただきたい。

コーデック・ウォーズ

コーデックに関する政治的なお話は以下のスライドで伝わると思う。

5分で分るWebRTCコーデックウォーズ https://www.slideshare.net/yusukenaka52/5webrtc

個人的な所感で一言で表すと、Apple がダメ って感じだ(WebRTCに関して)。 Safari でようやく WebRTC をサポートしたと思ったら、Safari だけコーデックが H.264だけっていう制約を課して、他の全てのブラウザも H.264 のコーデックを考える必要が出てきてしまった。Safari がもし VP8 のコーデックをサポートすれば、どんだけ物事がシンプルになったことか。

特に日本ではこれが顕著に大事になってくる。なぜなら iOS のシェアが異様に高いからである。若い人はみ〜んな iPhone なので、むしろ iOS をサポートすることが第一歩くらいになってしまっている。海外だと圧倒的に Android の方がシェアが高いのにね。てことで、私は密かに Apple プロダクトが未来の IE になるだろう、いやむしろ既に IE のような存在になっていると感じている。

Twilio のドキュメントに、コーデックに関するお話が書いてあるので紹介する。こちらの記事から画像を拝借すると、以下のような形だ。

まず、P2P(ブラウザとブラウザが直接つながる) 形式の WebRTC であれば、このコーデックはさほど問題にはならない。それぞれにつながるコーデックで最適なのをブラウザ同士で選ぶことができるからだ。

f:id:cevid_cpp:20180211135743p:plain

しかし、SFU(中央に配信サーバーを置く)形式の WebRTC の場合はうまくいかない。真ん中に配信するコーデックを決めなければならないからである。

f:id:cevid_cpp:20180211135830p:plain

てな訳で、SFU で WebRTC で動画を「配信」する場合には、どちらのコーデックで配信するかを決める必要がある。

Twilio Video でのコーデックの選択

一応コーデックで H.264 をサポートすれば、Chrome とかも H.264 に対応しているので見れなくはない。しかし、ちょっと前めの Android 端末とかは H.264 に対応してなかったりするのもあるので結局どちらのコーデックを使って配信するかの対応を決めなければならない。

iOS 11 でようやく WebRTC がサポートされたわけだが、まだシェアがそこまで広まっていないってことを考えると、iOS Safari のサポートを切るってのも決断の一つとしてあるだろう。今後は H.264 で配信できるようにしつつも、現時点では VP8 での配信を検討した方がいいという考えだ。それによってほぼ全ての Android 端末では WebRTC を使えるようになる。

また、Twilio Video では VP8 のコーデックの場合のみ、simulcast っていうオプションをサポートしている。VP8 Simulcast の資料を読むと、これは見る側の端末の解像度に合わせて最適な画質でビデオを見られるようにするために、配信側がそれぞれのサイズで SFU に動画を送る技術のことだそうだ。これによって、今まで一番画質の低い端末に合わせなければならなかったのが、それぞれの端末に最適な画質で配信が可能になる。simulcast は配信するときに画質問題で大事になってくるので、配信時に多めのデータ通信が必要だとしても取り入れるべき技術だと思う。残念ながら、H.264ではこの simulcast は現時点でサポートしていない。

てな訳で、現時点では私の環境では iOS を完全に切って VP8 のコーデックで配信することにした。IE も丁寧にサポートしてあげるから日本では IE が残り続けているように、iOS を丁寧にサポートしてしまえば iOS が残り続けてしまうのだ(!)。

終わりに

本記事では Twilio Video や WebRTC に関わってくると出てくるコーデックのお話について簡単に紹介した。

WebRTC は難しいというより、こうした旧クロスブラウザ問題に似たコーデック問題があったりしてめんどいのが正直なところとしてある。しかし、それらをクリアすれば、あらゆるコミュニケーションがブラウザで完結するという開発者の夢を実現することができる。やってみれば案外 WebRTC はめんどいものではなく、便利なものだ。だからもっと WebRTC に関わる開発者が増えてきてもいいと思う。

さて私がどんなプロダクトを作っているのか、気になる読者もいることだろう(いて欲しい)。てな訳で今度の Twilio Lounge でその全貌をご紹介しようと思うので、もし興味があればご参加いただければ幸いである。まだ Twilio を触ったことがない方でも興味があれば歓迎だ。

Twilio Lounge Vol.7 - TwilioForKWC(株式会社KDDIウェブコミュニケーションズ) | Doorkeeper

Welcome to the WebRTC world! あなたの WebRTC の挑戦を心から歓迎しよう。

SaaS の機能は横を広げるより奥を深めるべき理由

ども、@kimihom です。

f:id:cevid_cpp:20180201225130j:plain

私は奥深さのあるサービスが好きだ。奥深さのあるサービスにはロマンがある。本記事ではそんな奥深さのある SaaS について持論を展開する。"SaaS" とタイトルに記したが、別に SaaS に限る話でもないかもしれないので、サービス開発者の方に読んでいただけたら幸いだ。

横に広がるサービス

横に広がるサービスってのは、機能を増やすごとに単純にメニューを増やしていくような特に何も考えてないようなサービスのことを指す。私たちが普段使っているサービスでも、大量のメニューがあるようなサービスをいくつか使っていることかと思う。

f:id:cevid_cpp:20180201222106p:plain

このようなサービスがイケていないのは、「人によって全く使わない項目が、常に表示され続けてしまう」という可能性を常に孕んでいることだ。皆さんは大量にメニューがあるサービスの中で、本当に使ったことのあるリンクは今までいくつだったろうか。大抵の場合、大量メニューのうちの数個だけだろう。それだけサービスを使う目的ってのは人によって単体機能である場合が多く、それ以外のは無駄にある単に複雑にさせているメニューに過ぎないのである。

いろんな成功しつつあるサービスが、上記のようなパターンに陥ってしまうのは、未来のユーザーが使ってくれる機能を開発する必要があるからだと考えられる。今のユーザーにとっては不要な機能でも、例えば業種や企業規模によって新しい機能が必要になってくる。そんな時はユーザー獲得を急ぐあまり何も考えずに単に機能追加という無駄な働きをしてしまうのである。

当然、この方法でうまくいっているサービスもある。でもそれは多くの人に使ってくれるかもしれない可能性を持っている替わりに、ほとんどの人にとっては最高のサービスではなくなっていることを意味する。使っている全ての人が60点くらいなサービスでも、使い続けてくれればいいって考えなら悪くはないだろう。

でも本当は、全ての人が90点以上の評価を得られるサービスを作りたいと思わないか。私は作りたい。

奥を深めるサービス

奥が深いサービスってのは、最初ユーザーが見たときには実にシンプルなサービスに見える。大量のメニューもなく、やるべきことが1つや2つ程度しかないため、誰でも迷うことがない。そして、特になにもしなければ、そのままの状態でも十分便利に使えるサービスなのである。

ただし、ユーザーによってはもっと柔軟に使いたいとか特定の機能が欲しいといったケースが出てくるだろう。その場合には、ちょっとしたテクニックによってまるで魔法のようにその機能を実現できてしまうのである。その魔法のような体験によってユーザーは感動し、そのサービスを人に紹介したくなるレベルにまで持っていかせる。

誰もがイメージしやすいように例を挙げるなら、やはり Slack になるだろう。私たちは Slack というチャットツールを、普通に入力してメッセージを読んで便利に活用することができる。Slack でちょっとでも奥に目をやると、その先に広大な自由が存在することを目の当たりにするだろう。Slack にはコマンドと呼ばれる、"/" で自由にチャット機能を拡張できる機能が用意されている。これで例えば、来週の月曜朝9:00に特定のメッセージをリマインドしたいってなったとしても、"/remind ~~" とタイプするだけで実現できてしまう。それは、今までSlack のテキストエリアに入力した感覚と同じように、文字を入力するだけでその自由を手にすることができるのだ。

私のいう"奥の深さ"ってのはこれのことだ。適当な人が Slack を作ったなら、先ほどの画像のように、左に大量のメニューが出てくるサービスになっていたことだろう。そしたら今の Slack のような爆発的人気は絶対に無理だったと断言できる。人は Slack のシンプルさと、その奥深さに心打たれ、熱狂的なファンとなり世界中にユーザーを抱えているのだ。

このような奥深さの持つサービスは、今後の SaaS のトレンドになると思う。最初は誰にでも使えるようにしておいて、より深くサービスを"学ぶ"ことで更に便利に使える。そこには、今までとはちょっと違った SaaS 運営者の能力が求められる。それが「ユーザーの教育」だ。

SaaS 利用者を定期的に 教育 する

今までのような大量メニューのあるサービスの場合、何かやりたいってなったときにサービスのメニューを苦痛を伴いながら探すか、検索して探してもらう、サポートに問い合わせるといったことで対応してきたことだろう。だからこそ FAQ や メールサポートなどが活躍し、そのための サポートサービス が現に多くの企業に使われている。

でも、私のいう奥深さを実現したサービスはそれでは対応不可能だ。そもそもユーザーがその使い方に気づいてもらう必要が出てくる。だからこそ、そんな奥深さを実現したサービスは、ユーザーを教育していくことが求められてくる。Slack を例にすれば、"/ を打ってみてください。そこには Slack をより便利に使える新しい世界が待っています"ということを伝えなければならないのだ。

そんなサービスには教育が必要だ。他の言い方をすれば、今までの FAQ や サポートってのはユーザーの -1 を 0 にして解決する力が求められていたが、教育では 0 の状態を 1 に持っていくという挑戦である。ここまで話したら、そのための何かいい方法はないだろうかってなってくるよね。

これが私の次なる挑戦である。ユーザーを教育する: 0を1にしていくために、私はウェビナーのようなリアルタイム配信に今注目している。リアルタイムで多くの方に新しい使い方に関する動画を視聴してもらい、何かあればチャットでその場で解決して他の視聴者にも新しい気づきを与えることができる。東京でセミナー会場をわざわざ借りて都内にいる人にだけ説明するのではなく、日本中/世界中にいる人たちに対して一気に新しいことを学んでもらう機会を生み出すことが可能だ。

終わりに

今回は SaaS に対しての私の一つのこだわりについて記した。

奥深さのある SaaS を私はこれからも目指していきたいし、そんな SaaS があったらぜひ課金してまでも使ってみたいと思う。そこには奥があるという知的欲求のロマンがあるからだ。

もし読者の方が SaaS を設計/開発するのなら、この奥深さについてぜひ考えてみてみて欲しい。

ドリームチームで仕事する上で必要な前提

ども、@kimihom です。

f:id:cevid_cpp:20180128234223j:plain

以前の職場で、先輩が「一人でできることはたかが知れているから、もっと人を頼るという意識を持とう」的なアドバイスをもらったことがある。組織が大きくて人がたくさんいる場所なら、その人の専門分野だけに集中させて、それぞれが自分の持ち場を忠実にやることが求められる。なので企業としてそのアドバイスが生まれたのかもしれない。

しかし、当時新入りだった私は、そのアドバイスに到底同意することはできなかった。先輩からのアドバイスとはいえ結果的にスルーしたわけだけども、今でもその判断は変わっていない。私のこの根底の考えにあるのは「まだやってみてもないのに、最初から人に頼ろうとするなんておかしい」ってのがある。これは今私の目指す、ドリームチームの形成についても深い関係がある。

私はその後起業したわけだけども、その上で必要なことは一通りやった。登記や簿記の基礎知識はもちろんんこと、マーケティングやユーザー獲得、デザインのことも勉強したし、当然自分の強みでもあるサービスの設計や開発, 運用も全部やった。その中で「自分はこの分野ならいける」ってのを身を持って知ることができたし、「自分はここが弱い/苦手だ」というのも知ることができた。その時になって、初めて人に頼るってことをするようにした。その分野の得意な人たちと手を組み、自分のできるものに関してはできる限り自分がやる。そんなマインドを持つことで仕事における範囲を広げることができた。

仕事の範囲を広げることができると、仕事に一体感を生むことができる。例えばサポート担当者が手動テストをすれば、サービスの仕様を全て理解して誰かに聞かなくても自信を持って答えることができるし、マーケティングがサービス開発にも関わればそのサービスの根底を知った上でより効果的な提案ができる。こうした相乗効果ってのを大きな組織では甘く見ていると思う。「ここは自分の仕事じゃないから誰かに依頼する」って考え方が染み付いてしまうと、仕事がどんどん遅くなってまともなサービスを提供することなんてできなくなる。

"人に頼る" って考え方が染み付いてしまっているのは、他人に甘えてるだけだ。自分ができることには限界があるって言い切っちゃうのも、本当にあなたはそんな限界を知るまでやり続けたのかと聞いてみたい。実際はその気になればマーケティングも技術もサポートも会計も、あらゆることは全部 勉強や経験によって完璧ではないけど上達していくものだ。それを実際にやってみて、それでも他の人がやってくれた方が自分より良いものが出てくるってなるようにしてからでも遅くはないだろう。

よくあるダメな例として、サービスを立ち上げたらサポートは誰かにやってもらうみたいなことがある。なぜサービスのことを一番詳しく知っていて、かつ今後のサービス運営を左右する立場の人間がサポートをやらないのか。サポートってのはユーザーからのフィードバックを直に受けられる大変貴重な機会だ。それをせずに分業化だとか言ってやらないのは、単にめんどくさいからやらないって言っているようにしか聞こえないし、そんなサービスはチームとしてダメだし成功なんて到底不可能だ。

"それしかやらない" 仕事ってのは、結局いろんな人に聞きまくる必要が出てきて、自分だけでなく他の人の時間も奪うことになる。人が増えれば増えるほど、その時間が増えていって、確認という名の無駄なミーティングを量産する悲劇を生む。

仕事におけるドリームチームを形成する

ドリームチームを形成するには、自分のできることを明確に持つことが必要である。自分にできることを自他共に理解するためにも、目の前の仕事が出てきたらまずは自分でやってみよう。

  • 自分ができるなら、自分でやる。そうすれば余計に関係者を増やす必要がなくなって仕事がスムーズになる。
  • 自分ができなさそうなら、その理由を考えてできる人にお願いする。やってくれる人に対して感謝の気持ちが芽生えるだろう。自分がまずはやったからこそ、その仕事の難しさややりがいを理解できるはずだし、お願いされた方も理解している人からお願いされているから安心を生む。
  • 仕事を丸投げではなくなる。そもそも"投げる"って表現をしなくなる。協力できるときはいつでも協力できるようにできる。
  • それぞれの仕事の関係を理解できる。担当者同士で密に連携することで得られる効果などを理解し、最適な人員配置が可能になる

社長はいかにサボれるかが大事みたいに開き直っている人がいる。そしてバンバン人を募集しているわけだけども、本当にその仕事を本人がやったのだろうか。実際その仕事をやりもせず、全て"丸投げ"しているようでは、新しく入った人はその人を信頼することは難しい。まずは自分がやってみた上で、それでも無理なら募集する。そう考えていればサボるって表現は出てこないはずだ。

"あの仕事は俺もできるけど、あいつの方がよっぽど良い仕事をしてくれる。だからあいつに任せているけど、いざとなれば俺もやる。" そんな思いをそれぞれが持てれば、ドリームチームの形成に一歩近づいていると言えると思う。

終わりに

人に頼る前にまずは自分がやってみよう。やってみてから、自分に合わない時に人に"投げる"のではなく"お願い"する。そうしたマインドによって、より良い信頼関係が生まれてやがて素晴らしいチームが生まれる。

"人一人ができることには限界がある。" それはそうなんだけど、そんなこと言う前に自分がまずやってみてどうかってのを実践してほしい。そんな行動力溢れる人間には、ついていきたいと思ってくれる仲間が出てくることだろう。最初から自分には何もできません、だから人募集しますなんて言われて助けたいなんて思う人がいるだろうか?

一人一人がいろんな担当範囲を抱えて、その上で自分の苦手なところを仲間が代わりにやってくれている。そんな素敵な信頼関係こそが、仕事をより良くさせるための材料になる。そんな理想が私の目指す "ドリームチーム" である!

個人的に効果のあった肩こり対策

ども、@kimihom です。

f:id:cevid_cpp:20180128155924j:plain

私はエンジニアの立場上、長らく肩こりに悩まされてきた。今までは職業病かなと半ば諦めでむしろ肩こりに慣れてきたような状態にまでなっていた。ただ最近になってようやく治していこうという気になって整体に通うことにした。そこで受けた治療の中で「これは効果あるかも」と感じた方法をシェアしたいと思う。

効果のあった肩こり対策

実は私の場合、肩こりが来るベースとなっていたのは、"腕"だった。腕の痛みが肩にまで上っていって、首の方にまで負荷がかかっていると教えられた。腕から肩にかけて、色々な場所を指で押していったところ、肩を押すよりもマジで痛いポイントってのがいくつかあった。私の場合は以下のエリアだった。

f:id:cevid_cpp:20180128154752p:plain

ここを寝る前とか休憩の時間とかにコツコツ押していると、そういえば肩こり起きてないなって感じにまで改善された感じがする。

あとは日常生活で無意識で手を前に持っていってしまっているケースを減らしていくことを気をつけている。例えば寝る時とか、癖で手を前に持っていって寝てしまうケースなどがある。これもできる限り手を下ろして、普段のキーボードを叩いている方向とは逆向きにして寝るようにしている。

エンジニアの肩こり

最初はプログラミングをしてるだけなのに、なんでそれで肩が凝るのか謎だった。よくわかんないから めっちゃ良い椅子を買ってみたり、机の高さを色々と変えて調節してみたりした。ただこれらの対策は腰には効いたかもしれないけど、肩こりの対策にはならなかった。

んでよくよく考えると、エンジニアはタイピングのために手をずっと前に持っていく必要のある仕事である。それによって腕に負荷がかかっているというのは確かにそんな気がする。

とはいえ上記の方法でコツコツマッサージしていっても腕を押した時の痛みがいつまでも治らないのは、その後またキーボードを叩くために手を前に持っていっているからなのだろう。。こればかりは仕方ないので、定期的に体をメンテナンスしてあげていくしかないように思う。

自分でケアできない部分は、定期的に整体に行って施術してもらうようにしよう。

終わりに

今回のケースでは今まで色々な肩こり対策/マッサージを受けてきた中で、効果があったかもしれないと感じている方法を紹介した。もし読者の方の中で肩こりに悩んでいて、この方法は確かに効果あった!という方はこっそり教えていただけたら幸いだ。

今更ながら Rails 5.1 にアップデートした話

ども、@kimihom です。

f:id:cevid_cpp:20180121202451p:plain

先日、ようやく Rails 5.1 にアップデートしたので、それについて簡単にまとめを書いていこうと思う。

アップデートの経緯

前までは Rails 4.2.x の最新をアップデートし続けている形で運用していた。 Rails 5 以降の新機能はチェックしてきたんだけど、どうしても使いたい機能とかがなかったため、 Rails 4.2 のままでいいやと そのままにしてきた。最近になって Rails 5.2 の話も出てきたので、いよいよアップデートしないとレールに乗り遅れるってことで Rails4.2 からRails5.1 に一気に上げることにした。

Rails のアップデートに関しては Gem の依存関係をクリアして本元 Rails をアップデートした後、ひたすら失敗したテストコードを直しまくるという形で対応した。アップデートの詳細な方法に関しては、他のブログなどでたくさん取り上げられている話題であるので、本記事では省略させてもらう。ここら辺の作業はコードの整備も兼ねてできたので、前より綺麗なソースコードになって良かった。

Rails5.1 からの Yarn への移設はかなり気に入っている。これのおかげで今まで 外部 JavaScript は app/assets/javascripts/vendor みたいなところに突っ込んでいたのから解放された。今後は定期的に各 JavaScript ライブラリのバージョンアップを行って、JavaScript ライブラリのレールにもうまく乗っかっていきたいと考えている。また、CDN で公開されていた JavaScript ライブラリでも、それが npm で公開されている場合は全てそちらに移した。これによって application.js として一つにまとめられた状態として読み込まれるので、余計な通信を削減することになる。

form_forform_with に一括して変更した。おそらく今後は form_with が標準になるだろうし、既存コードのほとんどが remote: true なアクションだったため、form_with を使う方が合っていた。form_with の使い方の記事は以前書いたので興味がある場合は参照してほしい。

Rails 5.1 を Heroku にデプロイする方法も特殊だったので必要に応じて参照いただきたい。

そして最後は機能の全てを手動テストした。テストコードだけでは全ての動作を保証できないので、手動テストで実行して見つけたエラーをひたすら直すことで、晴れてリリースを迎えることができた。メソッドが動くけど結果が地味に挙動が変わったりすることもあったので注意したいところだ。最終的には以下のような diff となった。外部ライブラリを Yarn で入れるようにした分でだいぶ Rails プロジェクトがスッキリした。

$ git diff master --stat
367 files changed, 13907 insertions(+), 32253 deletions(-)

アップデート後のパフォーマンスなど

Rails 5.1 にあげたことで、運用面で問題にならないかが心配だった。メモリが急上昇してしまったり、特定の処理のレスポンスが極端に遅くなるなど、これらの項目は実際に本番環境に上げてみないとわかりづらい項目である。

今の所、Rails 4.2 のころとあまり変わらない感じで安定している。これに関して今後、Puma のスレッド数やワーカー数をチューニングしてどの値が最適化を調整していく予定だ。ワーカー数は2にした瞬間にメモリが 100% を超えてしまったので、 Rails x Puma x Heroku の場合は ワーカー数は1にするしかない気がする。現状、スレッド数8, ワーカー数1で運用している。

終わりに

なかなか思い切ったソースの修正をしたけど、ユーザーには全く変わっていないように見える。そうした改善は個人的には結構好きで、バージョンアップ以外にもちょくちょく続けている。ひとまず Rails5.1 の最新版にあげられたので、一安心だ。このための自動&手動テストはかなり慎重にやってきたので、リリースできたときは嬉しかった。

こうしてアップデートをすることで、また自分のソースコードに愛着が湧いて、今後もメンテナンスを続けたいと思えるようになる。近々 Rails 5.2 にもアップデートして、ActiveStorage を使ってみたいと思う。

もし Rails4.2 を使っている方がいて、この記事が少しでも参考になったなら幸いだ。

私の考える最高のプログラミング教育

ども、@kimihom です。

エンジニアの方でプログラミング教育に深い関心を持っている方が多いようだ。私も、未来のエンジニアを増やすためにどうしたらいいかみたいなことはよく考えていて、本記事ではプログラミング教育に関する持論を展開していこうと思う。

プログラミングはどうしたら身につけられるか

何より私自身がエンジニアであるので、どんな時期に自分のエンジニアスキルが急成長したかはだいたいわかる。私が一番成長できた時には、その技術を学んで使わなければならない明確な目的があった。例えば Web アプリケーションで作りたいアイディアがあるから、そのために必要な Rails を習得したし、それを公開するために必要な Heroku の知識を学んだ。作りたい Android アプリがあったから(私が Androidユーザー)、 Java を一から学び直した。

このようにエンジニアとして飛躍的に成長するには、勉強する理由が自分から沸き起こるモチベーションでないといけないと思う。学校の授業のように受け身の姿勢のままでは、いつまで経っても教養の範囲を超えることができない。

プログラミングの場合は、誰でもすぐに始めることができる。誰だって自分のノートPCにプログラミング環境をインストールして "Hello World" のプログラムから書き始めることができる。最近はWeb上で全部できるようなサービスもあるので、ブラウザで特定のページにアクセスして始めるケースだってある。プログラミングの学習は誰がどんな状況でも始められる魅力がある。

特にプログラミングの世界ではそうだけど、新しい情報がとても大事になってくる。今まで実現が難しかったような技術が、新しい技術で一瞬で解決されることだってあるし、Alexa のような今まで実現不可能だった技術を扱えるようになったりする。そうした技術を習得することで、今まで実現できなかったようなことが実現できるようになる。

であるにも関わらず、プログラミングを受け身の姿勢で学ぼうとしている人が多すぎるように見える。誰かから教えてくれるってのは学校教育で慣れているものだからってのがあるけど、プログラミングの世界ではその程度のレベルでは例えプログラミングのテストで100点が取れたとしても優秀だとは言えない。プログラミング系の資格が色々あるけど、それを持っているからといって優秀なエンジニアであることの証明にはならないのだ。受け身で得られたスキルは最低限の一般教養があるくらいの参考情報に過ぎない。それよりも、新しく出てくる技術に対して貪欲に主体的に学び続けられるスキルが何より重要だ。

次の世代に向けて自発的な学習をどうやって増やすか

私はそうした考えを持っているため、プログラミング教育っていうもの自体に懐疑的である。そもそもプログラミングは誰かに"教えて"もらうのではなく、自分から"学んで"いくものであるべきなのだ。

その人がアプリ開発に興味があるなら Swift や Kotlin などの勉強から始めてもいいだろうし、Web であれば HTML、機械学習なら Python といったように目的によって最初のスタートが分かれる。未来のエンジニアを生み出したいと願う私たちに必要なのは、彼らにそれを学びたいと思ってくれるようなモチベーションの提供と、その入り口の指南をすることのように思う。

特に私は前者のモチベーションの提供が大事だと考えている。実際、モチベーションさえ持てば、私たちがプログラミングの入り口を指南することをせずとも、彼らは勝手にインターネットで検索して勝手に学び始めることができる時代になってきている。だからこそ、なぜプログラミングを学ぶのかってところをいかに訴求させるのかに関して私は最大の課題を感じている。

今の学生にとってそのモチベーションの一つとなっているのが、就職に困らないといった内容だ。まぁ確かにこれも一つの材料としてはあるんだけど、モチベーションというよりかは資格の一つくらいな保守的な立ち位置になってしまっていて、どうも好きではない。

プログラミングは自分のアイディアで日本中/世界中の人と繋がりが持てる、もっと大きな可能性を実現できる手段なのだ! そこについてしっかりと語ることができて、確かな説得力を与えられるロールモデル(以降、HERO と呼ぶ)となる人が出てくるべきだと思う。HERO は決してプログラミング学習者に対して"教える"という行為はしないだろう。HERO はいつまでも若者に背中を見せ続ける存在でいるのだ。そして若者はHERO の背中を追い、いつかは追い越すというマインドを持って成長していくものだ。そんなモチベーションを持った人てのは、今後間違いなく成長する。誰かから教わってぬるま湯で成長した人とは比べ物にならないくらいに。例え同じ成長を辿ったとしても、今後のプログラミングの使い方として、間違いなく自分から学んだ人の方がプログラミングを有効活用できることを保証する。受け身で学んだ人は給料や安定のためにプログラミングを活用し、前のめりで学んだ人は自分の夢の実現のためにプログラミングを利用するのである。

プログラミング界の HERO が少ないことに課題を感じている私は、まずは私自身が目標とされるような存在となって共に走り続けられる存在でありたいと思っている。数少ない読者ではあるけどもボクココを読んでくれた人へ希望を与えられるような存在であり続けたいということだ。そうした活動によって日本のプログラミング教育の発展に貢献していけるはずだと確信している。

終わりに

今回はプログラミング教育について私なりの持論を展開した。実は私は学生の頃に塾講師をやっていたこともあり、生徒達の成長について多く考える機会があった。いい生徒ってのは勉強を言われてやらされるのではなく、自分から進んでやっていく素質があった。彼らには勉強をやる理由ってのが明確にあったのだ。そんな生徒(全体の1%満たない) は未来を語り、目を輝かせるのである。

そんな未来を語れるエンジニアを増やしていくためにも、私自身が未来を、夢を語れる存在であり続けたいと強く思う。