読者です 読者をやめる 読者になる 読者になる

rista’s blog

株式会社リスタの技術?ブログ

CSSの実装がバラバラになりがちなので、よくある実装パターンをesaにまとめておくようにした話

こんにちは!エンジニアの辻(@dim0627)です!

すっかり春めいてきましたね。皆さんいかがお過ごしですか。 僕は勇者ヨシヒコのシーズン3がAmazon Prime Videoで公開されたせいで寝不足気味です。

さて、今回はHTML/CSSについての話をちょっとだけしようと思います。

HTML/CSSのコーディングにおけるベンチャーあるある

HTML/CSSは比較的勉強を始めやすい分野だと思うんですが、 長く破綻しづらい考え抜かれた設計をするのはなかなか難しかったりします。

例えば、HTML/CSSを書いたことがある人なら、だいたいはこんな悩みを経験したことがあるのではないでしょうか?

  • 要素を横並びにするときはfloat?table?absolute?どれを使えばいいの?
  • 縦横中央揃えにするときはtable-cell + vetical-align?padding?line-height?どれがいいの?
  • clearfixはclear: both?overflow: hidden?

とりあえず思い通りのデザインを実現するだけなら簡単です。

しかし、行き当たりばったりの実装をしてしまうと、似たパーツでもあっちこっちで異なる実装になってしまうことが少なくありません。

スタイルガイドを導入/作成するコストはかけられない

僕がリスタに入社したとき、とりあえずスタイルガイドを作るかーと思って色々調査をしたりしました。

まあスタイルガイドはパーツを一元管理するのが目的だったのでバラバラな実装がまとまるわけではないのですが、コードを俯瞰できると少しは統一に役に立つ部分もあるかと思います。

が、事業のフェーズとしてコストをかけるべきか、運用する上で足かせにならないかという点から一度見送ることにしました。

今後もHTMLはガンガン更新がかかる予定でしたし、ある程度デザイン的に強固になってからでもいいだろうと。

ちなみにそのときに検討していたツールはhologramです。

弊社のJOBLISTはRailsで構築しているので、Rubyで統一できるのがよかったのと、CSSからドキュメントのHTMLを吐き出すことしかしないシンプルさに魅力を感じました。

スタイルガイドのツールって、結構余計なことをするツールが多いんですよね。

よくあるCSSの実装パターンをesaにまとめるようにした

というわけで、折衷案として弊社ではよくあるHTML/CSSの実装パターンをesaにまとめるようにしました。

f:id:dim0627:20170412104116p:plain

実現したいパーツに対してCSSの実装パターンが複数ある場合、 パーツの些細な違いに応じて適切な実装パターンがあるものです。

なのでまとめる際には、どういったときにどういった実装をすればいいのか、までをまとめるようにしています。

f:id:dim0627:20170412104328p:plain

CSSの統率が少しは取れるようになった

これをやりはじめて、実装がバラバラだったCSSが一気にきれいになるわけじゃないですが、 少なくとも状況が悪化するのを防げてると思います。

また、改修時にリファクタリングもかねて実装をあわせる基準ができたので、少しずつよくなっている実感もあります。

コーディングが楽になった

これまでは各自の趣味に任せた実装でしたが、基準ができたので特に何も考えずにそれに従えばよくなりました。

自分の趣味と違う実装方針だと少し抵抗があるかもしれませんが、それもすぐ慣れると思ってます。

レビューが楽になった

組織によってはCSS/HTMLのレビューをしないところもありますが、弊社ではできるだけCSS/HTMLもレビューするようにしています。

その際に「もっとこうした方がいいよ」っていう実装例を書いていたのが、esaのページのURLを書けばよくなったのでレビューは楽になりました。 esaになければ追加のリクエストを出せばいいので。

しかしあくまで暫定的な対応なので、将来的にはちゃんとUI/UXレベルでコミットしてくれる人がいて、 実装面でもスタイルガイドに近いドキュメントが管理できる体制が作れるといいなと思ってます。

というわけで弊社では絶賛採用活動中です! 興味を持ってくれた方は@mikedaまたは@dim0627までご連絡ください!

季節要因のアクセス変動、把握できてる?それ、Google Analyticsのベンチマーク機能でわかるよ

はいこんにちは!リスタでエンジニア兼集客担当をやってる辻(@dim0627)です。

ダクソ3のDLC第2弾がやっと出ましたね!いろんな評判が聞こえてますが、僕はまだやれてません。 最近はそっちのけでミステリー小説ばっかり読んでます。なんかオススメあったら教えてください。

