システム内製の原則 / principles-of-in-house-system-development

ラクス様主催の勉強会のLT枠で発表させていただきました(https://rakus.connpass.com/event/161744/)

Transcript

1. システム内製の原則 @tunemage
2. 自己紹介 • つねまげ（@tunemage） • 現職（1年半） • 製造業の社内SE的なポジション（研究開発も少し） • 社内基幹システムの開発・運用がメイン • 前職（6年） • ERPパッケージ開発 • それ以前 • Webやスマホアプリなど色々
3. •昨年、スクラッチ開発の社内基幹システムをロー ンチしました •本日は開発の中で意識した「原則」についてお話 します
4. 開発の流れ • 4〜6月（アーキテクチャ選定・基本設計・参照実装） • 2人体制（もう1人のメンバーがフロントエンドに明るくて助かりました） • 画面設計・DB設計・ライブラリの検証・クラウド環境の選定・最初の2画 面実装 • 7〜9月（機能実装） • 1.2人体制 • 4画面 ・共通コンポーネント・CI • 10〜12月（追加開発） • 1人体制 • 追加2画面・細かな要望&不具合対応・ユニットテスト導入
5. 構成 • 機能 • 画面✕8 • 帳票✕4 • CSV出力✕2 • システム構成 • サーバーサイド • Kotlin (一部Java) • Spring Boot • クライアントサイド • TypeScript（結構JavaScript） • NuxtJS • プラットフォーム • GAE（一部Heroku）
6. •比較的少ないリソースの中で、曲がりなりにもリ リースにまで辿り着けた •その中で大事にした原則は2つ
7. 原則①YAGNI（ You ain't gonna need it ） • 手を抜ける箇所は絶妙に手を抜く • 変更コストの高い部分に集中 • ただし、単なる付け焼き刃はNG
8. 原則②機構と方針の分離 「計算機科学における設計原則の1つ。機構（操作の認可と資源配分 を制御するシステム実装部分）は、どの操作を認可するかやどの資 源を割り当てるかといった決定を行う際の方針を表すべきでない （あるいは過度に制限すべきでない）という考え方である。 （Wikipedia）」 • よく分からんので具体例を（次ページ）
9. 実際の例）簡易帳票エンジンの実装 見積データ 帳票エンジン Excel テンプレート 方針 機構 出力帳票
10. 原則②機構と方針の分離 • 機構（エンジン）側は方針（条件分岐・レイアウト等）を意識し なくて良い • ハードコーディングによるif文地獄に陥らない • メンテナンス性向上 • 帳票エンジンの他にも、部署ごとに異なる作業工程の定義や権限 まわりでも応用しています
11. 原則②機構と方針の分離（その他の例） 機構 方針 カードキー カードリーダー・通信プロトコル セキュリティサーバの権限データ Maven・npm等 実行エンジン pom.xml、package.json 会計システム 仕訳エンジン 勘定科目マスタ 承認申請機能 画面コンポーネント 権限マスタのデータ ワークフロー ワークフローエンジン ワークフローの定義
12. まとめ • YAGNIと称した付け焼き刃はNG • 可変ポイントを見極めて適切な役割分担を促す設計が重要 • 業務ドメインと技術ドメインの全体感を見る • まだまだ未対応の問題は山ほどあるので楽しみです
13. 参考文献 • マルチパラダイムデザイン（ジェームズ・O. コプリン） • 機構と方針の分離（Wikipedia） https://ja.wikipedia.org/wiki/%E6%A9%9F%E6%A7%8B%E3%8 1%A8%E6%96%B9%E9%87%9D%E3%81%AE%E5%88%86%E9 %9B%A2