ユーザー視点でよりよい体験を考える。建設業界特化のマッチングサービス「ツクリンク」開発者 中村杏

「ツクリンク」という建設業界向けのサービスを開発・運営しています。元請けと下請け、同業者がお互いに助け合えるような受発注のマッチングを行うサービスです。

以前はゲームプランナーとして働いていましたが、その後、ハンズシェアにエンジニアとして入社し，現在は「ツクリンク」のプロダクト開発マネージャーとしてマネジメントと、開発の統括を行なっています。

開発スケジュールの作成や、企画が考えた機能を実際にどう実装するか、エンジニアに渡す仕様書の作成など、幅広く担当しています。

もともと、ゲームが好きでプログラムに興味があったため、大学・大学院でプログラミングを学びました。大学院卒業後、ゲーム開発会社にプランナーとして入社しましたが、激務でゲームを遊ぶ時間がなく、作り手にもかかわらずゲームへの知識が失われていくことに焦燥感を持ちました…。そこで、愛ゆえに一旦ゲーム開発から距離を置こうと退職しました。

その後、縁あって小学校の教員補助をしていたのですが、「ツクリンク」でも使用しているRuby on Railsのスキルを持っていたことで、ハンズシェアに勤務する友人に誘われて、エンジニアとして入社しました。

その当時、ゲームプログラマは仕様から携わることはないと思っていました。一方、自分はゲームの実装側ではなく、体験（ユーザーエクスペリエンス：UX）をデザインする部分に関心があったのでプランナーとして就職しました。

ゲームをプレイする際に、こまごまとしたチュートリアルを行わずとも自然とユーザーが目的を達成できるように誘導する作りになっているか、といったUXのデザインに関心があります。

「ポケットモンスター サン・ムーン」ですね。旧来のシリーズでは、戦闘終了後に戦闘に参加したポケモンしか経験値が入りませんでしたが、「サン・ムーン」から「がくしゅうそうち」の仕様変更で手持ちのポケモンみんなに経験値が入るようになりました。

ストーリーを進める中で捕獲したポケモンをパーティに入れて、また捕まえて…と、以前よりプレイヤーが育成を意識せずに、ポケモン図鑑のコレクションを自然に楽しめる仕様変更になっています。

「ペルソナ5」でも感じましたが、シリーズ作品にもかかわらず、以前よかった点に固執せず、ユーザーがより楽しめるよう時代に合わせて改善を行っていく、という姿勢は挑戦的でスゴいことだなと感じました。

自分はすべてのものの見方がゲームで成り立っています。ですので、「ツクリンク」の開発　でもユーザー目線に寄った視点はゲーム由来ですね。開発に没頭しているとエンジニア目線になっていきますが、ゲームを遊んで触れるとユーザー目線に戻ってくる、というところがあって。

そうですね。ハンズシェアではエンジニアとして仕事を進めながら「これが足りないな」という部分に気がついて、提案を行っているうちに、自然と企画というかディレクションの役割に寄っていきました。

サービスのシステムがうまく動いていないといった開発の課題の他にも、組織としてここが足りていない、というのも気になって…。私生活でも、日々身の回りのことに新しい仕組みや考え方を取り入れて、改善していきたいという欲求があります（笑）。

自分の根幹にある視点はゲームなので、プロダクトやサービスを俯瞰で見てみて、ユーザーにとってベストな体験・機能を考えて実装して、ユーザーからのフィードバックを見ることを面白く感じています。

たとえば、「ツクリンク」をユーザー視点で見た時に、個別にメッセージを交換できる機能が必要と感じて実装したのですが、その後、実際にユーザーが使用していることが分かり、作ってよかったなと思いました。

ユーザーから要望が直接届くこともありますが、まれですね。基本的にはゴールや中間地点で計測するしかないかなと思っています。

ユーザーからの要望は、要望の先に言語化されていない目的や不満があることがあります。要望をそのまま実装するのではなく、要望の理由やサービス全体を見て対応を考えていく必要があると考えています。

いろんなエンジニアのタイプがいると思いますが、ひとつ技術としての軸を持ちつつも、それだけに固執せずに複数の視野を持つエンジニアだと成長するなと思っています。

エンジニアの視野にとどまらず、ちょっとだけ自分の担当範囲を出て仕事をしてみる。エンジニアをしつつ、プランナーのほうに目を向けてみたりとか。ちょっと口出ししてみたりとか。そこで、足りていない部分を自分がやってみるとか。そうすると自分の守備範囲が広がっていっていいですね。

技術を例にとると、サーバーサイドとフロンドエンド、どっちで実装してもいいという場合、どちらがより開発効率がよいのか、ユーザー的にはどちらがよいのか、と考えた上で手段を選択して開発できる柔軟性はエンジニアとして強いなと思っています。

上司に作業を依頼された時に言われた通りに作るのではなく、依頼された作業の理由や目的を聞いて、「なぜそうするのか」と疑問を持つことが大事だと思います。依頼した上司の知識も絶対ではないので、ときには「それは違う」と言えた方がいいのかなと。

ハンズシェアではサーバーサイド、フロントエンドなどの区切りでは分業しておらず、エンジニアには全部やってもらっています。もちろん人によって得意不得意があるので、苦手な分野だったら得意な人に任せる、など互いに補い合う形です。

ハンズシェアはエンジニアの数が多くないので、専門分野で担当者を切り分けないことで作業待ちのスタッフをつくらず、誰か一人が休暇をとっても他のスタッフがフォローできる体制にしています。

論理的に話すことが、まずひとつ。

もうひとつは、ものづくりでは自分が作ったものにプライドを持つ傾向がありますが、それはエンジニアにもあてはまります。それでも、自分が作ったものが間違っていた時に、引き返すことを決断したり、固執したりしない。間違いを認められることが重要かなと思っています。これは、自分自身に言い聞かせている感じですね。いちど作ったものを崩すのは、惜しくなってしまう時があるので…。

もっと多くの人にハンズシェアを知っていただき、多くの人・企業のお役に立てるようにしたいですね。

そのために、組織としての体制、エンジニアの技術、どちらも今よりレベルを上げていきたいです。それぞれが経験を積み重ねて、ひとりが牽引して動くというより、皆が自立して動くことのできる組織にできればと考えています。

自分の軸となる技術のRailsは、最新バージョンで様々なJavaScriptのライブラリを管理することが楽になりました。Railsでフロントエンド領域を内包した管理が可能になって、今後どう進化していくのだろうと、 Railsの未来に興味がありますね。

プログラミング以外だと、少し前に日本で発売されたスマートスピーカー「Google Home」を購入しました。音声検索のニーズは自分ではあまり感じないんですが、若い世代に一定数利用されているという統計をみて、マジか？と思って。自分ならキーボードで打つのに…と思いつつ研究のために使ってみています。

音声入力以外だと先日、東京ゲームショウで「Airtone」というVRの音ゲーに興味を持ちました。VRを装着して、手にセンサを持って演出に合わせてリズムを入力する遊びです。音ゲーに空間演出やセンサによるユーザーの入力を組み合わせることで、従来と異なる魅せ方ができているのが興味深いです。入力センサの精度の課題はありますが。

…と、様々な新しい技術に関心があります！ 技術の先にある未来を見たいですし、自分も携わってみたいですね。