社内ハッカソンを通してライティング部の業務効率化に挑戦しました

こんにちは。エンジニアの濱田（ @hamakou108 ）です。

前回の記事に引き続き、社内ハッカソンの模様をレポートしたいと思います。

tech.macloud.jp

社内ハッカソンの概要については前回の記事の説明を引用します。

• 目的は、「エンジニアが他のチームの業務を理解すること & 他のチームがエンジニアの仕事を理解すること」
• テーマは「チームの業務効率化」
• 10:00~17:00でヒアリングと実装を行う
• 各チーム5分で発表

ライティングチームについて

今回のハッカソンではライティングチームとして、ライティング部のメンバーと共に業務効率化を図るための作品を制作しました。 ライティング部では弊社サービスM&Aクラウドに買収・出資を行いたい企業様の募集掲載ページを作成するため、取材やライティング、募集公開に向けたスケジュール管理などを行っています。

macloud.jp

チーム名は横浜エクセレント。偶然にもチームメンバーの名字の頭文字をすべて含む住所を開始5分で発見し、その住所付近にあるエクセレントなビル名を拝借しました。

チームメンバーの頭文字から横浜エクセレントと命名

ハッカソン当日の流れ

課題の洗い出し

まず最初にライティング部の業務フローを教えていただき、それぞれのフェーズで抱えている課題の洗い出しを行いました。

業務フローの各フェーズに紐づく課題

図中で丸で囲まれた箇所が作業のフェーズを表しており、矢印に従って次のフェーズへと進んでいきます。 実際には担当者の移り変わりなどを考慮したより細かいフェーズが存在するのですが、課題の洗い出しに注力するため単純化しています。

この時間では各フェーズについて一つ一つ議論し、時間が掛かる作業、合理的でない作業、ミスが発生しやすい作業などをマインドマップのようにメモしていきました。 一通り課題が出揃ってから全体を俯瞰し、どのペインが大きいかライティング部のメンバーは意見を出し、自分はエンジニアの立場で制限時間内でどのような解決手段が取れそうか意見を出し、協力しながらフォーカスする課題を絞っていきました。

最終的に対象となったのは一番目のフェーズ「取材日程調整」に関わる課題です。

何を制作するか決める

取材日程調整における課題には以下のようなものがありました。

• 取材関係者のスケジュールが変わりやすいため、日程調整がしづらい
• スケジュール調整を目検で行っているため、工数が掛かる
• 上記などが要因で日程調整が長引きやすいため、掲載までのスピードが落ちたり、掲載に至らなかったりする

課題を分析していくことで細かい問題点が募集掲載数という重要な KPI に影響を与えている可能性があるということが見えてきました。 これらの課題を解決できる以下のような特徴を備えた日程調整システムを作ることを今回のハッカソンでは目標としました。

• 取材関係者のスケジュールを一括管理すること
• 日程の調整を効率よくスピーディーに行うこと

制作

大きな目標を掲げたものの、このような日程調整システムを一日でスクラッチで開発するのは目に見えて困難です。 そこで今回はスケコンというサービスをベースにして、弊社のライティング業務にフィットしない部分や不足している部分を Zapier というサービスで調整・補完する方針で制作を進めました。

schecon.com

zapier.com

スケコンでは Google Calender と連携して自動的に参加者の空き時間に合わせて候補日程を決定することができます。

また Zapier は複数のサービス連携を GUI から簡単に行うことができるいわゆる iPaaS です。 スケコン経由で Google Calender に予定が追加されると、それをトリガーにして日程調整の後続作業の一部を自動的に行う Zap （ Zapier 上の一連の自動化タスクの通称）を作成しました。

1. 日程が確定したことを部内の関係者に通知する必要がある。 -> Slack のライティング部のチャンネルに日程および Google Calender の予定の URL を載せたメッセージを自動送信！
2. 先方に確定した日程および取材にあたっての注意点などをメールで知らせる必要がある。 -> Gmail 上で日程や注意事項が記された下書きメール ¹ を自動作成！
3. 取材先企業様との契約の進捗管理表を更新する必要がある。 -> Google Sheet の契約管理表の取材先企業の列を探して自動更新！

Zapier は他にも様々なサービスと連携が可能で、例えば契約管理が Salesforce に移行した場合に連携先を Salesforce に変更するといったことも簡単にできるので非常に便利です。

結果とその後

残念ながら最優秀賞を勝ち取ることはできませんでした。 しかし作成した Zap について他の部署から真似してみたいという声が上がるなど評価していただける点もあり、有意義な成果物になったと思います。

また課題の洗い出しの際に挙がったもののハッカソンでは解決できなかった項目の一部は Issue としてまとめられ、後々の開発で実装されました。 ハッカソンの目的の一つ「エンジニアが他のチームの業務を理解すること」をより進んだレベルで達成できたように感じています。

ハッカソンのような普段あまりプロダクトチームに届かない声を拾う機会が事業の成長の芽になりうるのだなということを実感しました。 引き続き One Team のバリューに沿って全社一丸となって成長していきたいと思います！

---

1. 取引先企業様に合わせて文面を微調整する可能性があるため、送信は行わずに下書きの作成のみに留めています。↩

社内ハッカソンを通じてコーポレート部の業務効率化に挑戦しました

こんにちは、M&Aクラウドの津崎です。

今回は、前回の記事に引き続き、社内ハッカソンについての記事を書いていきます。

tech.macloud.jp

社内ハッカソンがどんな風に行われたかについての詳細は、前回の記事をご参照ください。

ハッカソンの内容をざっくり説明すると以下のような内容です。

• 目的は、「エンジニアが他のチームの業務を理解すること & 他のチームがエンジニアの仕事を理解すること」
• テーマは「チームの業務効率化」
• 10:00~17:00でヒアリングと実装を行う
• 各チーム5分で発表

私は、コーポレートチームにエンジニアとして参加しました。 今回はコーポレートチームがどのような活動をしたのかについて書いていきます。

チーム概要

コーポレートチームは、コーポレート部2名 + 社外取締役1名 + エンジニア（私）の4名です。 コーポレート部は、経理・労務・総務などの業務を行う部門です。 コーポレート部2名のうち1名はM&Aのアドバイザーや上場準備などとの兼務のため、コーポレート部は実質1人で成り立っています。

ヒヤリング

コーポレート部の状況

　 最近は社員数が一年で倍以上になっており、入社手続きや給与の処理など業務は増えていく一方で、コーポレート部の負担が増加していました。 これからも社員数が増加することを考えると、コーポレート部の業務効率化は重要なミッションです。 ヒヤリングをしたところ、真っ先に出てきたのが、契約書の管理 についてでした。

これまでの契約書の管理

コーポレート部で日常的に取扱う契約書は、プラットフォームへの掲載をする企業様と弊社との契約書です。 以下のような問題がありました。

• SalesforceとSpreadSheetの2重管理
• 契約締結からファイリング・保管までの細かな作業が多い
• 多部署から口頭で契約状態や契約の内容の問い合わせを受ける
  • SalesforceもSpreadSheetも必要な人が必要な情報を気軽に見られるように整備されていなかった

効率化の試み

話し合いの結果、以下のような仕組みの開発を行えばかなりの効率化が計れることがわかりました。

コーポレート部が契約書PDFをSalesforceにアップロード
　　⬇️
文章中の重要事項（契約の種類や締結日、金額など）を自動で抽出
　　⬇️
Salesforce上に自動入力

この仕組みができれば、

• 契約書ファイルを開いてて入力する時間の削減
• 多部署のメンバーはSalesforceですぐに契約状態を確認できるため、問い合わせ対応の時間削減

を実現できます。

試算では、年間720分(12時間) の時間を削減できることがわかりました。 これは、現状の契約数をベースに算出したもので、弊社がグロースすれば、その恩恵は積み上がっていきます。 2年後に現在のクロージング数の4倍まで成長すると仮定すると 年272時間 もの時間を削減できる見通しです。

