ContractS開発者ブログ

契約マネジメントシステム「ContractS CLM」の開発者ブログです。株式会社HolmesはContractS株式会社に社名変更しました。

FirebaseのCloud Firestoreを試してみた

この記事は Holmes Advent Calendar 2020 - Qiita 23 日目の記事です。


こんにちは!株式会社Holmesでエンジニアをしている北原です。

私は、2020年の4月に新卒でエンジニアとしてjoinさせていただきました。当初はSpringFrameworkとThymeLeafで開発を行っておりましたが、現在は弊社で使用している技術であるVue.jsの業務にシフトしてきたので絶賛キャッチアップ中です!

その学習も兼ねて、趣味の範囲で小規模なWebアプリケーションの作成を考えているのですが、「storeのデータを永続化させたいけど、DBとかバックエンドの処理が動くサーバが必要だし、コストがかかるなぁ...」という課題が生まれてきました。

そこで目をつけたのがこのFirebaseです。

Firebaseとは

FirebaseはGoogle社が提供するmBaaS(mobile Backend as a Service)で、DBサーバの管理や保守なしでデータの永続化ができ、そのほかにも様々な機能が提供されています。

その中で今回使用するのはCloud Firestoreになります。

Cloud Firestoreについて

最大の特徴はリアルタイムでデータが同期される仕組みで、接続するクライアント全てにおいて同期を行っているので、変更が瞬時に各クライアントに適用されます。

また、オフライン上でも各クライアント上にデータがキャッシュされており、オンラインに戻ると瞬時に同期されます。

データの保存形態に関しては、ODBMS(Object DataBase Management System)となっています。
Cloud Firestoreの場合は、コレクション呼ばれるものの中にドキュメントが多数存在し、それぞれのドキュメントはデータを持っている。といった具合です。

例えば...

  • コレクション = ドキュメントを管理するフォルダ
  • ドキュメント = フォルダ中の書類
  • データ = 書類に書き込まれた文書

といったようなイメージをすると少しわかりやすいかなと思います。

検証環境

※ npmインストール済です

  • OS : macOS Mojave 10.14.6
  • editor : Visual Studio Code v1.52.1
  • npm : v6.14.8
  • project : Vue 3 ステート管理はVueX

VueにおけるFirebaseの設定

  1. Firebase Consoleにログインします
  2. プロジェクトを追加を選択します

    1. プロジェクト名を決めます f:id:k-kitahara:20201221203428p:plain
    2. Googleアナリティクスを利用するか決めます(利用するのであれば) f:id:k-kitahara:20201221203711p:plain 3.Googleアナリティクスのプロパティを作成するアカウントを選択します f:id:k-kitahara:20201221203812p:plain
  3. 作成したプロジェクトを選択して、トップのウェブをクリックします f:id:k-kitahara:20201221204130p:plain

    1. 利用するアプリ名を決めます f:id:k-kitahara:20201221204205p:plain
    2. Firebaseの設定をコピーします f:id:k-kitahara:20201221204230p:plain
  4. プロジェクトのルートで下記のコマンドを実行して、Firebaseのモジュールをインストールします
    $ npm install firebase

  5. src/main.jsに手順3-2でコピーした設定をペーストし、必要な部分のみ保存します f:id:k-kitahara:20201221205520p:plain

以上で、Firebase利用のための設定は完了です。

データベースの作成

  1. Firebase Consoleにログインします
  2. 作成したプロジェクトを選択して、左側のサイドメニューからCloud Firestoreを選択します f:id:k-kitahara:20201221205915p:plain
  3. データベースの作成を選択します f:id:k-kitahara:20201221205947p:plain
    1. セキュリティの保護ルール設定を選択します(テストモードにすると全ての操作を受け付けるので、初期設定では本番環境モードにしてから、適宜セキュリティルールを書き換えていく形が良いと思います) f:id:k-kitahara:20201221210119p:plain
    2. データ保存先のリージョンを選択します f:id:k-kitahara:20201221210255p:plain
  4. ルールのタブを選択します f:id:k-kitahara:20201221210313p:plain
  5. セキュリティルールをアプリケーションに合った形で書き換えます(アクセスするデータベースのパスに対して条件付きで権限を付与していきます。具体的な記法はこちら。)

コードの記述・画面からの操作

  1. VueXのアクションに、Cloud Firestoreにデータを追加する処理を記述します f:id:k-kitahara:20201221210755p:plain
  2. 画面から、処理を記述したアクションを呼び出すと追加されています!! f:id:k-kitahara:20201221210901p:plain

感想

無料版だと多少の制限はあるものの、DBの構成管理なしでデータの永続化が実現できるのは手軽で便利です!

ここの手順では記載しておりませんが、GoogleFacebookなどの認証も対応しており、それらを通じたアプリケーションのログイン/ログアウト機能を実装できたりするので、Webアプリケーションの構築がよりスムーズになるかと思います。

最後に

いかがでしたでしょうか。

私もまだまだ触り始めたばかりではありますが、今後も少しずつ理解を深めていきたいと思います!

Holmesではエンジニア・デザイナーを募集しております。ご興味がある方はこちらからご連絡ください。

lab.holmescloud.com

lab.holmescloud.com

【AviUtl】図形オブジェクトの座標と連動した数値の表示(スクリプト制御・Lua言語)

この記事は Holmes Advent Calendar 2020 - Qiita 24 日目の記事です。


Holmesの倉島です。趣味でAviUtlというツールを用いて映像編集を行なっています。この度、このAviUtlの機能の一つ「スクリプト制御」に触れたので自身の使用例を紹介したいと思います。

AviUtlとは

フリーの映像編集ソフトで、有志によるプラグイン開発等で高い拡張性が特徴です。

AviUtlについて詳しく解説されている記事があったので詳細はこちら。 aviutl.info

