まず、今回の新機能を使うためにEFSのボリュームを作ります。この手順は上のページに書いてあるそのままで大丈夫です。完全に同じ手順でやると /mnt/msg にマウントされるので、その下にデータファイルが置かれるように設定します。この当時のCGIスクリプトなので、minibbs.cgiを直接編集して上の方で変数に設定します。

$tmp_dir = '/mnt/msg';

これで、あとはこのminibbs.cgiをAWS Lambdaで動くようにすれば良いわけです。

そしてこのPerlのCGIスクリプトを動かすにはいくつかの道具を組み合わせていきます。

カスタムランタイムでPerlを動かす AWS::Lambda
AWS LambdaのインターフェースをPerl標準のPSGIに変換する AWS::Lambda::PSGI
PSGIをCGIインターフェースに変換する Plack::App::WrapCGI

この3段階をハンドラ関数としてまとめたものが、上のレポジトリにあるhandler.plです。

use utf8;
use warnings;
use strict;
use AWS::Lambda::PSGI;
use Plack::App::WrapCGI;

my $app = Plack::App::WrapCGI->new(script => "$ENV{'LAMBDA_TASK_ROOT'}/minibbs.cgi", execute => 1)->to_app;
my $func = AWS::Lambda::PSGI->wrap($app);

sub handle {
    $ENV{'TZ'} = "JST-9";
    return $func->(@_);
}

注意事項として、正しく動かすためには以下の設定も必要です。

minibbs.cgiに実行権限が必要なので、chmod +x minibbs.cgi してからZIPファイルでデプロイが必要（コンソールからの編集不可）
1行目のshebangが配布状態だと/usr/local/bin/perlになっているので、/usr/bin/perlに変更する
URLをminibbs.cgi内に設定する必要があるので、先にAPI Gatewayを設定する（運用でカバー）
あらかじめ空のデータファイルが必要なので、初回だけhandler.plでtouch /mnt/msg/data.cgiとかやっておく（運用でカバーその2）

このあたりをクリアすると、前世紀に普通に使っていたminibbs.cgiを、ほぼそのまま一般的な設定項目以外いじることなく、令和時代のサーバーレス環境AWS Lambda上で実行することができました。

運用でカバーした2点も、minibbs.cgi自体を少し直せばもちろん対応できるわけですが、今回はそういったプログラム本体の修正を一切せずに、そのままAWS Lambda上で動かす事ができるというデモンストレーションなので、上で紹介したperlのパスと変数以外は一切変更していません。

おそらく性能もさほどでないと思われますし、古いアプリケーションをそのまま動かしているので脆弱性対応は依然として必要ですが、まずは手軽に今動いているサーバ環境の運用コストを下げるために、このようなサーバーレス＋共有ディスクの構成は極めて有用です。あくまで「リフト＆シフト」のリフト策として、クラウドシフトのためのリソースをひねり出すために使うのが望ましいですが、カードの一つとしてこういったことがすぐに実現できるんだ！という紹介でした。

宣伝

nekoruri.booth.pm

AWSによるサーバーレスアーキテクチャ

作者:Peter Sbarski
発売日: 2018/03/14
メディア: 単行本（ソフトカバー）

CGI & Perl ポケットリファレンス (Pocket reference)

作者:藤田郁,三島俊司
発売日: 1999/12/02
メディア: 単行本（ソフトカバー）

2020-06-07

AWS LambdaとDynamoDBがこんなにツライ時代ではない

Serverless Azure AWS

ありがたいことに、3年前に#ssmjp 2017/06で話したスライド

AWS LambdaとDynamoDBがこんなにツライはずがない #ssmjp

をTwitterで紹介して頂いた*1 ようで、当時から大幅に改善しているところを振り返りたいと思います。あと、ついでに最近やっているAzureに関しても少し触れていきます。

サーバーレスアーキテクチャ #とは

f:id:nekoruri:20200607114509p:plain

当時はこう説明したのですが、今でもそんなに悪くない表現かなと思います。

f:id:nekoruri:20200607114853p:plain

書籍は現在「Serverlessを支える技術第3版」まで出ていますので、BOOTHからどうぞ（隙あらばダイマしていく方針）。

サーバーレス三種の神器

f:id:nekoruri:20200607115055p:plain

今このスライドを作るなら、認証認可の話を入れるかなと思います。システム内のAWS IAMとクライアント側のCognitoどちらも重要です。

