hikoharu's blog

エンジニアリング、プロダクトについて考えていること。twitter: @hikoharu06

Google I/Oで発表された電話予約、Duplexについて

Google I/O行きたかったけど、行けなくて発表されたものを一通り見ていました。 多分みんな同じだろうけど、一番の注目はDuplex

https://www.youtube.com/watch?v=bd1mEm2Fy08

https://japanese.engadget.com/2018/05/08/google-ai-duplex/

電話予約をGoogle Assistantがお店の人と電話してやってくれるという、ペコッターの中の人いない版ですね これは大きなゲームチェンジの可能性があうのではないかと。。 従来、電話で予約やら問い合わせやらやっていましたがこれだと

カスタマー - 時間に縛られる同期的なコミュニケーションしかできないので、人によっては手間

店 - 電話でのやり取りがデータとして残らないので、Q&Aや予約状況とかを公開ができず、いつまでも工数確保が必要

という課題があり、「じゃあWebサービス上でやったらよくね?」ということで美容院やら飲食、最近は病院とかまで ネットで申し込むという文化が徐々に広がってきたわけですね ただ結構長いことやっているけど、色々な問題がありカバレッジが一向に100%にならない。これって性質上、60%と80%の違いってそれほどなくて100%にならないと 意味がないものかなと思っています。

Duplexは技術の未来感、カスタマーから見たらとても便利なものの、店側としては対応工数変わらず、それほど嬉しくないという特徴があり、これが広まっていって 誰にとってもいいのかという不安があります。 まあ、Googleのことだから店側もAI用意して、AI同士で解決できる。もしくはAIと店側の会話内容からデータ作成するくらいやってくれそうですが

とにかく、レガシーなコミュニケーションしていたのをWeb上でやることで価値を出してきたサービスはこれから危なくなるんじゃないかというのがざっくりとした感想です。

Macのメモ帳のデータを手動で復旧した話

知人がMacのデータが全て消えてしまって、死にそうになっていたのでメモ帳の復旧をした話。経緯としては

  • Adobe Illustratorを入れようとする
  • インストールしようとするも、ハードディスクの設定が「大文字/小文字を区別する」という設定になっており入れられない
  • どうにもならないので、ハードディスクを初期化して設定を変えようと思い、Time Machineを使って全てバックアップした上でフォーマット
  • 「大文字/小文字を区別しない」設定にして、Time Machineから復旧しようとしたところ、フォーマットが異なっており復旧できないという事態に。。
  • しょうがないので、ファイルは外付けHDのTime Machineから手動で復旧、ただメモ帳に関してはファイルの実態がわからず、復旧できない。超大事なデータが入っておりヤバイ。。
  • iCloudに保存されていれば大丈夫だと思ったが、なぜかバックアップの設定をしていなかった。。。

というところで依頼され、色々ツッコミどころはあるものの、すでにメモ帳以外のデータが復旧されていたため、一旦スルーしてメモ帳の復旧作業始めることに

アプローチとしてはiCloudにバックアップされてない以上、メモ帳の実体ファイルを特定してTime Machineのバックアップ内から探して持ってくる以外は手がなさそうなので、 やってみる。

色々調べた結果、どうやらメモ帳の実体は

  • ユーザー名/Library/Containers/com.apple.Notes/Data/Library/Notes/ の NotesV6.storedata** :独自の拡張子でメモ帳内の情報がファイルに記載されている。一応テキスト形式なので、エディタで確認可能。
  • ユーザー名/Library/Group Containers/group.com.apple.notes/ の NoteStore.sqlite** :sqliteファイルでインデックスなどの情報が格納。ここにはあるテーブルにメモ帳の題名と、上記のファイル内の対応する本文のキー情報が記載されている

で管理されているらしい

ということでTime Machineのバックアップフォルダの中から、上記のファイルを探して、Macのものと置き換えて無事復旧。 まさかMacのメモ帳がsqliteで管理されているとは思わなかった。。。というかなりマニアックな知見でした。