スクリプト制御とは

AviUtlのスクリプト(動作・エフェクト等を操作する効果)はLua言語で書かれています。

ja.wikipedia.org

スクリプト制御はAviUtlの機能の一つで、Lua言語を直接記述して映像(図形やテキスト等のオブジェクト)を操作することができる機能です。

実践

例:図形オブジェクトが動くのと連動してX,Y座標をテキストで表示させる。 下記画像の右下のようなテキストを作成します。(X座標 : Y座標) f:id:t-kurashima:20210108130225p:plain

1. 連動させたい図形オブジェクトにスクリプト制御を付与

図形オブジェクトにスクリプト制御を付与し、入力欄に 

rendouX = obj.x
rendouY = obj.y

と入力。
obj.x で図形オブジェクトのx座標を、obj.yでy座標を取得することができ、それらの値をrendouX,rendouYという変数に代入します。
Luaでは変数名の前に修飾詞を入力しない場合はグローバル変数扱いになります。

f:id:t-kurashima:20210108130337p:plain

2. テキストでスクリプト制御

次にX座標 : Y座標 を表示する為に、テキストオブジェクトの入力欄に

<?
hyouji = rendouX .. ":" .. rendouY
mes(hyouji)
?>

と入力します。
※ <? ~ ?>で囲われている内容は直接テキストとしては表示されず、mes()などの関数を用いて表示されるものがテキストの内容となります。
mes()関数は()の中に指定した文字列を表示することができます。その為mes()の()の中に X座標 : Y座標 を表示することができる文字列を指定してあげればよさそうです。
hyouji という変数にrendouX(1. で設定した図形のx座標) + ":" + rendouY(1. で設定した図形のy座標)を代入し、hyouji をmes()に指定すれば表示ができそうですが、Lua言語の文字列結合は 「+」 ではなく「 .. 」で行います。その為

rendouX .. ":" .. rendouY 

と記述すると文字列結合が行えます。これをhyoujiに代入してmes()に指定します

f:id:t-kurashima:20210108130426p:plain

3.動作確認

現在、タイムライン上には、1.のスクリプト制御を付与した図形オブジェクト と 2.のテキストオブジェクトが存在します。

f:id:t-kurashima:20210108130450p:plain

これで図形オブジェクトを動かすと、テキストが動的に X座標 : Y座標 を表示します。

f:id:t-kurashima:20210108130703g:plain

感想

スクリプト制御を用いると、連動系の動きをとても簡単に作成することができます。
今までオブジェクトに一つずつ手作業でパラメーター調整していた苦労ともオサラバです。

最後に

Holmesはエンジニア・デザイナーを募集しています。 興味がある方はぜひこちらからご連絡ください!

lab.holmescloud.com

lab.holmescloud.com

弁護士からみたプロダクト開発の難しさと面白さ

はじめまして。Holmesの開発本部・PMチームの酒井です。

10年弱に亘り弁護士として働いたのち、昨年Holmesに入社してからはCEO室室長として主に経営企画やセールス的な仕事をしてきました。プロダクト開発との関係では、Holmesの事業領域である契約業務のドメインエキスパートとして関与してきたのですが、先月より正式に開発本部・PMチームに異動となり、PMM(プロダクトマーケティングマネージャー)を拝命しました。つまり、プロダクトマネジメントについては完全な素人です。

 

今回は、そんな初心者PdMが、プロダクト開発に潜む溝とそれを克服するために実践していることをまとめてみました。

部門間の言葉の溝をなくす

まず、セールス側で働いていたときには、開発陣から発せられる言葉の意味は全く理解できていませんでしたアジャイル?スプリント?レビュー?インクリメント?何となくわかったつもりでいましたが、開発で働き始めたら何もわかっていなかったことがわかりました。無知の知です。また、同じ言葉なのに全く違う意味で使われている場面もありました。例えば、「リリース」という言葉を、開発は内部リリースの意味で使い、営業は外部リリースの意味で解釈し、マーケはプレスリリースの意味で捉えていました。コミュニケーションコストが高くて仕方ありません。

 

このように、言葉の理解や使い方一つとっても、開発とそれ以外の世界には大きな溝がありますが、この問題を克服するためには、一つひとつの言葉を大切に定義して、その定義を徹底するという地道な作業をしなければならないと思っています。ちなみに、弁護士という生き物は、言葉の定義に並々ならぬこだわりを持つ人種なので、そのバイアスがかかっているのかもしれません。(ちなみに、法律や利用規約においては、第1条が目的、第2条が定義と相場が決まっています。)

 

フィードバックの背後にある課題を想像する

Holmesでは、ユーザーの皆様から寄せられた全ての要望やクレームを、「顧客要望」としてセールスフォースに登録して管理しています。MVP(Minimum Viable Product:実行可能な最低限のプロダクト)の形で市場に投入するのは、ユーザーの皆様からのフィードバックをいただくためと言っても過言ではありません

 

ただ、ユーザーのフィードバックを、きちんと理解せずに言葉通り受け止めるだけでは、其の背後にある本質的な課題を見逃すおそれがあります。「もし顧客に、彼らの望むものを聞いていたら、彼らは『もっと速い馬が欲しい』と答えていただろう」とか、「ドリルを買いに来た人が欲しいのはドリルではなく穴である」といった格言が示すとおりです。ユーザーの言葉を理解するためには、ユーザー自身のことを理解しなければならないと強く感じます

 

課題を理解するために、まずはユーザーを理解する

課題を特定するためには、前提として「ユーザー」をきちんと理解しなければなりません。そして、ユーザーの理解は、企業レベル・個人レベルの両方が必要です。企業としてのユーザーの規模、業種・業界、ビジネス構造、組織図はどうなっているのか。個人としてのユーザーの、部署、立場、日々の業務はどうなっているのか。一人ひとりのユーザーの視点に着目し、その一人の人にとっての世界を想像しなければ、自分たちが誰の、どのような課題に取り組まんとしているのか、迷子になってしまいます。

 