ちなみにAzureを含めておさらいすると、こんな感じの対応になります。

勝手にスケールするデータストア

Amazon DynamoDB、Amazon DocumentDB ↔ Cosmos DB
Amazon S3 ↔ Blob Storage、Data Lake Storage Gen2
Amazon Aurora Serverless ↔ SQL Database serverless

勝手にスケールするソフトウェア実行環境

AWS Lambda ↔ Azure Functions
(AWS Fargate ↔ Azure Container Instances)

それらをつなげる枠組み

Amazon Kinesis Streams ↔ EventHubs
Amazon Simple Queue Service (SQS) ↔ Queue Storage、Service Bus
Amazon Simple Notification Service (SNS) ↔ EventGrid
AWS Step Functions ↔ Logic Apps、Durable Functions
Amazon API Gateway ↔ (Functions組み込み機能)、API Management

f:id:nekoruri:20200607121752p:plain

この辺は今もあまり変わらずです。

この構成の肝は、クラウドサービスの構成と、関数のデプロイを完全に分けていることです。AWS SAMやServerless Frameworkで普通にやると、関数本体がCloudFormationスタックに入ってしまい、リアルからデータが上がってくる「本番環境」で高速に試行錯誤を繰り返すIoTビジネスの特性とちょっと合わないと感じたので、ここを切り離しました。ただApexがメンテされなくなってしまったので、今ならlambrollですね。

Azureでも同じように、全体の構成をTerraformで行い、関数は別レポジトリからデプロイしています。

サーバーレスあるある選手権 Lambda編

f:id:nekoruri:20200607125048p:plain

f:id:nekoruri:20200607125146p:plain

ログそのものは現状でも余り変わっていないのですが、追いかける部分に関してはAWS X-Rayの登場でだいぶ改善されました。AWSサービスへの外部リクエストは何もしなくても記録されますし、外部サービスや重い内部処理をプロファイリングしたければサブセグメントを生成してあげればX-Rayの時系列トレースグラフに表示できます。

Azureの場合はVSCode拡張からリアルタイムでログを見ることができます。Application InsightsからX-Rayと同じようにサービス間のコールグラフやサブセグメントごとのトレースグラフが見られるのも同じです。

f:id:nekoruri:20200607130253p:plain

ここは今でも変わっていませんが、その後運用して判った部分としてはmemory_sizeの調整になった時点で消費メモリ量が問題になることはあまりない（ざっと見て最大消費量より多ければ良い）ので、余程メモリ変動の大きい処理をしていないのであれば、カスタムメトリクスだして追いかけるほどではないです。逆に言えば、メモリ変動が大きい処理があるのであれば、どこかで仕組みを変えて処理量のほうを平準化できないか考えた方が良いです。

f:id:nekoruri:20200607130738p:plain

f:id:nekoruri:20200607131145p:plain

このスライドの中で状況がもっとも変わった部分です。なんとかしてくれました。

そもそもVPC環境でのLambda起動の仕組みが大幅に改善されました。

ENIを生やしたインスタンスを個別に作成していたものが、基盤側で用意した共有ENIにNATされるようになったので、15秒ほどかかっていたのが1秒前後になりコールドスタートが実用的な範囲になりました。

また、RDSへの同時接続数も、Lambda側で同時実行数が設定できるようになり、RDS側にもフルマネージドのコネクションプーリングRDS Proxyが提供されたので、問題にならなくなりました。

そもそもVPCを使わずAurora ServerlessのData APIを使うという選択肢もできました。

とはいえ、依然としてRedisなどはVPCの中にしか作成できないので、VPCを廃絶できないのがおしいところではあります。

サーバーレスあるある選手権 Kinesis編

f:id:nekoruri:20200607132542p:plain

f:id:nekoruri:20200607133153p:plain

f:id:nekoruri:20200607133208p:plain

ここも大幅に改善されたポイントです。

待ち時間を指定できるようになったので、データが少ない場合の処理効率が良くなりました。

またKinesis Data Streams側のシャード数と掛け算でLambda側の「Parallelization Factor」で並列実行できるようになったため、時間が掛かる処理をぶら下げたときにシャード数まで引き上げずに済むようになったのも地味に大きなポイントです。これまではKinesis側のリミット(1MB/sまたは1,000レコード/秒)より大幅に少ないデータしかないにもかかわらず、シャード一本月1500円(14.04USD)が掛かっていました。

