hikoharu's blog

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

エンジニア組織における組織開発について

先日会社でこんな感じのイベントをやってきました

https://tech.recruit-mp.co.jp/event/post-16667/

ぶっちゃけ転職して今の会社に入るまでは組織活性、組織開発という言葉も知らずにひたすら

  • 雑談大事
  • 1on1大事
  • メンター大事

みたいな戦略なき根性論みたいなことしかやってこず（それでも一定の効果は出ていたと思う）、しっかり組織開発について自分でも学んでみました。

イベントの趣旨として、実現したいのは開発組織におけるあらゆる知見がなめらかに循環する世界で、 中でもこのイベントの中でも参加者の１人が言っていて印象に残っているのがエンジニア組織は組織開発のsandboxということ エンジニア組織は規模もそれほど大きくないことがほとんどだし、エンジニア自身が勉強熱心で流行りに敏感だし、変化の許容量が大きいので最適だと、確かにその通り

ただ現状の問題として大体会社ごとに１つしかsandboxを持ってなく、そこへのcommitログが公開されておらず他社から見れないこと それにより、ある場所で起きているrevertとか、他の場所でも全く同じこと繰り返したりしてる ここらへんを循環できるようにしていきたいなと

最終的には別に他の会社のsandboxにcommitしてもいいと思うし、お互いのログを見せ合うことでかつてないほどお互いのコアな部分を知り合うことができると思っているので その関係値を利用した、施策とかが行えれば面白いなと思っています。

アジャイルについて最初に知るべきことだけをまとめてみた

今の副業してるところが本格的にフルコミットのエンジニアと学生インターン数名で開発組織を作ろうとしていたものの アジャイル開発について開発フローも何もかも全然わからんという状態だったので、 とりあえずアジャイルサムライとかScrum Boot Campとかエンジニア組織論への招待とかは読んでもらうとして

最初に知るべきことだけをまとめてみた。

  • 歴史
  • アジャイルに対する誤解
  • 目指すべきところ、そのために明日からやること

という構成に

特にこだわったのはアジャイルに対する誤解のところ

これだけ色々なところでスタートアップやっているアントレプレナーやエンジニアがいる中で アプリの開発について色々聞いたことや、ちょっとググって色々な資料が出てきたりする。

大体開発やったことない事業サイドの人だと、それらの情報から間違った開発フローのイメージ持って 突き進んでしまうなと経験的に感じているので、歴史的経緯と誤解を解消して事業サイド、開発サイド もゼロベースでスタート地点を合わせてこれから皆でインプットして健全に議論しながら 進めていこうというところを目指してみた

https://speakerdeck.com/hikoharu06/aziyairudeiketerutimuru-men

GTmetrix使ってサイトのパフォーマンス改善した

これは何

ブラウザアプリをGTmetrixというサイトのパフォーマンス計測するサービス使って、速度面でのボトルネックを特定して解決した話

https://gtmetrix.com/

そもそもなぜやろうと思ったか

最近、SEOやらコンテンツマーケティングやらに興味が出てきて、グロースハック的なmeetupに行っている。 その中である人が、「グロースハックには色々施策あるけど、一番コスパのいい施策は速度改善」と言っていたのが印象的だった。 実際に自分がプロダクトオーナーやっているサービスで試してみた

実際やってみた

これが最初に計測した時

f:id:hikoharu06:20180802160803p:plain

屈辱のF評価。。。。 どの項目が悪いか調べると

  • Serve scaled images: 必要以上に大きい画像を用意して、cssでサイズ調整している

  • Enable gzip compression: gzip圧縮を使っていない

  • Leverage browser caching: ブラウザキャッシュが有効になっていない

が問題なのがわかる。

なので、それぞれ

  • Serve scaled images: 画像のサイズ調整

  • Enable gzip compression: nginxでcss,javascriptをgzipするようにnginx.conf設定変更

  • Leverage browser caching: nginxで静的ファイルを30日間ブラウザキャッシュするようにnginx.conf変更（ブラウザキャッシュはブラウザ側の設定だけだと思っていたので、nginxにも設定あるの初めて知った）

結果が

f:id:hikoharu06:20180802160742p:plain

喜びのA評価！！

まとめ

まだサービスが動くようになってから、数ヶ月ということもあり２〜３時間程度で対応できた。nginx周りで少し詰まったので、知識ある人なら１時間以内とかでできると思う ただこれが１年運用したとかになると、膨大な修正を入れなければならず、永遠塩漬けになる未来が見える。。。

持論だけど速度改善（にとどまらず改善系全般）は担当者がちょっと手が空いた２時間くらいで「やってみるか」という状態にいかに保つことが重要だと思う。

  • マメにリファインメントして、課題の粒度を細かくしておく
  • 計測方法、修正方法の確立
  • チームの文化（空いたらその分機能開発ではなく、改善に力を注ぐ）

のを常に実行しようというのが改めて身にしみた

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はページにアクセスしてレンダリングするが、ChromeとIEの違いがあるようにブラウザによって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に比べて、導入も運用も低コストでいいと思うが、厳密には違うもののリクエスト投げてからブラウザ描画するのを２回やるオーバーヘッドを気にするのが理由かなと

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的にクローリングされなくても問題ない部分か

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

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

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

これまでしていた勘違い

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

正しいこと

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

勘違いの原因

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

POのセンス

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

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

内容のサマリー

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

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

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

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

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

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

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

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

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

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

参考

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