🐈
システム開発・運用体制まわりの雑感
結論
- システム開発・運用の method や tool はたくさんある
- 但し、銀の弾丸があるわけではない
- AS IS / TO BE に沿った method や tool を管理運用するべき
システム開発・運用の method, tool はたくさんある
- ソフトウェアが向き合う「課題」が大きく、広くなった
- ソフトウェアを使うヒトが「専門家」から「ユーザー」になった
- ソフトウェアの「開発効率」が上がったのと同時に「求められる価値提供の速度」が速くなった
ので、多くの手法、ツールが生まれた。
開発手法
-
ウォーターフォール
- Vモデル による開発で、初期要求・設計が正しい前提で進める
- 予め仕様を厳格に定められる、変更性が殆どない、長い開発期間を要するプロダクトに向いている
-
アジャイル開発
- 反復型開発 のひとつで、初期要求・設計は誤っている前提で機能追加・修正を繰り返す
- XP, スクラムなどの方法論があり、プログラムの変更許容、テスト容易性を重視
- 予め仕様を厳格に定められない、変更を求められる、短い期間で価値提供をするプロダクトで利用される
-
リーン開発
- スタートアップ時の手法でアジャイルに似ているが、プロトタイピング → 反響の確認 → 破棄 → プロトタイピングを繰り返して、要求される価値の本質を初期段階で突き詰めるスタイル
- アジャイルとの違い
開発・運用体制
-
ITIL
- 古くからある IT サービスマネジメントの実践ガイドライン
- ITILとは?
-
BizDevOps
- 企業の IT サービス運用に関する今風の考え方、ビジネス・運用・開発、それぞれの観点を包括的にエンジニアリングする
- SRE などの方法論がある
- DevOpsとは?
- 日立の DevOps 支援
ツール
- 課題管理 (プロジェクト管理・バックログ・バグトラッキング)
- JIRA, Planner, Backlog, Redmine
- ドキュメンテーション
- Office365, G suite, Confluence
- メッセージング
- メール, Slack, Teams
- ソースコード管理
- GitHub, SVN
- インフラ (サーバ・ネットワーク・ストレージ)
- AWS, GCP, Azure, データセンター
- CI/CD 継続的インテグレーション/継続的提供
- Circle CI, GitHub Actions, Jenkins
- 監視 (サーバ死活監視・パフォーマンス監視・エラー監視)
- Hinemos, NewRelic, DataDog, Sentry
- データ分析 (ロギング・ビッグデータ)
- Redash, BigQuery, Google Analytics
但し、銀の弾丸はない
- システム開発は偶有的/本質的な複雑性と、変更圧力との戦い
- 要求からくる本質的な複雑性 (価値そのものが内包するもの) は、エンジニアリングで減らさなければ増加し理解・制御できなくなる
- ヒトに依存する偶有的な複雑性 (価値提供の過程で生まれるもの) は、ツール・運用で回避しなければ遅滞・事故につながる
AS IS / TO BE に沿った method や tool を管理運用するべき
今と、将来にわたって解決したい課題、提供したい価値にあわせた手法を考える必要がある。
- 何が足りていなくて痛みがある/ないのか
- 何をもっと伸ばしたいのか
- 何をできるようになりたいのか
- どこまでを全体最適し、どこから先を部分最適 (属人) にゆだねるのか
各企業の取り組み
- 前職では
- システム受託開発会社 →
開発手法 > ウォーターフォール
+ツール > インフラ
くらいまで、納品で終わりだったため - 自社サービス運営会社 →
開発手法 > BizDevOps
+ツール
の全て
- システム受託開発会社 →
- IIJ社内におけるアジャイル開発 DevOpsへの取り組み
- 開発の品質を上げた7つの方法 - ソース管理、コード管理、テスト導入、開発環境の4つの視点から
Discussion