アジャイル原則から紐解くデザインエンジニアリングのひとつのあり方
こんにちは、株式会社Relicのデザインエンジニアリンググループです。
弊社は2021年7月にデザインエンジニアリンググループを発足しました。デザインエンジニアリングに特化した特殊なグループです。
私の肌感ですが、ここ数年で「デザインエンジニア」というワードをよく聞くようになった気がします。
ただ、この「デザイン」と「エンジニア」という聞き馴染みのあるワードに対して、具体的にどのような業務を行っているのか不透明な部分があると感じています。
企業、はたまた国内・国外によっても定義が違ったりするためではないでしょうか。
この記事では、そんな疑問にお応えすべく、Relicのデザインエンジニアとして働く私の具体的な日々の業務を紹介できたらと思います。
私は、Relicの自社開発プロダクトで運用・保守業務に携わっており、アジャイルな開発フレームワークのスクラムを取りいれて日々開発をしています。
アジャイルらしいデザインエンジニアの役割や、スクラムでの進め方について紹介していきます。
対象とする読者の方🗣
デザインエンジニアに興味がある方
デザインに興味がある方
アジャイルな開発（スクラム）に興味がある方
デザインエンジニアリンググループの組織に興味がある方
私がスクラムで大事にしていること💪
本題に入る前に・・・弊社のスクラムの取り組みについては、PMの北川の記事も是非ご覧ください！
アジャイルソフトウェア開発宣言のマインドセットの「個人と対話、動くソフトウェア、顧客との協調、変化への対応」の中でも、とくに私が開発中に意識しているのが「動くソフトウェア」です。
動くソフトウェアこそが進捗の最も重要な尺度です。
「動くソフトウェア」がなぜ最も重要な尺度かというと、目に見え、操作ができ、ユーザー体験を生み出せるたったひとつの手段だからです。
一枚絵で目に見えるだけでもなく、裏側でコマンドを打って操作されるだけでもなく、その両方ができてはじめてユーザーのサービスを使う体験が成り立ちます。不確実性が高い状態で何が信用できるかというと、この「動くソフトウェア」が一番なのです。
いや、そんなの当たり前でしょ？とツッコミを入れたくなるところですが、「動くソフトウェア」を達成するためには様々なフェーズを経て試行錯誤が必要です。決して容易いことではありません。
この容易くない開発において、仮説と検証を最短で形にすることがデザインエンジニアの役割のひとつではないかと思います。
機能改修の課題点🤔
機能改修を例にして、デザイナーの進め方を整理してみます。
（※Relicはそれぞれ役割に応じた作業を行なっています）
既存機能を理解する
ステークホルダーと仕様検討を進める
上記までの工程をUIに起こす
ステークホルダーに確認して合意形成を図る
3, 4の繰り返し
1つ目の課題
「既存機能」の理解です。
例えば完全なドキュメントがない場合、ドキュメントがあっても情報が最新でなかったり不完全だったりした場合はどうでしょうか。（そこに問題が〜！というご指摘は別問題として...）
把握しているエンジニアに確認をしたり、何かしらソースコードを読む必要があるかもしれません。
2つ目の課題
「UIに起こす」です。
情報設計を経てまとめ上げることは、素晴らしさこの上ない可視化と思います！
ただ、デザインデータは「設計図」に近いものでありそれ以上でも以下でもないことを忘れてはいけません。
あらゆるステータスを含むシステムにおいて、UIを静的に表現するには限度がありますし、パターン別で羅列することは思っている以上の情報量になります。
上記を網羅し並べ立てたところで、それは実際の「サービスに近しいもの」であって、本物ではありません。
最終的な「ステークホルダーに確認」では、デザインデータをもとに合意形成をとることが想定されますが、考慮漏れで作り直したり、いざ確認がとれて実装を進めた後にやっぱり変えたい！といった経験をされたことはないでしょうか？
不完全なアウトプットでも「動くソフトウェア」と捉える👩💻
上記にあげた課題に対してどういうアプローチが必要でしょうか。
記事冒頭で述べた「仮説と検証を最短で形にすることがデザインエンジニアの役割のひとつ」を思い出していただきたいです。
アジャイルの肝は「小さく・素早く」です。
このアジャイルの思想と、最短で形にすることは相性が良く、デザインエンジニアリングが実践しやすいと考えます。
やりかた1：デザインから実装までを担い、試しに一気に形にする
完璧なデザインでなくとも、完璧なコードでなくても、まずはシステムとして操作できるところまで作ってしまいます。
この時、UIがコンポーネント設計されている、最低限のUIルールが設けられている、と助かります。使いまわしができると、デザインの知識がそれほどないエンジニアでもデザインのハードルが下がりますし、既存UIとの秩序が保たれるからです。
もしそうでもなくても、エンジニアが既存デザインの意図をくみ取りながら形にしていきます。
この場合の進め方です。
既存機能のコードとUIを確認する
データ構造をコードで理解する
ステークホルダーと仕様検討を進める
上記までの工程を実装しながらUIに起こす
確認用サーバーにあげて（dev, stg環境など）ステークホルダーに操作しながら検収をしてもらう
4, 5の繰り返し
一番のメリットは、コード上で事実確認をしながらUIを構築できることです。これで仕様検討時の抜け漏れがだいぶ抑えられます。
この進め方だと、最低限の「動くソフトウェア」にはなっているため、より高度な検収が可能です。
たとえ不完全すぎてリリースはできなくとも、次のスプリント以降で改善を重ねることで、より良い機能ができあがる前提です。
しかし、大きな機能であればすべてを上記のように進めるのは困難ですが、うまく検討が進まないところや、動的にステータスをもっている画面のみに絞って、とりあえず形にした方が適している箇所はピンポイントにあるかもしれません。
ここで忘れてはいけないのは「小さく・素早く」です。アジャイルを実践するのであれば、なるべく小さな課題に分解することを意識しましょう。
また、最終的なUIを記録しておきたい場合は、後追いでデザインデータに残すことをおすすめします。その方が持続的な開発には向いています。
やりかた2：デザイナーと連携を取りながら形にする
やりかた1の進め方は、領域を超えて素早く形にすることができる反面、ひとりの裁量に偏ってしまいます。
もし、デザインと実装の役割に応じて進めることに慣れている場合は、連携の仕方ひとつで大きく変わってきます。
ここで役割分担での課題をあげてみます。
デザイナーとエンジニアで共通言語がなく言っていることがわからない
デザインが技術的に実現可能かわからない
デザイナーとエンジニアとでお互いに気を使ってしまい妥協したアウトプットができてしまう
お互いの小さな溝を埋めるために、デザインエンジニアはより厚みのあるコミュニケーションでデザイナーを支援できます。
この場合の進め方です。
既存機能をコードベースで仕様を伝える
データ構造を元に足りないステートを補う
初期段階でステークホルダーとの仕様検討に参加する
UIに起こした後のレビューで実装時の不安点を解消する
ステークホルダーに確認して合意形成を図る
4, 5の繰り返し
合意形成までの間、デザイナーとエンジニアでより多くのコミュニケーションをとることで認識齟齬や不明点を極力少なくできます。
お互いの遠慮のかたまりのようなアウトプットを避けるためには、寄り添いと、理解する努力、なによりユーザーに価値を届けることが最終ゴールということを忘れないことです。
もしこの進め方の結果が「動くソフトウェア」でなくとも、精度の高いアウトプットができることでしょう。
おわりに🙋
いかがでしたでしょうか。
アジャイル（スクラム）と絡めて、デザインエンジニアとしての役割を提案してみました。
領域を越えることは容易いことではありませんが、学びが多く刺激的です。
また、一緒に議論できるメンバーも増やしていきたいと思っておりますので、デザインエンジニアリングに興味がある方は是非Relic採用サイトからお気軽にお問い合わせください！（フロントエンドエンジニアでの応募）
地方拠点もありますので、U・Iターンも大歓迎です！🙌
長文となりましたが、読んでくださりありがとうございました。
この記事が気に入ったらサポートをしてみませんか？