Day24: 技術選定/アーキテクチャ設計で後悔しないためのガイドライン

https://qiita.com/hirokidaichi/items/a746062917595619720b

技術選定/アーキテクチャ設計で後悔しないためのガイドライン - Qiita

• ソフトウェアの規模やライフサイクルに応じて、技術選定やアーキテクチャ設計に常に慎重であるべきではないということです。
• ５年も１０年も拡張が続くことが十分に想定されている巨大なシステムであれば、必要に応じてアップデートがしやすいような設計を十分な時間をかけても価値があるでしょう。
• 悪影響を限定的にできるのかを常に考えるプロセスや組織的アプローチのほうが重要であるとも考えています。
• それ自体が責められるべきではなく、間違った意思決定を修正できないことのほうが問題なのです。
• 副作用
• 解くべき課題を明確にし、解決する。

取捨（しゅしゃ）	必要な箇所を取捨選択するための１種の考え方を提供するものです。
検討（けんとう）	だからといって組織だって議論・検討するようなものでもないのです。
手戻り（てもどり）	1万行(実際には空行やコメントを除いた実行行数で１万行)程度のソフトウェアであれば、リスク解決に用いる時間の割合や手戻りなどはかなり小さいことがわかります。
費やす（ついやす）	一方で、1000万行に及ぶ巨大プロジェクトでは全体の半分近くの時間を設計の検討に費やしてもお釣りが来るというのがこのモデルから見てとれます。
お釣り（おつり）
熟練（じゅくれん）
大まかな	大まかな傾向
生じた（生ずる）
責める（せめる）	それ自体が責められるべきではなく、間違った意思決定を修正できないことのほうが問題なのです。
副作用（ふくさよう）
審美眼（しんびかん）
手痛い（ていたい）
厄介（やっかい）
間接的（かんせつてき）
背後（はいご）	かならず背後に大きな社会的な課題や問題をはらんでいます。
交わす（かわす）

 

プロトタイピング/概念検証

ある技術的意思決定を行う際に、机上の空論になってしまうことが最も問題です。複数の選択肢やアプローチがあるのであれば、実際に動作するプログラムを書いてみることがもっとも検証として有効なケースがあります。

プロトタイピングを行う際に注意すべき点は、検証項目が表面的な「フレームワークの使い方」に終止してしまい、現実の問題解決とは離れた部分での検証ばかりをしてしまわないようにするという点です。プロトタイピングの目的は、問題解決に利用した際に発生しそうなリスクについて網羅的・実践的に露わにすることです。そのためには、実際に用いる場合の実システムの複雑な部分に向き合って検証していく必要があります。きれいで複雑でないサンプルケースの問題だけを説いても、リスクは暴露されません。せっかくプロトタイピングをしたのであれば、実業務を行うユーザーや開発者にも触れて貰う必要があるでしょう。

そして、さらに注意すべき点はプロトタイピング時のソースコードを基本的には破棄することです。プロトタイピングは、課題の洗い出し、リスクの暴露が目的なので、そのまま実運用に耐えるコードである必要はないのですが、しばしばプロトタイプをそのまま拡張して本番のシステムにしてしまいがちです。このような点にも注意しましょう。

• 課題の洗い出し、リスクの暴露が目的
• 問題解決に利用した際に発生しそうなリスクについて網羅的・実践的に露（あら）わにすること
• プロトタイピング時のソースコードを基本的には破棄する
• プロトタイピングをしたのであれば、実業務を行うユーザーや開発者にも触れて貰（もら）う必要があるでしょう

 

技術選定/アーキテクチャ設計における意思決定は、非常に難しく僕自身も多くの後悔をしてきました。最も大事なのは、そのような「失敗」をリカバリーできる体制やチーム、組織を作り上げることです。そのためには、その時考えたことや予測をしっかりと文書化し残していくことが大事になります。担当者が変わってしまったり、ツケを払うのが別の人物である可能性も十分考慮して、誠実な意思決定が行われていれば将来のチームメイトに対しての後悔は少なくなるはずです。

 

아키텍처, 기술 선정에 시간을 들인다고 정답은 없고 더 중요한건 그걸 해결하기 위한 조직문화이다.