f:id:nekoruri:20200607140510p:plain

きました。使っています。

f:id:nekoruri:20200607140619p:plain

東京には来てくれたのですが、結局うまく処理にはまらずに現状使っていません。

どちらかというと、Apache Flinkで分析処理を実装できるようになった方が個人的にインパクトが大きいです。

イベントソーシングパターンなど、ストリーミングデータに対してステートを持った継続処理を実装するユースケースがふえているのでもっと活用事例が増えて欲しいところです。

サーバーレスあるある選手権 DynamoDB編

f:id:nekoruri:20200607133813p:plain

f:id:nekoruri:20200607140330p:plain

KVSベースでの設計がRDBに比べて違うノウハウが必要となるのは以前通りです。これはもうキーベースで分散するデータストアである以上は逃げられません。とはいえ、サーバーレス開発の普及によって世の中の情報もだいぶ増えてきたので、3年前よりは実感的にはだいぶ始めやすくなったのではないでしょうか。

f:id:nekoruri:20200607133959p:plain

f:id:nekoruri:20200607134017p:plain

f:id:nekoruri:20200607134031p:plain

DynamoDBのコスト問題はまだまだ苦労する部分ですが、オンデマンドキャパシティーモードが用意されたので、リクエスト数が急激にスパイクするようなケースでも安心して使えるようになったのは大きいです。

ただ、オンデマンドキャパシティーモードの方が「単価」が大幅に高いため、常時リクエストがあるようなケースではかえって高くなってしまうこともあり、そこはユースケースと運用コストや障害リスクに見合った選択が必要です。

f:id:nekoruri:20200607135148p:plain

バックアップは完璧に用意されました。オンデマンドもPITRもあります。

注意としては、あくまでバックアップはDynamoDBサービス内にリストア可能な形で保存されるだけです。データ自体をCSVやJSONなどでエクスポートしたい場合は、これまで通りDataPipelineをつかったり、ひたすらスキャンでページを手繰る必要があります。

まだまだ道半ば

f:id:nekoruri:20200607142046p:plain

結局DynamoDBだけでは厳しくなったので、現在ではRedisも併用しています。

このあたりは、先日のServerless Meetup Tokyo #16でも話しました。

FaaSで小さくはじめるIoTリアルタイムデータ処理 #serverlesstokyo

f:id:nekoruri:20200607142209p:plain

現在は、お客様や大人の事情に合わせて、上でも書いたとおりAzureとAWSで両刀でやっています。GCPでもだいたいできそうな感触はありますが、案件ください。

f:id:nekoruri:20200607142221p:plain

3年前と比べると、大きな障壁はかなり取り除かれ、頑張ればだいたい問題ない、とはっきり言えるところまで来ました。

昨今、ソフトウェア開発の手法で社会や組織を変革し続けるデジタルトランスフォーメーションの波が来ていますが、特にIoTではとにかくサービスデリバリの高速化が重要です。サーバーレスアーキテクチャという選択肢で正解だったというのがこの3年間の最終的な評価です。

宣伝

AWSによるサーバーレスアーキテクチャ

作者:Peter Sbarski
発売日: 2018/03/14
メディア: 単行本（ソフトカバー）

Azure Functions入門~サーバー管理を不要にするサーバーレスアプリ開発のすべて~

作者:増田智明
発売日: 2019/06/06
メディア: 単行本

*1: https://twitter.com/kuromitsu_ka/status/1269080138852917248

2020-04-08

SPS認定済ソリューションパートナーになりました

私の所属先WHEREが、今更ではあるのですが！ソラコムさんの「SPS 認定済ソリューションパートナー」に認定されました。

where123.jp

soracom.jp

SORACOM-UGやServerlessConfなどの技術セッションでも表に出していたのでご存知の方も多い通り、2016年にEXBeaconプラットフォームの実証実験を始めて以来ずっとSORACOMを利用しつづけているのですが、色々と会社としても個人としても良くして頂いていたのでパートナーになるのをすっかり忘れていた、というのが正直なところです😀

SORACOM Beam/FunnelやSORACOM Gate/Napterを中心に、様々なプラットフォームサービスとしても弊社はごりごりと活用している側だと自認していますが、連携強化によってさらに楽しい社会を作っていければなと思います。

