$30 off During Our Annual Pro Sale. View Details »

設計できるエンジニアになるには / Design Guidelines for all engineers

Ueni
June 02, 2023

設計できるエンジニアになるには / Design Guidelines for all engineers

あまてく・CAC座談会 2023/06/02

---

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

設計する例

MVCモデルを採用しよう

その設計の上で開発する例

ビューを実装しよう

「開発しやすい」を設計する視点

エンジニアが理解していることを理解する = 二次的理解

設計者とは何か

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

デザインする例

ブックマーク機能を提供しよう

そのデザインの上で利用する例

投稿をブックマークしよう

「使いやすい」をデザインする視点

ユーザーが理解していることを理解する = 二次的理解

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

https://twitter.com/manabuueno/status/1605411200506155010

設計者の使命

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

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

生態心理学によると

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

アーキテクチャを図解しましょう

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

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

「開発しやすい」を保つための軸

“変更や拡張のアイデアはメンタルモデルから生まれる。
 一致していれば無理のない変更で実現できる。
 アイデアをすぐ実現できない設計は、メンタルモデルと齟齬がある”
 KOBA789 (@KOBA789)

https://twitter.com/KOBA789/status/1605966954740600836

メンタルモデルと一致させましょう

「前面に出す」とも言い換えられる

https://twitter.com/manabuueno/status/1309885609066942466

アーキテクチャを前面に出すとは

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

メンタルモデルと齟齬を生む行為

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

その他の例:ディレクトリ構造を設計する

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

まとめ

今回の内容

実は以前公開した内容でした

https://zenn.dev/uenitty/articles/ca7c488adcc387

「それが世界の中の何であるか」を問う視点

“技術の本質は技術的なものではない”
 マルティン・ハイデガー
ユーザーから見ればUIがシステムその
ものであり、その実現のために技術を
駆使してシステム全体が作られる

例えば我々にとって上水道システムとは蛇口のことである

https://twitter.com/manabuueno/status/1310913207108694016

設計の本質を学べる本

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

https://www.sociomedia.co.jp/10046

“真のシンプルさは、単に不要なものや装飾を省くだけでは生まれません。
それは、複雑さに秩序をもたらす作業なのです。”

Jony Ive

Apple - iOS 7 Feature https://youtu.be/j66Ji6VLV_Q?t=45

Ueni

June 02, 2023
Tweet

More Decks by Ueni

Other Decks in Programming

Transcript

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

    View Slide

  2. 設計する例

    MVCモデルを採用しよう

    View Slide

  3. その設計の上で開発する例

    ビューを実装しよう

    View Slide

  4. 「開発しやすい」を設計する視点

    エンジニアが理解していることを理解する = 二次的理解

    View Slide

  5. 設計者とは何か

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

    View Slide

  6. デザインする例

    ブックマーク機能を提供しよう

    View Slide

  7. そのデザインの上で利用する例

    投稿をブックマークしよう

    View Slide

  8. 「使いやすい」をデザインする視点

    ユーザーが理解していることを理解する = 二次的理解

    View Slide

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

    https://twitter.com/manabuueno/status/1605411200506155010

    View Slide

  10. 設計者の使命

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

    View Slide

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

    View Slide

  12. 生態心理学によると

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

    View Slide

  13. アーキテクチャを図解しましょう

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

    View Slide

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

    View Slide

  15. 「開発しやすい」を保つための軸

    “変更や拡張のアイデアはメンタルモデルから生まれる。
 一致していれば無理のない変更で実現できる。
 アイデアをすぐ実現できない設計は、メンタルモデルと齟齬がある”
 KOBA789 (@KOBA789)

    https://twitter.com/KOBA789/status/1605966954740600836

    View Slide

  16. メンタルモデルと一致させましょう

    「前面に出す」とも言い換えられる

    https://twitter.com/manabuueno/status/1309885609066942466

    View Slide

  17. アーキテクチャを前面に出すとは

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

    View Slide

  18. メンタルモデルと齟齬を生む行為

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

    View Slide

  19. その他の例:ディレクトリ構造を設計する

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

    View Slide

  20. まとめ

    View Slide

  21. 今回の内容

    実は以前公開した内容でした

    https://zenn.dev/uenitty/articles/ca7c488adcc387

    View Slide

  22. 「それが世界の中の何であるか」を問う視点

    “技術の本質は技術的なものではない”
 マルティン・ハイデガー
    ユーザーから見ればUIがシステムその
ものであり、その実現のために技術を
駆使してシステム全体が作られる

    例えば我々にとって上水道システムとは蛇口のことである

    https://twitter.com/manabuueno/status/1310913207108694016

    View Slide

  23. 設計の本質を学べる本

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

    https://www.sociomedia.co.jp/10046

    View Slide

  24. “真のシンプルさは、単に不要なものや装飾を省くだけでは生まれません。
それは、複雑さに秩序をもたらす作業なのです。”

    Jony Ive

    Apple - iOS 7 Feature https://youtu.be/j66Ji6VLV_Q?t=45

    View Slide