業務システムに関わる中で見えてきた開発者とデザイナーの共通点
こんにちは。NTTデータのデザイナー集団「Tangity」のKomatsuです。
Tangityに加わる前、私はシステムエンジニア、プロダクトオーナーとして、お客様の様々な業務システムの開発案件に携わってきました。現在は、サービスデザイナーとしてお客様の業務システムのUIUX検討を進めています。
同じ「業務システム」であっても、異なる立場で関わると、違う視点で物事が見える一方で、本質的には共通点もあるということを日々実感しています。
今回は、サービスデザイナーとしての歩みを進めて半年経ち、開発時代を振り返って改めて気づいた二点をお話します。
これまでの経歴やTangityへの異動を考えたきっかけは前回の記事をご覧下さい。
システム開発時代を振り返って気づいたこと
１．業務を理解しないと良いものはつくれない
長年、製薬業界（営業領域や臨床開発領域）のプロジェクトに従事し、現在は製造小売業界のお客様と仕事をしています。
業務システムに関わる立場は変わりましたが、業務を理解しなければいけないという点は変わらないと感じています。もちろん、開発者とデザイナーでは役割が異なるため、角度を変えた見方をする必要はあります。
開発を担当していたときは、お客様の要望をシステムとして実現するために、以下の流れで深掘りしながら検討を進めていました。
業務要件の背景・目的を理解した上で機能要件を検討し、
機能要件から業務に関わるユーザーのロールごとに実際に取り得る操作パターンを想定し、
操作パターンから生じるデータパターンを整理し、
例外データパターン含めてどのような仕様とすべきか提案した
システムが期待通り動くためには、曖昧さを排除して、あらゆる例外パターンを想定して仕様を決めておく必要があります。もちろん、全て予見することは難しいこともありますが、業務を理解することで、ある程度網羅的な検討につながり、仕様漏れを防ぐことができると考えています。
現在、デザイナーの立場でお客様の業務を捉える際も、業務を理解する必要性は変わらないと感じます。データレベルでの理解は必須ではありませんが、業務の流れにおいて、それぞれのユーザーがどのような状況に置かれて、どのような気持ちでその作業をしているのか理解する必要があります。
その際に、業務の背景や目的を把握しておかないと、ユーザーがなぜその行動をして、その感情を抱くのか汲み取ったり深掘りすることができず、本質的な課題を捉えることができないのではと感じます。
いずれの立場で関わるにしても、分かったフリをせず、業務のことを一番理解しているお客様に素直に質問して色々教えてもらって、業務を理解すること・理解しようとする姿勢がとても大切だと考えています。
２．フレームワークやベストプラクティスを鵜呑みにしない
転職を経て、自分自身が所属する会社やお客様の業界・業務を横断して経験を積み上げてきた中で、改めて感じるのは一つとして同じプロジェクトはないということです。
もちろん、お客様単位で捉えると、（お付き合いの年数などによる）信頼関係の深度の違いから、多少難易度の高い場合でも進めやすさ・やり易さの違いは出てきます。ただ、それでも、プロジェクトに閉じれば、予算や前提条件、納期、スコープ、構成されるプロジェクトメンバーなど、全く同じものはありません。
そのため、過去の成功体験や、世の中に溢れているフレームワーク、ベストプラクティスに囚われず、プロジェクトの置かれている状況を踏まえて、どのようなプロセス・手法を取るべきか都度考えることが大事だと考えています。この点についても、開発者、デザイナーいずれの立場でも共通だと感じています。
私は以前、プロダクトオーナーとしてスクラムのフレームワークを使ってアジャイル開発をしていました。当初、一般的なプロセスを使ってスプリントを繰り返していましたが、コミュニケーション面での課題が顕在化し、それが原因で期待と異なるシステムとなってしまう場面が何度かありました。そのため、スクラムマスターやチームメンバーと会話して、スクラムルールをチームオリジナルなものへ見直すことにしました。結果として、認識齟齬を早めに解消できるようになり、チーム内での期待値のズレがなくなりました。
今振り返ると、これは適切な対応だったと感じます。当時、チームビルディン中で未熟なチームに対して、世の中で「上手くいっている」と言われるフレームワークを当てはめるだけでは成功には近づかないということを悟りました。アジャイルの本質は、「コラボレートし、デリバリーし、内省し、改善する」（引用：https://heartofagile.com/）であり、プロセスを正しく実行することではありません。ユーザに価値を届けるという本来の目的を果たすために、必要と考える変更は恐れずに試してみるべきだと考えています。
同じような話が、デザインプロセスでも言えるのではないでしょうか。私自身はデザインのプロセスや手法の引き出しが少ないため、有識者の知恵や知見を日々お借りしながらプロジェクトを進めています。
ある場面でチームメンバーと次のフェーズのプロセスを検討していたときに、「今検討しているプロセスから想定されるアウトプットでは、お客様の期待値を下回ってしまうことが懸念される。もっと別のアウトプットの方が価値を提供できるはずだから、プロセスやタスクを見直そう」という話になり、ハッとしました。お客様に対してどのような価値を提供しようとしているのか自分なりに考えきれないまま、プロセスを何とか前に進めようと意識が向いていることに気づいて反省しました。
フレームワークやベストプラクティスは、出発点として利用するには有用ですが、決して成功を約束するものでありません。ここを意識しないと、プロセスを回すことや手法をこなすことに終始してしまい、そこから生み出されるアウトプットが本当にユーザーにとって価値のあるものなのか分からなくなってしまいます。
本質的に提供したい価値や目的は何なのか。これを日々考えながら、プロジェクトの前提や状況を鑑みて柔軟に変えるマインドを持って、お客様と関わっていきたいと考えています。
デザイナーさん大募集
現在Tangityではデザイナー職を積極的に採用しています！サービスデザイン、UXデザインのクライアント業務の経験がある方、ぜひ私たちと一緒に働きませんか？募集要項など詳細はこちら。お待ちしております。
インスタグラムやってます！
TangityのInstagramです。ぜひフォローしてください！
この記事が気に入ったらサポートをしてみませんか？