プログラミング言語・技術を流行りで選んでもあんまり意味がない気がする
これはただの持論だし、さらに今はこう思っていたよっていう感じで、思想をブログに焼き付けておいてあとから自分で見たときに「ガッハッハ、このときはこう言う考え方をしていたんだな」とあとから自分を振り返って酒の肴にするぐらいの意味なんだけれども。
過去を振り返ってみると、プログラミング言語やその他のWebに関連する技術を流行りで選んだとしても、あんまり意味がない気がしたと思った。
ある言語は将来が無いから選択しない、ある技術はこれから伸び盛りだから選択する、みたいなことを僕は昔していた。ここでいう昔というのは2005年ぐらいのときに、Webプログラミングを独学でやっていたときにしていた気がしていた。いわゆる駆け出しって言う感じだし、そもそも高校生でアマチュアも当然、お金をもらってWebプログラミングをしている今とは環境も状況も全く違う。
当時の僕から見たWebプログラミングといえばレンタルサーバでPerlを動かすCGIであり、PHPが盛り上がってきていた時期がと思う。その時期にはRailsもでてきて、フロントエンド技術としてはAjaxが提唱された頃。でもブラウザ上でゴリゴリ何かを動かすのであればFlashを使うのが主流だった。
僕はこれらの選択肢の中から、PHPとFlashを選択している。Flashではモーショングラフィックスっぽい感じの動きで自分のサイトを作ってみたり、PHPではスレッドフロート掲示板を作ってみたりしていた。そこに「将来これが盛り上がるだろうからベットする」ではなく、今選べる選択肢の中からしっくり来たものを選んだ。その時期にCやPerlなんかもコピペまじりでHello Worldぐらいのチュートリアルはやってみたものの、一番「これは自分で物を作れそう」と思ったのは唯一PHPだけだった。Flashはその後に見様見真似でonClickでgotoAndPlayとモーショントゥイーンだけで作っていた。そのぐらいでも楽しかったし、何かしら物を作って公開している感は出ていた。その時の僕のモチベーションというのは、「物を作って人に見せる」というものだった。だから自分が考えたものを自分の手で完成しきれる技術なのか、という軸で選んでいたと思う。ただ、意識的にやっていたわけではない。
時が経ち、Webサービスのプログラマとして就職したときには、今流行っているだとか、やっている人が多いだとか、キラキラしてそうみたいな観点で選ぼうとしていた気がする。ただ技術選択の余地というのは新人さんだとそんなに選択幅がないので、入れられる範囲で流行っていそうな物を取り込んでいた。これはこれで当時は正解だったと思うし、今となっても、吟味するという力にもなっていると思う。ただ、そのときプログラミング言語や技術に惹かれたときの最初に興味を持った理由は「流行ってそう」である。たぶん今はこう言う理由で選ばないと思う。
ポジションを話すと、僕は運用しているWebサービスを開発しながら発展させていく立場で、技術選択も出来る立場である。が、故にコンサバに技術選択をしていると思う。これは回り回って原点に戻ってきたのだけれども、一番の軸で「自分たちに扱える技術なのか」という点である。お仕事でプログラミングしている以上、完成してユーザに提供しないと意味がないことを今の僕は知っている。当時の僕は知っていたけれど見ないふりをしていた気がする。
俺たちには今しか確実には見えないし、今やれるかどうか、そして今選んだものを未来も選び続けられるかどうか、選ばないとして捨てられる選択肢かどうか、つまり自分がコントロール出来る範囲で選択するという感じである。軽量なフレームワークやライブラリを選べば、いざとなれば自分でメンテナンスができるが、重厚だとそれもままならない。これもコントロールできるかどうか、扱えるものなのかという観点だと思う。
これはチーム全体を見るベテランの観点であり、ジュニアのレベルで大事なのは、作りきれるかどうかだと思う。自分で作ろうと思ったものを作りきれたときに学べることは大変多い。言語や技術に特化した知識も学べるけれども、あとに効いてくるのはもっとメタな知識だと思う。メタな知識があれば、他の技術にわりかし楽に乗り移れる。強くてニューゲームがこの界隈にはあると思っている。あと技術を学ぶっていうのは、脳に覚えられる容量があって、一定の容量までしか詰め込められない、みたいなものではない。いっぱい覚えられるし、覚えれば覚えるほど技術の理解の解像度が上がる。ただ、時間的制約はあるので、そういう観点から使える技術をまず学ぶという圧力はあると思う。
最初に選んだ選択肢のうち、PHPは世間では広く使われている主流のプログラミング言語であるものの、今の僕は仕事で使っていない。もう一つのFlashの今の状況は、皆さんがよく知っているとおりである。だが、この選択肢は間違っていたかと言われると、全然間違っていなかった。なぜならどちらの道具も当時の僕が作りたいと思ったものを作りきれる技術だったからだ。それで学んだことは多いし、今にも活きている。
いつも調べることをチートシートにしてTシャツにした
相変わらず仕事ではPerlを書いているんですけれど、none とか zip とかそういう便利関数がList::UtilにあるのかList::MoreUtilsにあるのかわからなくて困っていた。
List::Utilっていうのは何かというと、Perlで配列を扱うときに便利な関数集で、コアモジュールなので特に追加でモジュールを入れなくても(CentOSとかのシステムPerlでない限り)使える。
例えばmaxっていう配列(厳密にはリスト)を渡したら最大の値のやつを返してくれる君があるんだけども、こんな感じ。
use List::Util qw/max/; my $max = max(1..10); # 10
別にこれはList::Utilを使わなくても、こんな感じでsort使えばできるんだけども、
my ($max) = sort { $b <=> $a } (1..10);
firstとかnoneとかは確定したら途中で打ち切ってくれるので自前で書くよりは速いし、そもそもXSだし、名前もわかりやすい。sumとかはmy $total; $total += $_ for ...;ってやればできるけれど、まあなんか$_とかあんまり使いたくないじゃないですか。そういうのを丸っと引き受けてくれて便利。
ところがこれだけだと足りないことが世の中あり、もっといろんな便利関数が実装されているのがList::MoreUtilsです。こっちはコアモジュールではないのでcpanm List::MoreUtilsをやる必要がある。
Pythonでもあるzipって関数がList::MoreUtilsにあったり、after { $_ > $treshold } @arrみたいなのもあって便利。
というわけで普段の暮らしでは、これらを両方使っていくという感じなんですが、List::UtilにあってList::MoreUtilsにないもの、List::MoreUtilsにあってList::Utilにないもの、両方にあるものがあってどっちがどっちだっけとuseを書くときに毎回perldocで調べていました。
毎回調べるのはなんだか無駄だなと思っていたある日のこと。
インターネットにこれが流れてきて、なるほどこれはコードの主義主張ですが、もしかしたらチートシートをTシャツにするといちいち調べなくてもいいかもと思ったのでした。というわけで画像を作ってTシャツを作って人生を豊かにしましょう。
List::UtilとList::MoreUtilsの差分を知る
両者はコードを読むとExporterを使って関数を外から使えるようにしていて、@EXPORT_OKに入っているのでこんな感じでワンライナーで生成してみる。
$ diff -u <(perl -MList::Util -E '$"="\n";say "@List::Util::EXPORT_OK";' | sort) <(perl -MList::MoreUtils -E '$"="\n";say "@List::MoreUtils::EXPORT_OK";' | sort)
これでdiffが出る。ちなみにList::MoreUtilsは_XScompiledってやつも出てくるが、これは実際に使える関数ではないので、取り除く。
画像を作る
このままImagerモジュールなどを使って生成したらPerl Hackerっぽいなと思ったけれども、僕はプロプライエタリ野郎なのでAdobe Colorでいい感じの配色を探しつつAffinity Designerで作る。
何がどっちにあるかいつも忘れるので表にした pic.twitter.com/aeuuBiY3z1
— 構造体移し替え業 (@mackee_w) 2021年3月27日
背中はこんな感じにしようと思った。どちらかというと背中の方がわかりやすい。
こっち https://t.co/tFdfkgrYaR よりも実用的な方 pic.twitter.com/JM41aUAN33
— 構造体移し替え業 (@mackee_w) 2021年3月27日
ちなみにこんな感じでレイヤーで分けている。
Tシャツにする
Tシャツは上記ツイートと同じsuzuriで作った。
パーカーも作った。
ただ、思ったのはこれを着てどっちがどっちかわからなくなって見ようと思った時に、自分の胸からお腹を見ると逆になっているので見づらいと思う。なので、同僚などに自分を見てもらって、どっちがどっちか教えてもらおうと思う。
左手キーボードPulsar(Rev.2)が #remap に対応してキーマップ変更もお手軽になりました
はい、自キ業は最近ご無沙汰してます、macopyです。在庫切らしていてすみません。近況としては現在仕事で使っているキーボードはkeyboardio atreusにhako clearを組み合わせてます。
本題としては以前販売していた左手キーボードPulsarですが、11キー版のRev.2に関してRemapに対応したのでお知らせします。
Remapとは
Remapとは特別なソフトウェア無しで、キーボードのキーマップを変更できるソフトウェアです。つい最近リリースされたChrome 89の機能であるWebHIDを用いています。
使用できるブラウザが限定されるとは言え、qmk firmwareに対する知識がある程度必要なファームウェア書き換えによるキーマップ変更と比べてかなりお手軽です。
Pulsarで使用するには
Pulsarで使用するには、Remap(およびVIA)に対応したファームウェアを書き込む必要があります。以下のページにビルドしたhexファイルを置きましたので、QMK Toolbox等で、Pulsarに書き込んでください。ちなみにPulsarのファームウェア書き込み時のリセット方法ですが、レバースイッチ押し込み+USBコネクタを上にしたときに右上のキーを押します。
このファームウェアが書き込まれた状態のPulsarをPCにつなぎ、Chrome89でRemapを開きます。その後、START REMAP FOR YOUR KEYBOARDを押して、+KEYBOARDをクリックし、現れたダイアログ内のpulsarを選択すると、以下の画面になります。
ここからキーマップの変更が出来ます。接続の方法がうまくわからなかったり、これ以降の詳しい設定方法については、サリチル酸さんが解説している以下の記事がわかりやすいです。
salicylic-acid3.hatenablog.com
Remapでできること
PulsarとRemapの組み合わせでは以下のことができることを確認しています。
- キースイッチおよびレバースイッチに対する記号や数字、文字、メタキーなどの基本的な設定
- フルカラーLEDバックライトの設定変更
- レイヤー変更
ただし、以下の設定変更は出来ません。従来どおり直接ファームウェアの変更が必要です。
- ロータリーエンコーダーの設定変更
- TapDanceを用いる設定変更
以上は私の身の回りの人が使っている機能のうち現在使用できない物をあげました。qmk firmwareの機能は豊富なのでRemapおよびVIAで使えないものも中にはあるようです。とはいえ、Pulsarのファームウェア側でなんとかすればできそうな気はするので、要望が多ければこれらの対応も挑戦してみようと思います。
Remap上のキー配置について
上の画像から見えるように、私のJSONの書き方がまずいのか、レバースイッチ部のキーが変な位置にあります。VIA Config上では以下のようにうまく表示されるのですが、VIA Config上で試行錯誤しながら角度をいじっているので、Remapでうまく表示できていない可能性があります。こちらは今後も私が原因を調べてみて、JSONを修正するかRemapに対してissueを上げるなどの対処をしていきます。
まとめ
- Pulsar Rev2がRemapに対応し、ブラウザからキーマップ変更ができるようになりました
- 一部使えない機能がありますが、ソフトを使いながらキーマップをリアルタイムに変更できるなど、試行錯誤にぴったりなのでぜひ使ってみてください
おまけ: 今後のPulsarの販売について
Pulsarの販売についてときどき聞かれることがあるのですが、正直言うと私のやる気次第という感じになっています...。というのも、PulsarはRev1/Rev2どちらも中国でPCBAを行うキットではありますが、OLED用ピンヘッダ(Rev1)やType-Cコネクタおよびレバースイッチ(Rev2)など、私が手半田をしなければ完成できない商品だったので、私の時間を奪っている状態で製造していたのが問題でした。
次に製造するときは、これらのはんだ付けもPCBAを行おうと思っているのですが、なかなか条件に合うやり方が見つけられてないのが現状です。なのでしばらくお待ち下さい。
#japanpm Japan.pm 2021でhotwireをMojoliciousから使うLTをしてきました
久しぶりに勉強会発表して緊張したなということで。
これに参加<してきました。
参加の感想
Perlでも関数の型をチェックしたい - Speaker Deck
データ解析ツールを作った話やAWS CDKの解説、InnoDBクラスタの仕組みなど、実世界に寄った話も盛り上がり、裏トークも合わせて聞くと深く知見を得られた気がしてよかったです
オフラインにあって、オンラインカンファレンスではなかなか成立しにくいものとして、セッションの間の時間での廊下での交流や、会の後の懇親会がありますが、それに似たような体験を得るために会の後に、交流会と称してDiscord内にボイスチャットグループを話題別にたくさんつくって解決していて、かなり面白かったです
交流会に「型」と名付けられたルームがあったので思い切って飛び込んでみたのですが、型や静的解析関連の登壇をされた方や興味がある人でPerlの型チェックにまつわる悩みトークが出来てよかったです。
型チャンネルの話題は参加されていたid:hitode909さんの記事のも言及があります。
発表
Mojoliciousでhotwireを使うトークをしました。というかhotwireっていうのがあって、それがこう言う事ができて、しかもフレームワーク依存はないですみたいなのを伝えたかった感じです。
スライド中のコードはこちらに上げています。動かす手順なども書いたので、興味がある方はぜひ。
sandbox/turbo/example1 at master · mackee/sandbox · GitHub
個人的な反省
- 速く終わりすぎた。多分速く終わりすぎていたと思う(計測していない)
- 手元にストップウォッチを置くの忘れていた
- 通しの練習が不足していた
- このへんは終わらないので事前に説明を飛ばすと決めていたところを予定通り飛ばしたが、時間を手元に用意しておけば飛ばさない判断もできていたと思う
- hotwire/turboがなんであるか(そもそもJSのライブラリであるよとか)そういう前提の話をすっ飛ばしてしまったなと、スライド見返していて思った
- 20分40分のトークだと、この辺の前提条件の共有みたいなのを、僕はかなり念入りにやるのだが。というのもWebエンジニアのカンファレンスでハードウェアの話をするなど聴者の専門分野と違う話をすることが多いので。ただ久しぶり<というのもありすっぽ抜けていた
- 今回は高度な話題はなくして中級者レベルの話題を目指したが、そういう人たちにとって重要な「これをやって何が嬉しいか」みたいな部分の説明が不足していた
- HTMLぶん投げて書き換えているみたいな当たりの面白さの説明は、「面白さが分かる人向け」なので果たして入れるべきかどうか、しかし演者が面白いと思うことをいうのが重要だなとは思う
hotwireについての感想
主にフロントエンドエンジニアやサーバ含めて全部やるエンジニアからhotwireという技術が広まることについての懸念がインターネット上で話されている。というのも、turboやstimulusという技術は現在のWebフロントエンド技術スタックからは連続していない技術であり、どちらかといえばRails/Django/Laravel的なHTTPリクエストを受けるとレスポンスとしてHTMLを返す技術の延長線上に存在しているものだからだと思う。これらは技術の相互運用が難しい。turboの前身であるturbolinksでも同種のハレーションが起こっていた。その時の記憶を思い出す人も多いのだと思う。
昨今のいわゆる"モダン"と呼ばれるWeb開発の環境は、JavaScriptによって駆動するブラウザ上で動くGUIアプリケーションに対して、サーバはHTMLではなくJSONやその他シリアライズフォーマットで返すものが指すものが多い。僕も仕事ではそういう環境でAPIサーバを書いている。もっというとBFFと呼ばれるアーキテクチャを採用すると、フロントエンドリソースの配信やキャッシュ、複数のAPIサーバからのレスポンスを集約するなど、フロントエンドのためにサーバサイドでしかかつて出来なかったことを、フロントエンド技術の延長線上で行うことが提唱されている。ここまでくると、サーバサイドとしてはWebアプリケーションを書いていると言うより、domain specificなデータベースのプログラムを書いている感覚に近くなってくる。そして、APIをしゃべる汎用的なデータベースでよいのであれば、そもそもmBaaSでよいということになり、FirebaseやAppSyncといったサービス、GraphQLとhasuraのようなAPIサーバを構築してくれる技術などが発達していく。
おそらく、僕の予測では、この流れは一般的な消費者がアクセスするようなWebサービスでは止まらないと思う。一方で、そこまでみんなGUI書くのが好きかと言われたらそうではないし、限られた組織向けのWebアプリケーションに、ユーザ体験が良くすることが得意なフロントエンドエンジニアを充てられるかどうかと言えば、今はノーであるという現場が多いのではないのだろうか。ここで指している"限られた組織向けのWebアプリケーション"というのは、社内向け管理画面だとか、勤怠管理システムだとか、在庫管理システムだとか、一般のお客さんからは見えないところで動いているサービスのことを指している。
とはいえ、体験が悪い勤怠管理システムに悩まされている業界の人は結構いるようで、僕もかつてはその一人であったけれども、やはり優れたGUIというのは充てられる人がいるいないに限らず、必要なものだと思う。しかし、優れたデータベースを作れる人が必ずしも優れたGUIを作れるかと言われたらそうではないし、いても超人の類なので、片手間でも優れたGUIを作れる機構というのは、選択肢として悪くないと思う。優れたGUIを作るのには技術だけではなく、作ろうとするシステムに対する深い理解も必要だし、他の例を引用するなどの労力も必要である。現代のフロントエンドスタックは 、それらとデータベースの操作をきちんとやる作業の片手間にやれるほど、お手軽ではないと僕は感じている。なので、hotwireを管理画面に採用するのを同僚に提案してみようと思う。フロントエンドの人には、僕ら以外の一般ユーザの体験を向上するのに注力したほうがビジネス的には正解だと思うからだ。
ただ、hotwireを剥がして一般的なフロントエンドスタックに載せ替えますといったときに、フロントエンドエンジニアの呪詛が激しいと思われるので、採用するなら採用したときのメンバーで閉じて作り続けていく覚悟が必要なんだと思う。ただ、turboを剥がしても普通のMPAとして作動するように作れとドキュメントにも書いてあるので、turbo特有の挙動に頼ったUIを作らなければ、そこまで移行は難しくない、そもそもMPAのアプリケーションをSPAにするのと同じぐらいの労力にとどまるのでは、とは思う。ただ、MPA -> SPAも難しく、というか静的なドキュメントをGUIアプリケーションという別物に作り変えるようなものなので、そもそもページの再設計が必要。
turboをMojoで使うときに困ったときのtips集
onchange=this.form.submit()でfetch requestが発火しない
this.form.submit()をすると、普通のHTMLであれば、submit buttonが押されたのと同じ動作、つまりフォーム送信が行われる。しかし、turboが導入された環境だとsubmit buttonが押されたらページ遷移せずにfetchが使われてリクエストし、レスポンスに応じてturbo driveやturbo framesによるDOM要素の書き換えが行われる。
ただ、今回のデモアプリで示した、トグル状態が変更したら送信するようなときに、素のJSだとタグ内にonchange="this.form.submit()"と書いてしまうのがお手軽だが、これだとturboの環境でもフォーム送信&ページ遷移が行われてしまう。
ググったところ以下のフォーラムのスレッドが見つかり、このスレッドではstimulusでrequestSubmit()というメソッドを呼び出していたが、普通に書いても使えそうだったので、onchange="this.form.requestSubmit()"と書いたところ、ちゃんとfetchのほうが発火したので、そのようにした。しかし今書いてて思ったのだが、turbo無し環境だとこれ動くのか？と思った。
Triggering Turbo Frame with JS - #23 by walterdavis - Hotwire Discussion
turbo streamsでメッセージを投げつけるときの形式
どうやるんやろと思って、turbo-rails gemを呼んでみたのだが、railsにはそんなに詳しくなくて、ぼんやりしかわからなかったので、とりあえず分かる言語でまず調べるか思ったところ、以下のGoでturbo streamsを使う記事が出てきた。
Turbo Streams powered by Go WebSockets - DEV Community
この記事で上げているリポジトリには、
{ "identifier": "{\"channel\":\"Turbo::StreamsChannel\", \"signed_stream_name\":\"**mysignature**\"}", "message": "<turbo-stream action='append' target='board'> <template> <p>My new Message</p> </template> </turbo-stream>" }
という形でWebSocketにメッセージを流しているっぽいので、これをそのまま採用したところちゃんと動作したのでそのまま採用している。しかし、messageキーの部分はわかるが、identifierの部分は何なのかわかってない。ActionCableとかそっち方面由来なんですかね？消しても動くのではと密かに思っている。
...
思ってるんなら試せばええやんと思って試したところ、普通に動いたので、message部だけで良さそう。
件のリポジトリのHTMLにはこういう記述もあって、
<!-- <turbo-cable-stream-source channel="Turbo::StreamsChannel" signed-stream-name="**mysignature**" > </turbo-cable-stream-source> -->
たぶんチャンネルとかシグネチャを設定できるんだと思う。これに対応するturbo-rails gemの実装はここだと思う。
turbo-rails/cable_stream_source_element.js at main · hotwired/turbo-rails · GitHub
これ、turboじゃなくてturbo-railsの方なので、turbo単体で動くのか？という気持ちがある。過去のバージョンだと動いていたのかもしれない。
turbo-streamsのmessageの文字化けだとかタグがエスケープされる
どちらかというとPerlあるあるなんだけれども、utf8フラグがあべこべの状態でながすとどうこうというやつである。最終的には、
my $rendered = $c->render_to_string(template => "append_messages"); $connection->send(decode_utf8(encode_json({ identifier => encode_json({ channel => "Turbo::StreamsChannel", signed_stream_name => "**mysignature**" }), message => $rendered->to_string =~ s/\n//gr, })));
こんな感じのへんてこりんになってしまった。この中には様々なトラブルシューティングの跡が詰まっている。
まず、MojoのWebSocketの接続オブジェクト(ここでいう$connection)は、Mojo::Transaction::WebSocketなのだが、これにもちゃんとJSONエンコード機能はついている。それを使うと上のコードはこのようになる。
$connection->send({ json => { identifier => encode_json({ channel => "Turbo::StreamsChannel", signed_stream_name => "**mysignature**" }), message => $rendered, }});
render_to_string使ってレンダリングしたやつも、to_stringと言いながら実はMojo::ByteStreamというオブジェクトなので、そのままJSON::XS::encode_jsonに突っ込んでも、シリアライズ出来ませんと怒ってくる。しかし、$connection->sendの機能でJSONエンコードした場合は、Mojo::JSONが使われるので、こいつはMojo::ByteStreamを食べられるので、そのままエンコード可能だ。
しかし、Mojo::JSONには普段は有用だがこの場合にはおせっかいな機能があり、
ドキュメントの記述なのだが、つまりXSS対策のためにHTMLタグをエスケープする。しかし、今回は実際にレンダリングするためのHTMLを送っているので、エスケープはされてほしくない。というわけで、Mojo::JSONを使わずにJSON::XSを使っている。
それから、s/\n//grとしているのは、改行コードが入っているとそれがそのまま\nと表示されてしまうからである。これ思ったが、turbo-rails側はどうしているか見に行けばよかったなと思った。この記事も長くなってきたので、今は調べないが、ちゃんとした解決方法を教えてほしい。
あとは、全体をdecode_utf8することである。JSON::XSにもutf8フラグを立てたり立てなかったりする機能があるのだが、それだとうまくいかなかった。なんでこれでうまくいって、JSON::XSでうまくいかないかは分かっていない。こんなのでPerlで仕事している。仕事でもあまり深く考えずにdecode_utf8 encode_utf8を試して文字化けしなかったら採用みたいなことをやっている。utf8フラグがどうのこうのあるが、こういうのは変数を受ける側がどう言う状態を想定しているかで挙動が違うので、知識よりはライブラリ側のコード読むか実際に試したほうが良いみたいな悪い学習をしている。
WebSocketのコネクション維持と再接続
turbo側が切っているのか、それともMojo側が切っているのかは知らないが、Webインスペクタを眺めていると素のnew WebSocketだと無通信が30秒で切れるような挙動を起こしていた。このへんは昔にWebSocket接続管理ミドルウェアを作ったときの知識から引用して、5秒おきにping messageを投げるようにした。そうすると切れなくなった。人生そういうものである。
my $id; $id = Mojo::IOLoop->recurring(5 => sub ($loop) { if (!defined $c->tx || $c->tx->is_finished) { $loop->remove($id); return; } $c->send([1, 0, 0, 0, WS_PING, 'Hello World!']); });
このとき、接続が切れている(is_finished)などのケースでは、繰り返しのタイマーを削除するなどしている。ちなみにMojoはイベントドリブンで動くので、こう言う芸当が可能なのである。ノリもJavaScriptに近い。
しかし、それでもアプリケーション再起動とかのときに接続が切れて切れっぱなしで不便というのもあったので、ReconnectiongWebSocketを使っている。これと同名でおそらく機能が同じのライブラリもあり、こちらはメンテされている雰囲気でなんだかモダンだし、普通ならこっちを選ぶんだが、cdnjsから配信されているからという理由で、前者を選択した。とにかくJavaScriptのビルド環境を用意したくないという気持ちが全面に現れている。
まとめ
Japan.pmまたやってほしい。というか** Weekly Talksみたいな感じで、週1とにかく集まるみたいなのもありでは無いか。それほど技術的な雑談に飢えている。特に会社外の人の意見を吸いたい。
あと技術は触ってみると印象が変わることがあるぞい
Backends for Frontendsはあるが、Frontends for Backendsはなぜ無いのか
この記事では僕の以下の疑問について書き出して、思索し、議論を喚起するものであり、何らかの答えが書かれているものではありません。
Webフロントエンドエンジニアに向けたバックエンドサーバーを構築する仕組みは様々提案されているものの、その逆であるバックエンドエンジニアに向けたフロントエンドを構築する仕組みがあまり提案されていない
この記事を書くきっかけ
以下の記事を読んで、フロントエンドの技術スタック内でサーバサイドアプリケーションの一部の責務を負うような動きがどんどん加速している現状であるが、我々バックエンドエンジニアはどういう動きをすればいいか考えている。
筆者の立場
- 自社開発のWebサービスのバックエンドアプリケーション開発を担当している
- 現代フロントエンドに関しては、社内ツール程度はNuxt.jsを用いて書いたことがある。2C向けのプロダクションコードではデバッグ目的でTypeScriptを読む程度
- 関心があるのは効率かつユーザのニーズを満たせる永続的データ構造とそれをうまく扱えるバックエンドアプリケーションの設計
なぜBackends for Frontendsと分かれているのか。
日本のほとんどのWeb開発現場においてはフロントエンドエンジニアとバックエンドエンジニアという2つの職能が並立して存在していると、僕の観測範囲では思う。しかし割り当てられたロールのラベルがそうなっているだけで、用いる技術はかぶっているケースもある。
現代の一般的なWebアプリケーションの構成は以下のようになっていると想定している。
これはかなり簡略化した形であり、例えばほとんどのサーバサイドWebアプリケーションにはログ集計解析基盤もあるし、フロントエンドスタックにSentryなどを用いたエラー監視スタックが含まれていることもあると思う。また、僕はフロントエンドエンジニアの仕事をすることはあまりないので、どうしても解像度に偏りが出てしまう。あくまでも、同僚がやっていることを外から観測するとこういう形で触っていることが分かれているようだ。さらにいうと僕が関わっているWebサービスはSPAとサーバサイドテンプレートレンダリングを併用しているものの、フロントエンドスタックでのSSRは採用していない。
そして職能ごとの責務はこのように分かれている。
ブラウザからこっちと、ブラウザがネットワークを通して向こう側に分かれている。ただし、フロントエンドスタックのビルドを通してキャッシュ制御を行っている領域もあるし、HTMLテンプレートはUIにも関わってくるため、フロントエンドエンジニアが担当している。というわけで赤字にしておいた。
つまるところ、「あなたはここまで」「わたしたちはここからここまでやる」と壁ができている。そのほうが専門性が深まり、効率が高くなるからだ。でももっと細かく分けることも出来る。実際、我々のチームは社内の他のプロジェクトではSREチームと呼ばれる部署が担当している部分もサーバサイドエンジニアが行っている。インフラ構築であったり、監視の部分だ。でもこれは切り出す事例が世の中にはたくさんある。更にいうと、データベースの管理はDBAという職能の方が専門的にやっているケースも世の中にはある。やろうと思えば無限に分割できるし、やろうと思えば全部やれる。全部やっている例が、世間ではフルスタックエンジニアと呼ばれること僕は理解している。
また、昨今ではこれらの一部をSaaSやPaaSに任せる例もある。僕のWebサービスはAWS上に構築され、メインのDBはAmazon Auroraを用いていることから、DBAおよびSREの一部の役割をAWSにやってもらっていると考えられる。アプリケーションによっては、FirebaseやVercelなどを用いると、CDNから先の向こうをほぼ全てサービス側にやってもらうことも可能である。
フロントエンド技術がバックエンドへ揺り戻しされる対する考察
じゃあなぜ全部やらないのか。それはそれぞれの技術スタックが複雑になり難易度が上がってきたからだ。僕の記憶では2010年以前のWeb開発においてはフロントエンドエンジニアと呼ばれず、マークアップと言う仕事として、現在のサーバサイドエンジニアが片手間にHTMLとCSSを書いたり、現在のデザイナーがこれらを書いていたと思う。しかし、Webが単なるページから動的なアプリケーションに進化し、HTMLがドキュメントを表現するための記法から、UIを記述するための基盤として利用されるようになった。そのため、より多くの技術の理解が求められて、マークアップ周辺の仕事はフロントエンドエンジニアという職能に切り出されてきた。同じ現象は、サーバサイドエンジニアからSREという職能が切り出されたのにも似ている。
一人で担当できないぐらい、技術が発展したから複数人で切り分けて担当するようになった。では、なぜフロントエンドエンジニアがわざわざ現状切り分けられているバックエンドの領域に足を踏み入れようとしているのか。それは2つの理由があると思っている
フロントエンドエンジニアが達成したい目的がフロントエンドのスタック内では収まりきらなくなった
Server Side Renderingという技術は、ブラウザサイドでのJavaScriptの実行では実現できなかったことをサーバサイドで実行することで解消する。アクセス一発目のレンダリングスピードを高めるためにサーバサイドリソースを使ったり、CDNキャッシュを利かして解決する。また、JavaScriptを解釈しないクローラに対しても有効に働く。しかし、本来はブラウザ向けに書かれたコードをサーバで実行するには制限が多い。フロントエンド感覚でサーバサイドで動くコードを書くのは未だに難しい。
そこで、React Server ComponentはSSRが抱えていた、SPAのアクセス一発目のみにフロントエンドのコードをサーバサイドで実行するのではなく、SPAのコンポーネントを局所的に常にサーバサイドで実行したものを透過的にクライアントが取得する点で違いがあると考えている。境界を再設定することで、よりフロントエンドが主でバックエンドが従である関係を強調し、扱いやすくしている。
フロントエンドでの実行に比べて、サーバサイドでの実行はいくつかのメリットがある。ユーザのブラウザに依存しないコントローラブルな実行環境、実行内容やコードの秘匿性などだ。このへんをどう実現するかは、様々なアイディアが出てくると思われる。しかし、どうやって運用するかどうか、うまく運用するかという点についてはもう少し事例がほしいと感じる。
この辺の議論はこちらの記事にもまとめられている。
◯◯エンジニアの〇〇には関心領域が込められている
じゃあみんなフロントエンジニアがフルスタックエンジニアになればいいじゃん、それが幸せと思うが、僕はそうはならないと現実的には思う。一人の人間が関心を寄せられる領域というのは思ったよりも狭い。UIを構築するためのマークアップは専門的な知識が必要だし、ビルドパイプラインにも、HTTP通信についてもそうだ。既にフロントエンドエンジニアが抱えている技術の領域は広く、そして深化していっている。
エンジニアというのはくっきりしているか、ぼんやりしているかの過多はあるものの、その仕事をするときのある程度の軸が存在すると僕は考えている。これを関心と呼ぶ。関心の周辺の領域というのは、効率よく学習でき、モチベーションもあるが、関心から遠いと効率が悪くなる。仕事上のWebサービスというのはユーザに見たり使ってもらったりして、その結果直接的・もしくは間接的にお金をもらうことを目的としているが、それはどのエンジニアであっても共通している目的だ。しかし、関心がそれぞれ違うし、それによって目的に対する手段が変わってくる。それがフロントエンドエンジニア・バックエンドエンジニアとラベリングされている物の本質である。一般的には責任の範囲とも言われるが、僕の仕事場ではあまりそれが当てはまらない。得意不得意はあるものすべての技術領域には物理的にはチーム内の人間は手を出せるので、責任範囲より関心の違いといったほうがしっくりくる。
どうしても、普段触ってる関心領域より遠い技術領域は学習の効率が悪くなってしまう。フロントエンドエンジニアで、普段はUI周りを触っているエンジニアほどバックエンド方向の技術領域は精度良く進めるのは難しい。これは世の中の情報についてもそうで、「フロントエンドエンジニア向け」「バックエンドエンジニア向け」とわかりやすいように情報が分かれている。BFFに必要とされる技術は、これまでのバックエンドの知見をかなり含んでいる。しかし、情報収集の際にフロントエンドエンジニア向けばかりの情報を読むと、理解が遠回りになってしまう可能性があるのではないか。
こういったラベリングは、主に求人上のマーケティングワードや、働く人のコンフォートゾーンとしても機能していたが、それが実態を表さなくなってくると思われる。実態が先か、言葉が変わったり、新しい言葉が生まれるのが先か、それちょっと予想がつかない。
バックエンド側からのアプローチがもっとあってもよいのではないか
Backends for Frontendsがフロントエンドの人が使いやすいように、バックエンドの仕組みをフロントエンドの技術スタックで構築したり、理解しやすいように抽象化するという目的もBFFにはあると思われる。では、バックエンドの技術スタックでフロントエンドを構成するアプローチは考えられるのか。
RailsのHotwireやPhenixのLiveView等が挙げられる。これらはSPAをトラディショナルなテンプレートレンダリングを行うフレームワークで作ることに対する回答だと見ている。また、vuguという、Goのフロントエンドライブラリがある。GoでVueライクなコンポーネントを書いて、wasmで実行するものである。本来、ブラウザ向けの技術スタックがNode.jsを介して動いてBFFを構成するように、バックエンド向けの技術スタックがフロントエンドで動く一例だと思う。
また、そもそもバックエンドだけ書いて、フロントエンドの記述を最小限に抑えるアプローチもあるのではないか。バックエンドアプリケーションの記述を最小限にするために、BaaSやサーバレス環境を用いる手法に対するアプローチである。これが僕が捉える、Frontends for Backendsであると感じる。実際この記事でいいたいのはここだけです。
僕は仕事では、GraphQLをしゃべるサーバを書いている。ここで思うのは、GraphQLさえ吐いて、あとは汎用的なコンポーネントを配置すればWebアプリケーションが作れたらいいのになと思う。例えば、管理画面のような独自のデザインやブランディングが必要ない場面ではbootstrapのようなコンポーネントとGraphQLのクエリを紐付けることさえすれば、そういったSPAが構成できるのではないか。React Adminがかなりこれに近いが、それにしてもReactやJavaScriptツールチェインの知識が多少必要である。
管理画面向けで言うと、Vironがある。VironはSwaggerを元にしたAPIサーバを書けばUI側を自動構成できるフレームワークである。こういったものをフロントエンドエンジニアの人はどう考えているかを知りたい。
しかし、一定の管理画面ではこれらは成立するだろうけれども、現代はSPAは、独特のコンポーネントのライフサイクルが存在する。これを、自動生成のツールだけで実現できるかは僕はわかっていない。また、多くの人が使うWebアプリケーションだと、出来合いのコンポーネントでは実現できないようなUIやインタラクションも存在すると思う。そういうのを人手を介さずに生成するには難しい。そこまで来るとノーコード, ローコードの領域に入ってくる。
というか僕がここまで言っているのは、得意なこと/力を入れたいこと以外はノーコード, ローコードで解決したいという話に近くなってくる。SaaSを活用してWebサービスを作ることもそうだし、サーバレスも、実際はサーバ運用レスであることもその証左だと思う。
僕は、バックエンドが得意だ。だからフロントエンドは楽して書きたい。そもそもフロントエンドがないとCLIのアプリケーションしか作れないからだ。
まとめ: とはいえ結局全部やることになる
もともとは一つの職能であった、Webエンジニアが技術の発展に伴って複雑化し、分業化されていったことを話した。しかし、それがBackends for Frontendsに代表されるような、それぞれ分割統治されていた技術領域だけで解決できなくなり、他方の領域の一部を担当するような現象が起こっていることを話した。
最終的には、全部やる人と、一部を深くやる人に分かれていくのではと予想している。実際にはクラウドコンピューティングという領域ではそれが起こったのだ。かつて、インフラエンジニアというデータセンターのサーバラックを管理したり、調達するような職能の人は会社内にいたり、委託されてそれをやる専門業者がいた。そういう仕事のやり方もまだ残って入るものの、AWSに代表されるクラウド事業者を用いてサービスを構成する際には、インフラエンジニアはクラウド事業者内で深く作る人と、クラウド事業者が提供するサービスを構成して組み合わせて使う人に分かれた。それでより高度に、より堅牢なサービスを作れるようになった。
フロントエンド・バックエンドにもそういう変化が起き、あるコンポーネントを深く作る人と、それを組み合わせる人に分かれていく。そうすることで、必要な知識を分担することが出来、さらに高度なWebサービスが作れるようになる。ただ、それどういう職業であると求人市場で言うか、どういった給与体系/雇用体系、サービス体系なのか。まだ僕にはわかっていない。
2020年の振り返りと2021年の抱負
はい、今年は色々ありましたね。しかし、他人と共有しやすい「色々」があったのであって、毎年色々はあったのではないか、つまり今年は多くの人が同じことを話題にした年であると言えるのではないか、そう考える日々です。
去年のやつ 2019年の振り返りと2020年の抱負 - ぱいぱいにっき
登壇とかイベントとか執筆とか
CircleCI ユーザーコミュニティミートアップ#8
CircleCIのイベントで話した新しいAPIを活用した話。しかしこのあとにCircleCIもいくつかの新機能が入ったり、社内で一部使い始めているGitHub Actionsも大きく変わったので、振り返るとここはActionsで作るなあとかそういうのもある。これは1月なのでまだオフラインイベントが開催されていた時期。
Tsukuba Mini Maker Faire 2020
あと、仕事とは関係ないのだけれども、2月にTMMFで出展をした。
内容としては、昨年のbuildersconで頒布したFMラジオバッジや自作キーボードなどを展示していた。周囲の出展も面白かった。会場のローカルで熱気が凝縮した雰囲気もあり、東京でやるのとは別にまた出展したいと思った。
吉祥寺.pm23【オンライン】
あと、オンラインイベントになったあとに、吉祥寺.pmで仕事で取り組んでいる話をした。
この話でおこなった、GoでGraphQLをさばくサーバは無事本番投入して元気に今も動いているので、どこかで話をしたい。
Perl Hackers Hub
それから、WEB+DB PressのPerl Hackers Hubでまた記事を書かせていただいた。
仕事でも、比率は少なくなったものの、まだまだPerlを書いているを書いているので、コミュニティに何らか還元をし続けたい。
ISUCON 10
藤原組として出た。他のお二人とは普段からよく一緒に仕事していたけれども、ISUCONに一緒に出るのは初めてであった。なんなら藤原さんとは出題時の移植を過去にやったことがある。
成績としては予選落ちだったが、並行回答チームというエキシビジョン枠の形で決勝に参加させていただいて、successしたチームの中では全体3位の成績だったので、良かったなとなった。来年は決勝に出たい。
オンラインイベントについて
みなさんも認識している通り、今年はリアルイベントが激減してしまった年だった。なので、登壇自体もあまりなく、オンラインの勉強会に行ったのもあんまりなく、今年は技術的な悩みを聞いてもらったり、自分が体験していないことを聞くような機会も少なく、今年、それと来年以降の技術に対するスタイルを変えなければならないのかな、とか思っていた。まあ、もがいても体力を食うだけなので、今は様子見状態ですが。
僕は技術勉強会やカンファレンスに行くときの目的として、一番に懇親会をおいていた。本編の登壇は生で話を聞いたり、質問をすることも大きな価値であるけれども、その話を肴に懇親会で他の参加者と技術的な話をして理解度を深めることで、僕は知識を得ていった体験が今まではあった。
一方、今年主流となったオンラインイベントの懇親会は同様の体験を得るのは難しい。今年の前半は、オフラインができなくなったので、オンラインにその代理の体験を求める動きが多かったのだけれども、オンラインはオンライン、オフラインはオフラインという別のものであり、それぞれ代わりになるものではない事がわかってきた。なので、オンラインのイベントでは代わりではなくオンラインならではの情報の取り方、接し方をしなくてはという気持ちがあるのだけれども、なかなか僕なりの答えを見出せていない。
代わりに一人でドキュメントと対峙することも多くなったし、一人でモックをガッと作ってしまうことも多い。発表の場があまりないので電子工作関連もM5Stackを使って色々作っているが、すぐにパーツを使い回すために崩したり、社内の仲間内だけの共有をしていたりする。作ることに専念できていていいのか、それともシェアとコラボレーションのサイクルが回っていかないことを損と考えるのか、わからない。。。。
仕事
今年は仕事の内容が変わった。去年までは社内ツールの作成だったり、技術検証をやっていたのだけれども、今年は運用中のWebサービスのサーバサイドエンジニアの仕事をやっている。その一環が以下のような仕事。
今年前半にこのプロジェクトに慣れて、後半は新機能の実装とともに、コア機能をほぼ全部PerlからGoに書き換えるという仕事をした。Goに書き換えた結果、コードの責務が整理されて、ある程度、型安全に守られながら書きやすくなり、レスポンスタイムが安定し、またDynamoDBに置き換えたことでほぼ無限のスケールアウト性能を手に入れた。
よかった、よかったのだが、GraphQL, DynamoDB, クリーンアーキテクチャなどの新しく導入した技術たちは、扱うのが初めてであり、今の時点でもある程度の歪みが生じてしまっている。また、Perlとの旧システムとの連携を取るためにアーキテクチャ的な無理をしているので、来年はこのあたりの解消を確実にやっていくのが、足元の目標ではないか。
今年得た技術として一番大きいのは、メインのDBを使い慣れたRDBMSではなくDynamoDBを使うことにしたことである。僕が今まで一番使ってきたデータストアはMySQLであり、ロックの仕方やパフォーマンスチューニングに一定の蓄積された知識があった。そうではなく、全く未体験のNoSQLを使うのはなかなかに抵抗があることであり、できるのかなと思ったが、理屈では出来て感情が拒否しているという感じだったので、やってみたらちゃんと動いてよかった。なんならボロボロでread/write throttlingが起こる状態からproduction readyの状態に持っていったチューニングもやったので、そのへんもどこかで話してみたい。
一年を通してかなり真剣に付き合った技術としてGraphQLがあるが、エコシステムは独特であるものの、数あるスキーマ定義言語/メッセージングプロトコルの一つであるので、あんまり自分の中では特別視していない。今後も型有りRESTful API定義言語として付き合うと思う。
とはいえ、サーバサイドの変化の流れもある。今年はEC2で運用されていたトラディショナルなアプリケーションをECSを使ったフルコンテナ環境に持っていったこともしたが、よっぽど理由がない限りはこれがLambdaやCloudRun/knativeといったサーバレス環境に行く流れを感じている。またコンテナやサーバレス環境で賄えないような機能要件も、FirebaseやAuth0やstripe、SendGridといったSaaSを併用するようになっていくと思う。ただ、これは僕らが向き合っている市場環境で取りうる最適な選択肢であって、コスト面や機能面で折り合わずに自作することもあると思う。けれども、僕には内製することが製品に大きなアドバンテージを与えるわけではない場合には、外部の部品を使うのを、前よりもためらわなくなったと感じる。
それでも、コアの機能は自分たちで作り続ける。むしろそれに専念するために、必要ないところはSaaSを使う。今の仕事でいうと、トーナメント表の進行管理や対戦管理が自分たちのシステムで今一番価値があるところだと僕は思っているので、それにはかなり力を入れる。それ以外は、外部サービスをできる限り使う。
ただ、SaaSをフル活用するというのは、知識のロックインにもつながる。あるSaaSで手に入れた知識を他のSaaSで使えるとは限らない。こういうとき、僕はプログラムを書くというより、組む、組み合わせると言う事が多いが、自分がモノをイチから作っている感覚ではなく、すでにあるパーツを組み合わせて新たなサービスを作っていると感じるからだ。昔の言い方だとマッシュアップと言ったり、別の観点だとオフザシェルフというかもしれない。
自分でイチから作らないことに対して、僕はあまり危機感を感じていない。知識を新たに手に入れなければいけないというのはそうだが、それはやればいいし、ドキュメントの読み方や探し方、共通のAPIの叩き方や扱い方などそういったメタ知識をためていくのが重要だと感じているからだ。最近だとwebhookといった形で、SaaSから自分たちで用意したエンドポイントにイベントを送信されることがあるが、こういったのもメタ知識である。
来年はLambdaにより傾倒するようなアーキテクチャを組むようになるだろうし、よりNoSQLを活用するようになるだろうし、SaaSも活用すると思う。それを胸張ってハックしているというぐらいにものにしたいと思う。
趣味
キーボード
今年は一気に失速した。現状、興味を失ったに近い状態にある。というのも、人と会わなくなったり、新しいハードウェア欲があまりなく自分のために作るつもりにもあまりなれなかったからだと思う。とはいえPulsarは今でも欲している人がいるし、異常にハンダがむずくて僕が発送を行うたびにめっちゃ細かいUSB-Cコネクタのはんだ付けをして発狂する現状が改善されればまた販売にチャレンジしてみようと思う。
車
買い替えた。
とはいえ前に乗っていたのは、実家近くの知り合いに譲ったので、また実家に帰ったときに乗らせてもらおうと思う。本当に楽しい車だった。色んな所に行った。
歩く
世の中こんななので、8月くらいまで家の中に引きこもりっきりで、仕事で時々会社に行くぐらいの生活で、睡眠の質も悪く、思えば体的に辛かったなと思ったのですが、9月ぐらいから歩くことを考えていた。
初っ端に9月に奥日光に行った。そんでもって戦場ヶ原を歩いた。
そのあとに伊豆で海近くの崖を歩いたりした。
それから、新たに始めたキャンプのついでに長瀞の山を登った。
ソロキャンプ
YouTube見てたらキャンプしたくなり、キャンプを始めた。車を持っていたのも大きい。
特に意識してなかったのだけれど、ワンポールテント+プラシパラトカの組み合わせをしているので、軍幕っぽい感じのコーディネートになっている。
来年へ
いつも来年はこれをしたいなあとここに書くのだけれど、今年は意外にも現状維持ぐらいにしか考えていない。死ぬのか？いや、今のまま平穏に暮らしたい。
とはいえ、状況が改善されてオフラインイベントがある程度開催され、旅行にもある程度行けるようになり、人と交流を持ちたい。それが叶わなければ、今どきにあったコミュニティを探すかもしれない。来年のことはわからない。。。
あーあと、Rustやりたいんだった。ずっとやりたいって言っているのをどうにかしたいですね。
Webサービスの機能を実装するか否か取捨選択のときに考えること
スマホアプリでも業務アプリでも同じようなことがあると思うんだけども、僕が携わってるのはツール的なWebサービスなので限定しておく。あとこれは個人的な体験から生まれた思考です。
ツール的に使われるWebサービスを作っていて、機能が十分に足りてなくて、何か追加するならこれ、という選択肢がいくつもある場合にはやはり全部一気に取り掛かることはできない。なんでかっていうと、一応言葉にしておくと、欲しい機能は無限に溢れ出てくるように見えるが、実装に使えるコストはそれに比べてかなり限定されているからだ。
金があればいいかと言われると、機能というのは人が多かれ少なかれ取り組んで出来るものだし、人を雇うには金が必要だが、金があれば必要な人が確保できるかというとそうではない。誰でもいいというわけではなく、ある程度プロジェクトの分野の知識がなければ、余計に時間を浪費する。また人が多くても、束ねるのも労力が必要で、小回りも効かなくなる。そこまで来ると小さい開発チームに分割していくのが業界的にも良いとされているが、マネジメントをオーバーヘッドと考えると、コストに対する効率が悪くなるように見えるかもしれない。なお、僕は直接成果物に触ってプロジェクトにコミットする職能ですが、マネジメントをやる人も必要なものだと感じる派閥です。
また、Webサービス開発においていい感じにチームを割れた経験は僕にはなく、少数精鋭で各個撃破が一番良いと思っている。しかし少数精鋭の効率の良いチームを作って回していくのも困難な話なのだ。
さて、各個撃破するということは、実装する機能に優先順位をつける行為に直結する。だとすれば、どういう基準で優先順位を付けるか。これにもいろいろな考え方がある。
まず、使われる機能であること。これは最優先事項である。使われない機能を実装することほど無意味なことはない。
そんなことは当たり前の話で、しないだろうと、皆さんは思うかもしれないが、サービス開発において、使われない機能を実装してしまうのは往々にしてありうる。
SNSや問い合わせなどで「この機能が欲しい」「この機能があればあなたサービスに乗り換える」という要望を受けることがある。これ自体は大変ありがたい。けれども、お客さんはその機能が実装されたからといって、その機能を使う義務はない。また、望み通りのものが実装される保証はない。いくら言葉で説明しても、頭の中のニュアンスまでそっくり他人に移植出来るわけではないからだ。
なので字面をそのままそっくり受けとるのは、僕は危険だと思っている。でも要望自体は捨ててはいけない。その言葉の裏に隠れたニーズを汲み取るが重要だ。でもこれは推測でしかなく、不確実性も高い。
では、実際に使われる機能を実装するにはどうすればいいか。これはチキンエッグ的結末で恐縮なんだけども、やってみてこれは望みのものでしたか、と聞くしかないと僕は思う。
要望する人がチーム内や会社内の人間であったり、開発費用を負担してくれるような協業パートナーであれば、まだ容易い。パワポでこんなのどうですか、と持っていって説明すれば、だいたい擦り合わせることができる。
ただ、相手が不特定多数の一般ユーザさんだと途端に難しくなる。直接言葉を届けられる相手以外だと、まだ世の中にないものを伝えるのは難しい。また限定的な機能でリリースしたり、モックを作るのも手ではあるが、お客さんは完成品が欲しいのであって、試作品を見たいわけではないので、これもまた上手く伝わるか自信がない。
僕は過去にゲームアプリ開発の現場にいたことがあり、以下のような体験をしたことがある。ゲーム開発では、本開発に入る前にモックやパワポの段階で面白いか、や、売れるか、を見て進退を決めるのだけども、試作の段階だとエフェクトや綺麗な絵や音が入っていないことが大半である。でも見たいのはゲーム性の部分なので本来は必要がない部分であるし、鍛えられた人であれば想像で補える。ただ、訓練されてない人は、きれいな表現を面白さの根源と勘違いしてしまって、判断を誤ることがある。きれいな表現は面白さを増幅するが、0に何掛けても0なので、0かどうかを判断しなければならない場で、掛ける側を見てしまうと事故が発生してしまう。
Webサービス開発でも同様のことはあり、経験を積んで試作品と完成品の差分を覚えて我々は試作品から完成品を想像できるようになる。ただ、世の中の大半の人はそうではないので、試作品を不特定多数の人に晒すのはかなり勇気がいることだと僕は思う。それが完成品と勘違いされるのが最もダメージがでかいからだ。
僕が思う、一般のお客さんがサービスに要望を出してそれを通すにはどうすればいいかを考えてみる。
それは、そのサービスを現時点で使っていること、さらにそれを周囲に公言していることが大事だと考える。サービスを使用している時点で利害関係者だ。もちろんまだ見ぬ未来にやってくるお客さんのために何か作るのも、サービスの拡大発展には必要である。しかし、これは博打で、使われない機能を作ってしまうリスクが高くなる。また、すでに使用しているユーザーであれば機能実装後にフィードバックを得て、作ったものがニーズからズレてるかズレてないかを判定できる。新しいユーザーというのは、新しく機能が実装されたからサービスを使い始めようというのではなく、大半が他人が使ってるから自分も使おうとなる。観察しているとそういう傾向だ。なので、すでにサービス自体を使っていて、フィードバックを得やすく、周囲に公言している人の意見を重要視したくなる。また、サービスと一蓮托生の人ほどとことん考えられたユースケースを提案してくるだろうというメタな推測もある。
ただ、これもある視点ではリスクをはらんでいる。今いる人にとってな大事な機能が、将来のユーザにとって障害になることもある。僕はこれをゲームアプリで学んだし、ゲームはそれがライフサイクルに組み込まれているものの、Webサービスはそうはいかんやろとも思う。
よくデザインや機能がリニューアルして既存のユーザから使いにくくなったと不評を受けるサービスがあるけれども、我々作る側は、上記のことを自分の中の天秤にかけて判断し、それから実際の綱渡りをしていると感じる。一歩バランスを崩せば真っ逆さまである。
サービス運用というのは、走ってる車の部品を走りながら取り替える行為をずっと続けるようなもの、と会社の人が言っていたのを思い出す。それは動いているプログラムを壊さないように機能を付け足す観点だと思うけれども、機能自体を付け足して、それ自体は完璧に動くが、サービス全体で見たサイクルが壊れることもしばしばある。
でも、これだから物を作るのって楽しいんですよね。