今日のはてブ(2017/01/11)(3)
IT屋の端くれとして仕事をしていると血圧が上がり健康に良くありません。伊達要一です。
システムの継続的開発による陳腐化の防止――その手段としてのDevOps
システム開発もシステム運用もインフラ周りも一通り触ったことがある立場からすると色々と趣深いものを感じてなりません。
DevOpsの究極は運用グループがなくなること? AppDynamicsの事例にみるDevOps | Think IT(シンクイット)
- [Impress]
- [ThinkIT]
- [システム開発]
- [DevOps]
- [U-NEXT]
- [KDDI]
DebOpsはここに出ているような消費者向けサービスでの適用が今のところ主流だけど、むしろユーザ系SIerのような分野の方が向いている気がする。
2017/01/10 09:32
DevOpsという開発手法自体はアジャイルソフトウェア開発や継続的インテグレーションとも関係性が強いので、単体で論評することにそもそも違和感を覚えてならないところがあります。
それはさておき、こういった手法は主にWeb系の業界で使われることが多くてSIer界隈――とりわけユーザ系SIerなんかではプレーヤーにもよるところではありますが遠い話に感じるところです。実際のところユーザ系SIerの主力業務は財務・経理系の基幹システムなんかの運営が中心で基本的には「枯れた」仕組みの中で動くことが多くてDevOpsのようなチョコチョコと変えていくような手法は馴染まない部分なのは確かです。
ただ、そういった基幹システムなんかは極論すればパッケージをドンと導入してお終いの世界であって、そこで企業の競争力強化に繋がるような性質じゃなくてIT屋の正道からは外れているんですよね。むしろ現場業務に近いところでフォースマルチプライヤーとして働くようなタイプのシステムこそがIT屋の正道だと思っています。もちろん細かいシステムが乱立することが適切か? ということについては議論が必要だけども、何でもかんでも大きな大福帳で管理出来るほど現場業務というのは単純な話じゃない。そういった部分をサポートしてフォースマルチプライヤーとして機能するようなものを継続して作り上げていくことが重要なんじゃないかと思う次第です。
この前提に基いてDevOpsのような開発手法を見てみると非常に馴染みやすいんですよね。現場に近くにある程度ITプレーヤーを常置しておいて、短いスパンで必要な機能や不要な機能を改廃していくことをしていくことでタイムリーにフォースマルチプライヤーを提供していくということは、むしろWeb系の界隈よりも分かりやすく思えます。まあ、私自身がWeb系界隈をよく理解していないというのも大きいんですが。