과제를 오니언 모델로 정리한다.

リスクストーミング

学習コスト

プロトタイピング

 

 

• 실제 문제와 복잡도 기반 검증: 단순 샘플이 아닌, 실사용 데이터·환경을 반영한 프로토타입으로 리스크를 노출해야 합니다.
• 코드 폐기 원칙: 프로토타입 코드는 실 운영 수준이 아니므로, 본 시스템에 바로 확장하지 않고 필요 부분만 구조적으로 참고해야 합니다.
• 직접 체험&전파: 실제 작업자와 사용자에게 직접 사용하게 하고 반복 피드백 → 개선 → 재검증 흐름을 조직적으로 돌려야 합니다.

 

프로토타이핑의 목적은 빠른 검증 

- 얼마나 더 문제가 없는지를 파악하기 위한 과정

- 그래서 빨리 만드는 게 중요하고 AI 활용 가능

- 직접 써보게 하고 반복적으로 피드백을 받고 고치는것이 좋다.

 

---

1) 

様々な技術的な意思決定のための考え方

 

2) 아키텍처 설계에 얼마나 힘을 들어야 할까?

잘못되었을 때 해결하고자 하는 조직 분위기, 그리고 그것으로 부터 배움을 남겨두는 것이 중요하다.

 

技術選定やアーキテクチャ設計に常に慎重であるべきではないということです。

ソフトウェアの規模やライフサイクルに応じて、そもそも時間をさく必要がないということも多くあります。

 

５年も１０年も拡張が続くことが十分に想定されている巨大なシステムであれば、必要に応じてアップデートがしやすいような設計を十分な時間をかけても価値があるでしょう。

 

間違った(かもしれない)意思決定があったとき、それ自体が責められるべきではなく、間違った意思決定を修正できないことのほうが問題なのです。

実のところ意思決定そのものに失敗や間違いはなく、その意思決定の後悔に伴う学びをいかに効率よく得るかということがエンジニアとしての技術選定の審美眼につながるのでしょう。

将来のどのタイミングでこの副作用を解決したらよいのか、どのようにすればその悪影響を限定的にできるのかを常に考えるプロセスや組織的アプローチのほうが重要であるとも考えています。

 

3) 언어, 설계, 아키텍처, 라이브러리등의 선택은 모두  과제를 해결하기 위한것,

과제를 명확히 하는 것이 중요하다.

요구되는 과제를 명확히 정의하기 위해서는 양파 모델 혹은 다양한 고려 요소가 있을 것 같다.

 

사회적 차원: 법적인가, 커뮤니티 지원 받을 수 있나?

고객 차원: 코어 가치 만족하나? 등

 

ソフトウェアは課題を解決するためにあります。言語、設計、アーキテクチャやライブラリ・フレームワークの選定も何らかの問題解決のためにあります。

 

そのため、技術的な意思決定にあたって、課題が何であるかを明確にするべきであるというのは当り前に聞こえるかもしれません。

 

これらは要求のオニオンモデルと言われます。

 

まるで玉葱の皮を向くように中心部にいくにつれ具体的な問題になり、外側に行くにつれて抽象的な（解決方法の多数ある）ような問題になっていきます。

 

▶︎ 社会

倫理的、法的な要請に背いていないか。背くようなリスクがないか。

コミュニティを通じた支援が期待できるか。

 

▶︎ 顧客

顧客にとってのコアな価値とはなにか。

顧客のニーズの変化、マーケットの変化に対して対応できる手法か。

 

▶︎ 企業

業務負担、運用負担のかかるものではないか。

 

▶︎ システム&ソフトウェア 

それらを実現するために開発者はどのような設計にするか。

 

言い換えれば、影響範囲が広く、交換可能性が低い部分を限定的にする手法がアーキテクチャパターンだと言えます。

 

意思決定のスピードと「失敗」した場合の交換をしやすくするという方法をまず第一には考えるべきでしょう。

 

ライブラリは、「あなたのアプリケーション」の一部に組み込まれる「あなたのコード”が”呼び出す」して機能を果たすものです。