さて、僕はリスタで集客周りを担当していて、成果として追いかけている指標の1つにPVやUUなどがあります。

しかし、PVやUUは季節や時事によって変動するので、「これなんで変動したのよ」という疑問を抱くことが少なくありません。 みなさんも同じ疑問を抱いたこと、あるんじゃないですか?

この記事ではGoogle Analyticsベンチマーク機能を使って、季節要因に関するアクセス数の変動を把握、予測する方法について書いてみます。

そのアクセス数の変動はなんでなの?

弊社では各自が担当している数値を定例の場などで報告しているんですが、 「結果」は報告できても「理由」が報告できない場合が多々あります。

例えば弊社でいうと、自慢じゃないですが最近はいい感じに数値が伸びている状況です。

とはいえ手放しに喜べるわけでもなく、「これはサービスの成長なの?それとも季節要因の影響なの?」、「いつまでこれが続くの?」という疑問が出ます。

弊社が運営しているJOBLISTは求人情報を扱うサービスなので、 「まあ3月から4月にかけては学生がバイト探しするだろうからそれであがってるんでしょ」という憶測も立てられます

その場合は「成長」ではなく「影響」と言わざるを得ません。

ですが、その憶測は本当でしょうか?ある程度根拠となる情報は得られないものでしょうか?

アクセス数が変動する主な理由を考えてみる

アクセス数の変動理由を知るためにまず、アクセス数が変動する外的な要因をざっと考えてみましょう。

季節要因による変動

まず考えられるのは、この記事で焦点をあてている季節によるアクセス数の変動ですね。

例えば、次のようなコンテンツが影響を受けると考えられます。

  • 寒暖差に影響を受けるコンテンツ
  • シーズンがあるスポーツや旬の食べ物に関するコンテンツ
  • バレンタインやクリスマスなどイベントごとに関するコンテンツ

プロモーションによる変動

次に考えられるのはプロモーションによる変動でしょうか。

  • TVCM
  • プレスリリース
  • 外部メディアによる記事広告

これらは自社で制御できるので、事前に変動が予測できるタイプの変動要因です。

時事やニュースによる変動

時事やニュースによる変動も考えられます。

世間で話題になったコンテンツは情報を得ようとする人が増えますし、 GoogleのQDF(Query Deserves Freshness)というアルゴリズムの影響も受けます。 「世間で話題になっているキーワードの検索は、新鮮な情報を上位に表示する」といったものです。

弊社では現状あまり影響がありませんが、サービスによっては大きく影響を受ける変動理由になると思います。

バズや炎上による変動

これはだいぶコンテンツが絞られますが、バズや炎上による変動も無視できない変動理由です。 バズは組織によっては狙って起こせるかもしれませんが、炎上は予測できない上にブランドを傷つけてしまうあまり嬉しくない変動ですね。

さて、この4つのうち、「季節要因による変動」以外は変動理由を特定しやすい要因だといえます。

ですが、「季節要因による変動」に関しては、「いつ変動するの?」、「どれくらい変動するの?」といった疑問が解決しづらい要因です。

Google Analyticsで季節によるアクセス数の変動を把握する

というわけでそろそろ本題に入りましょう。

Google Analyticsにはベンチマーク機能というものがあり、ここまでで挙げたような疑問はこの機能がだいたい解決してくれます。

どんな機能なのかを簡単に説明すると、他サイトの数値を平均して見せてくれる機能です。 業界やアクセス規模、国などでフィルタ出来るので、簡単に競合と比較分析ができます。

ベンチマーク機能を使ってみる

言葉で言ってもわかりづらいと思うので、実際に使ってみましょう。 ベンチマーク機能はサイドバーのここからアクセスできます。

f:id:dim0627:20170331112709p:plain

さっそく、弊社が属する求人系の業種に絞ってセッション数の平均値を見てみましょう。 以下に表示されているのが、求人系のウェブサイトにおけるセッション数の平均値(2016/01/01~2016/12/31)です。

f:id:dim0627:20170331114149p:plain

おお!どうやら求人業界のサイトには何度か季節要因の変動があるようです。 0まで落ちてる10月のデータはバグかなんかでしょうか。

「業種」に関しては更に細かく絞ることもできるので、絞れるところまで絞ったほうが信頼できる情報が得られると思います。 ですが、絞りすぎるとサンプルのデータが減ってしまい、データのブレが大きくなるので気をつけてください。

f:id:dim0627:20170331114601p:plain