そんな感じで、やることは決まりました。

実装

エンジニアがまず最初にすべきことは、やりたいことが実現可能か判断することです。

• 技術的に実現可能か？
• 与えられた時間・リソースで開発可能か？
• 実現できないリスクはどの程度あるか？

今回はSalesforce上の機能の開発が必要そうですので、おそらくはApexという未知の言語での開発になることは予想していました。

私「ApexはJavaみたいって聞いたことあるしJavaは何となくわかる」
私「Javaならライブラリもいっぱいある」
私「やれるかどうかわからないけど、とりあえずやってみよう」

ということで、「実現可能かをいつまでに判断するか？」「実現できなかったらどうするか？」など考えずにヌルッと技術調査を開始しました。

私「ApexってJavaっぽいけど結構ちがう 全然ワカラナイ」
私「ApexからSalesforceにアップロードしたファイルにアクセスするにはどのAPIを使えばいいの？全然情報が見つからない」
私「ApexってJavaみたいにいろんな便利なライブラリ使えいないの？ PDFを文字列に変換するにはバイナリにして自前でガチャガチャしなきゃいけないの？ 」

こんな具合で、限られた時間で落とし所を見つけるのすら難しそうなくらい実現が厳しそうだとわかりました。

私「えっもうこんな時間！ 今から作る内容変えるの無理だ・・・」

作業にのめり込みすぎて実現不能だと判断するのに時間がかかりすぎたため、作る内容を変える時間は残されていませんでした。 最初から未知の技術を選ぶのがミスってるし、「できないかもしれない」と思った時に、作業に没頭するのではなく手を止めて、「できません」というべきだったなと反省しています。

プレゼン

契約書の管理方法を変えて業務効率化を行うというアイデアと、業務時間が多く削減されるという点から社内からの反応はいい感じでした。 また、実装はうまくいきませんでしたが、なぜうまくいかなかったかを素直に話したら結構盛り上がりました。

まとめ

コーポレートチームの開発はうまく着地できませんでしたし、エンジニアとしてもっとうまくやれた点もあって反省している部分もあります。 ハッカソンは失敗せず限られた時間でいいものを作れるのが理想ですが、失敗しても大丈夫なところに魅力があるなと感じました。

他のチームでのハッカソンの様子については、また次回あたりで紹介されると思いますので、お楽しみに！

社内ハッカソンを通して営業チーム業務効率化を試みました

こんにちは。M&Aクラウドの鈴木（@yamotuki）です。

先日、第1回となる社内ハッカソンを行いました。 私は営業チームに入り込んで業務改善を試みたので、その記録をここに残します。他のチームにおけるハッカソンの成果については後続のブログで紹介されるかと思います。

こちらの写真はハッカソンにおける発表風景です。

ハッカソン発表風景

M&Aクラウドにおけるハッカソン

目的は、エンジニアが他のチームの業務を理解すること & 他のチームがエンジニアの仕事を理解すること。
初回のテーマは「チームの業務効率化」でした。
10:00~17:00でヒアリングと実装を行います。

以下のようなルールの下で行いました。

* それぞれのチームで日頃の業務から課題を抽出してください
* 発表時間は1チーム5分です。発表では資料に加え、必ず何らかの動くデモを発表してください。
* プログラムを書くことを必須にはしません
* 最優秀賞は皆さんの投票を一番集めたチームとします
* 評価基準は以下です
  * 勝つべくして勝つ - インパクトが大きいアイディアか？
  * 全員UX - チームメンバーが使いやすいかどうか？
  * One Team - 全員で協力して作ったか？

弊社には以下のような部署があるのですが、エンジニアがそれぞれの部署に入り込んで業務改善を目指しました。

• 営業チーム
• CSチーム
• FAチーム
• ライティングチーム
• コーポレートチーム
• 社長室チーム（このチームだけデザイナの長竹さんが担当し、プロダクトの案とXDでのモックと動画作成がされました）

事前準備

エンジニアの中で使えそうなツールと効率化についての意識合わせを行いました。

意識合わせについての資料

qiita.com

便利ツールについて

以下はチーム内で話した内容のメモです。裏を取っていないものも多いため、正確性には欠けるかもしれません。

• Zapier
  • Slack とか G Suite などAPI提供しているツールを連携させるツール
  • エンジニアの濱田さん「github issue -> asana のタスク追加 をやったことがある」
  • だいたいIFTTTと同じ。Enterprise系のツールへの連携が強い。連携先が多い。IFTTTはtoC向け。
  • お値段: 月100実行まで無料。750タスクで2000円。 2000タスク/5000円。１タスク1.5~3円くらい
• UiPath
  • RPA（robotic process automation）のツール。定番らしい
  • 画面上で入力して、クリックして、みたいなのを自動化できる。E2Eテストに近いイメージ
  • ブラウザだけじゃなくて画面のどこでも自動化できる
  • 画像をみて、画像の種類によって分岐させて次のタスクを実行
  • テキストでの分岐もできるっぽい？
  • お値段：不明。Trialがある。
• studio
  • コーディングがいらないLP作成ツール
  • 動的なものは難しいかも？メルカリは作れない可能性が高い。
  • 普通にプロダクト部の業務改善に使えそう
• FormRun
  • お問い合わせフォームが簡単に作れる
  • iframe で問い合わせフォームを組み込む
  • 問い合わせをこれで一元管理すればダッシュボードでまとめらていいかもしれない
  • studioで作ったLPにとりあえず組み込むとか、ありかもしれない
• Bubble
  • Webアプリが作れる。ガチ目なNoCodeツール
  • アイデア：営業専用アプリ、FA専用アプリなんかを作って日々の作業を隙間時間に気軽にできるようできるとか？
• Glide
  • https://note.com/a_n_do/n/n7b569c62770c
  • GoogleスプレッドシートをDBに使い、今流行りのPWAが制作出来るツール。用意されたテンプレートを使うだけで、簡単にWebアプリが制作出来るらしい。
  • 料金： 500行のデータは無料。25000行/2000円。会社で使うなら$8/人 で無制限
  • データ集めて一覧を綺麗に出す用途で良さそう

特に Zapier はすぐに使えそうだったのでその場でみんなで使ってみて、結構いい感じに動いたので後述するハッカソン本番でも活躍しました。
また、Glide についても、エンジニアの津崎さんが弊社サイトの管理ツールについている機能の一部機能の移植を試し、盛り上がりを見せました。

営業チームにおけるハッカソン

チーム概要

営業チームはインサイドセールスチームとフィールドセールスチームに分かれ、合計6人（当日は人数バランス調整のため5人）のチームです。 ざっくり言うと、前者は営業のアポを獲得するチーム、後者は実際に営業かけたりルート営業をやるチームになります。

エンジニア視点でいうと、インサイドセールスチームはテレアポを中心に繰り返しのタスクが多いため、エンジニアの力で改善の余地が多いのではないか、と感じました。
フィールドセールスは客先に伺って話をするのが中心ではあるので改善の余地は少ないのでは、と感じていましたが、実際に話を聞くと顧客にメールを送付したり日程調整したり、社内連携のためのslack入力など効率化できそうなところがそれなりにありました。

成果物

最終的に発表をした主な成果物としては以下の形になりました。

フィールドセールスの成果物　

1. 社内連携のためにSlackワークフローを適切に使う

• before: 掲載契約が獲得できたときに社内の契約やライティングなど各担当者にやってほしい業務を全てSlackに手動で入力していた
• after: Slackワークフローを使うことで最初にフォームに従って入力したらその連絡が終わるようにした

2. 掲載営業の後に即座に説明資料添付したメールを送付

• before: 掲載営業の後に、移動や次の営業の準備で顧客に説明資料添付したお礼メールを送ることができない。それにより鉄を熱いうちに打てていない。原因は送付先メールアドレスや名前を外出先で手動で転記しなければいけないという思い込みでした
• after: Slack上だけで写真を撮って会社にいるインサイドセールスチームに送信。代わりに送信してもらう。誰がどこの営業に行っているかは明らかなので言語コミュニケーションは不要でした