ちなみに多くのブログやQAでは

ユーザー名/Library/Containers/com.apple.Notes/Data/Library/CoreData/ExternalRecords

というところにデータの実体があるという回答が多かったのですが、確認できず

https://discussionsjapan.apple.com/thread/10175353

このブログがなかったら、なかなか厳しかった(とはいえ、該当フォルダ内のファイルはそれほど多くないので、手当たり次第チェックすれば多分たどり着ける。未確認だがフォルダ毎もってきても多分うまくいくかも)

https://gachan55.blogspot.jp/2016/05/el-capitantime-machine.html

React,Vue..どのFW使おうかなー 〜それSEO考慮しなくて大丈夫?〜

これは何?

とある新規のWebサービスを開発することになり、フレームワークを選ぶことに 「React使おうかな、Vue使おうかな、Angularはちょっと古いかな」とか色々考えていたら、作るサービスがKPIはMAU,Googleでの自然検索流入がメッチャ重要、SEO意識しないとダメということに気づき、これはエンジニアリング的な目線だけで決めてはマズいのでは?と思い調べてみた

そもそもの疑問

Googleがサイトをクローリングして検索のインデックスが作られて、自然検索に引っかかる訳だが、このクローリングはHTML要素をチェックしているはず。その時に

  • 操作によってHTML内のDOMがサーバーからのレスポンスによって動的に切り替わる場合:初期表示されていないものをクローリング対象にできないよね?
  • Reactとかだと、そもそもHTML単体だとほとんど情報がなくて、全部jsで差し込むけど大丈夫か?

というのがそもそもの疑問

クローラーとjsについて調べてみた

Googleクローラー(GoogleBot)がサイトを巡回して、キーワードを解釈してインデックスにしていることでGoogleで検索可能にしている。

Q.GoogleBotはjavascriptを認識できるのかどうか

A.できる どうやらGoogleが2015年くらいに公式で「JavaScriptで動的に表示されるコンテンツのインデックスはされない」という発表をしたらしく、それが広まってしまっているのが色々な認識齟齬の原因。 現在はGoogleBotがJavaScriptを実行してその結果を見ている。 この改善が公式発表されているわけでなく、GoogleのJohn Muellerさんが2016年くらいにtwitterでさりげなくつぶやいている。カジュアルか

https://twitter.com/GiceOne/status/804332185130008576?ref_src=twsrc%5Etfw&ref_url=https%3A%2F%2Fpromonista.com%2Fevaluation-of-javascript%2F&tfw_creator=Prmnista&tfw_site=Prmnista

Q.じゃあ何も気にしなくてもいいのか

A.いいえ 確かにGoogleBotはjavascriptを認識してくれるものの、

  • jsが正しく実行されるか
  • ページ内をもれなく操作してインデックスしてくれるか

を考慮する必要があります。

jsが正しく実行されるか

GoogleBotはページにアクセスしてレンダリングするが、ChromeIEの違いがあるようにブラウザによってjsの処理、パフォーマンスは微妙に変わってくる。 2018年現在GoogleBotのブラウザはChrome41(2015年1月リリース)を使っていると公式が発表しており、かなり古い これにより、意図しない部分でjsエラーが起きる。または処理が異常に遅くなりタイムアウトする可能性がある。

ページ内をもれなく操作してインデックスしてくれるか

GoogleBotはサイトのFirstViewにアクセスしてから、サイト内を操作して、FirstView以外のページの情報を取得している。この時にこちらが意図した通りに全ページを見てくれるかを考慮する必要がある

SSR(サーバーサイドレンダリング)とは

GoogleBotはjsは実行してくれるけど、正しく実行されない可能性がある。。。という問題に対して、現状よく使われているのがSSRです。 解決策としてはAPとは別でレンダリングサーバーを用意して、そこでjsが実行されたhtmlをキャッシュ、リクエストが来た場合はそれを返すというもの イメージは下記