ちなみに指標は追加で選択することができ、自社の数値と他社の数値を同じグラフに表示することもできます。

f:id:dim0627:20170403084038p:plain

チャネル、地域、デバイスごとのディメンション

ベンチマーク機能はチャネル、地域、デバイスといったディメンションが設定でき、 グラフの下部にそれぞれのディメンションで切り分けた情報が表示されます。

例えばオーガニックによる流入とソーシャルによる流入だと、だいぶ毛色が違いますし、 デバイスも最近では当たり前のように考慮しなければいけなくなりました。 PCとモバイルはきちんと切り分けて、違う観点で確認すべきでしょう。

弊社でのベンチマーク機能活用事例

というわけでベンチマーク機能の使い方をざっと説明しましたが、 実際弊社でどんな感じに役に立ったかを紹介してこの記事は終わりにしたいと思います!

弊社では前述したとおり、最近は堅調にアクセスが伸びています。 ということもあって、次のような調査をする必要が出てきました。

  • 現在アクセスが伸びているのは季節によるものなのか、改善の成果によるものなのか
  • 3月、4月はアクセスが伸びるものと考えているが、その仮説は間違っていないか
  • 1年を通してアクセスが変動するであろうタイミングはいつか

実際にベンチマーク機能で得られる情報をもとに考えると、次のようなことがわかりました。

  • アクセスが伸びているのは季節要因ではない、改善の成果によるものと考えていい
  • 季節要因による3月、4月のアクセス増加は期待できない
  • もっとも増加するのは1月、次に5月に増加があり、年末は大きく落ち込む

仮説が間違っていることがわかったり、今後どう変動するかをある程度予測できたり、だいぶ有益な情報が得られたかなと思います。

もちろんベンチマーク機能の情報をすべて正として鵜呑みにするべきではないと思いますが、 簡単な競合比較、アクセス推移の予想に使うだけなら十分な情報と言えるのではないでしょうか?

同じような疑問を抱いている方がいたら、使ってみてください!

弊社では絶賛採用活動中です! 興味を持ってくれた方は@mikedaまたは@dim0627までご連絡ください!

近況について

エンジニアの@mikedaです。
今年から執行役だったか執行役員だったか、そういうのになっていたらしいです。

しばらくお休みしてましたがまたちょくちょくブログ書こうと思いたち、
とりあえず会社の近況をまとめてみることにしました。

人が増えました

f:id:mikeda:20170224103952j:plain

年末あたりに社員を5人、在宅ワーカーを8人増やしました。

エンジニアチームは11月に2人採用して、自分いれて3人のチームになっていて、
UI・UX(応募率)、集客(UU)、顧客獲得・運用でそれぞれメイン担当を分担して開発を進めています。

UI担当の望月さん

@c5meru

f:id:mikeda:20170308114033j:plain

  • 大学文系
  • -> 生保レディー
  • -> なぜかWEB制作会社に転職してコーダーデビュー
  • -> 自社サービスがやってみたいとうちの会社に

という変わった経歴です。
ええやん、おもしろそうやん。ちゃんと自分で考えて決断・実行というのが出来てそうだし。
ということでジョインしてもらいました。

ruby & rails未経験でしたがもうrubyのコードもバリバリ書いてます。

wantedlyのインタビュー

集客担当の辻さん

@dim0627

f:id:mikeda:20170308114647j:plain

カカクコム、メドピア、株式会社医薬情報ネットなどでWEBエンジニアとして実績充分。
さらに

  • メディア運用実績がありSEOに詳しい
  • HTML/CSSなどフロントエンドにも非常に強い

自分の苦手なところだいたいやってもらえそう!
ということで初めて会った時ににその場でオファー出してジョインしてもらいました。

そしてその他雑用担当のmikeda