ホームズクラウドは、契約業務に関わらず全ての人の課題解決を目指していますが、契約業務には、法務部門だけでなく、事業部門やその他の管理部門、そして取引先などの様々な当事者が関与します。その分、ホームズクラウドのユーザーも多岐にわたり、必然的にユーザーの課題も多種多様です

 

このような複雑・多様なユーザー課題を深堀りするために必要となるのがドメイン知識です。Holmesの開発組織では、ドメイン駆動設計(DDD)を取り入れています。Holmesには、私以外を含め、弁護士経験者が3名、司法試験合格者が1名、法務部経験者が1名いるのですが、これらのメンバーがプロダクトオーナーとスクラムメンバーにドメイン知識を共有する取り組みを進めています。開発が極めて専門性の高い領域であるのと同じように、契約業務も専門性が高く、独特の専門用語が飛び交う領域です。この2つの異なる世界線が交わるよう、共通言語を作っていくことこそ、Holmesのプロダクトマネージャーとして求められる役割なのではないかと考えています

 

補論:弁護士業務との近似性

実はこの思考回路、弁護士がクライアントからの質問を受けるときに求められる姿勢と全く同じということに気づきました。たとえば、クライアントから「この契約書をレビューしてください」という依頼をうけたとき、契約書の文字面だけを見て、契約書の中の世界だけを見てレビューすることも可能です。ただ、実は、その契約によってやろうとしている取引自体が、法律上問題のある取引であるような場合もあります。だからこそ、弁護士は「このクライアントからの直接の依頼は契約書のレビューだけど、そもそもの問題点は取引の仕組みそのものにあるのではないか?」という想像が求められます。

 

また、裁判における事実認定の過程にも似ています。裁判では、「証拠上明らかな事実から、神様しか知り得ない客観的な事実を『推認』する」という過程を経て、事実認定が行われるのですが、目に見える事実を積み重ねて、過去の経験則(前提知識)に照らし合わせながら、目に見えない「顧客の本質的な課題」の仮説にたどり着くという開発における営みと親しいものに感じます。

 

今後の目標

ユーザーの本質的な課題を解決できるプロダクトを世の中に生み出すためには、開発言語、セールス言語、ドメイン知識という(同じ日本語のはずなのに)全然伝わらない3つの言語をうまく融合させることが必要不可欠です。そのためには、開発メンバーがセールスの言語を学び、セールスメンバーが開発の言語を学び、そして両者がドメイン知識を身につけることが必要になります

 

持っている知識や経験が全く違う人たちが、相互理解を深めていくというのは簡単ではありません。そこのドメイン知識まで必要となると非常に高いハードルのように思えます。しかし、だからこそ、開発言語・セールス言語・ドメイン知識が三位一体の組織を創ることができれば、その組織そのものがHolmesという会社の競争優位の源泉になっていくのではないかと思っています。

 

Holmesでは、法務での経験をプロダクト開発やセールスに活かし、事業の中心として働きたいという人材を募集していますので、いつでもお気軽にご連絡ください!

TestCafeにGaugeを組み合わせてBDDできないか試してみた

社内でE2Eテストツールとして、TestCafeの話題が出たため、前回の記事で試したGaugeとの組み合わせでBDDのようにテストを実行できないか、検証してみました。

実行環境

名前 バージョン
OS Windows 10 Pro 64bit バージョン2004
Node.js 14.15.2
Yarn 1.22.5
TestCafe 1.10.0
Gauge 1.1.6

なぜTestCafe単体ではなく、Gaugeと組み合わせようと思ったのか

TestCafe単体ではテストは簡潔に記述できるものの、実際の運用に乗せることを考えると、ログインや特定の状態への遷移といった、よくある処理の共通化は必要であると思います。

TestCafeはメソッドチェーンでテストを簡潔に記述できますが、共通で前処理を行おうと思うと、ツールのサポートとしてはFixtureのbeforeEachメソッドによるフィクスチャ単位の共通化しか見つけられませんでした。

Page Object Patternでも記述できるため、共通処理はPage Objectとして切り出し、フィクスチャやテストから実行することはできそうですが、BDDのように明示的に前処理を記述することは、TestCafe単体ではできないようなので、GaugeないしはCucumber.jsといったツールと組み合わせることで、明示的な処理の共通化ができるか確認できればと考えました。

また、前回はGaugeとJavaの組み合わせを試したため、今回はGaugeとJavaScriptの組み合わせで、使用感に違いがないかも確認できればと思い、Gauge+TestCafeで試してみることとします。

環境構築

TestCafeのインストール

devexpress.github.io

npmまたはYarnでインストールします。*1

インストールが完了したら、 testcafe -v でバージョンが確認可能です。記事作成時のバージョンは、1.10.0でした。

また、 testcafe -b で、利用可能なブラウザ一覧を確認できます。

# npm
$ npm install -g testcafe

# Yarn
$ yarn global add testcafe

# バージョン確認
$ testcafe -v
1.10.0

# 利用可能なブラウザ確認
# Firefox, Google Chrome, Microsoft Edge(Chromiumベース)、およびInternet Explorer 11と旧Microsoft EdgeがインストールされたWindows 10では、以下のように表示されました
$ testcafe -b
firefox
chrome
ie
edge
edge-legacy

Gaugeのインストール

前回の記事 と同様の手順で、Windowsインストーラーをダウンロードし、Gaugeをインストールします。

記事作成時のバージョンは、1.1.6でした。

Gauge+TestCafeのサンプルプロジェクトのダウンロード

getgauge-examples/gauge-testcafe にサンプルとなるGitプロジェクトがあったため、ZIPダウンロードおよび展開します。