スクリーンショット 2018-04-11 18.14.30.png

なおSEO的な意味とは別に、jsが事前に実行されているので純粋に初期描画が速くなるというメリットもある

なおSSR以外の解決策としてPrerenderingというものもある これはサーバーの中にヘッドレスブラウザ(Phantom.jsとかが有名)を用意しておいて、リクエストが来たら、ヘッドレスブラウザでレンダリング処理を行って、htmlを返すというもの。 どうやら、あまりメジャーではないよう SSRに比べて、導入も運用も低コストでいいと思うが、厳密には違うもののリクエスト投げてからブラウザ描画するのを2回やるオーバーヘッドを気にするのが理由かなと

SSRはいいことづくめ?

SSRには否定的意見も結構多い。ほとんどが

  • 費用対効果が悪すぎる:SEOと初期描画高速化に効果があることは間違いないが、それにしても導入、保守が大変だし。開発効率も大幅に落ちる
  • そもそも解決が本質的ではない:速度に関しては別の効果的な打ち手もあるし、SEO対策にしてもGoogleBotが更新されていけば改善されるのでは?なおかつなんか時代に逆行している気がする(歪なキメラという表現がされている)

というところに収束する 最近はNuxt.jsといったSSR専用のフレームワークとかも出てきているので、それで改善されるか?

結論

SPAにするかどうか、フロントエンドフレームワーク何使うかはSEO的には色々回避策あるので、それほど気にしなくてもいい。 ただ対応に尋常でないコストがかかる or 開発後期に見つかってアーキテクチャー変わると悲惨なので、こまめにGoogleBotにどう見られているのか確認する

このFetch as Googleを使うと簡単にチェックできるらしい https://support.google.com/webmasters/answer/6066468?hl=ja

一通り調べてみたものの、ぶっちゃけこれからやっていく段階で多分いろいろ試行錯誤しそう このあたり知見ある方いれば、ぜひご意見いただきたいです。

備考

SEO以外にも、近年のSNSの盛り上がりを経てOGP(Open Graph Protocol)対応も重要。 Facebookが始めた概念で、urlをSNSとかに書き込むと、概要が表示されるあれのこと

スクリーンショット 2018-04-11 18.51.00.png

このOGPもGoogleBotと同様にjavascriptの動作が通常のブラウザと違うという問題があり、SSRを含めて、対応が必要。これについては直近使う予定がないので、また必要になったら調べて書きます。

後日談

この記事を社内で共有したところ、いろいろ反響いただき結論としては SSRは導入、保守にとてつもない労力がかかるというのと、その労力をかけてまでSPAで表現する必要があるんだっけ? ということから、よほどの必要性がない限りはSSRに踏み切らないほうがいい(サービス全部をSPA前提にしないほうがいい)という結論に収束しつつあります。 ただサービスの中で部分的にSPAにするのは全然ありなので、サービスをデザインする時には初期段階で

  • どの部分をSPAで表現するか
  • そこはSEO的にクローリングされなくても問題ない部分か

ということを考慮すると、フレームワーク選定、リリース後にくる「こんなはずでは」を防げるのではと思いました。

プロダクトオーナー研修 2日目感想

昨日に引き続きプロダクトオーナー研修2日目 色々良かったが、中でも勘違いしていた部分を正すことができて、有意義だった

これまでしていた勘違い

アジャイル開発は仕様は最低限しか決めない。INVESTを満たすユーザーストーリーだけを決めて、どういう画面、機能で実現するかは開発者に任せられている。ドキュメントはあくまで最低限で不明点は会話で解決する。プロダクトバックログの役割の一つとしても会話を自然に促すというものがある

正しいこと

