心理的安全を担保するために、友達同士で設計について語る会を開いた

はじめに

おばんです、最近腰が痛くて爆発🚀💥している田中です。

今日は心理的安全を担保した設計の勉強会をやりました。 コンセプトはこんな感じ。

「設計」というと「怖い」という語がうしろにきがちなテーマなので、見知った人を集めて小規模に、心理的安全性を高めつつやろうと思います。 解釈が合ってる、間違ってるとかは気にせず、気軽にYATTEIKI。

設計の話ってマサカリが飛び交いがちで、いろんな人のいろんな解釈があって怖いということには共感していたので、「じゃあひとまず友達同士でやったら、心理的安全を担保しつつ、認識のすり合わせとかできるのでは?」と思ったのでやりました。

参加者の一人であるハゼさん(@haze_it_ac)もまとめを書いてくれました。

hazediary.hateblo.jp

やったこと、話したこと

自己紹介

  • 初めてリアルで顔を合わせる人同士もいたので、名前とidを言ってもらった
  • 普段やっていること、得意とすることによって「設計」という言葉に持っているイメージは異なると思ったので、技術領域とかを言ってもらった
  • 主な参加者の技術領域のキーワードは次のような感じ
    • iOS, Webフロント, バックエンド, Jenkins, AWS, Unity
    • Swift, Go, Python, Java, C#, PHP

設計とは

  • いろんな種類の設計がある
  • 設計にもいろいろあるので、どの設計の話か絞って、その設計に必要なものは何かから話がしたい
  • たとえば
    • アプリケーション設計
      • GUIに関する知識
      • プラットフォームに関する知識
    • インフラ設計
      • ネットワークに関する知識
      • セキュリティに関する知識
    • 「どこを専門にするかの話はあるけど、それぞれ関連しないわけでもないので、知識はあったほうが良いよね」という話も出た
  • 参加者がアプリケーションエンジニアが多かったので、ひとまずアプリケーション設計という単位に絞って話を進めることになった
  • この前提をふまえて、みんなはアプリケーション設計について何に困っているの?をざっくばらんに話していくことになった

フレームワークに依存したコードが辛い問題

MVホニャララがわからん問題

  • 「GUIアーキテクチャ」と「システムアーキテクチャ」という分類がある
  • GUIアーキテクチャ
    • MVC, MVP, MVVM, Flux, Reduxなど
    • UIに重きを置いてパターンの分類
      • Model: 画面に関係ないものすべて
      • View: 画面の表示
      • Controller/Presenter/ViewModel: ModelとViewの間でどうやり取りするか、どうデータを同期させるかなど
  • システムアーキテクチャ
    • ヘキサゴナル, オニオン, クリーンなど
    • UIよりも大きな範囲であり、Modelの部分にどういうパターンをあてはめるべきかまで語られている
    • layerという概念もあり、描画に関わる部分・アプリケーション固有の部分・外部のシステムとつながる部分・データそのもの まで語っている
  • なぜパターンで混乱するのか?
    • 人によって解釈が違うから
    • 例えばMVPの中でも色々な形があり、それが広まるごとに人々は誤解していく
    • 原点と、開発メンバー間で簡単にでも、コードに落とし込んで認識を合わせるのが大事
      • データの同期方法、
      • データの置き場所など
  • GUIアーキテクチャのパターンはいろいろあるけど、データの同期方法と、どこにどういうデータを置くかの違いを把握していくとわかりやすい
  • 具体的な書き方がわからん!問題
  • GUIアーキテクチャとシステムアーキテクチャの違い
    • サーバーサイドとクライアントサイドで関心が違う

アーキテクチャの管理をどうやっていくか問題

  • 依存関係の把握とか
  • コードレビューでカバーする
    • 組織がスケールしない場合はこれで回る
    • 「強いレビュワーがやめたらどうなる?」
      • 「知らんのか」
      • 「組織が死ぬ」
      • 正確には強いレビュワーが辞めてしまう状況が出来てしまったら、組織が死んでいるという話
  • ドキュメントでカバーする
    • ドキュメントの解釈違いも発生する...
    • そもそもドキュメントが古いとか、足りないとか...
  • レビューのタイミング
    • 実装する前のレビュー
    • 実装した後のレビュー
    • 実装する前のレビューの認識が合っていなければ、実装した後のレビューも合わないよね
    • 実装した後にレビューすると、設計がダメだった時の手戻りコスト高いよね
    • Design Doc
    • コードの近くにREADMEを置いて設計の話をまとめておく
      • 各パーツの大本となる部分のディレクトリに置いておく
      • 少なくともその時点での設計の意思決定の経緯をまとめておける

とまあ、こんな話をとりとめもなくざくざく話していったりしました。

開催して感じたこと

  • 思ったことを言いやすかった
  • iOSアプリ設計本は書いたけど、準備なしで口頭で喋るときにまだうまく言葉が作れていない部分があることがわかってよかった
  • バックエンドのエンジニアにとってGUIアーキテクチャはなじみがない
  • リモート参加の人向けの配信は、小規模であれば機材を強化して準備すれば出来そう(リモート参加の人がいた)
  • 設計の経緯や判断をどうやってまとめていくかという方法論が知れてよかった
  • GUIアーキテクチャの勘所みたいなのは、どこかで整理して発表してもよさそう
  • 事前にもう少し「設計で困っていることはなんですか?」的な話をまとめておいてもよかったかも