写真は妻が作った雪だるまです。
本件についてのお問い合わせは Kyashの送金メッセージでお願いします。（返答を保証するものではありません）
突然ですが、 README.md に動的なコンテンツを埋め込みたいと思ったことはないですか？僕はあります。 具体的には、リポジトリのコントリビューターをREADME.mdに埋め込みたいという願望がありました。
つまりこういうことです。
しかし毎回CIなどでREADME.mdを編集するのはセットアップが面倒です。
<contributors-list> みたいなCustom Elementsが使えたらきれいな世界だなあと思ったのですが、肝心のscriptタグが動かないのでそれは無理です。
ということで、頼れるのは 画像 ということになりました。
README.mdに埋め込めて、なおかつ動的なコンテンツを扱えるのは画像のURL展開だけなので、つまりコントリビューターリストを画像化するHTTPエンドポイントを用意し、そのURLをREADME.mdに埋め込めばいいわけですね。同じことはすでにCIサービスのSVGバッジなどで広く行われているので、これ自体は特筆すべきことではないと思います。
問題はコントリビューターリストの画像をどうやって作るかということです。今回はまずコントリビューターリストを表示するAngularアプリケーションを作り、そのスクリーンショットをPuppeteerで撮影する、という流れを実装しました。
シンプルにAngular CLIで作成し、@octokit/rest を使ってGitHub APIを呼び出しています。単純なアプリケーションです。
これをFirebase Hostingで公開し、Puppeteerで表示できるようにします。
https://contributors-img.firebaseapp.com/repo=angular/angular-ja
ポイントとしては、画像化したい要素にIDを付与していることです。このアプリケーションでは後ほど画像化するときに #contributors を指定します。
Cloud Functions for FirebaseではHeadless Chromeを便利に扱えるPuppeteerを実行できます。 Puppeteerを使ってHeadless Chromeを起動して、先ほどのAngularアプリケーションにアクセスし、スクリーンショットを撮影します。
async function renderContributorsImage(repository: string): Promise<Buffer> { const browser = await puppeteer.launch( isDebug ? {} : { headless: true, args: ['--no-sandbox'], }, ); const page = await browser.newPage(); await page.goto( `https://contributors-img.firebaseapp.com?repo=${repository}`, ); const screenshotTarget = await page.waitForSelector('#contributors'); await page.waitForResponse(() => true); const screenshot = await screenshotTarget.screenshot({ type: 'png', omitBackground: true, }); return await browser.close().then(() => screenshot); }
ここのポイントは await page.waitForResponse(() => true) でGitHubアバター画像のリクエストをすべて待っているところです。
これを待たないとHTMLのレンダリングが終わっただけではまだ画像が空っぽになるからです。
Cloud Functions上でPuppeteerを動かすのはメモリを多く使うし実行時間も長くてお金が結構かかりますし、毎回画像を作るのはパフォーマンスも悪いです。 FirebaseのCloud Storage上にリポジトリごとに画像をキャッシュし、キャッシュがある場合はキャッシュから返します。 Cloud StorageのBucketにExpirationの設定をしているので、24時間経った古いキャッシュは自動的に削除されます。Firebaseコンソール側からはこの設定が見えないんですが、GCPのコンソールからアクセスすると普通に使えます。
async function _createContributorsImage(repository: string): Promise<Buffer> { const cacheId = generateCacheId(repository); const cacheFile = bucket.file(cacheId); console.log(`Look for a cache...`); if (await cacheFile.exists().then(data => data[0])) { console.log(`Return from the cache`); return cacheFile.download().then(data => data[0]); } console.log(`Render an image`); const image = await renderContributorsImage(repository); console.log(`Save new cache`); await cacheFile.save(image, {}); console.log(`Return rendered image`); return image; }
Puppeteerはメモリを多量に使うので、Function定義時にメモリの設定が必要です。1GBあればまあ動きます。 ブラウザの起動、Angularアプリの実行、スクリーンショット撮影と保存まで含めると結構時間がかかるので、タイムアウト時間も30秒にしてあります。
export const createContributorsImage = functions .runWith({ timeoutSeconds: 30, memory: '1GB', }) .https.onRequest((request, response) => { const repoParam = request.query['repo']; if (!repoParam || typeof repoParam !== 'string') { response.status(400).send(`'repo' parameter is required.`); return; } _createContributorsImage(repoParam) .then(image => { response.setHeader('Content-Type', 'image/png'); response.status(200).send(image); }) .catch(err => { console.error(err); response.status(500).send(err.toString()); }); });
というわけで画像を展開できる場所であればどこでもコントリビューターリストを表示できるようになりました！
例:
https://github.com/angular/angular-ja/blob/283047c5686cb3957966a671264e4c1d7b32a073/README.md
24時間ごとにしか更新されない課題はありますが、それほどリアルタイム性があるデータではないので問題ないでしょう。
課題としてはPuppeteerでGitHubアバター画像をダウンロードするときに外部ネットワークが発生するので、僕のお財布にダメージが大きいところです。しばらく従量課金で動かしますが破産しそうになったらリポジトリにホワイトリストを作って運用します。
久々に趣味プロらしい趣味プロをしたら楽しかったです。また何か思いついたらやります。
有言実行しなきゃね...
ちょっと来月の頭くらいまでに、「本当にAngularは学習コストが高いのか？」っていう内容のブログを書くので、書いてなかったら怒ってください
— lacolaco / Suguru Inatomi (@laco2net) 2019年1月24日
この記事では、「学習コストが高い」と評されがちなAngularについて、本当にその学習コストは高いのかということについて紐解いていきます。
先に言っておきますが、ReactやVueをはじめとする他のフレームワークとの比較はしません。また、なかなか本題に入らない回りくどい文章になる予定なので、予めご了承ください。そして筆者はAngularが大好きです。Angularが好きな人間が書いたポジショントークであることは前提として読んでください。
まずはじめに、「学習コスト」って何だ？っていうところから始めましょう。名前からして、学習に関するコストであることは予想できます。しかし明確な定義はGoogleで1時間ほど検索した限りでは見つからなかったので、自力で考えていくことにします。
コスト(=費用)と呼ばれる以上、そこには経済活動の概念との共通点があるのでしょう。Wikipediaで "費用" について調べてみました。
費用（ひよう、英: cost, expense）とは、生産や取引などの経済活動に伴って支払う金銭である。
なるほど、コストとは、何かをおこなうために支払う金銭のことでした。であれば「学習コスト」とは学習をおこなうために支払う金銭ということになります。しかし私たちがプログラミングに関することを学習するときに金銭を払うことはあまり多くありません。代わりに私たちは時間を費やして新しい技術を学習しています。この時間を私たちは「学習コスト」と呼んでいるのでしょう。（プログラミングスクールや有料の教材も増えてきたので、今後は本当に金銭が学習コストになるかもしれません。）
コストといえば「削減」されるものです。限りある予算のなかでやりくりするために、かかる費用はできるだけ抑えたいものです。では「学習コスト」における予算とは何でしょうか。なぜ学習コストは低いほうがよいのでしょうか。
ここには、日本のソフトウェア開発のメインストリームが労働集約型のシステム開発であったことに起因するものがありそうです。このモデルで利益を大きくするには、人件費は安ければ安いほうがよく、開発期間が短いほうが収益マシーンをたくさん回すことができます。毎回システムの要件も変わりますので、従業員が必要なスキルを習得済みとは限りません。そうなれば従業員に教育を施す必要があります。当然、この教育も短期間で完了することが望ましいです。つまり、学ばせる側には学習コストが低い技術を選択するインセンティブが発生しています。
一方で、学ぶ側にとってはどうでしょうか。ここではプログラマーは自身のスキルを伸ばすこと、ひいては開発者としての市場価値を高め収入を上げることを目的としていると仮定します。ある技術の学習コストが低いということは、誰でもすぐに学べるということです。学習コストが低い技術では、市場価値は上がりにくいでしょう。かといって、学習コストの高い技術を習得したところで、仕事がなければこれも市場価値が上がりません。どの技術が金になるか、というのは時間とともに変わっていき、ある種の賭けのような側面もあります。ここで重要なのは一度学んだ技術を次に転用できるか、という観点です。新しい技術が出るたびにゼロから学び直していては時間が足りません。一度払った学習コストを再利用して新しい技術を学ぶことで、複利的にスキルアップしていくのです。つまり、学習コストの単なる高低ではなく、「何を学んだのか」という内訳に意味があるのです。
コストには2種類あります。費用の発生と資産の購入です。支払った資本が、将来の収益の獲得に貢献するならば、それは費用ではなく資産となります。「一度払った学習コストを再利用して新しい技術を学ぶ」というのは、学習コストを資産計上するということです。学習コストが高くても、それが将来に渡って利益を生む資産となるのなら、長期的な観点からその高いコストを払うことが好ましい場面もあります。
ある技術の学習コスト考えるときには、その内訳を考えてみましょう。そのコストの中で資産になる部分、費用になる部分があるはずです。その技術が時代遅れとなり市場で価値がなくなったとき、そのまま無駄になってしまうならそれは費用です。そうでなく、パラダイムシフトを越えて通用する根幹的な技術や概念を学べたなら、それは資産になるでしょう。これはコストの高低には関係ありません。多くが資産になる高コストな技術もあれば、ほとんどが費用になる低コストな技術もあるでしょう。安物買いの銭失いにならないように、資産化しやすい技術を選ぶことがひとつの指針になるかと思います。
さて、ようやく本題にはいる準備ができました。この記事で述べたいのは、Angularの学習コストです。ここまでの話を踏まえて、Angularの学習コストと、その内訳を考えていきましょう。
まずはAngularに入門するまでに必要なコストについて見ていきましょう。Angularをはじめるにあたって習得する必要がある技術は、HTML/CSS・TypeScript・Observable（RxJS）です。これに加えて、npmを中心としたエコシステムのWeb開発について基本を理解しておく必要もあるでしょう。
さて、これらは費用でしょうか。それとも資産になるでしょうか？
これは言うまでもなく資産でしょう。世界中のWebページを支えるWebの基本技術です。Angularを学ぶ以前から資産として持っている人も多いでしょう。AngularではじめてWebを学ぶという人にとっても、学んでおいて損はない技術です。
npmコマンド無しにWeb開発することは、いまとなってはほぼ皆無に近いでしょう。それほどにnpmを中心としたエコシステムは発展し、成熟し、定着しています。資産として計上されて当然でしょう。
これも大きな資産となるはずです。ここ2,3年でTypeScriptは広く普及しました。Angularに限らずReactやVue、その他のフレームワークやライブラリでも採用されるケースが増えています。Angularのために学んだTypeScriptの基礎は、別の場所でも活用できるでしょう。
RxJSそのものは、Angularの他で使うことはないかもしれません。その場合は費用として捉えることになるでしょう。しかしObservableあるいはObserverパターンという概念は様々な場面で応用可能です。また、AndroidやiOSといったモバイルアプリの開発においては RxJavaやRxSwiftといったRxファミリーを取り入れている場合もあります。マルチプラットフォームのFlutterで採用されているDartにも、Observableに似たStreamという仕組みが言語標準で組み込まれています。リアクティブなプログラミングパラダイムにおいて頻出するパターンなので、リアクティブプログラミングの入門としてAngularのRxJSを捉えてみれば、資産と見なすこともできるでしょう。
RxJSを除いて、Angularの入門に必要な学習はほぼすべて資産となることがわかりました。はじめてのWeb開発というケースでも、Angularを通じて学んだ技術は将来の利益になるでしょう。無駄にはならないので、悩む時間があったらぜひ入門してみましょう。
入門してからもまだまだ学ぶことはあります。確かにAngularの学習コストは高いのです。Angular特有の要素で言えば、Component/Directive・依存性の注入・Routingなどを学ぶ必要があるでしょう。それに加えて、モダンWeb開発につきものの要素として、状態管理・ユニットテスト・コンポーネント設計・パフォーマンスなどがあります。
当然モダンWeb開発をおこなう上で必要な技術は汎用的な資産になると考えてよいでしょう。ここではAngular特有の要素について詳しく見ていきます。
AngularのComponentやDirective、Templateの仕組みは他に転用できるものではなく、残念ながらほとんどは費用となるでしょう。ただし、すべてがそうなるわけではありません。ここで注目すべきが Web Componentsです。
AngularのComponentは、Web Components技術をモデルに設計されています。ComponentはCustom Elementのように独自タグをもち、内部のCSSはShadow DOMのようにカプセル化されます。デフォルトではエミュレートされたScoped CSSですが、実際にネイティブのShadow DOMを使うように命令することもできます。
さらに、Angular v7から導入されたAngular Elementsでは、AngularのComponentをCustom Elementsに変換することすら可能になりました。一度Custom Elementsとしてエクスポートされれば、フレームワークを問わずどこででも利用できるプログラムになります。
AngularのComponentはWeb Components技術を学ぶきっかけになりますし、実際にWeb Componentsを活用したアプリケーションを構築するためのツールとして利用することもできる。この点を資産と見なしてAngularに投資するのも間違いではないでしょう。
Webフロントエンドではマイナーですが、サーバーサイド言語では依存性の注入は一般的に行われている技術です。これはAngularで学んだ依存性の注入が資産になるというよりは、すでに依存性の注入を学んでいる人にとってのハードルを下げることに繋がる面が大きいでしょう。
また、TypeScriptの型情報を利用した宣言的なDIシステムは高く評価されており、Angular以外の場所で使うために模倣した仕組みが作られるケースもでてきました。InversifyJSやNestJSはその一例です。このような面から見ても、まったくの費用であるとは言えません。
AngularのRoutingはフレームワークと強く紐づく部分なので、Angular以外への転用は難しいでしょう。素直に費用と見なして学習します。
入門から中級へスキルアップするにつれて、Angularの学習コストは高くなります。ですが中級まで到達したあとにはアプリケーションについて考える時間が増えることでしょう。コンポーネント設計やテスト設計について思いを巡らせ、スケーラビリティと生産性を向上させる手段としてComponent/Directiveや依存性の注入を活用するフェーズに突入します。Angularが手足のように動き始め、アプリケーションに集中できるようになってきたら、中級者の壁を越えた証です。
アプリケーションを開発するための最短距離だけをたどるならもっと学習コストの低いフレームワークになったでしょう。しかしAngularが選んだのはWeb標準やエコシステムと協調し、未来を見据えたスタックです。そのためには今は寄り道と思えるような学習が必要になりますが、その多くは資産となります。得た資産を元に学習することで更に大きな資産となり、複利的にスキルアップできるようになります。
極論、払ったコストよりも大きなリターンがあるのがわかっていればどれだけ高くてもコストは払えます。ですが現実にはリターンがあるかどうか、不確実性があるから尻込みしてしまいますが、そんなときにはリスクヘッジを考えるべきです。失敗してもある程度の資産が残っていれば全損よりはマシです。そしてAngularは多くの資産を残し、リスクヘッジできる技術です。
また、コミュニティが学習コストを下げることができます。誰かが通った道を、後に続く人は楽に歩けるように知見を残していくことができます。そして自分が学んだ知見を残せば、また未来の誰かを助けられます。オープンなコミュニティの存在は学習コストを評価する上で勘定に含めるべきでしょう。Angular日本ユーザー会はそうした互助の精神でこれまでも、これからも運営されています。Angularを学ぶときにはぜひ参加してみてください。
長々とお付き合いいただきありがとうございました。学習コストの高低だけじゃない観点でAngularを評価してくれる人が一人でも増えたら嬉しいです。
Notionに書いた。
余談。Notionのほうが書きやすいし読みやすいんだけど、ブログとしての体裁（シェアしやすいとかそういう）が無いのでどうしようか悩む。 Notionで書いてリンクだけブログに貼っていくのどう思います？
今年の2冊目と3冊目をまとめて読後メモ。
田村秀氏の「地方都市の持続可能性」を読んだので、別の目線で日本を見た落合陽一氏の「日本進化論」と、ひとつの地方都市の内側からの目線で書かれた高島宗一郎氏の「福岡市を経営する」を読んだ。
そこそこにおもしろかった。 落合氏の言説は以前から特に変わっておらず、人口減少こそ機械、AIによる自動化の大義名分であり日本がこれからテクノロジーで進化するためのチャンスであるという話だった。 この本の中心になっているのは「ポリテック」で、技術で政治をアップデートすることから日本の進化が始まるという主張だ。
日本の政治の問題点は次のように述べられている
巨額の債務を抱える政府と既得権益に執着する企業に阻まれ、なかなか未来のための投資に踏み切れていない日本
.
戦後につくられた社会制度の多くが耐用年数を過ぎて劣化し、様々な局面でポリティクス（政治）が機能不全を起こしている現状
.
もっと低いレベルの話をすると、そもそも今の日本の政治は、テクノロジーにオープンではない。たとえば国会で、本会議はパソコン持ち込みはダメ。委員会で認めていないところもある。議論に必要な調べ物をするために会議中にスマートフォンを触っているだけで嫌な顔をされる
.
主要国の中で唯一Ｐｈ．Ｄ取得にお金がかかる国でもあります。 結果、日本の博士号取得者数は減少するという、世界的に見ると異例の事態を招いてしまっているのです
.
まとめると、わが国のリソース投下には２つ大きな課題があります。１つは、シニア層と過去へのリソース投下があまりにも重く、未来に投資できていない点。２つ目は、インフラ投資があまりにも重くて、都市集中型の未来しか描けていない点
これを打破するためにポリテックのムーブメントが必要だというのが落合氏と、対談相手の小泉進次郎氏の主張だ
政策が決められる過程で出てくる政治・経済といったあらゆる論点の中に、「テクノロジーの観点から見るとどうなのか？」といった視点を新たに加えたいのです。これは医療におけるセカンドオピニオンのようなものと考えるとわかりやすいと思うのですが、そうすることで、政策の意思決定過程に多様性が生まれる
.
語られる環境を整備するのは大切です。たとえば、金融界では誰もが口を揃えて「フィンテック」の重要性を叫んでいる。それを「わかった気になっているだけなんじゃないか」と批判する人もいますが、僕はそれをあまり否定的に捉えていません。「フィンテック」という言葉が普及しているだけで一歩進んでいると思うからです。議論に上がるのとそうでないのでは大違い
.
僕はまず、このポリテックという言葉をみんなが使うところからスタートすべきだと思います。言葉は魔力を持っています。最初のうちは意味がはっきりしないまま、ただのバズワードとしてツイッターでつぶやかれるだけかもしれませんが、そのうち人々の間で共通の観念が育まれ、言葉への理解が深まることで、そこから地に足が着いた議論がはじまるのを期待したい
5Gや日本版GPSなど、具体的なテクノロジーの進歩の話もあるが、大枠としてはポリテックという概念を定着させようという思いが見られる本だった。
ただし、ネットワークの進歩によりどこでも働けるようになるから地方にもチャンスがある、というのは「地方都市の持続可能性」を読んだあとでは楽観的に映った。
テクノロジーを活用すれば、「どこでも学べて、どこでも働ける」状況をつくり出すことができます。すると、今後は地方のほうが有利なケースも次々に生まれてくる。食や自然の魅力も今まで以上に人を呼び込む力になる
現福岡市長の高島氏による出馬から今に至るまで、何を考え何を行ってきたかを語った本。高島氏の著書はこれが初。
非常におもしろかった。おすすめ。 アナウンサーからいきなり地方都市の市長になった高島氏がなぜここまで福岡を急成長させられたのか不思議だったが、この本を読むと納得できた。 福岡に興味のある人はぜひ読んでみると良いと思う。
心構えや考え方などの話が多いが、これまでに取り組んできた施策、活動の裏話もある。
私もひとりの人間ですから「大変だな」と思うこともあります。そんなとき私は「よし、市長を辞めよう」と自分に言ってみるのです。私は誰から強制されたわけでもなく、ただ自分の意志で立候補しただけ。私の人生だから、私の自由。「ならば辞めたらいい。次にやりたいという人はいくらでもいるから、心配しなくていい」と、自分に言い聞かせるのです。 ... (中略) ... すると「いや、やっぱり、辞めるわけにはいかない」と思い直すのです。そして「自分はこの仕事をしたいのだ」と決意を新たにします
この本で語られているが、高島氏の目的は日本を活性化することであり、そのためには地方が自立して活性化することが重要だと考えている。 他の地方でも若い首長を増やすことで、若い世代の力で日本を変えていこうということを繰り返し述べている。
日本社会にもっとも足りないダイバーシティは「意思決定層に『若者』がほとんどいない」ことだと思っています。 これは企業でも政治の世界でも同じです。若い人たちに理想の社会のイメージがあるなら、誰かが行動してくれるのを座して待つのではなく、若い自分たちこそが立ち上がって世の中を変えればいい
.
この本を通して、私の経験をみなさんとシェアすることで、全国の若者はもちろんのこと、行政とは関係のない他業種からも、市長や知事に挑戦しようという人が増えることを心から期待しています。若い首長がスピーディーに各地方を変えていくことこそ、日本を最速で変えていくもっとも合理的な方法だと思うのです
.
日本という国は、それぞれ個性の異なる地方の総体であって、地方都市がそれぞれの個性で最高に輝くことで、結果的に、国が宝石箱のように輝くことができる。 つまり、地方都市をよくすることが、最速でこの国を変えることになる
この一節は、非常に高島氏の本心が現れている気がした。
有識者と呼ばれる人たちが「これからは成長ではなくて成熟である」などと、したり顔で解説しているのを見ると、嫌悪感を抱きます。 私たちの世代は、高齢化時代の福祉を支えるためだけに生まれてきたわけではありません。理屈や理論ではなくて、現実に成長・成功する喜びを感じたいのです。アジアをはじめ、世界を見渡すと、責任世代である同世代の人たちが、夢を持ってビジネスを大きく成長させようとしています。そういう成長を我々も夢見たいのです
福岡市の発展は、政令指定都市の裁量と、国家戦略特区の自由の2つが合わさったことが重要だと思う。 現代において都道府県という単位の位置づけが微妙になっていることは「地方都市の持続可能性」の中でも述べられていた。 だからこそ道州を設置し、県を廃止することで大阪市や福岡市のような都市がより動きやすくなるのだと思う。 高島氏も、次のように述べている。
私はこのようなチャレンジを行なううえでは、県並みの「権限」から基礎自治体としての「現場」までを一気通貫に持つ「政令指定都市」がもっともロールモデルを作りやすいと考えています。 しかも、福岡市は国家戦略特区ですから、内容によっては国の規制緩和も適用されます
.
国政とは異なり、予算権と人事権を直接選挙で選ばれた首長が握る地方は、国よりもスピーディーに物事を変えることができる
また、本のタイトルにもあるように高島氏は経営者のように政治を行なっている様子が見て取れる。特に民間とのコラボレーションには積極的で、いかに税金を使わずに効果を上げられるかの戦略がうまい。
市長に就任して最初に行なったのが、広報、報道部門を束ねて「広報戦略室」に衣替えすることでした。「どの媒体に行政のお知らせを掲載するか」などという牧歌的なやり方ではなく、ターゲットに合わせて、伝達するコンテンツや時期、媒体などを戦略的に選び、市役所組織としてその情報発信のノウハウを蓄積するようにしたのです。
.
企業において労働生産性の向上が大きな課題であるように、行政においてもその課題の重要性は変わりません。それは地方自治法にも「最少の経費で最大の効果を挙げなければならない」と記されているとおりです。そしてその実現のためには行政として民間ノウハウの活用は必須ともいえます
.
市民が自ら参加することでシビックプライド、つまり住んでいる街への誇りにもつながるでしょう。行政だけがまちづくりをするのではなく、市民や企業、ＮＰＯ、大学生などのみなさんと一緒にまちづくりをする。これは間違いなく、世界のトレンドになっていくはず
.
行政がこれまでしていたことを市民と一緒にやることで、自分の街に対する誇りと愛着が強化され、さらに税金をできるだけ使わずに持続可能ないいまちづくりが実現できる。これはとてもすばらしいアイデアだと思いました。「他の誰か」ではなく、「自分たちで」街をいい方向に変えていくのです
.
これからは、民間の活力を最大限に活かしながら課題解決をしていくことが大切になります。そのためにも、規制緩和で民間が活躍できる「あそび」の部分を作りながら、市民にとっても企業にとってもウィンウィンになる施策をできるかどうかが重要です。もはや都市間競争は税金の投入ではなく、知恵比べの時代なのです
.
新しいビジネスを生み出すのは起業家ですが、社会がそれを受け入れるかどうかを規定するのは政治なのです。法や規制を緩和させるためには、行政と首長、議会の力学、さらには官僚、政治家の行動原理を理解する必要があるのです。 政治家も経済を知る必要がありますが、同じように経済人も政治を知る必要があります
.
福岡市は、このようなテクノロジーを支えるエンジニアに注目しています。そして２０１８年に「エンジニアフレンドリーシティ福岡（Engineer Friendly City Fukuoka）」宣言を行ない、優秀なエンジニアが集まり、活躍し、成長できる取り組みを、行政とエンジニアで一緒にスタートしました。優秀なエンジニアがいるからこそ、とがったビジネスを形にすることができます。スタートアップがユニコーンに成長するためにも、世の中を変えて行くような新しいビジネスやサービスを次々に世に送り出すためにも、優秀なエンジニアの存在は極めて重要なのです
次は少し毛色を変えて、MaaS (Mobility as a Service) についての本を読むことにする。
今年に入って3冊、日本や地方都市の持続性についての本を読んだが、地方都市と都心の最大の違いは公共交通機関の力だと感じている。人間が移動しやすいということは企業にとっても人にとっても、経済活動の中心としては必須だろう。しかし東京並の公共交通機関は金の面でも人口の面でも他の都市では真似できない。そこでMaaSが地方都市が持続的に発展するためのキーになるんじゃないかと踏んでの一冊を選んだ。
読み終わったらまた読後メモを書く。