スプリントバックログに入ってREADY状態(エンジニアが着手可能)になるものはデザイン含んだ仕様、受け入れ条件、完了条件が明記されている。 ここにあるストーリー、タスクはPOと意思疎通なしで進められることが理想でもし会話が必要になったら、それはPO、チームのリファインメントが甘かったということ

勘違いの原因

プロダクトバックログとスプリントバックログを混同していた。確かにあいまいな状態で会話により進めていくのはあっているが、それはスプリント対象外のタスクにおいてのみ 「仕様が全部決まらないと作れないとか、これだとウォーターフォールじゃん」と思うかもしれないが、アジャイルの真髄は全体像が決まりきっていなくても、ビジョンを分解して部分的に進めて積み上げられるところにある

POのセンス

アジャイルの真髄はビジョンの分解と積み上げ。分解してどうやって積み上げてプロダクトを作っていくかがPOのセンスが問われると思った

  • ユーザーにとって最も価値のある機能、MVPは何か
  • フィーチャー、エピック、ストーリーは構造的にユーザーストーリーマッピングで整理されているか
  • インターフェイスを意識して、各機能の依存は十分に考えられているか

内容のサマリー

プロダクトバックログ、スプリントバックログ、READYの定義は上でも書いたとおり あと細かいが - チームにデザイナーがいる場合:デザイン完了してREADY状態 - ミドルウェアサードパーティ何使うかの選定:Howの部分なのでチームメンバーがやる

あとPOの手前に事業としてマネタイズ、KPIどうするというプロセスがあるが、そこはビジネスアナリストが専門でやる。誰がスクラム的に担当になるかわかっていなかったのでスッキリした。

dailyScrumはとりあえず進捗が見えづらい時、意思疎通で問題が起きている時のカンフル剤、あととりあえずアジャイルだしやってみるかというのでこれまでやってきたが、理想的なのはオールブラックスのハカ。士気を上げてチームでゴールに突進するという意思を統一すること。これまでdaily割とのそのそやること多かったのでここは反省。。。

プランニングポーカーやる時にPOは加わってはいけない、あくまで仕様、要件を説明する係。あと細かすぎる資料、ドキュメントが増えるとポイントは上がる傾向にあるので注意

ユーザーストーリーマッピングスクラムの最初にやるもの

  • プロダクトビジョン
  • コンポーネントゴール
  • フィーチャー
  • エピック
  • ストーリー

の順に分解されていく。直近の部分は細くして、未来の部分は割と適当にビジョンだけだったりする。 またスクラムの最初でとりあえずざっくりエピックにポイントをPOの独断でふってポイントの全量を出す。 大体わかると思うが、超あてずっぽう。とはいえ仮説でも出すことが重要 大体3イテレーションくらいやるとズレがわかってくる。そこで再度見直しを行って、正確なバーンダウンチャートが見えてくる。

アジャイルウォーターフォールの違いは色々あるがしっくりきた表現は計画に対する誠実さ。ウォータフォールはあたかも未来が正確に見積もれているふりをする。 ただスクラムが全面的にいいというわけではなく、結構組織を選ぶ。導入が大変というのもあるし、スクラムに必要な正直、誠実、透明、イノベーションへの意思を持っていないとうまくいかない。

内容はかなり満足 ただプロダクトを考えてチームでユーザーストーリーマッピングしてみようという割と大きめのワークがあったが正直微妙だった

  • 時間短いし、6人とかで遠慮しながらマッピングしても全然スピード感でない
  • プロダクト考えるというところで、本質とは違う奇抜なアイデア出し的な方にそれてしまうことがある

参考

研修のスライドの中で紹介があって、ただただ最高だった

プロダクトオーナー研修 1日目感想

Sierでなんちゃってアジャイルやったり、スタートアップにアジャイルプロセス導入したり、アジャイルサムライ一通り読んでみたり スクラムとは結構3年くらい付き合ってきたものの、どちらかというと現場の叩き上げで学んできたので一度整理したかった。

というわけでこれ行ってきた

https://scrum.esm.co.jp/

