今月は参加するイベントが、なぜかマイクロソフトさん関係に集中している気がします(笑) この週末に、はじめてハッカソンに参加してきました。本当にあっと言う間の２日間でしたが、チームメンバーが最高で、とっても楽しかったです。 過去には、サーバーやネットワーク機器の構築エンジニアとして、コーディングとは別世界で生きてきただけに、まさかハッカソンに参加する日が来るとは思っていませんでしたが、ハードウェアや仮想化技術がコモディティ化していく中、ソフトウェアを学ばないでどうする！という気持ち（焦りかも）が、参加の一つのきっかけでした。もっとも今はエンジニアでもないですが（苦笑）
今回のハッカソンは、実体験を通してDevOpsの考え方を、自ら楽しく実験する場所を提供いただくという、言うなれば「a DevOps journey」といった内容でした。 DevOpsというテーマはありましたが、制約事項としては手法やプラットフォーム・ツールに関しての最低限の縛りしかなく、ほぼチームの好み・要望で自由に選択できるとても自由な雰囲気で、学びの場として最高だったと思います。 当然何かを作成するので、ゴールを設け評価をするのですが、作品の完成度とかがゴールでなかったことも良かったです。
イベントの概要や雰囲気は、はまもつさんが、すでに書かれているので割愛で(^^; http://blog.hamamotsu.jp/entry/devopsjp-fukuoka2016
個人的な理解（超訳）
DevOpsの印象
- 何かツールを採用すればDevOpsというような話ではない
- 定着させるには、上層部に価値を理解してもらう必要がある。
- それなりに学習コストもかかる。
- 色々なプラクティス（知恵）の集まりから成っている。 開発だけでなく、リリースのプラクティスも多く、企業システムでいうとセキュリティ維持のためのパッチ適用など、応用ができそうなものもあると思う
DevOpsに至るまで
1) ウォーターフォール フェーズで進んでいくために、粒度がおっきいから、何かあったときの手戻り量もばかでかい 2) アジャイル コーディングフェースは小まめな確認が働いて大きな手戻りはないが、プロジェクトの一番最後にシステムテスト・負荷テスト等がっつり来て、でっかいリリースとなってしまう可能性が残っていた 3) DevOps リリースまで含めて、小規模に行うことで、手戻り最小化、リリースにミスしたときの影響範囲の最小化・局所化。 また、性能やサービス品質を測定し、改善を回していくという最終的なゴールもある。（コレがとてもいいと思う）
雑感
企業の情報システムというと、パッケージソフトウェアをオンプレミス環境の仮想化基盤に導入して、それをSIerにお願いして、いじって、いじって使い続けてきているという文化が多いと思います。そこには、DevOpsが効果的に活かせる場面はそうそうないでしょう。 でもそれらシステムも様々な理由（コスト、拡張性、セキュリティを保ちつつ社内外を結びつける難しさ等）で、徐々にクラウドを使った再構築を検討・採用しなければならない状況になってきたと思います。 この再構築タイミングが、今までの運用スタイルを変える良いチャンスに間違いなくなるので、DevOpsの考え方で合うところを取り込んた運用スタイルの再構築をしたら、とても素敵ではないでしょうか ３年間とか長めの時間軸で見ると、企業の情報インフラにおける競争力に差が付く主因は、クラウドとモバイルの活用、自動化技術となりそうな気がしているので、DevOpsの考え方は今、学んでおいて損はないと思いました。 という訳で、個人的には今回のハッカソンで学んだことを生かせる日が、今後来るのが楽しみです♪