メインコンテンツまでスキップ

「【勉強会】チームで開発し事業を加速するための"良い"設計の考え方」に参加した

· 約3分
yumechi
Software Engineer

サポーターズ主催のオンラインセミナー「チームで開発し事業を加速するための"良い"設計の考え方」に参加しました。設計とはトレードオフの中でより良い状態を探索する創造的かつ論理的な活動であり、ドメイン・ソフトウェア・組織の三つの歯車を意識することが重要だという内容でした。

資料リンク

感想・学び

  • 設計 = トレードオフの中でより良い状態を探索する活動、その活動は創造的で論理的な動的な性質を持つ。多元的なトレードオフ
  • ロジカルに大切な要素を決め、その代わりに落とすものを決める
  • 事業の方向性の変更や、新しい技術の進出によって指標の優先度が下がったり、指標の両立ができるようになった
  • 「ドメイン」「ソフトウェア」「組織」の歯車を意識する(ドメインは法律などにより変化するが、ソフトウェア側からは変更しにくい)
  • 今の文化や今のコードはどうなのか、というのをメンバーがよくわかっていることなので、そこを無視してはいけない。AIの活用などでチームサイズを小さくし、コミュニケーションパスを小さくするというのも一つの方法
  • 現状と理想のギャップを埋めることで価値が出る
  • サービスの特性を知ることで、設計が決まることもある。特に非機能要件(パフォーマンス、信頼性、セキュリティ、など)
  • 大きい設計判断をする、数年後の未来を読み解いて設計することを考え抜くことは難しいことであるが、ある程度考え抜いてロジカルに決めないといけない(ロジカルな説得力が大事)
  • 判断基準を育てるため、多様な視点を持つ。そのためにインプットをしまくっておく、巷の設計論、他社の事例、技術トレンド、とにかくインプット
  • 言葉や概念を知っているのは役立つ。一方でぼんやりしている理解で伝わらないし、実践が難しい
  • いきなり価値を出すことを目指す、初手の実戦で価値が出せるとやり切りやすい。そのために要素を分解して、最小限の構成で進めることが大事

ドメインをよく見極めて非機能要件などを洗い出す、などじっくりと取り組む必要があるものだと思いつつ、AIによる組織体系の変化、それに伴う開発設計の変化もあるように感じました。 コミュニケーションパスを意識して、AIを活用したスモールチームで機能開発に取り組むなどは今後実践していきたい部分ではあるなと思います。 ドメインや組織にとって良い方向の判断となる選択肢は多いほうが良いので、インプットは積極的に行っていければと思います。やっぱり銀の弾丸みたいになるものはないんだなあと再認識。