先に前提としてPO,SMの役割について

プロダクトオーナーとは

プロダクトのWhatを扱うもの。Howには決して言及しない。チームメンバーに任せる。 半分の時間は顧客、ステークホルダーと過ごして、半分の時間はチームと一緒に過ごす。 プロダクトマネージャーとの違いは諸説あるが、Scrum Inc曰く本質は同じで、より「プロダクトの全責任はあなたにあるよ」というオーナーシップを意識してPOと呼ぶ

スクラムマスターとは

プロセスを管理する。チームの幸福度、ベロシティの向上が責務 プロダクトオーナーとは基本的に対立する立場となる。POの機能要求をスクラムマスターは管理しなくてはいけない

内容のサマリー

序盤はアジャイル語る上で欠かせないウォーターフォール叩きから入る。計画から逸脱しない前提でやってるけど現実そんなことはおきないという感じ。 新しかったのは化学工場の例え。「工場で行っている化学反応はリアルタイムで微妙に調整しないとコントロールできない。失敗すると爆発してしまう。最初から全部予測なんて無理だろ」と妙に説得力あった。

アジャイル行う上で重要なものは

  • 勇気
  • 集中
  • コミット
  • 尊敬
  • 公開

の5つ。 中でも難しい(特に日本では)のは勇気と公開。 これは日本人の謙虚さ、礼儀という性質の副作用。プロセスの透明性、検査によってアジャイルは実現されるが、上記を欠くと遅延、成果物の品質問題を正直にレポートできない、チームの自己組織化が損なわれる あと日本は根回ししすぎ、これはPOが責任取る覚悟が足りていないから。全部決めて、責任取るべき。別に失敗してもクビにならないんだから、もっとリスクを取るべきと

あと大切なのはスクラムスクラムするという考え方、いわゆるカイゼンというやつ。スクラムやる以上ベロシティを上げるために全力を尽くさなくてはいけない。具体的には以下が有効

  • カイゼン:振り返りをして改善できるポイントは次のスプリントの再優先事項として扱う
  • やり方:集中というやつ。マルチタスク状態にならないように
  • 幸福度:メンバー全員が役割、チームに幸せを感じて働けるように

違和感感じた部分

違和感感じた部分は大体共通していて、いわゆる理想と現実のギャップというやつ

  • PO,SMの役割分担:メンバーとは明確に必要なスキルが分かれているものの、ぶっちゃけ優秀なメンバーを経験してPOになるケースがほとんどだと思う。POがシニアエンジニア、メンバーは新卒とかの構図も普通に多いはず。PO的にはHowに言及したいし、組織としてもPOにSM的役割、またメンバーのマネジメントを求めている時にどうすればいいのか

  • ベロシティの向上:ソフトウェア開発は労働集約なので、基本メンバーが最初から十分なスキルを持っている前提であれば、ベロシティがそんな劇的に上がるイメージはない。上げるとすれば時間か人を増やす。ベロシティはものさしでこなせるタスクの量を決めるもの。SMが使うチームを守るための指標で、それをどういうやり取りで上げていくのかイメージできない

  • メンバーの意識:アカデミックなスクラムではメンバーにタスクがアサインされることはない。メンバーはバックログから勝手に必要なタスクを取っていく。ただ実際には期限、アサインを明確にしないと進まないということからSM権限、あるいは合議でアサインが決まっている。メンバーにそこまでアグレッシブさを求めるのもなと。。。

総じて - 役割全員が十分なスキル、スクラム知識を持っている - なおかつチームに対するビジネス側の圧力がほとんどない(POが十分なスキルを持っているということかもしれないが) - メンバー全員のモチベーションがメチャクチャ高い。労働時間が完全に固定されているか、眼中にない。

という現実にはなかなか揃わない条件が揃った時に成立する部分に違和感を感じた。 ただ仮にこれらが実現できなくても、スクラムのメリットは十分だと思う