それに対して、フレームワークは、「あなたのアプリケーション」の一部に組み込まれて、「あなたのコード”を”呼び出す」ものです。

一般にフレームワークは、あなたのコードに特定のインタフェースを持つことを強制することで、ある種のアプリケーションを簡単・高速・安全に作成することを手助けします。

一般にフレームワークのほうが長期のライフサイクルでの意思決定になりますが、ライブラリは交換可能性が高い事が多いのです。

 

4) 

실무 담당자에게 의견을 물어보기 위한 질문들의 요건과.

그것을 어떻게 정리해서 핵심 목적을 파악하라!

 

ステークホルダーの要望や必要な観点をまとめていき、整理していきます。

どのような機能要望や観点が存在するのかを把握することができます。

 

そのため、ステークホルダーで聞くべきインタビュー内容を事前に整理しておくことが望ましいです。

 

システムを利用する業務担当者に対してヒアリングするのであれば、

現在の業務の目的はなんですか？定量的な指標をいくつか教えて下さい。

具体的にはどのようなアクションをしてそれらを達成しますか？

業務の目的の達成のためにボトルネックになることはなんですか？

上記のような業務に関わる目的から順番に聞いていくのもよいかもしれません。

 

5) 리스크 탐색

리스크에 대한 명확한 정의가 필요하다.

 

たとえば、現在のリードエンジニアが退職してしまい、別のメンバーだけで改善・保守しなくてはならなくなったら。

 

そういったソフトウェアシステムを開発していく上で、どこかのライフサイクルで起きるかもしれないような出来事です。

 

ここで発見されたリスクについて、一覧表にしてまとめ、発生確率（頻度や蓋然性）とアーキテクチャへの影響度にマッピングしておくとよいでしょう。

 

6) 새로운 기술을 배우는 것은 투자. 하지만 팀원들을 고려해서 적용해야 한다.

 

新しい技術を学んだり体得したりするのは、基本的には投資であってコストではないわけですし、

自分たちのチームだけの効率であれば、学習コストを一定程度無視して投資として新しいことに挑戦することは非常に価値のあることです。

あるいは、その習熟がまるでその人のキャリアプランを無視したものであるなども考える必要があるでしょう。

もしかしたら、そのときに足りないのはステークホルダーへの理解と共感なのかもしれません。

 

7) 

트레이드 오프를 생각해야 한다. 양립할 수 없는 가치가 있을 수 있다.

 

トレードオフとは、「何かを立てれば何かが立たない」という両立が難しい物事に対して使われます。

 

モジュール化して独立した変更がしやすい手法が求められている一方、

他の環境への移植や習熟コストのようなものはあまり考慮しなくても良いということが記述されています。

 

8)

 

実際に動作するプログラムを書いてみることがもっとも検証として有効なケースがあります。

プロトタイピングを行う際に注意すべき点は、検証項目が表面的な「フレームワークの使い方」に終止してしまい、

現実の問題解決とは離れた部分での検証ばかりをしてしまわないようにするという点です。

 

プロトタイピングの目的は、問題解決に利用した際に発生しそうなリスクについて網羅的・実践的に露わにすることです。

そのためには、実際に用いる場合の実システムの複雑な部分に向き合って検証していく必要があります。

 

せっかくプロトタイピングをしたのであれば、実業務を行うユーザーや開発者にも触れて貰う必要があるでしょう。

 

そして、さらに注意すべき点はプロトタイピング時のソースコードを基本的には破棄することです。

 

軽量なテキストベースのテンプレートを利用して、アーキテクチャ上の意思決定・設計判断を記録します。

そのときの意思決定に至った流れが明記され、時系列でわかることであとから追試・学習へと活かすことができます。

 

9)

最も大事なのは、そのような「失敗」をリカバリーできる体制やチーム、組織を作り上げることです。

そのためには、その時考えたことや予測をしっかりと文書化し残していくことが大事になります。

担当者が変わってしまったり、ツケを払うのが別の人物である可能性も十分考慮して、

誠実な意思決定が行われていれば将来のチームメイトに対しての後悔は少なくなるはずです。