インサイドセールスの成果物

Zapier を使ってSalesforce と他のツールを連携して手間を減らす。

• before: アポ獲得した時にやること3つ。
  • Googleカレンダーに予定を追加
  • Slack にアポ設定内容を手動で書き込み
  • Slack を見て Salesforce に「商談」を作成
  • アポ先に確認メール

アポ設定数は月間100件単位なので、それぞれのタスクが1分程度でもチリツモでかなりの時間がかかっていました。

• after: 業務ステップを見直してNoCodeツールの Zapier を使う
  • Salesforce に「商談」を追加
  • 買い手商談だけフィルターし、以下の処理が自動で行われる
  • Slack に通知
  • カレンダーに登録
  • Gmail下書きを作成（当日は未実装だったが、他チームの発表も聞いてできることに気がつきました）

担当者が複数にまたがる業務ステップは、案外無駄な処理が隠れているものなのだなあと感じました。

結果

全くコードは書いていないですが、今後も営業チームの中だけでも運用しやすい優しい解決策になったかなと思います。
評価基準として以下のものが挙げられていました（再掲）。

  * 勝つべくして勝つ - インパクトが大きいアイディアか？
  * 全員UX - チームメンバーが使いやすいかどうか？
  * One Team - 全員で協力して作ったか？

営業チームは、このうちOne Teamの「全員で協力して作ったか？」でいうと良い結果になったと思います。

• フィールドセールスチームはSlackワークフローの使い方をエンジニアの私が教えた後は、フィールドセールスチームのメンバーだけで詳細の処理を詰めて完成させてくれました
• インサイドセールスチームは、Zapier 自体は私がいじることが多かったですが、Salesforce のレコードの構造やフィルターなどはチームメンバーによって詳細を詰めてもらいました

成果物のインパクトがやや薄く、他のチームの実装・発表が素晴らしかったこともあり、投票の結果はそこまで良いものではなかったでしたが、私も営業チームも学び多い1日となりました。

その後の話

営業チームでも使用した Zapier ですが、ハッカソンではライティングチームも使用し、さらにCSチームで兼ねてからNoCodeツールの検討をしていたこともあり、晴れて全社導入が決まりました。
今後も One Team のバリューに沿って、エンジニアと他チームが一丸となって会社を大きくしていくと思います。

Nuxt.js化計画vol.3

こんにちは、こんばんは、kubotak（@kubotak_public）です。

前回の記事は以下 tech.macloud.jp

シリーズ第３段
今回は売り手向けマイページトップと売り手向け会員登録ページのNuxt.js化を紹介します。

売り手向けマイページトップ

売り手向けマイページトップは、会社や事業を売却したい、または資金調達をしたいユーザーがM&Aクラウドにログインした場合に遷移するページです。 現在のアクティビティやステータス、次に行うアクションなどがこのページで見ることが出来ます。

今回のリニューアルでは成約までのTODOリストが追加されました。

成約までのTODOリストとは

売却や資金調達の際してどのような事をする必要があり、どんな資料が必要になるかなどをTODOリストにまとめています。 ユーザーはこのTODOリストを参考にして買い手企業との連絡を行い、完了したものはチェックをつけることで進捗を確認することができます。

モーダルから詳細を表示することもできます。

Nuxt.js及びVue.jsを利用することでこのようにインタラクティブなUIも苦労せず構築することが出来ました。

売り手向け会員登録ページ

会員登録ページでは、JavaScriptならではの即時バリデーションによりユーザーのストレスを減らすことを目的にリニューアルしました。

従来の会員登録ページではLaravelによるMPAで作られていたこともあり登録ボタンを押した後にLaravelのFormValidationによって登録画面に戻されて入力不備の項目を表示していました。 この問題として、ユーザーが登録ボタンを押すまで入力不備が分かりづらいという問題と、登録ボタンを押して次へのアクションを行うモチベーションを挫いてしまうことがあります。

この問題を解決するために、弊社ではVue.jsのバリデーションライブラリのVeeValidateを利用してインタラクティブなバリデーションを実装しています。
QiitaにVeeValidate関連の記事も書いていますので興味のある方は参照ください。

qiita.com

qiita.com

VeeValidateを利用し、画面の右下に入力不備のある項目の残数を出すことでユーザーに入力達成率を把握しやすく工夫しています。

input要素一つ一つをコンポーネント化し、Storybookでまとめているので再利用も簡単に行なえますし、デザインの統一性も高まります。

これはemail入力欄のStorybookです。入力不備があれば赤枠になり、不備がなければチェックマークがインタラクティブにつきます。

会員登録ページリニューアル効果

リニューアルは連休前の8/7にリリース致しました。
以降の登録率はリニューアル前と比較し20%ほど改善しています！💪

最後に

M&Aクラウドでは着々とフロントエンドをNuxt.jsに移行しています。
今後もリニューアル・リプレイスしたページを随時紹介していきます。

リリースタグとリリースノート作成の半自動化でリリースサイクルを改善した話

こんにちは。エンジニアの濱田（ @hamakou108 ）です。

近年 DevOps の文脈で開発生産性の指標としてリリース頻度が注目されています。 DevOps Research and Assessment が提供している State of DevOps Report 2019 ではハイパフォーマンスな開発チームに顕著なメトリクスとして、リードタイムや復旧時間などと並びリリース頻度が紹介されています。 またリリース頻度の向上や付随する障害リスクの低下を図るためのプラクティスについて多くの議論が行われています。

• Release Frequency: A Need for Speed - DZone DevOps
• Why it's Vital to Release Software to Production Multiple Times a Day
• State of DevOps Reportより踏み込んだ考察本「Accelerate: The Science Behind Devops: Building and Scaling High Performing Technology Organizations」が面白い - 勘と経験と読経

M&Aクラウドでもリリースを高頻度かつスピーディーに実施するため、リリース作業をできるだけ自動化するように工夫しています。 以前にデプロイの半自動化の事例について鈴木から紹介しましたが、今回はリリースタグおよびリリースノートの作成などのリリース準備作業の半自動化を行った事例について紹介したいと思います。

リリース準備作業で抱えていた課題

M&Aクラウドの開発チームにはリリース準備の作業効率に関わる二つの問題がありました。

手作業に伴うミス

弊社ではブランチ管理の手法として Git Flow を採用しています。 Git Flow は gitflow コマンドを利用することで比較的簡単に実践することができますが、それでも作業時のミスは発生しがちです。 例えばローカルの develop ブランチの内容が古い状態で release ブランチを切ってしまったり、 release と hotfix の作業手順を混同してしまったり、タグ名の形式を誤ったり¹など、数え上げたらキリがありません。。

また初めてリリース作業を行うメンバーの場合、ローカル環境で gitflow のインストールや初期化が済んでいないといった別の問題も発生していました。

このようにリリースの準備作業は全体的に注意が必要な心理的ハードルの高い作業になっていました。

作業時間

リリースブランチの作成、リリースに含まれる PR のリスト化、リリースブランチのマージ、タグ作成までの一連の作業をマニュアルで実施するとそれなりに時間が掛かります。 特にリリースノートの作成に関してはどの PR が含まれているかコミット履歴を辿らなければならず、面倒な作業でした。 これらの作業によってリリース作業の担当者は普段の開発に掛けられる時間が大幅に減ってしまうことも問題でした。

スクリプトによる作業自動化

これらの作業手順はほぼ定型化されていたため、大半の作業をシェルスクリプトで自動化することで課題解決を図りました。 幾つかキーポイントとなる部分をコードスニペットと共に見ていきたいと思います。

事前要件のチェック