npmまたはYarnで、依存モジュールのインストール後、テストを実行します。

# npm
$ npm install && npm test

# Yarn
$ yarn install && yarn test

TestCafeが起動し、Google Chromeのウィンドウが開きます。

起動時の画面

...が、以下のエラーで失敗しました。

Failed Step: Search for "github TestCafe"
Specification: specs\example.spec:6
Error Message: Error: Timed out
Stacktrace:
Error: Timed out
サンプルテストの修正

specs/example.spec がテスト仕様、 tests/step_implementation.js がテスト実装になります。

テスト内容を確認してみると、以下のようになっていました。

  1. Googleを開く
  2. 「github TestCafe」で検索
  3. 検索結果の最初のリンクのテキストに「GitHub - DevExpress/testcafe:」が含まれるか検証

まず、検索する文字列の入力欄を input[title="Search"] で取得しようとしているものの、日本語環境ではtitleが「検索」になっているようです。

また、GitHubの検索結果のリンクテキストが、記事作成時点では「DevExpress/testcafe: A Node.js tool to automate end ... - GitHub」となっているため、検証も失敗します。

それぞれ以下のように変更し、テストを再実行すると成功しました。

  1. 検索文字列の入力欄取得を input[title="検索"] で行うよう step_implementation.js を変更
  2. example.spec から渡される検証用の文字列を "GitHub - DevExpress/testcafe:" から "DevExpress/testcafe:" に変更

前回と同様、 reports/html-report/index.html にレポートが出力されます。

f:id:h-yamamoto_holmescloud:20201225124621p:plain
Gaugeのテストレポート

実装

いきなり躓きましたが、気を取り直して実装していきます。

テストするブラウザの変更

初期状態では、Google Chromeでのテストのみ実行されました。

コマンドからTestCafeを実行する場合、 testcafe ブラウザ名,ブラウザ名,... JavaScriptテストファイル でテストするブラウザを追加できるため、それっぽい設定はないかと確認したところ、 tests/testcafe_init.jsbrowsers('chrome') という設定がありました。調べてみると、APIを使ってJavaScriptから実行できるようです。

browsers(['chrome', 'ie', 'edge']) のように記述すると、各ブラウザのウィンドウは最初に開きますが、先頭のブラウザにのみテストが実行され、それが終わった段階でテスト終了と判断されます。

おそらく、オーケストレーションを行うGaugeと、テストを実行するTestCafeのライフサイクルの違いが原因かと思います。

ひとまず、Google Chrome以外にも、 browsers('ie')Internet Explorerbrowsers('edge')ChromiumMicrosoft Edgeでテストを実行できることは確認できました。

テスト仕様の追加

前回と同じMarkdownを、 specs/search.spec に保存しました。

テスト実装の記述

当初は tests/search_steps.js を追加して検証しようとしたのですが、GaugeではJavaScriptでテストを実装する場合、 tests/step_implementation.js にしかステップを記述できないようです。

ステップ内で実行する関数の内容を別ファイルに書いてimportしたりはできそうですが、ひとまず tests/step_implementation.js に以下を追記します。

なお、変数 _Selector は、それぞれTestCafeのTestController、およびSelectorになります。

step('検索エンジンのURL <url> を開く', async (url) => {
  await _.navigateTo(url);
});

step('検索文字列入力欄 <inputSelector> を取得する', async (inputSelector) => {
  const searchTextInput = Selector(inputSelector).with({ boundTestRun: _ });
  gauge.dataStore.scenarioStore.put('searchTextInput', searchTextInput);
});

step('<searchText> で検索する', async (searchText) => {
  const searchTextInput = gauge.dataStore.scenarioStore.get('searchTextInput');
  await _.typeText(searchTextInput, searchText);
  await _.pressKey('enter');
});

step('検索結果ページのタイトルが <title> であることを確認する', async (title) => {
  const titleElement = Selector('title').with({ boundTestRun: _ });
  const pageTitle = await titleElement.innerText;
  gauge.message(`検索結果ページのタイトル: ${pageTitle}`);
  await _.expect(pageTitle).eql(title);
});

TestCafeでは通常 fixturetest で記述していきますが、Gauge+TestCafeでは、実行時にGaugeのシナリオがTestCafeのfixtureに変換されるようです。

前回Javaで記述した部分をそのままJavaScriptに置き換えただけなので、TestCafeの記述としては洗練されていないですが、この状態で yarn test でテストの実行ができました。

感想

GaugeとTestCafeの組み合わせは、あまり良くはない印象です。

感じたデメリット

GaugeのJavaScriptによるテスト実装では、ステップを step_implementation.js にしか記述できないようです。私の調査不足かもしれませんが、ドキュメントをざっと読んだ限り、変更方法などは見つけられませんでした。

Gauge+TestCafeのサンプルプロジェクトでも、 step_implementation.js から test_controller_holder.js をimportしているため、実装を分割することは可能ですが、テストのステップをすべて単一ファイルに記述することになると、管理が煩雑になりそうです。

また、TestCafeの複数ブラウザによるテストや、並列テスト実行が活かせなくなりました。こちらはTestCafeのメリットを打ち消してしまっています。

TestCafe単体でできたことが、Gaugeと組み合わせたことでできなくなるのであれば、相性が悪いと言って差し支えないかと思います。

Gauge+Javaとの使用感の違い

Gauge+Javaでは複数ファイルにステップ記述が可能なため、そちらと比較するとGauge+JavaScriptは使い勝手が悪く感じました。

GaugeのData Storeに相当するctxがTestControllerに用意されていたりと、TestCafe自体が高機能ということもあり、Javaと組み合わせたときほど利便性の向上も感じませんでした。

TestCafeでBDDするための代替手段

TestCafeをGaugeと組み合わせるのは難しそうなので、Cucumberなど他のツールとの組み合わせが可能か調べてみました。