世界中のヒトとモノをつなげ共鳴する社会で、
IoTがもたらす真の豊かさを追求していきます！
よろしくお願いします！

soracom.jp

where123.jp

2020-02-08

Coinhive事件とその先についての個人的見解

経緯については、Wikipedia見てください。

ja.wikipedia.org

また、裁判の争点に関してはこちらが詳しいです。

www.bengo4.com

本件に対して個人的な立場としては、地裁判決を支持しています。

その上で、Twitter上などで自分の感覚と異なる意見もあるため、そのあたりで自分の立場を整理してみます。

まだこまかい論点については自分の中でももやもやしていますし、そもそも宗教上の理由等で違う意見を持つ方も多いとは思いますが、そこは個人の意見としてご理解を。

広告との違い

動作が重く不自由なUIを持つ広告とどこが違うのか、という意見がありました。

Coinhive等に関する問題には、まず「サイレントにやるな」というのと、「消費リソース量が金銭的インセンティブに”比例”する」という二つの問題ががあり、これらの点において広告と同一視して議論するのは違うように思います。

黙ってオプトアウトもできないような状態で勝手にやるな、というのは地裁も高裁も認めているとおりです。

その上で、そもそも広告は画像等を表示してリンク先に遷移させることが目的です。ふざけた広告システムも多いので混乱しがちですが、広告はリンク先に正しく遷移させることが主目的であり、クライアント側もサーバー側も処理は軽ければ軽いほど良いわけです。

例えばそれが「重い」動画再生という形態であっても、少しでも多くの人をリンク先に誘導するために、ブラウザの処理を軽くしたいというインセンティブが（本来は）生じます。その一方でCoinhive等は「より重くすること」そのものに直接価値が生じてしまうのが異なります。

被害の有無

ただの計算であり悪い動作は無い、という意見がありました。

これに関しては、無罪判決と無った地裁においても、反意図──つまり閲覧者の意図に沿わない動作であることはみとめ「ユーザーに利益をもたらさないものである上、ユーザーに無断でCPUを提供させて利益を得ようとするもの」とばっさりしています。

実際に、本来動かなくて良かったCPUやGPU（CoinhiveはCPUのみですが）等の消費電力増加による電気代金、ファン等の経年劣化加速など積み重なると無視できないと思われる不利益は生じています。決してゼロでは無く、社会通念上許される範囲であるかです（ここは広告等と同じ）。

他にもありますがそれは次に書きます。

カジュアルにCoinhive等が普及した場合

本件は無罪であるべきだ、という主張の上で、ただそれを受けてCoinhiveのようなクライアントリソースを消費するソフトウェアが普及した場合を考えます。

その場合、先ほども書いた通り「消費リソース量が金銭的インセンティブに”比例”する」という点が大きな問題となります。現状では（逮捕者が出たこともあり）)数限られたウェブサイトでしか利用されていません。しかしこれが様々なウェブサイトで普通に使われるようになると、自明ですがブラウザの動作が重くなります(小並感)。

それが加速すると、クライアントリソースの取り合いとなり、CPUは常時100%に張り付き、本来CPUを消費するべき重要なアプリケーションの動作が重くなるなど、具体的なユーザの不利益に繋がります。

さらにそれが進んだ結果、ブラウザにクライアントリソースに対する使用量制限（quota）のような仕組みを取り入れることが予想され、煩雑な仕組みといたちごっこにつながります。そしてその結果不利益を受けるのは、普通のウェブアプリケーションです。

法規制とアーキテクチャによる規制

この手の話をする上で重要な視点として、できる限りこういったものは各国の法では無く、アーキテクチャとして解決すべきという意見があります。私も極めて同意します。

ですが本件に関しては、マルウェアと極めて近い領域のユースケースであることが多く、アーキテクチャとして何らかの規制（上記のquotaなど）を設計したとしても、それを回避するような「いたちごっこ」となることが予想できます。

その一方でユーザの意図に沿ったリソースを多く消費したいウェブアプリケーションも存在します。少なくともそれらの間に画期的かつ現実的な解決策が提案されるまで、この問題が野放図になることも、現行の不正指令電磁的記録（コンピュータウイルス）を対象とした法律の拡大解釈で運用されることも望みません。