2人にまかせてサービスのコード書く時間がどんどん減って雑用担当になってきてる(´・ω・`)

サービスについて

JOBLISTのほうは体制が整ってきて、年始あたりから各種数字が伸び始めました。

求人数

15,000件を超えました。

f:id:mikeda:20170308114918p:plain

掲載社数

250社を超える企業に利用いただいてます。

f:id:mikeda:20170308114941p:plain

UU/応募数

順調に伸びてますが、詳細はないしょ!

まとめ

というわけで、徐々に仕組みとベースとなる体制が整ってきて、
会社としてアクセル踏む準備が出来たかなという感じです。

ここから全方位的に人増やして、サービスの拡大、改善、新規サービス企画などバシバシ進めて行きたいと思ってるので、
興味のある人いたら@mikedaまで連絡下さい!

CTO枠もあけてますよ!

新入社員といっしょに新しいMacBook Pro買ってきました

エンジニアの@mikedaです。

アップルストア表参道店で新しいMacBook Proを⊂(゚Д゚⊂≡<ゲトズサー

f:id:mikeda:20161028141053j:plain

11月から入社する社員の開発用MacBookを、本人といっしょに買ってきました。

こちらで購入・準備しておいても良かったんですが、
自分で実際お店行って選んで箱開けてセットアップして、
ってやったほうが愛着わくかなと。

いろいろ苦戦

Touch Bar付きのを購入予定だったんですが、
事前に確認したら
『現時点で購入できるのはTouch Bar無しのモデルのみです。』
とのこと。

じゃあ無しモデルでいいかとアップルストア渋谷に行ってみたら、
『渋谷店には入荷してません。表参道にはあります』
とのこと。

しかたないので表参道まで移動してやっと購入。。。

現物について

色はスペースグレイを選択。
女子なのに渋い。
※箱や袋は迷いなく即捨てでそこも渋い

自分のMacBook Airと比較してみると、

  • サイズが一回り小さい
    • ディスプレイ、キーボードサイズはあんま変わらんけど周りのスペースが小さい
  • (均一に)薄い
  • 重さは同じぐらい
  • キーボードのストロークが小さい(なれないと違和感ある)
  • タッチパッドがデカイ
  • 外部ポートがUSB-C ×2のみでちょっと辛そう
  • スペックはMacBook Airとあんまかわらん

という感じです。

f:id:mikeda:20161028174013j:plain:w400

f:id:mikeda:20161028174037j:plain:w400

持ち運び安いコンパクトサイズでそこそこのスペック。
非常に自分好みです。

自分のMacBook Airも2012年のやつでだいぶ古いので、
Touch Barのやつ出たら買い換えようと思います。

vimmerなのでエスケープキーが無い問題はつらいですが、
まぁなんとかなるだろう。

Google Cloud Vision APIで街の求人チラシを読み取ってみる

エンジニアのmikedaです。

街の求人チラシの写真をアップロードすれば求人広告が自動生成される、
というのが出来ると楽だなーとふと思って、
Google Cloud Vision APIを使ってOCR処理(画像からのテキスト読み取り)をちょっとやってみました。

コード

事前にGoogleのdeveloper consoleでキーを作って、コードはこんな感じです。

require 'google/apis/vision_v1'

GOOGLE_API_SERVER_KEY = 'XXXXXXXXXXXXXXXXX'

def ocr_text(content)
  vision = Google::Apis::VisionV1::VisionService.new
  vision.key = GOOGLE_API_SERVER_KEY
  request = Google::Apis::VisionV1::BatchAnnotateImagesRequest.new(
    requests: [
      {
        image:{
          content: content
        },
        features: [
          {
            type: "TEXT_DETECTION",
            maxResults: 100 
          }
        ]
      }
    ]
  )
  response = vision.annotate_image(request)
  response.responses[0].text_annotations[0].description
end 

puts ocr_text(File.open(ARGV.shift, &:read))

画像ファイルを指定すると読み取ったテキストが表示されます。

$ bundle exec ruby ocr_text.rb ocr_test01.png
4さん募集!!
月~土曜日
時給900円以上
食事&交通費付き
時間·曜日応相談
昔ながらの町のお麦蕎屋さんです。
平日のランチ9(ムに、日数多く働ける方.
大觀迎!!
広尾丸屋 です担当金田

実際に求人チラシを読み込んで見る

印刷物その1

元画像

f:id:mikeda:20161019085843p:plain:w400

読み取ったテキスト

アルバイトスタッフ 社員同時募集
OKONOMI-YAKI HOUSE
aw'So: FLOUR
hass
鉄板焼キュイジーヌバンブーグラッシィ恵比寿店
·お好み焼きハウス フラワー
お問合せ
03-5739-0527
採用担当:金城 090-2620-xxxx
給与:
アルバイト 1050円~/社員25万円~
勤務時間
14:00-24:00 / 1日3時間·週2日から応相談
待遇:
制服貸与·労災完備。食事あり·従業員割引あり
資格:
学歴不問·未経験者OK·経験者優遇
鉄板焼キュイジーヌバンブーグラッシ億比寿店店内イメージ www.roundtable-tky.com

レイアウトやフォントサイズなど複雑ですが、いい感じに読み取ってます。

印刷物その2

元画像

f:id:mikeda:20161019085909p:plain:w400

読み取ったテキスト

明るく楽しく元気な職場です腕に覚えのあるあなたも
未経験の方も大切なのはヤル気です!まずは2を!
時 給| 1000円~1250円
平日土日10:00~16:0017:30~24:00
勤務時間|その他週5フルタイムまたは
週3日~、1日4時間以上勤務OK!
職種|接客·調理,調理補助
交通費|交通費支給
勤務地|当店(ちょもらんま酒煬恵比寿東口店)
その他|制服貸与·まかない有●昇給有 社員登用有
社員同時募集
詳しくは
お電話で
ちょもらんま酒場恵比寿東口店
雷話:03-6459-3968
担当迄
ら1か

筆文字っぽいフォントもけっこうちゃんと読めてますね。

手書きその1

元画像

f:id:mikeda:20161019085925p:plain:w400

読み取ったテキスト

4さん募集!!
月~土曜日
時給900円以上
食事&交通費付き
時間·曜日応相談
昔ながらの町のお麦蕎屋さんです。
平日のランチ9(ムに、日数多く働ける方.
大觀迎!!
広尾丸屋 です担当金田

手書きでもこのぐらいはっきりとした文字だとかなりの制度で読み込めます。

でも斜めに書かれた部分はちょっとつらいですね。

手書きその2

元画像

f:id:mikeda:20161019085934p:plain:w400

読み取ったテキスト

剋募.
昼, Q/ooo~ ( ~日瞬)
/0 :30^. 4 : 3010
夜、G) /_coo~ (月哪~日㈱
«h氛为ジ湘谈下さい
ˋ洗V't, ® /ro~ <义剔日曜)
/ 1:30N 《4:30
訓꿸補助@H70~ ("X蜘889)
吹透彪妗, a)服あ')
●勤移畸1히 (zhN)
㍼ .眑ぢー47湘娑1:0)29
47湘炙にの
日

ここまで崩した字体だとぜんぜんだめです。。。

まとめ

求人チラシ画像からのテキスト取り込みにGoogle Cloud Vision APIを試してみました。

手書きはなかなか厳しいですが、一般的なフォントを使った印刷物であればそこそこの精度で読み取れそうでした。

ただ今回のサンプルはかなりハッキリとした画像を中心に選んでしまっていて、
実際はもっとごチャットした特殊なレイアウトもいっぱいだし、
撮影した角度など写真の状態も様々だしでそこまでちゃんと読み取れないものが多く、
そのままこのテキストからなんらかのデータを抽出するのはけっこう厳しいなという印象でした。

なので実際は人力なりで、求人チラシとして自然な内容に補正する必要がありそうで、
そうすると最初から人力のでもいいかなぁ。。。

cap deployでcurrentが変わったのを作業者に通知する

capistranoでアプリをデプロイすると、

各サーバ上のタイムスタンプ名ディレクトリに新しいコードが配置され、

$ cd /var/www/joblist
$ ls releases/
20161016103403
20161016104310
20161016215218 
20161016231246 
20161016231528

currentディレクトリのシンボリックリンクをそこに向けることでコードの切り替えが行われます。

$ ls -l
lrwxrwxrwx 1 rista rista    40 Oct 17 08:15 current -> 
  /var/www/joblist/releases/20161016231528
...

で、サーバにログインしてcurrentで作業している時に誰か(たいてい自分)がデプロイすると、
currentが切り替わったのに気づかずそのまま作業しちゃって、

  • rails consoleで作業してるんだがなんか挙動がおかしいな。。。
  • デバッグコード仕込んだのになんもログが出ねぇ。。。

みたいなことになり、
しばらくしてあー、そうだった。。。とcurrentが変わったんだ。。。
と気づいてcurrent入り直したりしてます。

$ cd ..
$ cd current

いやー、これ辛いわー、とか思ってるの自分だけですかね。。。

まぁというわけで、

試しにwallで通知するようにしてみました

deploy.rbにこんなコードを追加します。

task :notify_current_changed do
  on roles(:all) do
    execute :wall, 'currentが変わったので注意してね!'
  end
end

namespace :deploy do
  after :published, :notify_current_changed

デプロイすると、

$ bundle exec cap staging deploy

作業中のターミナルで通知が出る!

f:id:mikeda:20161017085214p:plain:w500

まとめ

というわけでcap deployでcurrentが変わったことになかなか気づかなくて辛いのでwallコマンドで通知するようにしてみました。

でもrails consoleとかエディタ開いてるとこに出てくるとハンパなくウザいので、すぐやめそう。。。

ブログを作り直しました( はてブが無くなりました(´・ω・`) )