3年ほどOpenされているTestCafeのissueで、CucumberとTestCafeの統合についての要望が上がっており、そこからたどったissueの Cucumber Integration with Testcafe removed from roadmap? にて、Cucumber Integration がロードマップから削除されたこと、および gherkin-testcafe の使用が推奨されていました。

gherkin-testcafe を用いれば、Gherkin構文でTestCafeのテスト記述および実行ができるため、現時点ではこれを使うのがTestCafe+BDDには最適なようです。

実運用ではPage Objectとしてテスト対象のページをクラス化し、それをGherkinで記述したテスト仕様クラスから操作するのがいいかと思います。

総括

Gauge+Javaではかなりのメリットを感じられたのですが、Gauge+TestCafeではデメリットが目立つ結果となりました。

TestCafe自体の有用性は確認でき、またPage Object Patternによる記述ができることも確認できたため、今後はPage Object Patternによる実装や、 gherkin-testcafe との組み合わせの検証を行いたいと思います。

最後に

Holmesではエンジニア・デザイナーを募集しております。ご興味がある方はこちらからご連絡ください。

lab.holmescloud.com

lab.holmescloud.com

*1:Node.js、およびYarnのインストールについては割愛します

デザインのデイリー壁打ち

こんにちは。Holmesでデザイナーをしています古谷です。

今回は、プロダクトのイメージを固めていくアプローチについて書いてみたいと思います。

デザインをするにあたって、大まかな流れとしては、英デザイン・カウンシルの発表しているダブルダイヤモンドプロセスや、デザインスプリント等の手法でも用いられている通り、前提となるのは定性、定量データを元にしたアイデアの発散です。

発散する前提となる課題の発見や顧客の現状についての理解はまた別の機会で整理したいとおもいますが、では最初の仮設からどのようにして課題の特定と解決方法を検討していったら良いでしょう?

デザインをもとにした壁打ち

f:id:nfur:20201220144518p:plain

方法としては色々あるのですが、今年の夏前からの新プロダクトの構想を検討するに当たって、かなり泥臭いアプローチを実施してみました。

何を実施したか?

やったことはシンプルに「デイリー壁打ち」です。 新しい機能を構築する際に、CTOの花井と1時間のデイリー壁打ち、それをひたすら続けることでデザインを含めた新機能のイメージ、仕様を固めていきました。

というのも、大まかに「こんな感じの機能」というイメージというのは共通認識は取れているのですが、それが具体的にいうとどんな形で、どんな機能で、どんな機能なのかはお互いの頭の中にのみある状態だったのでそれを確かめる必要があったのです。

何を議論したか?

実現したいことが明確になる一歩手前の状態だったので、プロトタイプを作って、それが実現したいイメージとあっているかどうか?を検証していきました。プロトタイプを作ってそれが正しいかどうかを検証するというよりは、プロトタイプを作って、自分たちが作ろうとしているものが本当に有効な状態になるかどうか?が一番の大きな課題でした。

議論する内容としては、もちろん、仕様やインタラクションといったデザインの要素も含まれていますが、これって自分たちが自身をもって提供したいものだっけ?という批評をひたすら繰り返していきました。

新しい価値の提供を考えたときに、社内への共有や、社外の顧客への共有も含めて、実現したいことを簡潔に言語化できる状態にまで持っていく必要があります。

何十回ものデイリーでの壁打ちを繰り返す中で、できること、やらなくても良いことが明確になってきました。

壁打ちの進め方

まずはプロトタイプをざっくりと作ります。 途中でも中途半端でも、レイアウトが定まっていなくてもとにかくそれを共有します。 途中でも悩んでいるところでも良いので共有して、それをみながら議論するをします。 仕様や機能としてのあるべき姿、そして既存の要望を可能な限り巻き取って、プロダクトの方向性を定めていきました。

毎日1時間のミーティングですが、終わった後はクタクタになるくらい、ミーティング中はあらゆる可能性と指向を巡らせて、議論を繰り返します。

プロトタイプをそれなりに見える状態にまとめあげると共に、CTOは機能要件をドキュメントとして整理していく、というの平行して進めていきました。

プロトタイプのレベル

ワイヤーフレームだけで壁打ちの場に出すこともありますが、その場合、想像力で良い方に解釈してしまうこともあって、中途半端な議論になりがちです。 壁打ちの1時間を価値のある時間にするには、ある程度のレベルまで(顧客に見せてヒアリングしても良いレベルまで)一気に作り込んでしまうのが良いと思います。

ユーザーテストや顧客へ聞いた方が良いのでは?

ユーザーテストや、顧客に聴く、という行為もとても重要ですが、自分たちが提供したいこと、強み、弱点がクリアになっていないと芯のないフワフワとした検証になってしまいます。 中途半端なものを見せて、「いいんじゃないですか?」くらいの反応を収集しても、こちらが検証したいことは検証できないものです。

もちろん、プロダクトのフェーズによっては、顧客にまず聞け、というのはそのとおりだと思います。

細かいインタラクションは別途リファインメントでカバー

できる限り細かい部分も整合性がとれる状態でプロトタイプを作成しますが、 細いインタラクションなどはスクラムのプロセスの中でリファインメント時に再検討されます。

毎日の壁打ちで作成したプロトタイプから、MVPの状態にまで機能を絞り込むので、検討した内容がゴッソリと削られる部分も沢山あります。 それでも、将来的に有りたい姿を描いておくことで、何を削って何を入れるべきか?という判断が容易になって来るので、時間の許す限りプロトタイプは作り込むことをオススメします。

※もちろん、フィードバックを得るためのプロトタイプとして作り込む!というのが大前提です!

壁打ち相手