function checkRequirements() {
  if [[ ! "$OSTYPE" == "darwin"* ]]; then
    echo "MacOS を利用してください。" >&2; exit 1
  fi

  if ! type git > /dev/null; then
    echo "Git をインストールしてください。" >&2; exit 1
  fi

  if ! brew ls --versions git-flow > /dev/null; then
    echo "Git Flow をインストールしてください。" >&2; exit 1
  fi
}

function checkoutAndPull() {
  git checkout master
  git pull upstream master
  git checkout develop
  git pull upstream develop
  git fetch upstream
}

checkRequirements() では Git や gitflow など必要なツールがインストールされているか確認しています。 見て分かる通り MacOS に限定した実装にしていますが、これは現時点で開発者全員が Mac ユーザーであるためです。 複数の OS に対応した汎用性の高い実装にすることも可能でしたが、直接的に事業価値に貢献するコードではないので少ないコストで実装できる仕様を採用しました。 YAGNI です。

さらに checkoutAndPull() ではリモートリポジトリの pull を行い、ローカルリポジトリの内容が古いまま作業してしまうことを防止しています。

リリースに含まれる PR のタイトルとリンクの抽出

function printPullRequestToBeReleased() {
  local repositoryName
  local prevRelease

  repositoryName=${1}

  read -r -p "${repositoryName} の前回のリリースタグを指定してください: " prevRelease
  echo "${prevRelease}"
  git log "${prevRelease}".. --merges --first-parent --reverse --pretty=format:"* %b %s" | \
    REPO="${repositoryName}" perl -ple 's/Merge.*#(\d*).*$/(https:\/\/github.com\/your-organization-name\/$ENV{REPO}\/pull\/$1)/' | \
    perl -ple 's/\*\s(.*)\(h/\* [$1]\(h/'
  printf "\n\n"
  read -r -p "上記のリストをコピーしておいてください"
}

printPullRequestToBeReleased() では前回のリリースタグ名を指定するとそこから最新のコミットまでに含まれる PR のタイトルと URL をコミット本文から抽出して Markdown のリスト形式で出力します。 出力されたリストをそのまま利用するだけで簡単にリリースノートが作れます。

release ブランチの作成、マージ、タグ作成

function startRelease() {
  local repositoryName
  local currentRelease

  repositoryName=${1}

  read -r -p "${repositoryName} の「今回の」リリースタグを指定してください。空なら今日の日付が使われます: " currentRelease
  if test -z "${currentRelease}"; then
    currentRelease=$(date "+%Y-%m-%d")
  fi
  echo "${currentRelease}"

  git flow release start "${currentRelease}"
  git push upstream "release/${currentRelease}"
}

function finishRelease() {
  local repositoryName
  local releaseBranch

  repositoryName=${1}
  releaseBranch=$(git branch | egrep -o "release\/[0-9]{4}-[0-9]{2}-[0-9]{2}.*")

  if [[ -z "${releaseBranch}" ]]; then
    echo "リリースブランチが存在しません。" >&2; exit 1
  fi

  git checkout "${releaseBranch}"
  git pull upstream "${releaseBranch}"
  git flow release finish "$(echo "${releaseBranch}" | perl -ple 's/release\/(.*)/$1/')"
  git push upstream master
  git push upstream --tags
  git push upstream develop
  git push upstream --delete "${releaseBranch}"
}

startRelease() で release ブランチの作成を行います。 特に指定がなければブランチ名は release/YYYY-MM-DD のような形式で作成され、忘れがちなリモートリポジトリへの push も自動化しています ² 。

また finishRelease() で release ブランチのマージ、タグ作成もスクリプト化しました。

スクリプト導入の結果

スクリプトを作成したことで前述した課題を次のように解決することができました。

• 事前要件を満たせていない場合はスクリプト実行不可とすることで環境依存の問題を防止。
• Git 操作をスクリプト内で完結させることで手順の誤りによるミスを解消。
• リリースノートの作成なども含め、自動化した部分の作業時間は1-2分にまで短縮。

まとめ

リリースタグおよびリリースノートの作成をスクリプトで半自動化することで、環境依存や手作業によるミスを軽減し、作業時間も短縮することができました。 作業効率に加えて DX も向上させることができましたが、まだ幾つかマニュアル作業も残っているので今後もリリースサイクルの効率化を適宜進めていきたいと思います。

---

1. 弊社ではタグ名を特定のフォーマットとした場合に CircleCI のリリース専用ワークフローが実行されるようにしているため、名前を間違えるとタグを切り直さなければならない場合があります。↩

2. ちなみに hotfix のフローに関してもほぼ同様にスクリプト化してあり、リリースフローによって使い分けています。↩

施策の効果測定のためにRedashを導入しました。

こんにちは、M&Aクラウドのかずへいです。

弊社では5月頃から、開発の施策立案と効果測定のためにRedashの導入を進めているので、その活用方法を紹介します。

Redash導入前の課題

そもそも、開発チームとして以下のような課題がありました。

• 開発チームの成果が事業貢献ではなく、リリースした機能の数で評価されがち。
• リリースした機能の貢献が分からない。
• リリースした機能が、開発されっぱなしで、その後ユーザーに受け入れられているかどうか確認するサイクルがなく、その後の細かいチューニングもされたりされなかったりしている。

これらの問題は、

1. 事業上の目標(売上等)が数値ベースでプロダクトの指標(PV、UU、登録数、クリック数)に落とし込めていないこと
2. 指標を継続的に計測する手軽な仕組みがないこと

が原因です。

1が出来るようになるためにも、とりあえず2の計測の仕組みが必要になります。計測の仕組みが整備されてようやく事業の数字とプラットフォーム上の指標がどう連動しているかが見えてくるようになるからです。

このために導入したツールがRedashでした。

Redashとは

RedashはオープンソースのBIツールで、SQLを使って様々なデータソースからデータの取得、整形、可視化ができます。

github.com

Redashの導入

RedashはAWS上で構築しました。 Setting up a Redash Instance こちらからAMIを選択して起動すると設定無しでログインするところまで行けます。

マネージドのRedashについて

redash.io

こちらでRedashを簡単に試すことが出来ます。料金もそれほどではないので、インスタンスのお世話をしない分こちらの方が楽なんじゃないか？と初期はこちらを検討しました。

しかし、少し試してみたところ、

• 外部のサービスをRDSに直接繋がなくてはいけない
• redash.ioのリージョンがアメリカ？にあるので、日本にあるRDSにつなげると地味に遅い

などの問題があったため、自前でインスタンスを設定することにしました。

Redashのログイン周り

RedashにはGoogleログインがあり、弊社では全てのメンバーがGSuiteのアカウントを持っているため、とても簡単にログインの設定をすることが出来ました。また、GSuiteのアカウント自体に多要素認証が設定されています。

また、Redashではデフォルトユーザーの権限が大きいのですが、社員誰でもなんでも見られるというようにはしたくなかったので、デフォルトの設定を変更しています。

詳しくはこちらの記事を御覧ください。

qiita.com

Redashの活用

データへのアクセスは

• 手軽であること
• 即時性があること
• 1箇所にまとまっていること

がとても大事だと実感しています。 Redashでは簡単にこれらを達成することが出来ます。

どんなサービスと連携させているか

弊社ではRedashでいろんなデータソースからデータを取っています。 Redashの便利な機能として複合クエリーという複数のデータソースから取ってきた結果に対して更にクエリーを書くという機能があるのですが、それを活用すればGoogleAnalyticsのデータとMySQLのデータをJoinしてグラフ化するといったことも可能になります。

主に以下のようなデータソースと連携させています。

• RDS(MySQL)
• GoogleAnalytics
• Googleスプレッドシート
• AmazonElasticsearchSearvice(アクセスログをElasticSearchに入れています)
• Salesforce

どんなダッシュボードを作っているか

弊社では

• 定期的に数値を確認するためのダッシュボード
• 施策の結果を見るためのダッシュボード

の2種類に分けて運用しています。

