(読書メモ) モブプログラミング・ベストプラクティス まとめ・感想
読んだ本 books.rakuten.co.jp 英語版 learning.oreilly.com
モブプログラミング自体はこのブログがよくまとまってると思います。 medium.com
全体のまとめ
モブプログラミングへの感想
チームのコミュニケーションとスキルシェアリングを主として、モブプロを導入したいと思って、いろいろと調べてたらこの本がおすすめされたので、読んでみた。 実際にこの本を読みながら、チーム内で、モブプロを導入してみた。今、リモートチームということもあり、この本通りにいかないことも多くあったが、考え方自体を理解していれば、それに伴って、自チームのオリジナルのモブスタイルが生まれてきて、なかなかおもしろかった。リモートモブワークのことについてはまた、別の機会にブログにしたいと思う。あと、モブ自体は今の所うまくできており、ナリッジシェアリングやコミュニケーションの増加につながっている。フロー重視の開発に対し、正しい理解をして、なんのためにこれを導入するかを考えることが非常に重要だと思う。
本の感想
モブプログラミングとは、なにか、メリット・デメリットはなにか、導入と継続はどうするか、より効果的にモブするためにはどうするか、などに焦点をおいて、無駄な情報はなく、シンプルなので簡単に理解できるいい本だった。著者の経験や、解決策なども盛り込まれており、非常に参考になる。また、エンジニアチームという観点からもこの本は良い切り口を書いており、チームの育成を考えると、もう一度、必要なときに読みたい本。
どういった人におすすめ
今後、誰かに本を紹介するときのために、ちょっと、まとめてみる。
チームに所属していて、こういった悩みやモチベーションがある方
- プルリクのレビューが遅い、リリースまでのサイクルが遅い
- チームでスキルセットが偏ってる、スーパースペシャリスト様がいる
- ペアプロがうまくいかなかった、モブプロを導入したがしっくりこない
- タスクの終わり方がゆるゆるとしてる
- モブプロに興味がある
- 新しいことをしてみたい、チャレンジングなチームだ
- 知識をシェアする時間が非常に長い、同じことを毎度新規の人に説明してる
- 組織でのチームビルディングにコーディングが使える
印象に残ったこと
モブプログラミング
- いくつかベストプラクティスな話があるので、まずはそれに準拠するといいかも、で必要に応じてチームで変更していく。
モブプログラミング導入の仕方
- 最初は実験として導入
- 最初の何回かは必ずレトロスペクティブ
バットマン制度
- 名前がいいよね
- モブプログラミングを止める割り込みを止める人
- 他でも使えそうな考え方
- 割り込み自体を止めるスキルをシェア
タックマンモデルとモブプログラミング
- もし、モブプログラミングを初めて、問題が出てきたら、それは表面化しただけなので（幸いなことに）、良いことだ。タックマンモデルで言う混乱期。
フロー重視の進め方
- 自チームがリソース重視だったので、非常に参考になる考え方。全部フロー重視でタスクしなくとも、フロー＋リソース重視でより効率的に育つチームを作れる気がする。
フローを維持するために
- 場所を確保
- 邪魔を減らす
- みんなが違和感ないキーボードとエディタ
採用面接にも役に立つ
- １，２日短期採用期間を設けることが可能なら、モブプログラミングすると良いかも
- １，２時間ならペアプログラミングするのもありかも
こんな感じかな。チームで今、週１のモブプログラミングをしてみているので、また、それをベースにブログを書きたいと思います。それについて、まとめました。ぜひこちらも、読んでください。
katacodaでLearn Kubernetes ver1 Clusterの作成/コンテナの立ち上げ/pod,deploy,service
katacodaで kubernetesの勉強をしていきます。このページはメモ。 www.katacoda.com
Launch A Single Node Cluster
kubernetes上にコンテナを立ち上げる
- minikube - kubernetesのクラスターをローカルテスト用に構築する
- kubectl - kuberneteのクライアント
Commnads
- minikube version
- minikube start
- minikube addons enable dashboard : ダッシュボードの追加
- kubectl cluster-info
- kubectl get pods
- kubectl run : imageから実行
kubectl run first-deployment --image=nginx --port=80
- kubectl expose : portのフォワーディングなどできる
kubectl expose deployment first-deployment --port=80 --type=NodePort
実際のサンプルケース
- ジョブの実行
kubectl run first-deployment --image=nginx --port=80
- ポートのフォワーディング
kubectl expose deployment first-deployment --port=80 --type=NodePort
- ポートを探る
export PORT=$(kubectl get svc first-deployment -o go-template='{{range.spec.ports}}{{if .nodePort}}{{.nodePort}}{{"\n"}}{{end}}{{end}}')
Launch a multi-node cluster using Kubeadm
kubernetesのクラスターをkubeadmで立ち上げる
* kubeadm : manager cli of kubernetes
command
- kubeadm init : masterノードを立ち上げるコマンド。token初期値を渡すこともできる、ランダム生成させることもできる。productionではランダム生成させよう
- kubeadm token list : 保持しているトークンを表示できる
- kubeadm join : master ipとトークンを渡すことでkubernetesクラスターに参加できる
- kubectl get nodes 参加しているノードを調べる
- kubectl create deployment imageからpodを立ち上げる
yaml
- kind: ServiceAccount service Accountをつくる
- kind: ClusterRoleBinding ServiceAccountを紐づけできる
Start containers using Kubectl
command
- kubectl describe 対象の詳細を表示できる
- kubectl expose ポートをexternal-ipに紐付けるやり方。実際はserviceを作成する。
- kubectl scale --replica=3 deployment * のpod数を上げる
kubectl get svc svc = services
エンジニアがエンジニアであるために
はじめに
久々に思い立ってブログを書くことにしました。
僕が思う「エンジニアがエンジニアであるために」について、まとめようと思ったからです。
ここで言うエンジニアは俗に言うWeb業界がメインです。（僕がそうなので）
本とかブログとかを交え紹介をしていこうと思います。
基本的に３つの軸で書いていきます
- 考え方を身に付け
- 良いとは何かを知る
- 自分の知識を更新していくこと
この３つが必要だと、僕は思います。個人的見解なので、ほかにももっとこういう考え方あるよ、とかもあると思いますので、参考までに読んでいただけるとうれしいです。
考え方を身に付け
考え方を意識すること
まず、エンジニアであるということは、柔軟な思考と戦略的な思考が必要だと思います。そもそも今目の前にある課題をクリアするために、コードを書くだけが解決の方法ではありません。オープンソースを利用して対応する方法もあります。DBも多種多様です。柔軟に考えプロダクトを前進させていかなければいけません。
最初にお勧めしたいのが、このストラテジックマインドです。
企業経営のための本と書いてありますが、本質は戦略的な思考の本です。エンジニアは常に考えなければいけません、課題をどう解決するか、将来どのようにプロダクトを成長させるのか。その中で、いろいろな自分の固定概念やあるべき論に縛られることがあります。その時にどう考えればいいかを紐解く一冊になると思います。
books.rakuten.co.jp
次にお勧めしたいのがエッセンシャル思考です。
これは有名な本ですね。まず、エンジニアは時間がないことを知らなければいけないと思います。自分が勉強できる・成長できる時間。仕事中の時間をなにに使い、何に貢献するのか。なにも考えないとすぐに１年終わってしまいます。エンジニアには時間がないのです。そのため、「しないことはしない」、「やるべきこと」、「やりたいこと」をするためにどういう考えを持つ必要があるか。正直これができてないエンジニアは、成長が鈍化するだけでなく、ストレスをためてしまうかと思います。
簡単に読める割には、多くの発見がある本です。
books.rakuten.co.jp
エンジニアには文化があることを知ること
エンジニアリングをしていると、当然のように人とかかわることがあると思います。直接でなくてもコードの中やシステムを通して間接的にも多々かかわることもあると思います。開発をする、チームを作るということは、そのメンバーで文化を構築していくということを意識することが非常に重要だと思います。AgileやScrumなどもその文化の中のひとつだと思います。文化はリーダーだけでなく、そこにいるメンバー一人ひとりによって代わるものです。
文化については、ここら辺がお勧めです。どういう組織を作りたいかGeekな集団とは何か。
books.rakuten.co.jp
Spotifyの文化は、すごく参考になります。英語ですがスライドを見ればなんとなくわかるかと思います。
labs.spotify.com
labs.spotify.com
ちなみに、僕は文化として、重要だと思ってることは大きく３つ合ります。
- 真剣に振り返るできること
- Retrospective や Postmortem : https://landing.google.com/sre/book/chapters/postmortem-culture.html
- 安心感があること・失敗を恐れないこと
- Spotifyの文化だとFailure Celebration: 失敗をして新たな発見をできたことを祝う。
- 先を見越し動くこと(プロアクティブ)
- 言われて実装するのではなく、先見の目を持って技術投資を行い、プロダクトを改新していく感じ
- フォードもこの文化を持ってる１社ではないかと思います。
「もし顧客に、彼らの望むものを聞いていたら、彼らは「もっと速い馬が欲しい」と答えていただろう。」
by ヘンリー・フォード（アメリカの自動車会社「フォード」の創業者）
http://meigensyu.seesaa.net/article/205528783.html
良いとは何かを知る
良いコードを知ること・良いアーキテクトを知ること
コードを書くときに、動けばいいや？って書いてるとそれは大間違いです。コードを書いた瞬間からそのコードの運用が始まります。コードを運用するためにはコードを読まなければいけません。そのためには、どのようなコードが読みやすいのか知る必要があります。僕はこう考えています。「企業の成長速度は、コードの良し悪しで決まる」と。改修しやすい、変更しやすいコードは企業のビジネスの変更に強く、その仮説検証を促進してくれます。逆にテストがなかったり、汚いコードはすぐにリリースはできますが、変更に弱く、いざビジネスを進化させようとする際に足を引っ張ります。
ゆっくり読んでも１週間くらいで読める本だと思いますので、とりあえず読むといいと思います。
books.rakuten.co.jp
次にお勧めしたいのが、レガシーソフトウェア改善ガイド
これを読めば、そもそもどんなソフトウェアが危険なのかの勘所とそれに対してどうすればよいかがわかります。なので、自分がレガシーソフトウェアに携わってないと思っていても、１度読むことをお勧めします。そもそもソフトウェアの構造がここ数年でどのように変わってきたかもわかるので、ある意味歴史の教科書です。個人的に、心に残ってるフェーズは「チームが既存のコードを改修しなくなったらそれはレガシーの始まりである。」という、組織文化についても少し触れていた点です。
books.rakuten.co.jp
使っているモノをちゃんと知ること
自分の扱ってるプロダクトに合わせて言語習得をしたりすると思います。既存のコードや書きたいコードを検索して調べて、それで実装して、リリースしたりしてると思います。でも、本当にその言語の強み、フレームワークの利用方法を学習してますか？なんとなく使えるからと、怠らずちゃんとそれがなんなのか知りましょう。先人たちが知るべきことを示してくれてます。
ベストプラクティスを読む
あと、ツールやDBだとベストプラクティスは結構公式に乗ってます。きちんと理解しましょう。
Googleで「Ansible BestPractice」とか打つと大抵出てきます。独自の発想で使うのではなく、ベストプラクティスに合わせて使いましょう。
そもそも、ベストプラクティスはツールの意義に沿って案じてあります。それに沿わないと、ツールがバージョンアップするときに取り残されて将来古いバージョンを利用し続けなくならなければいけない危険性があります。そんな、運用したくないですよね。
- Ansibleだと
自分の知識を更新していくこと
幅広くアンテナを持ち続ける。
ご存知のとおり、Web含めIT業界の技術というものは日進月歩です。
日々とまでは言いませんが、常に少しだけでも読むようにしておきましょう。課題を解決するときに新しいOSSのことを知っていたり、既存のOSSをバージョンアップすることでより、より便利にしたりと、プロダクトとあなたをアップデートしてくれます。
ここでは僕が日々キャッチアップしている軸とサイトを少しだけ紹介します。自分に合ったものをちゃんと見つけましょう。
幅広くキャッチアップする
いろいろなものはどこかでつながってるもので、浅くてもいいので幅広く知っておきたいものです。
hacker news
ここでは非常に幅広いジャンルの記事を読むことができます。
OSSだけでなく、世の中の情勢記事（技術によってる）などを読むことができます。TOP３０くらいが常にトップページに出てるので、朝から面白そうな記事だけ２，３個だけピックアップして読みます。
使い方的には技術新聞をぺらぺら読んで、情勢を知ったり、キャッチアップのために使います。
Hacker News
技術方法論を日々更新する
自分が良いと思っているやり方だけにこだわらず、いろいろな手法を勉強し続けることが大事だと思います。
dev to
表示速度が異常に早いことで有名になったページです。基本的にはWeb技術や手法についての記事が多いです。
自分のプログラミングや技術手法を改善するために、暇なときに読みます。
The DEV Community
利用してるものの知識を更新する
自分が使う技術回りは常にアップデートしておきましょう。それがそのまま自分の更なる強みになります。
ScalaTimes
名前から予測できるとおり、Scala周りの技術周り、ブログ周りを集めてるサイトです。
http://scalatimes.com/
ほかの言語でもいろいろとあると思います。メールを購読するようなサービスも意外と便利です。
同ジャンルの競合を知る。
自分が利用している技術の同ジャンル等はできるだけキャッチアップできることが大事です。
DB-Engines
DBのランキング紹介サイト。各ジャンルごとにDBのRankingを紹介しています。
僕は、上位のものを使うというより、そのジャンルで今どういうDBが出てるのかを知るために利用しています。それで、自分の利用用途に一番合うのはどれかを考えます。やはり、何かを採用する際は、ちゃんと競合には何が存在するのかを知っておく必要があると思います。
DB-Engines Ranking - popularity ranking of database management systems
最後に
最近、どのようにすれば自分がエンジニアとして価値を出せるのかを考えることが良くあります。この記事は、それに紐付いて思ったことを書きました。こういった人材を育て、同じチームでプロダクトに向かっていけるといいなと思います。もちろん自分もこういったエンジニアで在り続けないといけないなと思います。
最近、リモートワークで使ってるツール紹介
リモートワークで利用しているオンラインツールを簡単に説明したいと思います。
個人的には必須のサービスになりつつあります。
ぜひぜひ、利用してみてください。
appear.in
appear.in – one click video conversations
簡単にテレビ会議をするためのサービスです。真ん中のリンクに適当な文字列を入力すると、会議が始まります。そして、そのリンクを会議したい人に渡すだけで、テレビ会議が始まるというすぐれもの。必要な環境はブラウザだけなので、なにか特殊なアプリをインストール必要が無いのがすごい楽。
画面はこんな感じ。
web white board
A web whiteboard
これは、ウェブ上にみんなで落書き可能なホワイトボードを作成するサービスです。
リモートで説明するときに、落書きしながら話したいときに、効果を発揮します。でも、マウスでのお絵かきはやっぱり難しいです。
ちなみに、この左下の人を＋するみたいなアイコンをクリックしたあと、"Invite to board"すると、シェア用のリンクが出てきます。
- オンラインで参加者全員でお絵かきするホワイトボード
- 文字も打てる、ペンのサイズ、色も変更可能
- 図も挿入できる
- 何気にチャットも可能
- 書いたホワイトボードを、imageにして保存可能
- 有料会員になると、ボイスチャット、ボードの保存が可能
- やっぱり、書きながら説明するのは良い。
idea board
www.ideaboardz.com
オンラインで付箋を貼り付けるスペースを提供してくれるサービス。
ブレインストーミングや、レトロスペクティブに使える。
こんなかんじで、スペースが提供される
各チケットにイイねできる
パリで働いて感じたこと 第５話 レトロスペクティブ楽しい
どーも、だいごろうです。
今回、パリで感じたことというより、
会社でやってるスクラムのレトロスペクティブが面白いなと思ったので、
ブログに書いておきます。
（スクラム？それってラグビーのことだろ？？ってひとは、ごめんなさい。）
チームで振り返りをしてみたいって人にはおすすめ。ただし、コンテンツは英語。
日本語で雰囲気を知りたい人はご連絡下しあ。
さきに、このレトロスペクティブの流れのイメージを話すと
レトロスペクティブが始まると、
最初に、スプリントの全体を全員が１枚ずつ絵を書いて発表します。
次に、スプリントのイベントをTwitterのつぶやきの書き方で時系列に並べます。
それから、何をすれば次のスプリントが完璧になるかをボード上に貼っていきます。
そのボード上のモノを、実行しやすいかどうか、効果が高いかどうかの軸で並べ、
実行しやすく、効果が高いものを次のスプリントの目標に設定する！
という感じで、わいわい楽しみながら、みんなでスプリントを思い出し、
なにすれば良くなるかなーってのを話し合うイメージです。
しかも、毎回レトロスペクティブの中身が変わります！
じゃあ、具体的に説明していきます。
使ってるもの
Retromatというレトロスペクティブ用に作られたページ
Retromat - Inspiration & plans for (agile) retrospectives
このブログの著者が運営してるみたいです。
Finding-Marbles | Making sense of systems – Lean, Agile, Change & Communication
このページどうみるのか
このレトロスペクティブでは５つのステップに分かれています。
- SET THE STAGE ( 振り返る準備に入る
- GATHER DATA ( スプリントの出来事を集める
- GENERATE INSIGHTS ( 改善点、良かった点をあぶり出す
- DECIDE WHAT TO DO (何するか決める
- CLOSE THE RETROSPECTIVE ( 振り返りの締め
ページを見ていただくと、色によって、５ステップに分かれてるのがわかるかと思います。
そして、それぞれのステップに複数のコンテンツがあるので、
毎回それを変えながら、いつも違った形でレトロスペクティブを楽しむことができます。
しかも、それぞれのステップで10-20くらいのアクティビティがあり、
全部で105のアクティビティが有るみたいです (2015/07/24現在
3321204 combinations (20x23x19x19x20+4)って公式に書いてあるっすね。
最後の+4がよくわからんっすけどｗ
ちなみに、ページアクセスすると、自動でアクティビティを選んでくれます。
しかも、それぞれの組み合わせはURLとして、表現されているので、
URLのコピペでレトロスペクティブの項目を保存しておけます。（便利）
では、それぞれのステップがどんなことをするか例を上げて説明します
例
SET THE STAGE ( 振り返る準備に入る
Check In - Amazon Review (#18)
スプリントをアマゾンのレビューと同じように評価する
- Title
- Content
- Star rating (5 stars is the best)
そして、前で発表する
http://plans-for-retrospectives.com/?id=18
GATHER DATA ( スプリントの出来事を集める
#tweetmysprint (#97)
ホワイトボードにスプリントの始まりから、終わりまで時間軸を書き、
その上に付箋で、twitterでつぶやくように出来事を書いていく。
もちろん、@や#タグなども使って良い。
@daigoro
ここでだいごろうのバグ発見があった。
おかげで、リリース前にフィックスできた。
#bugfix #goodjob
GENERATE INSIGHTS ( 改善点、良かった点をあぶり出す
Perfection Game (#20)
全員が２枚の付箋を持つ、
１枚には前回のスプリントを１０点満点で評価する。
もう１枚には、どうすれば次のスプリントが１０点満点になるか書く。
最後に、一人一人、前で発表しながらホワイトボードに貼る。
http://plans-for-retrospectives.com/?id=20
DECIDE WHAT TO DO (何するか決める
Divide the Dollar (#72)
前のステップで出た改善点をすべて、並べて
もし、自分が１００ドル持ってたら、どれにどれだけ投資するかを書く。
全員が投資を書いた時点で、点数が高い順から次のアクションになる。
http://plans-for-retrospectives.com/?id=72
CLOSE THE RETROSPECTIVE ( 振り返りの締め
Motivational Poster (#92)
前のステップで決めたアクションをポスターにして自席の近くに貼っておく。
ポイントは、
- イメージ画像が有ること、
- チーム同意のアクションが書いてあること
- 自分の行動イメージが書いてあること
ちなみに
僕らが会社でやってるのは、ここにあるアクティビティを噛み砕いて、やりやすいようにやってます。
どうでしょうイメージ湧きましたでしょうか？
複雑そうに見えますが、非常に簡単なので、
レトロスペクティブがマンネリ化してると思うならば、
一度やってみることをおすすめします。
ちなみに、こちら、プリントエディションもありますので、
もし、興味がある方がいらっしゃいましたら、購入してみるのもありです。
この地球上なら送料無料です。（僕も買って、日本に送ってもらってますｗ
ただ、今年の販売が7/26までなので、もし買いたい方がいたら、早めに。
Retromat - The Print Edition
本日は、いままでにないくらいちゃんとブログを書いた気がします。
フランスに来て、スクラム・アジャイルを自由にやってる方々を見ると、
日本では形式から入る人が多いのでは？と感じます。
とりあえず、こういう面白そうなことだけから始めるのもいいかなーって感じました。
では！
パリで働いて感じたこと 第４話 今しかできないというセリフを言うこと
パリでフランス人と話して考えたこと。
「なんでそんなに仕事してるの？」
「今、幸せなの？」
「なんで家族とか友達とかにもっと時間割かないの？」
っとか、けっこう聞かれます。
"once life. you should do you want to do" : 「人生一回だから、自分のやりたいことやれよ」
っとか、言われます。
それに対して、
「だって、プログラマとして頑張れるのは今しかできない。だから今、イロイロと挑戦してます」
って答えてたんだけど、なんかしっくりこない気がしたから、ちょっとだけ考えてみた。
なんで、今しかできないの？？ってことを突き詰めて考えると
- 体力がなくなる
- 頭が回らなくなる
- 技術を追いかけられなくなる
- 他にエンジニアリング以外のことが見えてきて、そっちが楽しくなる。（かも）
- 日本ではそういう働き方では稼げなくなる
っとかを、頭のなかにでてきて、
でも、結局はどれも本質ではないなと思った。
エンジニア３５歳定年説とかも、ここらへんを見据えてのことじゃないかな。
まだ、３５歳じゃないから、本当のことはわからないけど。
結局は自分が好きなうちはプログラマで楽しく出来るんじゃないかなって思った。
今も、好きだからこの仕事でプログラミングしてるんだろうな。
きっと、今しかできないってことはないんだと思う。
ただ、「今しかできない」って言う、緊迫感を持ってチャレンジしていったほうが、
自分のキャリアとか人生とか面白い方に転びそうだなって思ったから
これからも、俺は今しかできないってこれからも言い続けると思います。
今しかできない（気がする）からチャレンジしたいんです、もっと。
そんで、振り返った時に、けっこうむちゃしてきたなーｗ
って言いたい。
パリで働いて感じたこと 外伝第１話 Google IO と WWDCを見て思ったこと
こんばんわー！！(´・ω・`)
全然、パリ関係ないけどブログ更新します！書きなぐります。
本日は、２つのでかいイベントを見て感じたこと、思ったことを書いていきます。
みなさん知っての通り、今、スマートフォン/タブレットといえば、
- apple (wwdc)
- android (google io)
の２つが巨塔( ・∀・)ﾉ
その２つの企業の発表から何がどうなのかーってことを、ぼちぼち考えてみました。
聞いてる部分と、聞いてない部分があるし、いつもどおり、このブログは完全なる個人的見解。
逆に総まとめから、書きます。
まとめ
それぞれの企業
- apple
- 今回の発表はapple製品と他のソフトウェアとの差分を埋めること。
- なにが○倍早くなります！新しいエンジン積みました！っていうのは、すごいことだが、なんだか、実感がわかない。
- インパクトを持ってこようとしているのは、分かったが、近年、イノベーションに慣れたユーザには目新しい物は少なかった。
- developerに視点をおいて、swiftとかappの新規APIの話などをしてる点は、良かったと思う。
- でも、その点はもっと深堀りしてもよかったのでは？apple musicとかで、ムダな時間使わずに。
- うーん。やっぱり、発表が開発した人とか思いがこもってる人ではなく、偉い人がやってるイメージしかなかった。いいもの作ってると思うのに、ほんとにもったいない。
- ios上でのサーチにチカラを入れていることが非常に分かった。アプリにAPIを公開するなど。
- iOSもOSXも最新版を８割位のユーザが持ってることは、開発側にとってすごくいいなと思った。androidの最新版のユーザはかなり少ないし、ほとんどのユーザが最新版を持ってることは非常にアドバンテージだと思った。
総じて感じたことは
- 今、両方で起きている２つの大きなテーマは、「機械学習とユーザエクスペリエンス」だと思った。appleはユーザが聞いた音楽などの動向から、サジェストを作るという点にチカラを置いている。googleは、検索、メール、お気に入り、写真などのさまざまな情報から、ユーザに適切なコンテンツやサジェスト、執事機能を提供するという点にチカラを置いている。この点においては、どうしてもgoogleのほうが多くの情報量やサービスを持っていて、ほんとにユーザのエクスペリエンスにそってると思うので、今のところは軍配はgoogleにあがってる。機械学習した情報をユーザにフィードバックする仕組み自体が完成していってる気がする。google now, okay google, google photosなどはそのたぐいだと思う。
- あと、ほそぼそと来てるのが、「スマート家電」かな。googleはbrilloとweaveを発表し、appleはhome kits を開発中。やっぱり、多くの家にスマートフォンがあるこの世の中では、家にある家電は、スマートフォンと連携することで進化を遂げるという見解は、両者おなじっぽい。ココについては、正直、おれ、すごく興味があるから、どっちもちゃんとこの分野を成長させていって、開発キットをOSSで出して欲しい。スマート家電開発したい。
- 全体的に、この記事がapple微妙って言ってる気がするが、絶対、発表者の問題。googleのほうが、ストーリ仕立てとか非常に上手くて、惹きこまれたのが事実。発表終わった時に、新しいスマホとスマートウォッチが欲しくなったのは、google I/Oやな。
- googleは、どんどん新しいものを作って、まだ見ぬユーザエクスペリエンスを狙ってる感じ。
- appleは順当進化と、ほかが持つ便利さを取り入れてる感じ。
あとは、いろいろな視点から、殴り書き。
発表されたものについて
- apple
- siri/検索自体の言語解釈はかなり進んでいてい、自然言語でイロイロと検索したり、操作したりが可能になってきている。
- 多くの既存プロダクトの更新があった。map/memo/music/....などなど。でもどれも他サービスをおってるだけのイメージしか感じない。
- apple musicは名前のインパクトからすると、もっとインパクトの有ることがあっても良かったのではないか？youtubeとやってることは同じ感じ。他サービスを追っているイメージ。
- なにげに、itunesがandroidででるってことに驚いた。
- apple watchでできること増えてる。別に、watchで写真を閲覧できなくてもよくね？
- swiftのOSSは本当に嬉しい。Linuxで触りたい。ムダになんか作りたい。