社内にかなり強力な壁打ち相手がいるおかげで、より良い形にすることができました。

  • ドメインに対する理解が深いCTO

  • エンジニアリングのプロセスを理解してくれるドメインエキスパート

  • 一般的な有るべき論を正してくれるプロダクトオーナー

得に、自分はまだまだドメイン知識が足りておらず、これらのエキスパートと議論することでより深い議論がでました。

見える化することによる議論の深化

形にすることで気づく細い違和感や、理想の状態との差分に気づくことが容易になるので、深い議論ができるようになります。 反面、これは見た目を決める議論ではない、という前提でいないと、枝葉の部分のツッコミが入るので注意は必要です。

議論の空中戦を防ぐことで課題を明確にできる

空中戦で抽象的な議題をまとめ上げるのは(個人的には)好きですが、結局どうするんだっけ?というフェーズになったときにもう一度同じ議論を繰り返しがちになります。貴重な時間の短縮という意味でも、可視化しながら議論を進めていくことは効果的です。

デザイナーのアウトプットについて

一人より、チームで課題に取り組んだほうがより顧客やビジネス、エンジニアリングの課題を反映した状態にできます。

厳しい壁打ちを繰り返して、打たれても負けない状態でリングに上がったほうがより良いものを作れると思うので、正しい批評を行って、正しい改善をできるだけ早く繰り返すにはデイリー壁打ちはとても良い方法だと思います。

また、プロトタイプはあくまでもフィードバックを引き出すための材料、という認識があるので、素早く、小さく、細かく試行錯誤を繰り返すには、長くても1日位の期間で新しいフィードバックをどんどん引き出せる状態にするのが効果的です。

株式会社Holmesでは、豊富な知識と経験をもつドメインエキスパートやエンジニアリングのスペシャリストと 壁打ちを繰り返して、より良いプロダクトを作っていきたいデザイナーを大募集しています。 また、壁打ち相手をしてくれるエンジニア(バックエンド、フロントエンド問わず)も大募集です。

lab.holmescloud.com

lab.holmescloud.com

参考書籍

デザイナーのためのプロトタイピング入門

https://www.amazon.co.jp/dp/B07VYPY7BF/

突破するデザイン

https://www.amazon.co.jp/dp/B073VDYX9J


ディーター・ラムスの「グッド・デザインに必要な10の原則」について改めて考えてみる

こんにちは、Holmesでデザイナーをしています竹内です。
この記事は Holmes Advent Calendar 2020 - Qiita 22 日目の記事です。

今回は、私がデザインをする上で、思考の基準となっている、ディーター・ラムスの「グッド・デザインに必要な10の原則」について、自分の考えを交えながら語っていきたいと思います。

f:id:t-takeuchi-holmes:20201221214553j:plain

ディーター・ラムスとは

ディーター・ラムスは、1950年代ごろから活躍されている、ドイツ出身のインダストリアルデザイナーです。

巨匠です(BraunやVitsœのデザイナーとして有名な方です)。

「グッド・デザインに必要な10の原則」とは、ディーター・ラムスが70年代ごろに定義したデザインの原則です。

グッド・デザインに必要な10の原則

  1. Good Design is innovative. (革新的である。)
  2. Good Design makes a product useful.(良いデザインは製品を便利にする。)
  3. Good Desgin is aesthetic. (良いデザインは美しい。)
  4. Good Desgin makes a product understandable.(良いデザインは製品を分かりやすくする。)
  5. Good Desgin is unobtrusive.(良いデザインは慎み深い。)
  6. Good Desgin is honest. (良いデザインは、誠実である。)
  7. Good Desgin is long-lasting. (良いデザインは恒久的だ。)
  8. Good Desgin is thorough down to the last detail.(良いデザインは首尾一貫している。)
  9. Good Design is environmentally.(良いデザインは環境に配慮する。)
  10. Good Desgin is as little design as possible. (良いデザインは可能な限りデザインをしない。)

語ってみる

「グッド・デザインに必要な10の原則」を自分の考えなりに語ってみます。
私の主観がかなり入ってますのでそこはご容赦ください。

1. Good Design is innovative.

良いデザインは革新的である。

デザインが革新的というのではなく、進んだ技術と常に協力関係にあるデザインということ。 既製品をなぞるではなく、またあえて新奇性があるように見せたものではなく、 発展いく技術とともに進化してくデザインと解釈しています。

革新的ということは、ユーザーを感動させ、そして愛され、それが普遍なものになり、良いデザインへの認識へと発展していくものと思います。(ほんとうは、登場したその時から良いデザインということだとは思いますが、万人へと考えたときに皆がその革新的なものに触れられる機会やタイミングも要素としてあるのではないかと思います。)

この言葉を知る前でしたが、心に残った言葉があります。
すこし昔、NHKのプロフェッショナルという番組で工業デザイナーの吉岡徳仁さんが吉岡徳仁さんが言っていた言葉です。

木の時代に作られた鉄のパイプのイスは、今から見れば普通だが、当時は革新的だったはず。自分も、これから未来では『普通』になるような新しいデザインをしたい

まさにこういうことではないかと思います。 未来では普通になる(定着すること)デザインが、その時点での革新的で良いデザインだと思います。

2. Good Design makes a product useful.

良いデザインは製品を便利にする。

これは読んで字の如しですね。
製品は使われるためにあるもの、実用性がなければ良いデザインとは言えません。

私たちデザイナーの力の発揮どころで、機能を最大化させるのもデザイン次第と言っても過言ではないかと思います。

3. Good Desgin is aesthetic.

良いデザインは美しい。

美しさは製品には必要不可欠。
とくに日常的に使われるものは、心理的な面でも美しくないと長く愛されるプロダクトにはなりません。 古来より美しいものは心を豊かにし、感動を与えるものと考えられているからでしょうか。