定期的に数値を確認するためのダッシュボードは、目標として置いている数字を追いかけるのに使ったり、サービス上の異常を検知するのに使います。

施策の結果を見るためのダッシュボードは、最上段にどんな施策をいつ実行して、どの指標がどれくらい向上するのを期待するのかというリストがあり、その下に実際の計測指標があります。

施策ダッシュボードの例

リリースした機能を週次で確認し、ユーザーに受け入れられているか、期待した効果が出ているかを確認しています。

どうやって運用しているか

RedashをSlack連携することによって、定時にRedash内の指標をSlackに通知してもらようにしています。

これはGunosyさんのブログを参考にしていて、手軽にSlackで定期的に数字を見るようになります。

data.gunosy.io

社内布教活動について

Redashの導入とともに布教活動を行いました。

• エンジニア向けRedashの使い方
• 非エンジニア向けデータベースの構造とSQLの書き方
• 非エンジニア向けRedashの使い方

エンジニア向けのものはもちろんですが、これを機に非エンジニアにもSQLに触れてもらうことにしました。

導入した結果と今後

Redashの導入により、指標を継続的に計測する手軽な仕組みを手に入れることは達成できたのではないかなと思います。 目標の数値が毎日更新され定期的にSlack通知される事により、メンバーの数値への意識も向上しました。

また、開発メンバー以外にもSQLを書くメンバーが出始めたのはとても良い兆候だと思っています。

これからは、Redashでの可視化をより精緻化するとともに、より事業理解を深めて、事業の目標とサービス上の指標の紐付けを進めて行くことで、事業貢献が見える開発が出来るようにしていきます。

プロダクト開発で重要なことは兎に角ユーザーヒアリングをすること

こんにちは。M&Aクラウドでプロダクトマネージャーをやっている横田です。 先月シリーズBの投資ラウンドで2.2億の資金調達のプレスリリースを終えて従業員も約30人にまで増え、2年前に僕が入社を決めたときにはまだ社員が4名しかいなかったことにとてもなつかしさを憶えています・・・

prtimes.jp

そんな絶好調のM&Aクラウドですが、今日はプロダクト開発においてどんなサービスでも必ず直面する「使ってもらえる機能開発をするためにはどうすれば良いか？」という命題について、「ユーザーヒアリングがとても重要」だという話をします。

特に、今年の2月にリリースをした「クローズドプラン」というM&Aクラウドの新機能ができるまでのプロダクト開発の過程（特にヒアリングについて）をご紹介したいと思います！ macloud.jp

このブログで伝えたいこと

• ユーザーヒアリングを軽視してプロダクト開発をするとひどいことになる笑
• ユーザーヒアリングは「事前準備」と「試行回数」につきる
• オペレーションの構築まで考え抜いた開発を行う

1分で分かる背景

M&Aクラウドは「会社を売りたい起業家が買い手に直接アプローチすることができるプラットフォーム」という新しい体験を売りにしているベンチャー企業です。 「買いたい」という企業（一流・優良企業ばかり）がまるで「リクナビ」のようにM&Aニーズを掲載しているところがポイントなのです。

macloud.jp

しかし、「M&Aニーズを掲載する」というのはいままでの日本の商習慣では存在せず、「顔出しNG」という理由で、M&Aクラウドへの掲載を断られることがとても多いのです。
※とはいえ、徐々に世間の認識を変えられてきているのか、M&Aクラウドの掲載社数は順調に成長しており、2020年6月は過去最高の掲載売上を記録

そこで「買い手が掲載せずともM&Aクラウドのサービスを利用できる機能を開発したら、もっとプロダクトが成長するのではないか」という仮説のもと、このプロジェクトはスタートしました。

クローズドプランの前身である「トライアルプラン」の"失敗"

実はクローズドプランを開発する前に、営業チームの日々の営業活動の報告結果から「顔出しNG」でお断りされるのは体の良い方便で、本当は「もっと気軽にM&Aクラウドのサービスを利用できるようになれば利用社数は増えるのではないか？」という仮説を持っていました。

そこで、「トライアルプラン」という、従来のM&Aニーズを取材してプロのライターが掲載記事を書く方法ではなく、買い手企業が自らM&Aニーズを書き宣材写真等を準備する代わりに、初期費用が無料になるプランを立案して開発をしました。

※料金体系等は当時のものなのでご注意ください。

このプランはWantedlyのように、求人の募集記事を自ら運用するUXがワークしていることをヒントに立案をしました。 しかし、実際に機能をリリースしてみると、申込企業数は月に数件あれば良いところで、かつ実際に利用を表明した企業も、ほとんどが掲載までは至らず、途中の掲載記事作成の時点で歩留まりしてしまいました。
実際に掲載を開始しても、ほとんど売り手企業から売却打診をされず、また無料でスタートしているためかモチベーションがそこまで高くなく、売り手への返信が遅いなど、プラットフォーム全体のUXを損ねる結果ばかりを生み出しました。
トライアルプランは見事に、作ったけど「使ってもらえない機能」でした。

この機能開発での失敗点は以下だと内省しています。
* 課題に対する仮説を正しいと信じ込んでしまい、いわゆるProblem/Solution Fit（プロブレム・ソリューション・フィット）を疎かにしてしまった * 課題に対するソリューションの筋が良くなかった（特にビジネスオペレーションを軽視してしまった）

致命的だったのは、実際に作ったプロダクト（もしくはモックアップやプロトタイプ）を実際にユーザーが使ってくれそうかどうかヒアリングすることなくリリースをしてしまったことです。
Wantedlyは人材サービスであり、M&Aとは異なる性質であるのにも関わらず、「そこまで大きな負担ではないから、これぐらいならやってくれるだろう」とタカをくくってしまったのです。
また、プロダクトとオペレーションの作り込みも甘く、実際に作り始めたユーザーへのサポートも出来ていませんでした。
結果として、「使ってもらえない機能」になることは必然だったのです。

新たに開発をした「クローズドプラン」

トライアルプランの反省を踏まえて、ユーザーにとってのソリューションは、気軽に掲載まで無料でできることではなく、純粋に「顔出しNG」であることが多いのを解決する機能なのではないかとふりだしに戻りました。
そこで、次なる機能開発では、買い手企業が"会社情報を一般公開せずに"売り手企業に直接アプローチすることができる機能が、買い手企業のペインを解決するソリューションであるという仮説を持って取り組みました。
M&Aクラウドのビジネスモデル上、一見従来の「掲載プラン」の持ち味が失われてしまう機能ではあるもの、まずはプラットフォーム自体を使ってもらうことでM&Aクラウドの満足度を上げ、そこからのアップセルで「掲載プラン」を利用してもらおうと考えたのです。

また、同様にプロダクト開発面での反省を活かして、以下を心がけました。

• 仮説の確からしさをきちんと検証するために、ユーザーヒアリングを徹底して行うこと
• プロダクトリリース後のオペレーションとモニタリング基盤を構築すること

ヒアリングの「事前準備」

サービス自体の新規開発を行うときはリーンスタートアップに倣いユーザーヒアリングを当然のように行うと思いますが、新規機能の開発（しかも規模の小さいスタートアップ）ではユーザーヒアリングを簡易に済ましてしまうことは多いのではないでしょうか。

クローズドプランは、買い手企業が"会社情報を一般公開せずに"売り手企業に直接アプローチすることができる機能です。
実は、クローズドプランのような買い手企業が匿名の売手企情報（業界用語でノンネームと呼ばれる）を見てスカウトをするというサービスは、すでに競合他社で前例があったのですが、トライアルプランと同じ轍を踏まないよう、M&Aクラウドだからこそ「使ってもらえる」機能を開発できるようにヒアリングに精一杯取り組みました。

「M&Aクラウドのクローズドプラン」のペルソナは誰で、どういうペインを抱えているのか、その課題を解決できるようなソリューションは何で、考えているもので本当に合っているのかを明確にする必要がありました。