ブログを作り直して、頑張って集めた80はてブがぶっ飛んだぞヒャッホーイ

経緯

この会社ブログは『はてなブログ』なんですが、
会社アカウント(rista-inc)で作って自分(mikeda)をメンバーにするつもりが、
間違えて自分のアカウントで会社ブログを作っていました。

ブログのプロフィールが自分になっていた。。。

f:id:mikeda:20161011083202p:plain

なんとかならないかなとサポートに問合せて見たところ、独自ドメインなら移行は可能だが『はてブ』は引き継げない旨、手順付きで非常に丁寧な返事をいただきました。

異なるはてなID間で作成されたはてなブログにつきまして、 ご連絡いただきました、はてなID「mikeda」で作成したはてなブログを、はてなID「rista-inc」へと移行することはできません。

しかしながら、独自ドメインをご利用いただいている場合には、はてなID「rista-inc」で新しく作成したはてなブログに対して、 独自ドメイン(blog.rista.jp)を設定しなおしていただくことで、blog.rista.jpというドメインでのご利用を、 新たにはてなID「rista-inc」で行っていただくことは可能です。

ただし上記のように独自ドメインを移す場合、下記のような影響がございますので、 こちらをご確認いただきご了承いただきました上で、ご自身にて作業を行っていただけますようお願いいたします。