美しさとは何かというと、 私は、この10の原則にある以下により構成されるものと解釈しています。

  • Good Design makes a product useful. (良いデザインは製品を便利にする。)
  • Good Desgin makes a product understandable. (良いデザインは製品を分かりやすくする。)
  • Good Desgin is as little design as possible. (良いデザインは可能な限りデザインをしない。)

4. Good Desgin makes a product understandable.

良いデザインは製品を分かりやすくする。

わかりやすくなければ、作ったものの価値は当然半減します。 どんなに機能がよくても使い勝手が悪く、多くの手順を踏むようなデザインは誰にも愛されません。

わかりやすいとは何か、極端にいうと製品自体が語り、説明不要なもの。 目的を達成しやすい導線になっていることが、わかりやすいということだと思います。 10原則の中の Good Desgin is as little design as possible.(良いデザインは可能な限りデザインをしない。) に通じますね。

身近なものでいうと、iPhoneみたいなイメージでしょうか、iPhoneは説明書もほとんどなく、直感的に操作できるので、長い間、愛されているのでしょう。

5. Good Desgin is unobtrusive.

良いデザインは慎み深い。

わかりやすく言うならば、おしつけがましくないということでしょうか。
製品は芸術品や装飾品ではないので、デザインが独り歩きしないことが望まれることと解釈しています。

また、ここは機能にも言えることかと思います。
作り手の想いが強すぎて、プロダクトアウトにならないことも重要で、ユーザーファーストを根底に持つことが大事だということですね。

6. Good Desgin is honest.

良いデザインは、誠実である。

ここは言うまでもないですね。
誇張や、約束できない操作でユーザーを惑わせない。

7. Good Desgin is long-lasting.

良いデザインは恒久的だ。

短いトレンドを反映させた製品は、あまり長持ちしません。
ファストファッションのように、使い捨てのサイクルが早くなってしまい、 何年、何十年と愛されるプロダクトにはならないということと解釈しています。

ここはとても、難しいところです。 デザインはトレンドを追いやすく、ここに陥りやすいのではないかと思います。

個人的な考えですが、最近の WEBデザインのトレンドとして、 フラットデザインからマテリアルデザインがトレンドになっていることは、 個人的には現在はとてもいい流れができていると思います。

余分な要素を取り除き、シンプルに削ぎ落とした最小限のデザインのフラットデザインから、そこに現実世界のルール(奥行きや立体感、質量など)を足すことにより直感的な操作を促すマテリアルデザイン
ここは、この10の原則の以下に当てはまるところだと思います。

  • Good Desgin makes a product understandable. (良いデザインは製品を分かりやすくする。)
  • Good Desgin is as little design as possible. (良いデザインは可能な限りデザインをしない。)

8. Good Desgin is thorough down to the last detail.

良いデザインは首尾一貫している。

曖昧なものを作ってはいけないということだと解釈しています。
曖昧なものは、それがユーザーへの不安につながってしまうということだと思います。一貫していないということは、ユーザーが操作していく上での予測や期待に背いてしまうことになり、ユーザーの体験を悪いものとしてしまう。

9. Good Design is environmentally.

良いデザインは環境に配慮する。

こはちょっと省略します。すみません…

10. Good Desgin is as little design as possible.

良いデザインは可能な限りデザインをしない。

字面だけ見ると、「んんん?」となってしまいそうですが、 これは、ユーザーに目的を達成してもらうために、できるだけその妨げになるものを削っていけば、 Good Desgin makes a product understandable. (良いデザインは製品を分かりやすくする。)につながり、わかりやすいことの実現を可能にするということだと解釈しています。

また、重要でない箇所のデザインに時間をそそいでも、それはユーザーの助けにならず、 ユーザーに余計な時間を使わせてしまうかもしれない、ミスリードを起こすかもしれないとも考えられますね。
双方にとって無駄なエネルギーを生んでしまうのであれば、必要なものに重点をおき、より良いものを作っていくことが大切ということですね。

まとめ

この10の原則に出会ったのは、プロダクトデザイナーを目指していた学生の頃で、改めて振り返ってみると、さまざまな分野に対応できる原則であると感じました。 10の原則は一つひとつが独立したものではなく、何一つもかけてはならない、とても良く考えられた原則だと思います。

ここに出てくる原則は当たり前のことかもしれません。 10の原則を何一つ欠けることなくデザインに反映させることは難しいですが、特に以下の2つには意識を置いて、開発に挑みたいと考えています。

  • Good Desgin makes a product understandable.(良いデザインは製品を分かりやすくする。)

  • Good Desgin is honest. (良いデザインは、誠実である。)

我々の作るプロダクトが、この10の原則を体現し、多くのユーザーに愛されることを考えながら、デザインに取り組んでいきたいと思います。

lab.holmescloud.com

プロダクトマネージャーとしてのヒアリングスキル

こんにちは。Holmesでプロダクトマネージャーをやっている井上と申します。 今回の記事は Holmes Advent Calendar 2020 - Qiita 17日目の記事です。

はじめに

プロダクトマネージャーのスキルには実に様々なものがあります。調べるとよく出てくるのが下記のプロダクトマネジメントのトライアングルにあたるものです。

f:id:yinoue22:20201223202309p:plain
https://productlogic.org/2014/06/22/the-product-management-triangle/

もちろん全て欠かすことのできない重要な要素ではありますが、そのような中でも特に重要なものとして私が考えているのは、「ユーザヒアリング」です。(上記の図でいうところの「User Research」にあたる箇所になります。)

ユーザヒアリングの目的について

何故「ユーザヒアリング」を行う必要があるのか。 それはいかにお客様が抱えている課題を聞き出し理解し、その上で機能として実装するのかどうかを判断するためです。ここはひとつプロダクトマネジメントにとって大きな観点になります。

今回はその「ユーザヒアリング」を行う上で意識すべき点について書いていきたいと思います。