まず、ペルソナ像を3パターン作り、そのペルソナのすべてのパターンにヒアリングができるように営業チームと協力してヒアリングを行いました。

さらには、毎回ヒアリングをする買い手企業を事前に調査して、企業毎に質問を変えて（ヒアリング対象企業の業種、インタビュイーの役職等を考慮）ヒアリングに臨みました。

＜参考＞ユーザーヒアリングシートのFMT

docs.google.com

ユーザーヒアリングの「試行回数」にこだわる

結果としてですが、クローズドプランの機能開発では、以下の企業数に1ヶ月間かけて徹底的にヒアリングをしました。

• 買い手企業15社
• 売り手企業6社

合計20社程度にヒアリングをしたことで、ヒアリング前に立てたペルソナやソリューションに自身が持てるようになりました。
よく、「ヒアリングは最低6社程度したほうが良い」と書籍等では書かれていますが、6社で止めていたら、アウトプットの質は変わっていたかもしれません。
また、人気の案件にスカウトを送ることができる「オプション機能」は他社にはないM&Aクラウド独自の機能であり、これはヒアリング結果からアイデアを得ることができました。

オペレーションの構築

トライアルプラン時にはとりあえず作ってしまった機能も、クローズドプランではしっかりとオペレーションを組んで、「何をどこまでやるか」ということを明確にして取り組みました。

各部関係者を巻き込んでオペレーションを構築し、事前に念入りに擦り合わせをした上でリリースを迎えることが出来ました。

＜参考＞オペレーションの整理

クローズドプランの成果

結果として、クローズドプランはトライアルプランの20倍以上の利用社数を記録しており、毎月一定以上の安定した利用率で推移しています。
また、ヒアリングを基に開発した「オプション機能」も安定して申込がされており、アップセルや従来の「掲載プラン」へのアップグレードへのおためし機能として活躍し始めています。

最後に

このブログで記載した通り、機能開発時のユーザーヒアリングは非常に重要です。
そもそもすでに出来ているスタートアップ企業が大半だと思うので、当然のことを記載しただけのように見えると思いますが、今回は非常にわかりやすく「使ってもらえない」機能の開発→「使ってもらえる」機能への昇華を行えた貴重な体験だったので、共有をさせてもらいました。
引き続き、よいプロダクト開発をしていきます！

うっかりミスを防ぐPull-Requestテンプレート

こんにちは、M&Aクラウドの津崎です。

今日は、プロダクトチームで使っているGitHubのPull-Request(以下PR)テンプレートについて紹介したいと思います。

プロダクトチームでは、「ミスは個人の問題ではなくチームの問題」と取られ、 ミスした個人を責めるのではなく、「同じミスが起こらないようにするにはどうすればいいか？ 」と考える文化が根付いています。

そのため、「気をつける」「教育する」「ミスしないように周知する」といった精神論ではなく、 そもそもミスしない仕組みを作り、ブラッシュアップすることを日常的に行っています。

プロダクトチームでは、2週間のスプリントの終わりにスプリントの振り返りを行う会を開いています。 スプリントの振り返り会では、KPT（Keep Problem Try）を議論する時間があり、 Tryの一環としてGitHubのPRテンプレートの更新を行ってきました。

今回は、我々が運用しているPRテンプレートについて公開し、 どんな風に使っているか紹介します。

pr_template

PRテンプレートの解説

📝確認すべき項目

レビュアとPMがわかるように「どのURLの」「どのパーツが」「どうあるべきか」 を書く  
例: `/mypage/applications` の絞り込みパネルでステータスで絞り込みができること）

必要に応じてスクショも貼っておく。

この項目は、PRのレビューするひとがPRを動作ベースで確認するときに必要な情報を書きます。 この情報を埋めることで余計な情報交換を減らし、スムーズにレビューできるように心がけています。

🛠️リリース時作業

あれば
- PRタイトルに `[作業有]` をつける
- 手順をここに書く。2行以上あるならesaに書いてリンクを貼る

この項目は、リリース時に手動での作業が必要な場合について記載します。

リリースはCIにより半自動化していますが、DBの値を書き換えたり、環境変数を変更するなどの作業がリリース前後に必要な場合があります。 そういった場合は、ここに詳細を記載し、PRのタイトルにも[作業有]という文字列を追加します。

PRを作った人とリリースする人が別になることもよくあるので、 「誰でもリリースできる」「抜け漏れを起こさない」ためにこの項目を作りました。

😎ユーザーに伝えること

機能の使い方が変わった場合や新機能など、新しい使い方の説明を書きましょう。

これはプロダクトオーナーからの要望で追加しました。

弊社のプロダクトは、カスタマーサクセスチームや営業チームも仕様を理解している必要があります。 うっかり伝え漏れがあると、「いつの間にか使い方が変わってる」「お客さんに間違ったことを教えてしまった」といった問題が起こってしまいますので、 漏れのないようこちらに記載するようにしています。

✅PR前のチェック項目

- [ ] PRのタイトルの先頭に必要に応じて`[プロジェクト名]`または`[影響無し]`を付けた

PRのタイトルを工夫することで、PRの詳細を開かなくても必要な情報がわかるようにしています。

[影響無し]がついたPRは、リリース時にユーザー影響がないPRを意味しています。 通常はリリース前にプロダクトマネージャを含めた動作チェックを行っていますが、[影響無し]なPRは簡易的な確認だけでスピーディにリリースできます。

- [ ] PRのタイトルに「どのツールの」「なんの機能が」「どうなるか」が分かるように書いた

こちらもPRのタイトルについてのリマインドです。

プログラミングもそうですが、名前はとても重要です。 適切な名前であれば、わざわざPRの詳細を確認する必要がなく、プロダクトマネージャやリリース担当の負担を軽減できます。

- [ ] PMへの事前仕様確認 or 仕様はもう明確になっている

プロダクトマネージャと仕様のすり合わせが終わってるかの確認を促しています。

プロダクトマネージャと仕様の認識がずれていていると、リリース前の開発環境での動作確認のタイミングで仕様変更が発生し、 リリースが伸びたり、HotFixで追加のリリースが必要だったりと、手間が増えてしまいます。 そういった問題を軽減するためにPR作成の段階で、その仕様で大丈夫か？と確認するようにしています。

- [ ] テストを書いた or すでにある or 不要なほど軽微な修正

テストちゃんと書いてねという確認です。

- [ ] 動作検証した

動作確認は大事です。

開発中はもちろん全員動作確認はしているはずですが、 PRを投げる直前にゴミが混入してしまったり、リファクタでぶっ壊れたりしてる可能性もあります。

レビュワーに「動かない」と報告されるケースが何度かあったので、テンプレートに追加しました。

- [ ] ユーザ影響度: 高ならラベルをつける or 無し
  - `高`の定義: 注意深いレビューが必要（コードの仕様理解と動作確認）。サイト外に影響して取り返しのつかないもの（メール送信など）や、ユーザ行動に影響する部分（登録フォームや打診フォームなど）の改修。

ユーザー影響度についてラベルをつけようという確認です。

ユーザー影響度:高のPRはレビューと動作確認で入念なチェックを行うようにしています。

🌐インフラ影響がある場合（不要な場合は削除）

- [ ] PRのタイトルに`[インフラ]`を付けた
- [ ] 作業者は影響範囲を可能な限り説明できる
- [ ] 確認会・共有会（15~30min）をスケジュールに設定する

インフラ系の変更を行うPR向けの確認事項です。

インフラ系の変更は、予想外の影響が起こることが今までに多々ありました。 そこで、同じ問題を起こさないために、私達のチームでは出来るだけ「確認会」を実施しようと決めています。

