今日は株式会社estie（エスティと読みます）のデザイナーの荒井が、「詰まないモノづくり」について書きたいと思います。
estieについて
本題の前に、estieについて皆さんご存知でしょうか？
株式会社estieは不動産と情報技術を組み合わせた、いわゆる不動産テックと呼ばれる分野で事業を行なっている会社です。
まだ創業1年ほどで、生まれたてホヤッホヤの会社です。これまでの会社の軌跡については、創業1周年をむかえて弊社の代表がしたためたアツイ投稿をご一読ください！
estieは主に2つの事業を開発・運営しています。
1つはオフィス探しをシンプルにする賃貸不動産探索/提案プラットフォームである「estie」、もう1つは機関投資家の投資/運用（アセットマネジメント）業務を高度化するAIアナリティクスサービスである「estie pro」です。
この1年で2つのサービスをリリースできたわけですが、これらの開発体制はこのような感じです。
estieは、OKRのフレームワークに沿って開発を進めています。詳細なKRの説明は省略しますが、サービスのグロースのために必要な「リーチの拡大・効率化」と「リテンションの向上」に効果的な改善をチームで進めています。
1（デザイナー）:N（エンジニア）の時に起こりうること
このようにestieでは1人のデザイナーと複数のエンジニアが協業しています。
これ自体は全然珍しいことではないのですが、複数プロダクトにまたがって、協業するエンジニアの数が増えるにつれて、デザイン工程でタスクが詰まり、エンジニアの方の稼働にムラがでがちです。
特にリリース間もないプロダクトはやりたいこと・やるべきことが山積みな上、得てして大体の施策にデザインが必要になります。
そんな状況で、単純に施策を1つずつデザイン→実装という流れで繰り返すと、デザイン工程でタスクがスタックします。
どこかでタスクがスタックすると、当事者は焦りと罪の意識から精神的に詰みますし、無理にリカバリーしようとすれば肉体的に詰みます。また、これが原因となりプロダクトの成長スピードが鈍化すると、事業的に詰みます。（多少大げさですがw）
前置きが長くなってしまいましたが、今日は、デザイナー1人でプロダクトの成長スピードを落とさず、やりきるための1年間のアプローチを「詰まないモノづくり」として振り返りも兼ねて書きます。
チームの処理能力とは？
個人としても事業としても詰まないモノづくりをするために、チームの処理能力を健全な形で最大化させる必要があります。それではチームの処理能力とは何によって決まるのでしょうか？
ずばり、チームの処理能力はボトルネックの処理能力に依存します。
ウィキペディアによると、ボトルネックとは…
ボトルネック (bottleneck) とは、システム設計上の制約の概念。英語の「瓶の首」の意。一部（主に化学分野）においては律速（りっそく、「速さ」を「律する（制御する）」要素を示すために使われる）、また、隘路（あいろ）という同意語も存在する。
80-20の法則などが示すように、物事がスムーズに進行しない場合の遅延の原因は全体から見れば小さな部分が要因となり、他所をいくら向上させても状況改善が認められない場合が多い。このような部分を、ボトルネックという。
瓶のサイズがどれほど大きくても、中身の流出量・速度（スループット）は、狭まった首のみに制約を受けることからの連想である。
参考：ボトルネック - Wikipedia
とあります。中身の流出量・速度（スループット）は、狭まった首のみに制約を受けるという箇所が肝かなと思います。これは「17年間翻訳が禁じられたいわくつきの一冊」という鳴り物入りで2000年頃に日本語訳版が出版された「ザ・ゴール」でも言及されていることですね！
また、複数の不揃いの板で構成される桶に水を注いだ場合、1枚の板がどれだけ長くとも、1番短い板の部分から水が溢れ出す様子から、ボトルネックの重要性を説いた「桶の理論」も有名ですね。
これらの概念を開発体制と照らして考えると、何も工夫をしないと単純なリソース差からボトルネックは私になり、チームのアウトプットが私1人の処理能力と同等程度になってしまいます。
特にリリースのうち、デザイン系のタスクの割合が大きいフェーズでは、大きな影響があります。
チームのアウトプット最大化に向けて
チームの処理能力はボトルネックの処理能力に依存するので、最適化すべきはボトルネックの工程です。
成果を左右するボトルネックの存在はそれほど重要で、レバレッジ・ポイントになり得ます。
私がこの1年、自分がボトルネックになりやすい状況であることを自覚し、行ったことはタスクの内容に応じた作業工程を入れ替えです。
estieは2週間単位のスプリントをベースにアジャイル開発を行なっています。そこで私は、スプリントの最初に工程を並べ替えにくいタスクと並べ替えやすいタスクを分けました。
例えば、既存コンポーネントの組み合わせでない、全く新しい画面の作成は、要件を整理しながらデザインを詰める必要があるので、工程の並べ替えは難しいです。
一方で、既存機能の延長線上にある改善や要件が明確なケースは実装を先に進めてもらうことが可能です。
スプリントの序盤、私はUIデザインと新規のコンポーネント作りに集中します。その間、エンジニアの方々には機能開発を進めてもらいます。その後、タスクを交換し、私は実装済みの要素に後追いでスタイルを当ててつつ、エンジニアの方々には私が作ったコンポートにロジックやapiとの繋ぎこみをしてもらいます。
こうすることで一定のデザインクオリティは維持しつつ、スピードを出しています。
・右：物件提案者がより提案をしやすくる（ことでオフィス移転希望者への提案が増え、利用率の向上を狙った）施策です
チャットUIのデザインとcomponentは要件とともに詰める必要があったため、デザイン→実装の順で行い、たけすさんにパスしました。
一方、既存機能の延長線上にある改善施策は、後追いでスタイルを当てられるので実装が先行しています。こちらは実装→デザインという流れで、実装済みのタスクを受け取りました。
こんな感じで、「UIデザインとマークアップやCSS設計、JS実装多少できる」私と「開発なら任せろ！」なエンジニアとうまく工程を入れ替え、全員が常にムラなく稼働している状態を作り出します。
メリット・デメリット
もちろん、このアプローチには良い面だけでなく悪い面があります。
【メリット】
- デザイン完成の待ち時間が発生しないのでチームのアウトプットを最大化できる
- スタイルを後であっていく際に自ずと実装に触れるので開発への理解が深まる
- 待たせていることによる焦りがない
【デメリット】
- 後追いでスタイルを当てていく場合、デザインデータとの乖離が生まれる
- 最初にCSS設計をするケースと比べて、場当たり的な書き方をしてしまう（ことに後で気がつく）
メリット・デメリット、どちらを重要視するかは人員のバランスやプロダクトの成熟度などのフェーズによって異なって然るべきだと思います。
少なくともestieの今のフェーズは、Figmaと本番稼働しているページのデザインの乖離、多少の場当たり的なCSSという負債は抱え込んででもプロダクトを前進させることが正義だと思っています。
逆に、複数のデザイナーで多くのユーザーを抱えるプロダクトのデザインをする際は（私の本業はこちらのケースです）デザインを作らずに直接スタイル当てて仕様書とかほぼないっすwみたいなことすると多分怒られると思います笑
ただ、自戒を込めて書くと、「内部的にも、表層的にも美しい、且つ爆速」という状態が一番素晴らしいことは忘れてはいけません。いかなるフェーズであれユーザーの目に触れる表層部分に手を抜くことは無いとしても、先の通り、内部的な品質に妥協することはあると思います。スピードを盾に妥協ばかりするのは気をつけたい点ですね。
中には「内部的にも、表層的にも美しい、且つ爆速」を実現しちゃうツワモノもいるので…w
スピードを隠れ蓑にして妥協を繰り返すとツワモノへの成長ストーリーも絶たれることを今後も意識したいものです。
必要なスキルとマインド
デザインと実装の流動的なタスク工程の入れ替えは、HTMLとCSSの設計・浅いなりにもJSへの理解なしでは実現できなかったので、単純にこれらのスキルは持っていて良かったなと思いました。
また、エンジニアが実装した真っ白なページに装飾なしのdivタグが並ぶところから、ロジックを読み解きながら適切なマークアップとスタイルを当ててくタフネスは必要かと思います！w
間違いなくこの経験によって実装への理解が深まるのでおすすめです。
このようなことを書くものの、私は十把一絡げにデザイナーもコードを書かけるべきと言いたいのではありません。
正義は「組織とプロダクトのフェーズ」によって決まります。（何よりデザイナーがコードを書く／書かない話とか、プロダクトを取り巻くアレコレに境界があることを前提に「越境する」みたいな表現はナンセンスだよねと思う派です笑）
近い将来どちらかしかしていないかもしれませんし、どちらもし続けるかもしれませんし、何か新しいことが加わるかもしれません。
ただ、あらゆるリソースが足りないスタートアップの環境では自分のスキルはハマったなとは思います。
恒例のお仲間募集！
ここまでいろいろ書きましたが、UI作ってコンポーネント作って…を1人でやるのはツライ！もっとスピード出したい！のでフロントエンドエンジニア（特にCSS設計とかまで強いと嬉しいです）大募集です！