その落とし所として、リソースの消費にインセンティブがあるようなソフトウェアへの法規制は一定の現実解では無いかと考えています。

まとめ

Coinhiveのようなクライアントリソースの消費量がそのまま金銭的インセンティブに比例するソフトウェアを黙って仕込むことは極めてクソであり、ユーザへの告知無しでは規制されるべき、オプトインが義務付けられるべきものと感じます。

その一方で、それは上記のような性質に対して規制されるべきものであって、現行の不正指令電磁的記録の枠組みでは不十分であり、あらためて法整備すべきです。そして法律の不遡及原則から、本件は無罪となるべきです。

既に逮捕してしまったから、今から法改正を進めると現行法での無罪が確定してしまうので強硬になっているのでは、というコメントすら見かける始末です。法のアップデートが遅いうえに、古い法に基づいて「非倫理的」だと判断された行為を逮捕するために既存法の拡大解釈が行われることは極めて遺憾です。

以上、個人の感想でした。

2020-01-05

新刊：TechReport 2019.12 「2019年振り返りと2020年予想」

あけましておめでとうございます！

昨年末に行われた技術書同人誌博覧会2とコミックマーケット97に、個人サークル「めもおきば」として参加してきました。

gishohaku.dev

www.comiket.co.jp

今回は間隔が2週間ということで、あわせて1冊だけ新刊を出しました。

年末恒例の技術トレンド予想本です。

nekoruri.booth.pm

今回紹介したキーワードです。

「2019年予想」の振り返り
デジタルツイン
IoTシステムのデザインパターン
エッジコンピューティング
Stateful FaaS
CNCF CloudEventsとEventBridge
認証基盤のクラウドサービス化
パスワードの終焉、MFA 2.0
情報システムとゼロトラスト
レガシーシステムと2025年の崖
ARMとRISC-V

コピー本と言うことで200円とお手軽価格なので、このあたりのキーワードが気になった方はぜひBOOTHからどうぞ。

次回のサークル参加は、2/29、3/1の技術書典8です。二日間ともいます！

techbookfest.org

2019-12-23

「サーバーレス」の次の段階に進むためのキーワード

この記事は、Serverless Advent Calendar 2019の23日目の記事です。

adventar.org

Serverlessというキーワードが登場*1して7年、Google App Engine Preview*2から11年、AWS Lambda*3から5年、みなさんサーバーレスしてますか？

FaaS(Function-as-a-Service)を中心としたサーバーレスなシステム開発事例はいよいよ普及フェーズに入ってきたところですが、その一方でステートレス性などプログラミングモデルとしての制約の厳しさなど課題が多くあることも事実です。というわけで、「サーバーレス」という技術ムーブメントで次の段階に進むためのキーワードをいくつか紹介します。

Stateful FaaS

ソフトウェア実行基盤として、プロセス上のメモリやサーバ上のファイルシステム上のデータを永続化しない*4、ステートレスという性質によって、FaaSはクラウド基盤側が「自由に」スケールさせることができ、その結果として消費したCPUやメモリの量によって従量課金されるというのがFaaSの本質的な特徴です。

スケーラブルなソフトウェア実行基盤としては極めて重要なこのステートレス性ですが、プログラミングモデルとしては面倒なことが増えているというのも事実です。そこで、ステートレスなソフトウェア実行基盤の上に、外部のデータストアと連携してプログラミングモデルとしてステートフルなプログラミングモデルを提供しようという仕組みが登場してきています。

最も有名なものがMicrosoft AzureのDurable Functions*5、特にそのEntity Funtions*6ですが、これらはAzure FunctionsというFaaSの上で、Azure Storage*7を組み合わせて実現しています。ほかにも、KnativeとAkka Clusterを組み合わせたCloudstateなどがあります。

このように、FaaSの「今の在り方」にこだわらず、プログラミングモデルとしてどうすべきか、というのがサーバーレス開発の次を考える上で最も重要なことです。

Streaming Processing

FaaSと相性の良いイベントドリブンなアーキテクチャの採用に伴って、これまでビッグデータ分析のような場面が主に想像されていたストリーム処理を、サーバーレス開発でも活用できます。

もともとビッグデータ分析のためのOSSがいくつも開発されてきたためエコシステムとして十分に育っているのが最大の特長です。プログラミングモデルとしてもこなれています。例えば、Apache Flinkを使って、いわゆるワードカウント（英単語ごとの出現回数を数え上げる）をScalaで実装した場合のソースコードです。