はてなブックマークの影響につきまして> 現在、独自ドメイン「blog.rista.jp」を「rista.hatenablog.com」でご利用いただいておりますが、 こちらの独自ドメインを、移行するにあたり、ドメインの設定を解除していただく必要がございます。 ※はてなブログのURLは、一度削除したURLを再度利用したり、すでに利用済みとなっているものを利用することはできませんのでご注意ください。

その際、独自ドメイン「blog.rista.jp」の設定を解除した段階で、URLは 「rista.hatenablog.com」へと置き換わり、以下のように、はてなブックマークが行われているURLも、

http://b.hatena.ne.jp/entry/blog.rista.jp/entry/2016/10/04/092653

上記のURLから

http://b.hatena.ne.jp/entry/rista.hatenablog.com/entry/2016/10/04/092653

上記のURLへと置き換わり、はてなブックマークや、はてなスター独自ドメインではなく「rista.hatenablog.com」の方へと紐づくようなかたちとなり、 はてなブックマークはてなスターを移行先のブログへと引き継ぐことはできませんのでご了承ください。

<エクスポート、インポート機能をご利用いただいた場合のはてなフォトライフへとアップロードした写真の取り扱いについて>

はてなブログ移行の際に、エクスポート・インポート機能をご利用いただいた場合、 エクスポートされたデータは、も元々のはてなブログ「rista.hatenablog.com」を作成しているはてなID「mikeda」のフォトライフにアップロードされた写真がそのまま移行されます。 写真のアップロード先も、移行先のはてなID「rista-inc」に統一されたい場合には、お手数ですがご自身にてはてなID「rista-inc」のフォトライフへとアップロードし直していただく必要がございますので、ご了承ください。

簡単な移行手順としては下記をご参考にしていただけましたら幸いです。

  1. はてなID「rista-inc」で今後利用するはてなブログを新しく作成する
  2. 現在ご利用のblog.rista.jpでデータをエクスポートし、(1)で作成したはてなブログにインポートをする、もしくは手動で記事を移す ※フォトライフにアップロードしている写真に修正が必要な場合には、任意で修正をお願いいたします。
  3. blog.rista.jpのドメイン設定を外し(外している間はblog.rista.jp以下のアクセスができなくなる場合がございます)、(1)で作成したはてなブログドメインblog.rista.jpを設定する

というわけでブログ作り直しました。

以前のブログは別ドメインになっていて、はてブはこっちに持ってかれてます。

http://rista.hatenablog.com/

Facebookのシェア数はURLベースなのでこっちに引き継げてます。

あと過去記事のAuthorがmikedaではなく全部rista-incになってしまいました。
エクスポートしたファイルにはちゃんとAuthor入ってるんですが、インポートした時点でブログ作成アカウントになってしまうっぽい(インポートの実行自体がブログ作成アカウントでしか出来ない)。

まとめ

はてなブログで会社ブログ作るとき、オーナーアカウントは後で変更出来ないので注意しましょう(´・ω・`)