プロダクトマネジメントの文脈で書いてはおりますが、これは必ずしもプロダクト開発のみならず、どんな種類の仕事を行う上でもはたまた私生活にも十分応用できる考え方になります。

なお、内容についてはほとんどこちらの書籍を参考にしているのでご興味ある方がいれば是非読んでみてください。

「対話型ファシリテーションの手ほどき」

悪いヒアリング

『私たちは、「なぜ?」と聞かれるとつい「言い訳」をするようにできているのです。』

いきなりどきっとする記述がこちらの本の中にあります。

ヒアリングにおいて気をつけるべきことはこの一文につきると思います。 なぜと聞かれるとどうしても責められているように人間は受け取ってしまい、ちょっと濁して答えてしまったり言い訳のようなことをいってしまったりついついその場を逃れようとすぐに謝ったりします。皆様もご経験あるのではないのでしょうか。 (かく言う自分も「なんで?」「どうして?」と聞かれることが非常に苦手です・・・) そして本当に聞きたかったことが全然聞くことができなかったということになりがちです。

お客様へのヒアリングにしても往々にしてこういったことが発生しがちだなと思います。

私:「最近なかなかホームズクラウドを利用できていないみたいですね。どうしたんですか?」

お客様:「いや、ここのところちょっと忙しくて・・・」

私:「そうだったんですね、なんで最近忙しくなってきたんですか?」

お客様:「やらなきゃいけない業務もたくさんありますし・・・」

私:「そうですか、それは大変ですね。いつごろなら落ち着いてきそうですか?」

お客様:「うーん、なんとも言えないところですね・・・」

私:「そうですか、ではまた進捗確認しに打ち合わせさせていただきますね。」

上記の通り、実態はなんで忙しかったのか、どうすれば使ってもらえそうなのかといったことが何も分からず終わってしまいました。

おそらくこの調子だと次回の打ち合わせを行っても特に進捗はないでしょう。

青文字で書いてある部分が悪いヒアリングの部分です。その後事実確認をしようと赤文字の質問をしてはいますが、お客様からするとすでにかなり嫌な気分になっていると思われるのでここの回答も曖昧になってしまっていますね。

よく「なぜなぜ分析」をやったけど問題解決にならなかったというのは、なぜと聞くこと自体が本質的に感情に訴えかけているものなので、どこかに感情が入り込んでいるからだと思います。 問題解決のためには「なぜ」を分析すべきだ!というのはよく分かるのですが、上記の通りコミュニケーションが特に重要な場においては逆効果である可能性もあります。 (そもそもなぜなぜ分析は自分が関わる課題に対してやるのがよく、お客様に対してなぜなぜ分析をしたらおそらく嫌われると思っています笑)

良いヒアリング

では良いヒアリングとはなんでしょうか。

「なぜと聞いてしまうと人はついつい言い訳をしてしまう」 ということであれば、「なぜ」「どうして」を聞かずにとにかく、「何」「いつ」「どこ」「誰」を尋ねていくことと本の中にはあります。 そうやって事実確認のみを行いひたすら事実を積み上げていって、何が問題か何が課題なのかをこちらが推測で立てるのではなく、相手に自ら気づいてもらうことです。 そして本当に解決しなければいけない課題が浮き彫りになってきます。

先ほどの悪いヒアリングを良いヒアリングに置き換えるとどうなるでしょうか。

私:「最近なかなかホームズクラウドを利用できていないみたいですね。何かつまづいているところがありますか?」

お客様:「いや、つまづいているというよりは単純に時間がとれていないって感じですね。」

私:「そうだったんですね、時間がとれていないのは具体的にどなたになりますか?営業の方ですか?法務の方ですか?」

お客様:「うーん、主に法務部、というか私が今は立て込んでいてなかなか時間がとれていないですね。」

私:「そうですか、それは大変ですね。何の業務で忙しいんですか?」

お客様:「今は営業からの契約レビュー依頼がとてもたくさん来ているという状況で、、結構困っているんです。」

私:「主に困っている点はでしょうか?単純にレビュー自体に時間がかかるということでしょうか。それとも数が多く来すぎて把握・管理に時間がかかってしまうということでしょうか。」

お客様:「それでいうとまずは部長である私のもとにレビュー依頼は一旦寄せられるのですが、数が多いのとその依頼がメールで来るのでなかなか全体像が把握しづらいんです。ときには抜け漏れも発生してしまいそのことでまた営業から問合せがきて再度やりとりが発生して。。レビュー依頼の把握と担当者への割り降り等が煩雑になってきており、そこの管理に時間が取られてしまっているという状況です。」

私:「そうでしたか、ありがとうございます。」

この通り事実確認を積み重ねることにより、「業務が多忙でホームズクラウドを使っている暇がない」という認識から、業務多忙が実は課題ではなく「レビュー依頼の数が多く管理がしきれず把握に時間がとられてしまう、ときには抜け漏れも発生してしまうなど、コミュニケーションコストも大きく発生している。」という課題を掴むことができました。

そうすると後は、「各方面から来ているレビュー依頼について簡単に把握でき効率的に最適な担当者にさばけるようになる」ということは実現できればこのお客様はホームズクラウドを利用することで課題解決につながり、活用率も向上していくことでしょう。

さいごに

ユーザヒアリングは直接お客様の課題感を感じられる良い機会である一方、きちんと準備をして臨まないと単に時間の無駄になることも多いです。こちらが一方的に聞きたいことだけ聞こうとすると相手は萎縮してしまったり、意図したことが聞けなかったりということもあります。 そこで相手がいかに答えやすい形で事実確認の質問をするかが重要になってきます。

とつらつら書きましたが自分自身ももちろんまだまだ実践できてはいないため、今後も強く意識して頑張っていきたいところです。

参考書籍:「対話型ファシリテーションの手ほどき」