最近気づいたこと
こんにちは。
全然記事も書けてないし、Playful-Coreも進んでないし、自分の勉強も進んでいないTomofilesです。
転職準備で自分のキャリアと向き合うのが大変で、なかなか思うように進められないですね。
最近作業が進んでいないのも、色々視点や視野が変わってきて、新しい知識も入ってきて、
そっちに舵を切りたくなってしまって、作業が手につかないということが発生しているからなのですが、
ここらで今気づいたり、悩んでいることを一度アウトプットしておこうと思いました。
Playful-Coreどうなった
Scheduler完成して、つい最近、新生Reservationが完成したばかりです。
いまRecordingに取り掛かるところですが、そこで止まっていますね。
それがなんでかというと、Kubernetesの勉強を始めたのですが、
やっぱりノー知識で取り掛かったからですが、全体構成がちょっと問題ありと
わかってしまったのです。
あとは、最近見つけた以下の記事が、最高に衝撃的でした。
最近よくサービスメッシュって聞くなぁと思って色々調べていたときに見つけたのですが、
アーキテクチャの変遷・背景をこうやって整理して知っていくと、
やっぱり部分適用というか、ボトムアップ的にIT技術を見てもダメだなぁと感じたのです。
トップダウンでIT技術を見てみる
業務システム界隈にいるとどうしても自分ごととして関心を持つことが少ないですが、
世の中のビジネスのITは、２４時間ノンストップで稼働することが前提で、
常にサービスが稼働×常にサービスを開発＝価値・利益
というのがITに求められていることなのです。
そのためには、稼働し続ける安定した基盤と、新しいサービスを常にリリースし続ける、
ということを両立しないといけないですが、それを実現するのが非常に難しいのが、
従来のアーキテクチャだったのです。
マイクロサービスアーキテクチャが台頭し始めたのも、これを実現したいから。
アーキテクチャの複雑さと、サービスの稼働と開発を両立させることを天秤にかけたとき、
後者を取ることが、自社の事業を展開する上で重要な戦略だということですね。
この視点で現在のシステムアーキテクチャを眺めてみると、非常にしっくりきます。
システムが安定稼働するというのは、コンピュータのハードウェアからお手入れが必要です。
ディスクが破損したり、電源に不具合が発生するというようなことは、
サーバーを抱えていれば往々にして発生します。
クラウドコンピューティングは、計算能力を従量課金性で使用でき、何よりこのハードウェアの
メンテナンスをする必要がありません。また、近年のマネージドサービスの充実も相まって、
「組み合わせて」「利用する」ことで、サービスを展開することができる。
安定稼働のハードウェア面の革新は、クラウドですね。
※今朝知りましたが、ブロックチェーンのマネージドサービスが展開されるようです。
もう死角がないですね。
AWSのマネージドブロックチェーンサービスが一般に公開 | TechCrunch Japan
そして、ソフトウェア面では、コンテナとオーケストレーション技術です。
私もよくわからずKubernetesを使ったり、機能を勉強したりしていましたが、
ソフトウェアのスケールや構成変更などを、安定稼働を維持したまま適用できる、
というのが、これら技術のキモなんですよね。
私は、Kubernetesの勉強をしながら、いまのPlayful-Coreの構成が全然この流れを
汲めていないことに気づいて、全部を作り直したくなりました。
コンテナはイミュータブルな実行環境で、突然切り捨てられても構わないようにしないといけない、
だからスケールアウトに柔軟で、可用性があって、セルフ・ヒーリングが有効に働く。
宣言的設定によって、「定義したとおりに環境を維持し続ける」。
Playful-Coreはそういう意味で、色々問題があります。
MQTTはまず、Kubernetesと相性が悪いです。
MQTTはテレメトリデータ（一定間隔のセンサー情報など）を処理するのに適していますが、
ロストを許さないデータをやり取りするには、向いていません。
Playful-Coreでは、重要なイベント情報をやり取りしています。
そういう意味で、接続を維持しつつ、必要に応じて切り捨てられるコンテナで動作するというのは、
イベントのロストを許容していることになり、アーキテクチャとして信頼性がありません。
それに、MQTTはM2Mなので、スケールアウトに向いていないのです。
単純にサービスをスケールアウトすると、そのサービス向けのメッセージが複製され、
同一メッセージが複数処理されることになります。
べき等性を考慮すればいいかもしれませんが、無駄な処理にリソースを割くことになり、
非効率です。
また、Scheduler、Recodingの２つのコンポーネントが、ステートフルになっています。
スケールアウトが全く出来ず、また、コンテナが切り捨てられると、全てが吹き飛びます。
マイクロサービス化をしていくなら、状態はデータベースなどのミドルウェアに格納し、
各サービスはあらゆる状態を保持しない（セッションも、メモリ上のデータも）ようにしないといけません。
まぁ、ミドルウェアにいい感じのタイマーが無いから、Schedulerを作ったのですが、
やっぱりちゃんと考えて作ろうと思うと、問題はたくさんあります。
スキルとして不足していること
ハード面、ソフト面から、世の中の潮流と、自分の現状を比較してみました。
クラウドサービスは、とにかく勉強するしかないですね。
あとは、マネージドサービスも色々展開されていて、こういうのの動向を追ってくのは重要そうです。
最近スキルの棚卸ししてて気づいたことなんですが、
やっぱり圧倒的な物量で品質担保するのが業務システム界隈のやり方で、
テストケースの観点・網羅性と、アナログ的テスト消化による品質担保が、
現状の私のやり方になってしまっているなと。
観点や網羅性の考え方・視点は重要だなとは思うんですが、
テスト実行の方は、もうちょっといい方法があるのではないかと思うんです。
継続的インテグレーションである程度のテストを自動化することは、まず重要ですね。
ただ、マイクロサービス化したコンポーネントの、何をどこまでテストを自動化できるのか、
そこが今の疑問です。
ソフトウェアの開発プロセス全体で見たときに、継続的インテグレーションがどのように、
「目的」「適用範囲」という問題領域を持っていて、どのように解決するから有効なのか、
全体感を知りたい。
いい書籍とかありますかね。
アジャイル開発による品質担保と、サービス価値を維持・向上する方法論的な。
これってQAとかSREとかって分野なんですかね。
だめだー、勉強が足りない！
Playful-Core -Scheduler編-
スケジューラ機能が形になったので、ここらで現状をまとめたいと思います。
全体構成
全体構成が少し変わりました。
Schedulerが実は見えてなくて、最初はReservationの中に含まれると思っていたけど、
これが構成を複雑化させていました。
分けることによって、Reservationが担う役割が大幅に減ってシンプルになりました。
スケジューラ機能
今回作ったのは、Schedulerコンポーネント、スケジューラ機能です。
Reservationは録音予約情報を管理するコンポーネントで、
基本的にはデータの登録・更新・削除・参照の管理を行うだけです。
現状まだ修正出来てないですが、Reservationで時刻の考慮があるロジックは、すべてSchedulerに移されます。
こうすることで、いかのような役割分担が実現出来ます。
Reservation
- データの管理
- 予約された、キャンセルされた、をイベント発火
Scheduler
- スケジューリング管理
- 予約された、キャンセルされた、のイベントを購読し、スケジューリングする
- 予約時間に時刻到達イベントを発火
Schedulerから発火された時刻到達イベントをReservationが購読し、
Recording（録音管理）に予約情報を通知します。
そうすることで、録音を開始する仕組みです。
並行処理
今回のキモは、Go言語の並行処理です。
スケジューラを作るに当たって、Go言語の並行処理が必要なのは見えていました。
とにかく、Javaと平行処理の考え方が違うので、それを吸収するまでに難儀しました。
並行処理は以下の書籍を読んで勉強してます。
※現在、４章まで読み終わっています
- 作者:Katherine Cox-Buday
- 発売日: 2018/10/26
- メディア: 単行本（ソフトカバー）
現時点での、Go言語での並行処理の理解は次の通りです。
- クリティカルセクション（同時アクセスを防ぎたい箇所）に悲観排他を仕込むのではなく、クリティカルセクションを単一のGoroutineに閉じ込める（これが、通信によるメモリの共有）
- Goroutineにはチャネルによる入出力を行い、Goroutineをつなぎ合わせてパイプラインを形成する
読んでいて、部分的にJavaのStreamAPIに似ているなぁなんて感じていました。
データの集合を、流れるものに抽象化して、それをパイプの中を通すように処理していくのが、まさにそうですね。
４章が読んでいてとてもおもしろかったのですが、
基本的なパイプラインの構成と、スケールのやりかたとしてのファンアウト・ファンイン、
パイプラインをまとめ上げるブリッジ、キューイング。。。
この手のフローは、Javaだと構築が難しすぎるのですが、Goroutineは非常に簡単です。
JavaやってるとFrameworkの中でやってしまっているコンテキストも、ここで理解できました。
今回の技術話
さて、今回のスケジューラ機能の仕組みの話です。
スケジューラ機能に関しては、正直ビジネスロジックは多くないので、ドメインモデルの構築はしてないです。
ほぼアプリケーションレイヤーのコンポーネントで成り立っています。
スケジューラ機能は以下の機能を備えなければなりません。
- 予約できること
- キャンセルできること
- 指定時間にイベント発火できること
キャンセルできること、が結構厄介で、スケジューリングのパイプラインを生成するのと、
そのパイプラインのコンテキストにキャンセルを実行する契機が、別のリクエストになります。
コンテキストの管理単位は、リクエストスコープが推奨されており、リクエストをまたいだコンテキストのキャンセルは
本来してはいけないはずです。
そこで、今回は少し工夫して、パイプラインのステージを次の通りとしました。
- 管理ステージ
- スケジューリングステージ
- パブリッシュステージ
なお、ソースでいうと、以下のあたりです。
管理ステージはチャネルを一つ受け取ってGoroutineを起動します。
このチャネルにスケジュールの識別情報を流し、次々と後続のステージに流していき、
最後のステージに到達するとイベントを発火します。
管理ステージでコンテキストを生成します。つまり、スケジュールごとにコンテキストを生成し、パイプラインと紐付けます。
チャネルをクローズすることで、コンテキストがキャンセルされ、パイプラインをまるごと終了させます。
コンテキストがリクエストスコープではないですが、スケジューラ機能としてのコンテキスト（文脈）はスケジュール単位なので、
このようにパイプラインごとに管理すると、しっくり来ました。
スケジューリングステージは、OSSのスケジューラを起動して、実際にスケジュールします。
今回のパイプラインは、流れるのがものすごい遅いパイプラインという抽象化により、スケジューリングを実現しています。
つまり、上のステージから流れてきた識別情報をこのステージがせき止め、予約時間に次のステージに流します。
パブリッシュステージは、その名の通り、識別情報からイベントを生成して発行します。
この一連のパイプラインは、スケジューリングされるたびに生成されるため、
そのたびにこのパイプラインの出力チャネルが生成されます。
出力チャネルは、実際にMQTTブローカーにパブリッシュするGoroutineと繋がないといけません。
そこで、出力チャネルを、チャネル型のチャネルに通して、ファンインのGoroutineを起動するブリッジにかまして、
MQTTブローカーのパブリッシュGoroutineにイベントを流します。
以下のあたりですね。
このようにして、スケジューリングを実現しています。
【Part6】一本線の貢献
どうもどうも。
ここ最近、転職エージェントとやりとりしながら、自分の転職に対する気持ちや考えを整理してます。
ここで過去のパートで綴ってきたことが、良い意味と悪い意味で一本線に収斂し始めてて、自分のことながらなかなか興味深い気持ちです。
今回は、その一本線と、そこに紛れ込んでいるものを整理するパートになります。
不満に思っていること
過去のパートから、現在不満に思っていることを、大きく分けて次の３つ抽出しました。
- 使う人が見えるものを作りたい
- 新しいものを柔軟に取り込んでいく環境に身を置きたい
- 給料の低さをなんとかしたい※
※これは、いままで、あえて挙げていないもの
人の問題とか、業界の問題とか、考える過程で仮設的に議題として挙げてみましたが、
今はどうも違うような気がしています。
過去の経験から、人に期待しても自分の思うとおりにいかないということも学んでいて、
大体、人との関係でうまくいかないときは、コミュニケーションがうまくいっていないときです。
Part2の内容なんて、今見返してもわかるけど、コミュニケーションの問題です。
「みんな同じ方向を向いている」の結論に向けてのエピソード選びに失敗してますね。
師匠が欲しいというPart4の内容も、正直仕事に求めるのも違う気がします。
ただこれは、現在の界隈でモデルケースとなる人がいないという現状に対して、
新しい環境に期待していることではあります。
それ以外は、仕事外で見つけるべきですね。
Githubの環境もそのために整備したもので、
結局自分のアウトプット不足と、客観的な目が入る機会が足らないだけです。
一貫していること
自分の考えを客観的に見直してみると、結局は「誰かのために」というコンテキストで語っています。
Part3で自分が求めていることが、「隣の人のために」であったことも、
「使う人が見えるものを作りたい」というのも、このコンテキストで一貫しています。
私自身が自分のことを語ることすら気後れしてしまう人見知りだからというのもあるのですが、
昔から人と人の間の関係がこじれることに大きな不安感を抱いてしまいます。
私自身が、人が欲しいと思ったものが、その人に届くまで、一貫した価値の提供が出来ないと、
落ち着かない気がしてなりません。
それが、今身を置いている受託開発のやり方に不安を覚える原因なのかもしれません。
私は仕様管理者とたくさん会話します。
使う人が想定されないソフトウェアであろうが、その価値を一番知っていて、管理している人と話さないと、
その価値を作るはずのエンジニアが、筋の通ったものが作れないと思うからです。
私生活の人見知りは、仕事では逆に我慢できません。
私はそれで、一度失敗しました。
奥手になることが、結局自分の不安感を増大させてしまったのです。
だから、自分の仕事を確かなものにするには、そのソフトウェアを作る人たち（理想的にはすべての関係者）と、
しっかりと同じ方向に向いていることを確認したいのです。
体験を作る
GoProの記事を書いたのは、気まぐれではないです。
本当はもっといろいろな体験について書きたいのですが、ちょっと余裕がなくて一つだけになっています。
使う人が想定されないソフトウェアを作るのが、いま関わっているプロジェクトです。
新しいビジネスなので、想定出来ないのが正しいのですが（想定してもそれが正しい保証がない、という理屈）、
想定できないから、想定しないのはちょっと違うのではないかなぁと感じることが多いです。
GoProだって、各々のユーザが使うシーンは、別にすべて想定しているわけではないと思います。
でも、GoProの方から使い方を示してくれています。
こんなユーザを想定していて、こんなシーンで使われることを想定していて、そんなときこんなことが出来ます、と。
これって、ものを作るときに、作る人の役目なのではないかなと、思います。
体験を作ることって、実はITと親和性がよくて、それを本格的に考える仕事ができれば、
自分のITのスキルも、もっと向上していくのではないかなと、考えています。
Part5のブランドに感じる価値の話も、実は同じことを言っています。
価値の提供元の思想と、提供する商品と、提供方法と、全てに一貫したものがあります。
Playful-Core -インターネットラジオ録音・クラウドアップロード-
2019/04/05 追記
現在は、ここで紹介しているGithubリポジトリの場所が変わっています。
playful-core/dustbox/playful-reservation at master · Tomofiles/playful-core · GitHub
今回は最近ちょっとずつ作ってるサービスの紹介をしようと思います。
内容があれなんで一般公開は出来ないですが、自分の困ってることを解決するためなので、良いかなと思います。
なにこれ
インターネットラジオ Radikoを録音するサービスです。
深夜ラジオ聴きたいけど、夜中なので録音してあとで聴きたい、と思ってる人は多いと思います。
そんな人のために、ラジオの番組表から聴きたい番組を指定して、録音予約をしてあげるサービスです。
最終的には、Google Play Musicにアップロードまでやってくれるようになります。
ただ現実は
Radikoの録音サービスは、現在どこにも存在しません。
もちろん、Youtube等への二次配布と同じで、著作権侵害に当たるからだと思われます。
個人の環境に仕込んで、あくまでも私的利用の範囲であれば問題ないはずなので、
cronで仕込めるようなシェルスクリプトや、Windowsデスクトップアプリなどは公開されています。
私の環境だと、インターネットがたまに死ぬので、結構な頻度で録音できていないことがあるので、
そういう個人の環境による問題がサービス化したらなくなるのではと思いますが、
まぁ現実的には公開とまではいきません。
機能概要
Playful-Coreは次のような機能を有してます（予定ですが）
・日時、録音時間による、ラジオ録音の予約情報の管理
・録音機能
・音声データの管理
・ Google Play Musicへのアップロード
Coreは本当にコア機能しかなく、Playfulシリーズとして、番組表機能と、予約管理機能が、別で存在します。
現時点では、そちらは全く考えていないですが、境界付けられたコンテキストに則って、区切ってます。
ソースコード
Githubに公開しています。
公開してるし、こんな紹介ブログを書いていますが、まだ完成していません。
目的は、技術やスキルのアウトプットなので、そのきっかけになればということで公開しました。
技術的な話
全体構成は以下のような感じです。
Playful-Coreは、Reservation（録音予約）という集約を中心としたモデルで構成されます。
Reservationがコアドメイン、それ以外のRecording（録音）、PlayMusic（クラウドアップロード）がサブドメインのイメージです。
ドメイン間はイベントによる非同期的な連携を行い、機能を実現しています。
イベントソーシングとまではいきませんでしたが、イベントドリブンなアーキテクチャは目指しています。
言語はGo言語、イベントPubSubはMQTTを用いています。
コンテナ管理はKubernetes、CI/CDでビルドとリリースを回しています。（この辺は、完全に適当な構成になっています）
現在ある程度形になってるのが、録音予約管理を司るReservationのみです。
ReservationはRestful APIで録音予約情報のリソース管理ができます。
認証は機能をシンプルにするために排除してますが、本来だったらちゃんと考えないとですね。
API管理には、Swaggerを使っています。Swaggerから吐き出したgoサーバモジュールのモデル部分のみ、使用するようにしています。
本当はMQTT部分のIFもそういうの使いたかったのですが、唯一見つけたAsyncAPIがGo非対応のようなので諦めました。
データベースは完全にDocker上に立ててるので、揮発性になっちゃってます。
この辺はKubernetesの勉強をもっとやらないと、ストレージ周りの知識が足りてなくて実装できてません。
ヘキサゴナルアーキテクチャ
私のシステム設計のルーツは、実践ドメイン駆動設計という書籍なので、この思想に大いに影響されてます。
実践ドメイン駆動設計 (Object Oriented SELECTION)
- 作者:ヴァーン・ヴァーノン
- 発売日: 2015/03/17
- メディア: 大型本
この書籍では、純粋なビジネスモデルを中心とするアーキテクチャを、ヘキサゴナルアーキテクチャと紹介しています。
巷では、クリーンアーキテクチャやオニオンアーキテクチャなどもよく耳にしますが、問題領域は同じことを言っていますね。
私はこのアーキテクチャを、いい感じにシンプルに解釈して適用しています。
Reservationプロジェクトを例に説明していきます。
構成は大別して、以下の通りです。
- playful-core/playful-reservation/src/tomofiles/api
- playful-core/playful-reservation/src/tomofiles/application
- playful-core/playful-reservation/src/tomofiles/domain
- playful-core/playful-reservation/src/tomofiles/infrastructure
レイヤー別に、説明していきます。
ドメインレイヤー
domainがすべての中心です。ここには、何らかのフレームワーク、基盤、外部システムへの依存はありません。
逆に依存される立場としています。
ここに、すべてのビジネスロジックが集中しています。例えば、データの重複条件、制約、そして、何かが達成したときのイベント、などです。
Reservationは集約エンティティです。
集約エンティティがオブジェクトを束ねることで、
という手順でビジネスが抽象化され、モデルを使った機能実現を簡易にしています。
Reservationでは、書き込みとキャンセルの操作を用意してます。
予約業務って、予約簿に書き込むか、取り消すかだと思うので、モデルにもその考え方をそのまま反映してます。
書き込みとキャンセルは、ある条件を満たすとイベントが発生します。
例えば、指定した時刻はすでに過ぎていること、指定した時刻がもうすぐ到来すること、直近の予約が取り消されたこと、などです。
このイベント、ドメインイベントが強力な戦術で、ある業務にまつわる様々な状況を別の業務に通知することで、全体で見たときの機能実現につなげます。
上のイベントの例だと、Reservationから発行された、指定した時刻が過ぎているイベントは、Recordingが関心があり、購読しています。
Recordingがイベントを受信すると、ラジオの録音を始めます。Recordingは、他の業務領域内のルールが決めたタイミングで動作するため、業務がシンプルになります。
こうしたイベントの連鎖で機能を実現することで、一枚岩のシステムより柔軟な構成をとることができるのです。
アプリケーションレイヤー
applicationは、domainを用いて業務要件を達成するレイヤーです。
Reservationでは、録音予約情報の登録、更新、削除、参照の機能を提供しています。
その機能を実現するにあたり、ドメインレイヤーのオブジェクトを操作して状態を変化させたり、状態を読み取ったりします。
ドメインへのアクセスの仕方は、ドメインレイヤーの項目に書いたとおり、リポジトリから集約エンティティを取得し、操作します。
アプリケーションレイヤーはシンプルなフロー制御になります。
業務の複雑さはドメインレイヤーに隠蔽されるので、ユーザの価値となる機能を実現するための手続きを、高い抽象度で記述出来ます。
集約エンティティの操作と、そこから発行されるイベントを処理に専念でき、どのような機能を実現するのかを、その構成要素の詳細から切り離すことが出来ます。
トランザクションもこのレイヤーの責務となります。
インフラストラクチャレイヤー
infrastructureは、ドメインレイヤーの永続化の実現や、その他基盤的な機能の実装を担います。
ドメインレイヤーにはエンティティの永続化をモデル化したリポジトリがありますが、リポジトリ自体はインフラストラクチャレイヤーの実装により、取得や保存を実現します。
今回作成しているReservationでは、リポジトリの実装がまるごとインフラストラクチャレイヤーに存在しますが、
この構成は正直微妙です。
エンティティの構築に関する詳細はドメインレイヤーの責務ですが、インフラストラクチャレイヤーに漏れ出てしまっています。
（このせいで、ファクトリーの再構築メソッドがパブリックスコープになってしまっています）
いずれ直せるかなぁ。
UIレイヤー
apiは、UIレイヤーです。
Reservationでは、SwaggerのモデルオブジェクトでリクエストボディのJSONを解析したり、
アプリケーションレイヤーのサービスに渡すDTOオブジェクトに変換したり、
パラメータのバリデーションチェックを行ったりするコントローラが、このレイヤーに配置されます。
コントローラは、ルーティングライブラリに差し込まれ、HTTPリクエストのルーティングに設定されます。
このレイヤーは外部ライブラリやUIに依存し、ユーザへのサービス提供形式によって実装が変わります。
以上のレイヤーの構成をイメージにすると、以下のようになります。
今後の展望
まずは、いったん全部作りきることが目標です。
早く安心してラジオ聴きたいですし。
Recordingを作るにあたって、Goの並行プログラミングが必須になりそうなので、いま書籍買って勉強してます。
メモリ共有型じゃない並行プログラミングが初めてで、今まで「ロックしときゃいいんじゃね？」でなんとかなってたのが把握できました。並行プログラミング、難しい。
定期的にできてるとこまでの紹介とか、技術的な整理のための記事が書けると良いですね。
【Part5】良いなと感じる感情
第五回です。
今回は仕事の話ではないのですが、ここ近年のプライベートで感じたことをまとめたいと思います。
ファッションへの興味
高校時代や大学時代は、ファッションに対する興味はありませんでした。
正直、自分が着る洋服に対して、誰にどう見られるかなどという思考が働くことは、一度もなかったです。
今思えば、変な色だったり、ゴテゴテな装飾だったり、見た目の変さもかなりのものだったとも思いますが、
そもそもファッションに対して、心が動かされることがなかったと今は感じています。
そんな私が、社会人になってから、ファッションに対する興味が出てきました。
人間関係はあまり広い方ではなく、人と関わることも苦手意識がある私ですが、
テレビを見てて気になった芸能人の持つ、人を惹き付ける何かがあるなと感じ取ったのか、
その芸能人が身につけているモノをネットで調べたりしてました。
そうやって好きなファッションブランドを探したり、雑誌を見たりするのが楽しくなってきた頃、
一つのファッションブランドと出会いました。
ファッションブランド
私のブランドのイメージは、お金持ちのセレブなどが買い漁るものだという偏見があったのですが、
このブランドと出会ってから、自分が持っていたイメージが全く持って違うなと気づきました。
そのブランドは、これまでのベーシックなファッションアイテムを、そのブランドらしい解釈をし直し、
新しい魅力のあるアイテムを再構築して提供していました。
洋服って、アイテムのバリエーション自体は、既存のものが充実しているので、
そこに新しいものを投入することが出来ない業界だと、今の私は勝手に思っています。
だからこそ、その型にはまったそれぞれのアイテムにどのような価値を付与するのかは、
ブランド独自の解釈の仕方次第なのだと考えています。
このブランドの店舗に何回か通っているうちに、店員さんと仲良くなって、ファッションについて色々教えてもらいました、
店員さんも、自分たちのアイテムの話をしたくてウズウズしていて、私もそんなこだわりのある話を聞くのが楽しくて、
店先で結構長い時間話してしまったこともありました。
様々なアイテムの基本的な位置づけと、それに対するブランド独自の魅力を聞いていると、
その洋服が全身のコーディネートの位置づけとしても、ストンと気持ち的に落ちる気がして、
途端にその洋服に対して、「良いな、ほしいな」と感じてしまうのです。
これがブランドなのだなと、私はこの買い物で知ることになりました。
眼鏡も同様に
私は目が悪いので、眼鏡をかけます。
眼鏡も同様に、贔屓の眼鏡屋さんを作って色々教えてもらって、買うことが増えました。
眼鏡はとりあえず十本集めるなんて目標立てるのも楽しくて、どんな種類の眼鏡があって、
どれが私の顔に合うのか、選び方なども教えてもらいました。
結局現在、サングラス含めて七本も買ってしまいました。
良いなと感じる感情
洋服も眼鏡もそうなんですが、商品を売るときに、いかに価値を見出してお客さんにお金を出してもらうかを、
考えなくてはならないなと感じました。
どういうところに魅力があって他と違うところで、そのアイテムが生活の中でどのように生きてくるのか、
そういうのが見えてくると、その価値はグッと上がるのです。
洋服や眼鏡は、そのモノ自体が実用的な価値のあるものなので、実用レベルで有効性があれば、
そこへの付加価値は必要のないものでもあります。
でも、だからこそ、普段当たり前のように使っているモノに、ちょっとした心の動きがあると、
人生はちょっと豊かになるのではないかなと思います。
私はITエンジニアをやっていて、こういう付加価値を考えたり、誰かに魅力を語ったりすることが無いなぁと感じます。
もちろん、職種が違うのだから、やることが別なだけだということも言えると思います。
でもITだって、何かを作ることができる手段ではあります。しかも世界中が繋がる空間でもあります。
ブランドの価値を広めることも、ITで加速させることができるし、まったく新しい価値を作ることもできるんじゃないかなとも思います。
受託開発にいると、そういうのが見えません。
作ったものがどう生きるのか、私からは見えません。
というか、誰にも見えていないのではないでしょうか？
私の立ち位置は限定的なので、これ以上のことは何も言えませんが、
社会インフラとなるような大規模システムですら、最近の私には魅力を感じません。
私のこのブランドに感じる感情自体が、実は私の深層で望んでいることなのではないかと思っています。
目的が見える。
価値が見える。
人に言いたくなる。
応援したくなる。
次に期待したくなる。
そういう価値を届ける仕事が、ITエンジニアとして出来ないでしょうか？
私の興味は、今はそこしかありません。
ちなみに
上で話したブランドはnest Robe CONFECTさんです。
最近仕事で脳を圧迫されていて余裕がないので行けてないですが、また色々話聞きに行きたいですね。
眼鏡屋さんは、金子眼鏡さんです。
kaneko-optical.tumblr.comそして、今回の記事を書こうと思ったきっかけは、雑誌で見て一目惚れして買った腕時計を見たときに、
ふとこの体験って、自分の中に結構な影響を及ぼしているなぁと思ったからです。
![TRIWA トリワ 限定 CRAYON KLINGA クレヨン クリンガ KLST115-ME021212 ホワイト マルチカラー アナログ ウォッチ ボーイズサイズ メンズ レディース 防水 デイデイト(曜日/日付) カレンダー [並行輸入品]](https://m.media-amazon.com/images/I/41PUtcb-TAL._SL160_.jpg "TRIWA トリワ 限定 CRAYON KLINGA クレヨン クリンガ KLST115-ME021212 ホワイト マルチカラー アナログ ウォッチ ボーイズサイズ メンズ レディース 防水 デイデイト(曜日/日付) カレンダー [並行輸入品]")
GoProが提供する撮影体験
みなさん、GoProって使ったことありますか？
私は去年、趣味でダイビングを始めたのですが、ダイビングの楽しみの一つとして、GoProを買いました。
水中の景色を動画、写真で撮影して、記録を残そうと思ったのです。
このGoPro、ものすごい撮影体験を提供してくれています。
カメラはあまり使いません
私は普段あまりカメラを触ることがありません。
人付き合いが苦手な私は、撮影をする状況がないのです。
なので、スマートフォンのカメラで事足りるのです。
だから、このGoProを初めて使ったとき、いまどきのカメラに大変驚きました。
驚きポイント
エンジニア的な目線になってしまうのですが、まずは、GoProの一番の驚きポイントです。
それは、"スマホとの連動による、新たな撮影体験と、写真、動画のシェアリング体験"です。
デジタルカメラって、メディアデータのやり取りに、どうしても物理的な記憶媒体による煩雑さが伴ってしまい、扱いづらさがありました。
SDカードや有線接続など、配線や記憶媒体の物理的な規格が地味に厄介で、間違えると動かなかったり、壊してしまうこともあります。
特に、GoProはアクションカメラの部類なので、ちょうどいい小型化がされており、シチュエーション次第でケースに入れて使うこともあります。
なので、よりこの物理的なやりとりが、目立ってしまうのです。
GoProの解決方法は非常にシンプルで、無線でスマホと連動してデータのやり取りができるようにしたことです。
そのうえで、このバランス感覚がとてもちょうどいい。
たとえば、遊び終えて撮影した写真・動画を友達と確認しようとしたときに、スマホに予めインストールしておいたアプリを通して、GoProと接続します。
GoProと接続が完了すれば、スマホから撮影した写真や動画が閲覧・視聴出来ます。
気に入ったデータはスマホにダウンロードし、友達にシェアしたり、パソコンに保存したりできます。
スマホとの接続方法はGoPro本体に搭載されたWi-Fiアクセスポイントにスマホから接続しにいく感じです。
写真・動画データ自体はあくまで本体のメディアに記録されているのですが、あたかもスマホに写真・動画が入っているかのように、ユーザに見せてくれます。
価値ある情報を蓄積しているカメラ自体をサーバに見立てて、スマホをクライアントにして実現しているのですね。
Wi-Fiで接続するので、高画質な動画データのやり取りも、結構なスピードが出ます。
スマホとの連動で提供されている機能は、データのやりとりだけではありません。
スマホからカメラの操作ができるのです。これ、いつ使うのだろう？ と最初は疑問だったのですが、自撮りをするときに非常に役に立ちました。
友達と旅行に行った際に、自撮り棒の先端に取り付けたGoProは直接操作できません。
そのとき、スマホと接続しておくと、手元でシャッターを切ることができるのです。
手元から少し稼働範囲が広がることで、ユーザに提供できる価値の幅が広がる。
サイズが小さくなることで煩わしくなるデジタル機材の扱いが、スマホとの連動で新たな価値を提供してくれる。
このバランス感覚が、大変素晴らしいと思いました。
ITの真価が発揮されるとき
カメラとスマホを接続すること。
なんだか当たり前のような技術の進化ですが、このバランスの調整はかなりの苦労があったのでは、となんとなく感じています。
繋げば良いってものじゃない。繋いだときに、そこにどんな新たな価値をユーザに提供できるのかを、問わなければいけない。
カメラは純粋にハード的な価値の追求をする。
アクションカメラとして、軽くて小型で、ブレの少ない鮮明な映像が撮影でき、様々なシーンで利用できるものを作る。
その追求と同時に、ソフト的にユーザの撮影体験をデザインし、そのカメラが威力を発揮できる最高の環境を作り出す。
写真・動画を撮影することが楽しくなるような、そんなサービスをスマホを通して提供する。
IoTの技術的向上に伴って、こうしてカメラの撮影体験も向上している。
でも、結局その技術を使って、ユーザにどのような価値を提供するのか、それをデザインするのが重要な気がする。
モノとモノをネットワークで繋ぐことができる時代になってきたが、どれとどれを繋ぐにしても、結局どんな価値を提供したいのかを追求していかないと意味がない。
ただGoProで遊んでただけだったが、そんなことを考えさせられたのが、妙に楽しかった。
誰のために、何のために。それが見える仕事がしてみたいものだ。
