Tweet
Tweet

Slide 1

Slide 1 text

設計できるエンジニアになるには

Slide 2

Slide 2 text

設計する例 MVCモデルを採用しよう

Slide 3

Slide 3 text

その設計の上で開発する例 ビューを実装しよう

Slide 4

Slide 4 text

「開発しやすい」を設計する視点 エンジニアが理解していることを理解する = 二次的理解

Slide 5

Slide 5 text

設計者とは何か システムを設計するエンジニア（設計者）は、その設計の上で開発する
エンジニア（実装者）と同じエンジニアが担うことも多いため、両者の区別
は曖昧になりやすいかもしれない しかし、システム設計における設計者と実装者の関係は、UIデザインにおける
デザイナーとユーザーの関係と同じである

Slide 6

Slide 6 text

デザインする例 ブックマーク機能を提供しよう

Slide 7

Slide 7 text

そのデザインの上で利用する例 投稿をブックマークしよう

Slide 8

Slide 8 text

「使いやすい」をデザインする視点 ユーザーが理解していることを理解する = 二次的理解

Slide 9

Slide 9 text

“UIデザインの思考は、システム管理画面はもとより、
APIや内部オブジェクトのインターフェース、あるい
は運用手順の設計等にも適用できる。これらは
インターフェースデザインというひとつのジャンルと
言えるかもしれない。つまり異なる二項のモデルを
透過的にする、中間項モデルのデザインである。” Manabu Ueno (@manabuueno) https://twitter.com/manabuueno/status/1605411200506155010

Slide 10

Slide 10 text

設計者の使命 将来のすべてのエンジニアが自分なりの方法でアイデアを実現できる
（＝開発しやすい）システム（＝インターフェース）を設計すること エンジニアがこの使命を果たすには、実装者としての自分から意識的に
抜け出し、エンジニアの置かれる状況（仕様、アーキテクチャ、
エンジニア自身）を客観視する「設計者の視点」を持つ必要がある

Slide 11

Slide 11 text

設計者の視点を体現するには → アーキテクチャを図解する

Slide 12

Slide 12 text

生態心理学によると 人間をはじめとする動物は、環境のさまざまな
要素から価値や意味（アフォーダンス）を受け
取り、その環境に適合した行動をとる これに従うと、エンジニアはシステムの構造や構成要素（名詞）を把握することで、さまざまな行動（動詞）の可能性を直感し、例えば
コードを理解したりアイデアの実現方法を模索したりといった、状況に適合した行動をとれるようになるといえる

Slide 13

Slide 13 text

アーキテクチャを図解しましょう アーキテクチャとは、エンジニアが使命を果たすために追加、更新、削除
する対象、すなわちシステムの構造や構成要素のこと システムの構造や構成要素を把握する＝メンタルモデルを構築するには、
図を見るのが効果的 エンジニアがメンタルモデルを構築したり共有したりできるように、
アーキテクチャを構成する「名詞」同士の関係が視覚的に理解できる図を
作成しましょう

Slide 14

Slide 14 text

設計者の視点を体現するには → メンタルモデルと一致させる

Slide 15

Slide 15 text

「開発しやすい」を保つための軸 “変更や拡張のアイデアはメンタルモデルから生まれる。
 一致していれば無理のない変更で実現できる。
 アイデアをすぐ実現できない設計は、メンタルモデルと齟齬がある”
 KOBA789 (@KOBA789) https://twitter.com/KOBA789/status/1605966954740600836

Slide 16

Slide 16 text

メンタルモデルと一致させましょう 「前面に出す」とも言い換えられる https://twitter.com/manabuueno/status/1309885609066942466

Slide 17

Slide 17 text

アーキテクチャを前面に出すとは アーキテクチャ図に現れる要素や存在が自明な要素は上位階層に露出する 例：アーキテクチャ図を見て自然に理解できる事項はすべて main 関数上で
確認できるように実装する アーキテクチャ図に現れない要素や存在が自明でない要素は下位階層に隠蔽
する 例：実際に実装してみて初めて気付くような事項は別の関数に切り出して
実装する

Slide 18

Slide 18 text

メンタルモデルと齟齬を生む行為 隠蔽すべきでない要素を隠蔽する可能性がある例 コードの行数が大きくなってきたことを理由に別の関数に切り出す コードの形状が似ていることを理由に共通化する 仕様の複雑性は仕様を変更しない限り取り除けない どうしても仕様が複雑ならその複雑性は正直に前面に出してメンタルモデルと
一致させるべき

Slide 19

Slide 19 text

その他の例：ディレクトリ構造を設計する 利用者を明確にした上で、彼らは何を直接追加、更新、削除することで
使命を果たすのかを分析し、その対象を上位ディレクトリに出す

Slide 20

Slide 20 text

まとめ

Slide 21

Slide 21 text

今回の内容 実は以前公開した内容でした https://zenn.dev/uenitty/articles/ca7c488adcc387

Slide 22

Slide 22 text

「それが世界の中の何であるか」を問う視点 “技術の本質は技術的なものではない”
 マルティン・ハイデガー ユーザーから見ればUIがシステムその
ものであり、その実現のために技術を
駆使してシステム全体が作られる 例えば我々にとって上水道システムとは蛇口のことである https://twitter.com/manabuueno/status/1310913207108694016

Slide 23

Slide 23 text

設計の本質を学べる本 オブジェクト指向UIデザイン（通称OOUI本） UIデザインが入り口だが、単なる手法を超えて
ものづくりや設計の本質を学べる名著 エンジニアなら就職するまでには読んでおきたい https://www.sociomedia.co.jp/10046

Slide 24

Slide 24 text

“真のシンプルさは、単に不要なものや装飾を省くだけでは生まれません。
それは、複雑さに秩序をもたらす作業なのです。” Jony Ive Apple - iOS 7 Feature https://youtu.be/j66Ji6VLV_Q?t=45