(関連: workerインスタンスを追加したら障害が発生した話 https://tech.macloud.jp/entry/advent_calendar_2019_12_17 )

📊効果測定

機能の効果を測定できるRe:dashのURLを貼ってください。

Re:Dashはプロダクトの分析ツールです。 ここには、リリース後にプロダクトにどういった影響が出たかわかるようなRe:Dashのページを作成して追加します。

プロダクトチームでは6月から OODAループに基づく開発を行うことにしています。 そのため、プロダクトの新機能開発や機能改善を行うときは、その効果が現れたのかどうか効果を測定できるように、分析ページの作成も同時に行っています。

ℹ️issue

close: #

関連するIssue番号を入力できるようにしています。 close: #123と書けば、PRがマージされた時に#123も同時にCloseしてくれます。

以前、よくIssueの閉じ忘れがあったのですが、このテンプレートを追加してから閉じ忘れることは減ったように思います。

まとめ

今回は、うっかりミスを防ぐ方法として、PRのテンプレートについて紹介しました。 プロダクトチームでは、他にも「CircleCIを使ったリリースの自動化」や、「リリースのためのリリースタグ作成作業の自動化」、「リリース時の作業内容のテンプレート化」など、ミスを起こさない仕組みを随時取り入れていいます。

私達のPRテンプレートはかなり「ごった煮」な具合になっていますが、組織の数だけPRテンプレートはあってもいいと思います。 プロダクトの性質やチーム、文化に合わせて、自分達にぴったり合うPRテンプレートに熟成させていけたらと思います。

以上、参考になりましたら幸いです。

付録（PRテンプレートファイル）

Pull-Rquestテンプレートファイルはプロジェクトディレクトリに特定のパスで格納してあります。 .github/PULL_REQUEST_TEMPLATE.md 詳しくはこちらをご覧ください。

help.github.com

### 📝確認すべき項目
レビュアとPMがわかるように「どのURLの」「どのパーツが」「どうあるべきか」 を書く  
例: `/mypage/applications` の絞り込みパネルでステータスで絞り込みができること）

必要に応じてスクショも貼っておく。


### 🛠️リリース時作業
あれば
- PRタイトルに `[作業有]` をつける
- 手順をここに書く。2行以上あるならesaに書いてリンクを貼る

### 😎ユーザーに伝えること(CX等社内向けも含む)
機能の使い方が変わった場合や新機能など、新しい使い方の説明を書きましょう。

### ✅PR前のチェック項目
- [ ] PRのタイトルの先頭に必要に応じて`[プロジェクト名]`または`[影響無し]`を付けた
- [ ] PRのタイトルに「どのツールの」「なんの機能が」「どうなるか」が分かるように書いた
- [ ] PMへの事前仕様確認 or 仕様はもう明確になっている
- [ ] テストを書いた or すでにある or 不要なほど軽微な修正
- [ ] 動作検証した
- [ ] ユーザ影響度: 高ならラベルをつける or 無し
  - `高`の定義: 注意深いレビューが必要（コードの仕様理解と動作確認）。サイト外に影響して取り返しのつかないもの（メール送信など）や、ユーザ行動に影響する部分（登録フォームや打診フォームなど）の改修。

### 🌐インフラ影響がある場合（不要な場合は削除）
- [ ] PRのタイトルに`[インフラ]`を付けた
- [ ] 作業者は影響範囲を可能な限り説明できる
- [ ] 確認会・共有会（15~30min）をスケジュールに設定する

### 📊効果測定
機能の効果を測定できるRe:dashのURLを貼ってください。

### ℹ️issue
close: #

TOPページリニューアルのデザイン裏話

こんにちは。M&Aクラウド Webデザイナーの長竹です🐤
入社してから約1年立ちました！

note.com

ここ数ヶ月では、M&Aクラウドの主要ページのリニューアルを進めてきました。 その振り返りも含めて、学んだことや意識的に行った事をまとめたいと思います。 今回はTOPページのリニューアルについて振り返ります。

リリースまでのフロー

始めてみると、必要なタスクは膨大にありました。 他部署に協力してもらったり、多くのユーザー様にご協力頂き、少しづつ進めていきました。

トップページの課題

旧TOPページ

• 「M&Aクラウド」というサービスを印象付けるものが無い
• 資金調達もできることが伝えられていない
• 新しいサービスなのに、その説明や魅力を伝えられていない

サービスの成長に伴い、主に上記3つが課題として存在していました。 これらを解決するために今回リニューアルを進めていきました。

UXリサーチ

様々なデータや、今まで貰っていたユーザーの生の声、普段ユーザーと対話しているメンバーにヒアリングなどを行い 現状の課題感やユーザーの求めるものを整理しました。

• アナリティクスやマウスフローなどのデータ解析
• ユーザーから今までに貰っていた意見をまとめる
• 要望のヒアリング
• 改めてペルソナを作成

軸を定める

M&Aという業界で、競合や類似業界のTOPページがどんな軸で作られているのかを調査しました。 まず、コンテンツを見せているのか？サービスの説明をしているのか？といった大きい軸に当てはめ、競合や類似サイトを2つに分類しました。

旧トップページは後者で、コンテンツをメインにしていました。 しかし、今までに無い新しいサービスなのにあまり説明をせずにコンテンツを見せているため、そのコンテンツが何なのかをユーザーが理解していなかったりなど問題がありました。

そこで、今回のリニューアルではまずはしっかりとサービスを理解してもらい、M&A業界にサービスを浸透させていくことを軸として定めました。

プロトタイプを作る

様々な参考サイトを集め、UXリサーチで得た情報を基にプロトタイプを作成します。 ユーザーヒアリングを想定しているため、今回はある程度作り込みます。

デザインのルールを見直す
M&Aクラウドで使用しているカラーリングをまずは見直し、プロトタイプ作りを進めました。

サービスサイトでは、M&Aクラウドのロゴカラーの「赤」と「青」を様々なボタンに使用しています。 しかし、どちらも色が強く、結果ユーザーを迷わせてしまいます。

白黒にした場合の色の濃さがほぼ同じ

新カラー

そこで、新しいカラーを用意し、強調したいボタンをより明確にしました。 このルールをサイト全体に反映し、分かりやすいUIを目指します。

ファーストビューを考える
社内・外からアイデアを募り「事業売却と資金調達で次のステージへ」というキャッチコピーを作成しました。

事業売却と資金調達をする事で、各々の「次のステージ」に進む事が出来る。といったメッセージを込めています。 出来上がったキャッチコピーを基に「次のステージに向かってる感！」のあるファーストビューを作成しました。

訴求のテーマを決める
説明をしっかりしたいので、どのような訴求の流れが良いのかを模索し、今回は「悩みを解決」をテーマにサイトを構成しました。

ユーザーヒアリングを実施

出来上がったプロタイプを基に、計6回ほどユーザーヒアリングを行いました。 新鮮な意見を聞くことができとても参考になりました。

例）「売却案件」とありますが、売り手側からすると「案件」ではないので違和感があります。 など、本当にユーザー目線でいなければ気づかなかった細かい視点に今回多く気付く事ができました。

遂にリリース

Before

After

思い切ってファーストビューでの検索フォームは外し、キャッチコピーを目立たせています。 サービスについても具体的で分かりやすくなったと思います。

今回のリニューアルでは、業務フローや技術はもちろん
弊社のミッション「テクノロジーの力でM&Aに流通革命を」を実現するデザイナーとしてユーザーの理解がまた少し進んだと実感しました。

現在デザイナーは1名なので、引き続きオールマイティーに頑張りたいと思います！

テストを再設計して開発効率と実効速度を向上しました。

こんにちは、M&Aクラウドのかずへいです。

M&Aクラウドのサービスでは、サービスが拡大するにつれて、開発当初は気にならなかったいくつかの課題が生まれました。

今回、テストの設計を見直し、これらの課題を解決する取り組みを行いましたので、ご紹介したいと思います。

テスト環境に発生していた課題

テスト環境に発生していた課題には以下のようなものがありました。

• Migrateが遅い
• Seedingが遅い、Seedが複数のテストで使われており、変更がしづらい
• テストが足りていないと感じる
• DomainServiceのテストが書きづらい
• Test時間が長い

それぞれどういうことが説明します。

Migrateが遅い

M&Aクラウドでは、2年間サービスを運用してきて、Migrationのファイルが積み重なっていました。テーブルを追加するものから、カラムを1つ追加するだけの細かなものまで合わせて280ファイルあまりが存在しました。

このMigrateをテスト実行の一番最初に実行していましたが、1回にローカルのPCで40秒ほど掛かっていました。

Seedingが遅い、Seedが複数のテストで使われており、変更がしづらい

M&Aクラウドのアプリケーションでは、テスト用のデータもSeedingという形で、テスト前のデータベース構成時に一括でデータを流し込んでいました。

そのおかげでテスト時にDBにデータを言える手間が省け、すぐにテストが書けるという状態になっていましたが、2年間かけてSeedingの分量が積み上がっていました。

また、アプリケーションが複雑になるにつれて、Seedのデータを複数のテストが呼び出すようになってしまいました。これでは、テストのためにSeedを変更すると関係ないテストが落ちるということが起きてしまいます。テストがSeedを介して密結合になり壊れやすくなってしまいました。

テストが少ないと感じる

テストが多いかどうかについては、カバレッジのような指標もありますが、基本的には開発者がどう感じているかが重要だと考えています。 「今のコードをリリースするのが不安だ」、「テストをちゃんと書いているのに不具合が出る」と感じているとき、テストが足りていないのでは無いかと思います。

既存のアプリケーションの設計上、テストを書くのに大きなコストが掛かったりパターンを網羅するのがむずかしい状態になっていたりすると、個別の開発者の努力だけではこの不安を払拭するのは難しいと思います。

DomainServiceのテストが書きづらい

M&Aクラウドのアプリケーションでは、データを持ったDomainクラスに収まらない、複数のDomainクラスを呼び出して調整するような操作をDomainServiceクラスという名前で扱っています。

Domainクラスを返してくれるRepositoryクラスがあり、DomainServiceクラスは複数のRepositoryクラスを呼び出し、Repositoryクラスから受け取ったDomainクラスをもとにビジネス上の処理を行います。

このようなクラスは、他の複数のクラスを呼び出す構造にあるため、Unitテストを書こうとするとMockを複数箇所に使ってテストを書かなければならず、テストを書く際の大きな負担になっていました。

Test時間が長い

M&Aクラウドのアプリケーションでは、テストの数は1,500件程度とそれほど多くありませんが、その6割に当たる900件ほどのテストがUnitテストではなくFeatureテストであり、すべて実行すると10分ほど掛かるようになっていました。

解決策

このような課題が発生していましたが、中にはアプリケーションの設計そのものに関係するものもあり、個別の課題を一つづつ直せば解決するというわけではありませんでした。

ここで問題を整理し、以下のような複数の解決案を講じました。

• 過去のMigrateをまとめてSQLのダンプにする
• Unit、Featureの2つの区分だったテストをUnit、DbIntegration、Featureの3種類に分割する
• テストを並列実行し、実行時間を短くする

過去のMigrateをまとめてSQLのダンプにする

過去のMigrateをMySQLのdumpにしてすべてまとめた1つのmigrateにしました。 これによって実行時間が40秒→6秒ほどになりました。

MySQLのdumpにしてしまったので、MySQL以外のDBとの互換性が無くなってしまったということはありますが、すでにMigrateの中にMySQL依存のSQLなども書かれていたことから思い切ってMySQLのみというふうに決め込むことにしました。

Unit、Featureの2つの区分だったテストをUnit、DbIntegration、Featureの3種類に分割する

テストピラミッドという考え方をご存知でしょうか？Unitテスト > 統合テスト > UIテストの順にテストの数を増やすことで、無駄なく信頼性の高いテストを保守できるという考えです。

テストピラミッド

M&AクラウドのアプリケーションはLaravelを使っており、PHPUnitでテストを実行しています。Laravelのアプリケーションには、インストールしたときからUnitとFeatureという2つのテスト区分が存在しており、M&Aクラウドではそれをそのまま使ってテストを書いていました。

Featureテストはリクエストからレスポンスまでの一連の処理がすべて行われて初めてGreenになるため、Featureテストが動いていれば機能がちゃんと動いているという安心感？からか、どうしてもFeatureテストを書きがちになってしまいます。

しかし、Featureテストは統合テストに近い概念なので、これではテストピラミッドに違反してしまいます。

どうすればFeatureテストを減らし、Unitテストを増やすことができるでしょうか？

Featureテストで担保していたロジックをUnitテストに移す

Featureテストでは、リクエストからレスポンスまでの処理のすべてがテストできるため、ここの部分をテストしているぞ！という意識が希薄になりがちで、実際にUnitテストできるはずのものもFeatureテストに含まれていました。

今回それらを抽出し、アプリケーションの設定とともに見直すことで、Unitテストを書けるようにしました。

以下が抽出されたクラスです。

• Requestクラス
• Responseクラス
• Repositoryクラス

次からどのようにクラスが抽出されテストされるのかを説明します。

Controllerの処理をRequestとResponseに分解しテスト可能にする

Laravelはとても便利なので、ControllerでLaravelが提供してくれるリクエストとレスポンスのクラスを活用するだけで簡単に処理が書けてしまいます。

例えば

return view('view_name', $params);

と書くだけで簡単にレスポンスを返す事ができます。

しかし、これではリクエストとレスポンスをテストするためにControllerを呼び出さねばならずFeatureテストになるのは必至です。

そこでRequestをFormRequestを継承したクラスとして、ResponseをResponsableインターフェースを実装したクラスとして丁寧に実装してやります。

これによりRequestとResponseのクラスを個別にテストすることができます。

以下はResponsableなクラスのテストの例です。

qiita.com

UnitテストとFeatureテストの間として、DbIntegrationテストを定義する

データベースからデータを取得する箇所のテストは、Mockに差し替えてしまうと本質的にはテストできません。よってどうしてもFeatureテスト側によってしまいがちです。そこで、DbIntegrationテストとしてUnitテストとFeatureテストの間に「データベースにアクセスしちゃうけど、Featureテストではないテスト」を新しく定義することにしました。

また、課題になっていたDomainServiceクラスのテストもこのDbIntegrationテストに含め、データベースアクセスを許すことにしました。 Mockをたくさん書かないといけないテストはMockの処理自体がコードと密結合してしまうため、テストが壊れやすくなってしまうという問題があります。また、Mock::aが呼ばれて、Mock::bが呼ばれて…とMockが正しく呼ばれることをテストに書き、Mock経由で得られた値が返却されることをテストできても、それはテストとして正しく動いているのか？というと疑問があります。

この問題は「モックの泥沼」という名前で「初めての自動テスト」という本に紹介されていますので、是非読んでみていただければと思います。

初めての自動テスト ―Webシステムのための自動テスト基礎

よってDomainServiceのテストは、テスト中にデータベース接続することを許し、Mockを使いすぎないようにするという方針にしました。

DbIntegrationテストは以下のような方法で、テストに接続はするが遅くはならないように実装しています。

qiita.com

テストを並列実行し、実行時間を短くする

新しくテストをUnitテスト、DbIntegrationテスト、Featureテストに分割したことにより、それぞれのテスト郡に属するテストが減り、並列に実行するとテスト時間が抑えられます。

弊社ではCircleCIを利用していますので、テストを並列実行し、全てが完了したら開発環境にデプロイするといった仕組みを組んでいます。

現状ではまだFeatureテストが多いですが、徐々にUnitとDbIntegrationに寄せていくつもりです。

まとめ

アプリケーションの成長とともにテストの設計が開発効率を下げるようになってしまったので、アプリケーションの設計とともにテストの設計を見直した事例を紹介させていただきました。

テストの設計もアプリケーションと同様に、最初の設計をただ守り続けるだけではなくて、状況に合わせてアップデートしていく必要があるなと改めて思いました。