val windowCounts = text
.flatMap { w => w.split("¥¥s") }
.map { w => WordWithCount(w, 1) }
.keyBy("word")
.timeWindow(Time.seconds(5), Time.seconds(1))
.sum("count")
（省略）
case class WordWithCount(word: String, count: Long)

継続して流れてくるデータストリームに対して、Scala上のDSLとして抽象度の高いソースコードでプログラムを書くことができます。

考え方の基本は、ストリームデータの一つずつに「キー」が存在し（ここでは英単語）、キーごとに状態（ここではこれまでに登場した出現回数）を持って状態をひたすら更新していくというものです。

Cloud 2.0

ちょっと名前には仰々しさがありますが、今年の2月にPaul Johnston氏によって提唱されたキーワード*8です。制約の多いFaaSや、制約しかないDSLのさらに先として、様々なマネージドサービスの活用によってFaaSのような「自分の書いたプログラム」から脱却しようというものです。

複雑なシステムを、ID基盤やMicrosoft GraphのようなAPIの組み合わせに分解し、ワークフローエンジンやBIツールなどで連携させていくことで、従来のようなウェブアプリケーションフレームワークの上でシステムを実現するのでは無く、クラウドサービスを連携させるための設定（これ自体も、極めて制約が強いDSLですが）として実現できることが増えてきました。古くからのキーワードで言うなら、Infrastructure as Codeにおける「Code」の部分を新しい表現にしたものです。

今年はTerraformのDSL(HCL)を大幅に改善したTerraform 0.12の登場に始まり、HCLの癖の強さをそもそもTypeScriptやPythonなどの内部DSLに置き換えることで大幅に改善するPulumiが急速に普及したほか、AWSからもCloudFormationをラップして、やはりTypeScriptやPythonの内部DSLとして記述できるAWS CDKが登場するなど、Cloud 2.0を実現するための下準備が整った年でした。

これは余談ですが、この20年ほどで、プロプライエタリなソフトウェアよりも、コミュニティによるOSSのほうが結果的に良いソフトウェアが生まれやすいという状況になったのはご存知の通りですが、これはある種その「揺り戻し」でもあり「発展」とも言えます。大量の開発者を抱えたメガクラウドと、そこに載っかる大量の利用者からの不具合報告、改善要望があれば、そのクラウドサービスを構成するソフトウェア自体がプロプライエタリであっても十分な品質のサービスが提供されています。その一方で、OSSによって様々なライブラリやミドルウェアが開発され、自分で開発せずOSSミドルウェアを利用するようになったという流れの先にあると言うこともできます。もちろん、クラウドサービスを実現するソフトウェア自体をOSS化する流れもあり、その最大例がKubernetesです。

クラウドサービスの内部で使われているOSSの開発者との軋轢、という問題*9も生じていますが、まず利用者としては自分で書いて運用するべきコードを減らし、少ないコードでやりたい事を実現することを考えていくべきです。

Serverless Spectrum

AWS Lambdaのインパクトが大きかったため、サーバーレスと言えばステートレスな関数型プログラミングという印象が強いですが、実際はここまで紹介したキーワードからも判るとおり様々な実現方法があります。プリズムで分解した虹色のSpecrtum(スペクトル)のように、サーバーレスかどうか1/0ではなく、様々な形態が地続きで存在しています。

インターフェース一つ取っても、AWS Lambdaを代表とする言語内の関数というやり方もあれば、HTTP*10やgRPC*11を使う場合もあります。

サーバーレスにおいて最も重要なことは、クラウドをクラウドらしく活用(Cloud Native)することで、より少ない手数(≒Code量＋運用作業量＋α)でより大きな価値のあるシステムを構築していこう、そして従量課金を活用してスタートアップ段階のアジリティも高めよう、という継続的な挑戦を続ける気持ちです。

その一方でこれまでのレガシーなシステムの存在や価値は決して無視できるものでは無く、これからその間を埋めるためのものがたくさん登場していくことでしょう。そして「サーバーレス」として表現される対象もまた、より広いスペクトルとなって拡がっていくことでしょう。過去の記事でも書きましたが、言葉の定義にこだわらず、楽しいことを実現するときに考えを整理するための道具、指針ぐらいに捉えていくのが良いと思います。