目次

はじめに
謝辞
免責事項
第1章 人々はなぜデザイナーとエンジニアをつなぐ架け橋に夢を見て、それでもなお夢であり続けるのか
1.1 はじめに
1.2 そもそもなぜ人はそこに「夢」を見るのか
1.3 実際にかけられた橋たち
1.4 何がネックになっているのか?
1.5 何が銀の弾丸たり得るのか
1.6 理想の橋を渡す
1.7 おわりに
第2章 エンジニアから始めるチームデザイン
2.1 はじめに
2.2 デザイナーと並走するスクラム開発デザイン
2.3 スケールするドキュメントデザイン
2.4 みんなで育てる仕様書デザイン
2.5 おわりに
第3章 テクニカルプロトタイプのすすめ〜日常の中で行う体験検証〜
3.1 はじめに
3.2 プロトタイプの意義
3.3 「テクニカル」である意味
3.4 テクニカルプロトタイプの各ステップ
3.5 実践事例
3.6 おわりに
第4章 UIKitで実装されているiOS AppにSwiftUIを導入する
4.1 はじめに
4.2 基本方針
4.3 Storyboard
4.4 View Controller
4.5 Presenter
4.6 View
4.7 Wireframe
4.8 UIViewControllerのextension
4.9 この実装パターンの注意点
4.10 macOS appでの応用
4.11 Storyboard上の一部のViewだけをSwiftUIで実装するケース
4.12 おわりに
第5章 Jetpack ComposeでModifier順序の影響を理解する
5.1 はじめに
5.2 Modifier
5.3 LayoutModifier
5.4 DrawModifier
5.5 .padding()に注意しよう
5.6 終わりに
著者紹介

はじめに

 グッドパッチは、デザインの力でビジネスを前進させるデザインカンパニーです。

 「デザインの力を証明する」をミッションとして掲げ、これまでスタートアップのデザイン支援や大手企業における新規事業の立ち上げなど、さまざまなプロジェクトで戦略から開発まで幅広くお手伝いしてきました。

 社内には多様なバックグランドを持つエンジニアがいます。その中から有志が集い、技術について何を思い、普段どのようなことに興味を持ち、ユーザーにより高い価値を届けるためにどのようなことを考え、仕事に活かしているのかを書き、まとめました。この本を手にとっていただいた読者の皆様にとって、デザインの観点でエンジニアリングを考えるきっかけになれば幸いです。

謝辞

 インプレスR&D編集長 山城敬さんにお声がけをいただき、出版する運びとなりました。表紙はYang Peiyuanさんに作成いただきました。トンマナやモチーフなどエンジニアと相談しながら進め、オリジナルの3Dモデルを使って素晴らしい表紙に仕上げていただきました。第3章「テクニカルプロトタイプのすすめ~日常の中で行う体験検証~」を執筆するにあたっては、関根椋太さんにUXデザイナーの観点からご助言いただきました。第5章「Jetpack ComposeでModifierの順序の影響を理解する」を執筆するにあたっては、Androidのエキスパートとして、古家佳武さんに査読いただきました。その他にも、グッドパッチ社内で多くの方々にご協力いただきました。そして、中谷文彦さん(@milio_nktn)には、執筆のきっかけ作りをはじめ、多くの面でサポートいただきました。

 また、執筆にあたり、Re:VIEW1、TechBooster/Re:VIEW2、テキスト校正くん3を使わせていただきました。

 様々な方のご協力のおかげで出版することができました。著者一同、心より御礼申し上げます。

免責事項

 本書は、グッドパッチ所属の有志一同が自らの責任をもって執筆したものです。そのため、本書に記載されている内容は株式会社グッドパッチの見解等を代表するものではありません。

 また、本書に記載された内容は、情報の提供のみを目的としています。したがって、本書を用いた開発、製作、運用は、必ずご自身の責任と判断によって行ってください。これらの情報による開発、製作、運用の結果について、著者はいかなる責任も負いません。

1. Re:VIEW, https://github.com/kmuto/review

2. TechBooster/Re:VIEW Template, https://github.com/TechBooster/ReVIEW-Template

3. テキスト校正くん, https://marketplace.visualstudio.com/items?itemName=ICS.japanese-proofreading

第1章 人々はなぜデザイナーとエンジニアをつなぐ架け橋に夢を見て、それでもなお夢であり続けるのか

 藤井 陽介(Twitter/@touyou_dev)1

1.1 はじめに

 筆者は普段iOSアプリの開発を主に取り組んでいるのですが、昔から興味を持ち続けているテーマとして、「デザイナーとエンジニアの架け橋となるツール開発」があります。このテーマは、デザイナー、エンジニアという職能の分業が進んだ現代、職種に関わらず様々な人が繰り返し考えてきたのではないでしょうか。

 その証拠に、この世にはデザインツールからコードを書き出す機能を持った、さまざまなツール・プラグインなどが溢れています。そして不思議なことに、それらはリリースされた瞬間には歓迎と驚きを持って人々に迎えられるのですが、一過性のバズワードのようにしばらくすると名前を聞かなくなり、さらには実際の仕事で使い続けているという話ともなると、ほとんど聞きません。

 筆者も「デザイナーとエンジニアの協業」をテーマにこのようなツールの調査・開発に取り組んだ経験があり、その中でしだいにこの歪みが気になり始めました。そして、この歪みがなぜ起こるのかを探ることが、最終的に何が本当に必要なのかを明らかにする第一歩となるのではないか、という仮説を立てました。この章ではいくつかの事例を取り上げながら、本当に必要とされているものは何か、どうすれば協業を楽にする「夢」を現実にできるのか、考えていきます。

1.2 そもそもなぜ人はそこに「夢」を見るのか

 思考を深めていく大前提として、まずは人がなぜデザイナーとエンジニアの架け橋となるツールに夢を見るのか考えます。

 夢を見る、ということは、そこに何かしらの課題感があるということです。ツール開発なのか、仕組みなのか、人なのか、課題感にも解決策にもそれぞれ多様性があります。ですが、共通して一番の課題となっているのは、デザイナーとエンジニアのコミュニケーションコストではないでしょうか。

 では、このコミュニケーションコストはどのような要因で生まれているのでしょうか。これについて、まずはいくつか考えてみました。

図1.1: コミュニケーションコストが課題感となっている要因

 これで全て洗いだせたとは言い切れないですが、整理すると、次のようなポイントが見えてきました。


 ・デザインツールと開発ツール(コード)というまったく違うツールで同じものを再現する必要が出てくる。結果、そのアウトプットに人依存の要素が多くなる

 ・ゼロにすることは難しい手戻りが起こったときの変更コストが、デザイナーとエンジニアの双方で高い


 つまり、それぞれの作業環境の差異が大きく影響していると考えられます。それぞれの職種においてプロフェッショナリズムが進んだ結果、得意とするアウトプットにも差異が生まれてしまうようになり、その差異がコミュニケーションコストになってしまいました。だからこそ、デザインツールから直接コードを書き出せるという響きは、このコミュニケーションコストを解決する銀の弾丸のように聞こえますが、実際のところ、決定的に広まるには至っていないように見えます。この理由を探るために、次節で実際の事例を見ていきます。

1. Twitter, @touyou_dev, https://twitter.com/touyou_dev

試し読みはここまでです。
この続きは、製品版でお楽しみください。