Agile も DevOps も銀の弾丸なんかじゃない

……と、のっけから噛みつかれそうなタイトルを掲げてみたのですが;、ここ最近、立て続けて数件、「いやそれはアジャイルとか無理だろ;」的な話があって、ちょっとエントリを書いてみようかと思った次第。どんな話だったのかというと、 アジャイルとか DevOps やれば必ず開発生産性上がるんでしょ? → そんなわけないでしょ;。 これからの開発は当然アジャイルとか DevOps でしょ! → そんなわけないでしょ;。 みたいな話;。2 年ほど前に、「続・拝啓『変わらない開発現場』を嘆く皆様へ ~ ウォータフォール & アジャイル編~」というエントリを書いたのですが、その補足的な意味合いも兼ねて、少しまとめてみようと思います。正直、当たり前すぎる話なので、その道のプロな方は「ふ~ん」と読み流してください;。 [アジャイルや DevOps を活用することによる ROI 最大化の注意点] のっけから結論を書いてしまうのですが、アジャイルや DevOps をエンプラ系プロジェクトに適用してメリットを得たい場合には、以下 2 つの点に特に注意する必要があります。 簡単に言えば、十把一絡げにアジャイルや DevOps を適用してもうまく行くわけがなく、これらの手法は決して銀の弾丸ではありません。しかし、なぜこれらが銀の弾丸ではないのか、またどんな条件があればアジャイルや DevOps のメリットが最大化されるのかは、意外に端的に語られていないため、軽く説明してみたいと思います。 [アジャイル開発 vs ウォータフォール型開発] モノづくりの観点から考えると、ウォータフォールとアジャイルは、計画型/適応型のトレードオフの関係で捉えることができます。このため、それぞれ請負向き/内製向きという特性があることは、以前のエントリでも解説しました。日本の開発現場では、両者は二者択一の文面で語られることが多いのですが、日本のエンプラ系開発現場においてより良い開発を目指すためには、両者をミックスした開発プロセスのテーラリングが必要になります。 しかし、このような説明だとなかなかしっくりこないと思いますので、ぶっちぎりの適応型アジャイル(ここでは仮に「フルアジャイル」と呼ぶことにしましょう)がどのようなものなのかを考えてみたいと思います。 [完璧(?)なアジャイル開発について] ご存じのように、アジャイル開発の背後には、「アジャイルソフトウェア開発宣言」と「アジャイル宣言の背後にある原則」がベースラインの考え方として存在します。原典そのまま引用すると、こんな感じです。 しかし見ていただければわかる通り、これらは具体的に何かの(技術的)手法を定義しているわけではなく、ある意味、ソフトウェア開発の『理想像』や『思想』を語ったものに近いです。実際、アジャイルを実践する開発現場では、日々、自律的な模索と改善が続けられ、よりよい開発技法を目指して進化を続ける……これこそがアジャイルの真価ではないかと思います。 ……が、ぶっちゃけこれだと煙に巻かれた気がするなんだかよくわからないのも実際のところです;。以下は完全に私の私見なのですが、実際にこれらを目指して優れたアジャイル開発を実現している現場では、特に以下の 4 つをきっちり実践しているように思います。(この辺は皆様のご意見をいただきたいところですが、私の感覚として。) ちょっとだけ補足をすると、以下の通りです。(MVP アプローチは極めて重要なので後述) 内製開発 一般的に請負型ウォータフォール開発では、受発注関係による利害関係が生じるため、請負契約の後は、発注側は「いかに変更・修正を突っ込むか」、受注側は「いかにそれを突っぱねるか」という不毛な争いが生じます。 (特に大規模開発においては)請負契約は、確実に成果物責任を以て遂行させるという観点において極めて重要なものですが、一方で、関係者全員が同じ方向を向いてゴールを共有することが時として難しくなる元凶にもなり得ます。 内製開発であれば関係者全員が同じ方向を向いてゴールを共有することが容易ですが、その一方で、全員がプロフェッショナルであり、オープンかつ自律的な活動・改善ができる(言い換えれば全員が大人である)ことが求められます。(大規模開発だとそれだけの数のプロフェッショナルの頭数を揃えることが困難なケースが多いです。) データ駆動型開発(運用環境第一主義、Production First Mindset) 例えば仕様案として A, B…

0

.NET Framework における時差情報(サマータイム)の取り扱い

実は先日、8/1 に社内で異動しまして、18 年間続けてきたコンサルタントからクラウドソリューションアーキテクトにロールチェンジしました。さてこの blog もタイトルを変えるべきかどうなのか……とかまったり考えていたら、ここ数日、びっくりするような話題が飛び込んできました。 「サマータイム導入はコンピュータシステム的に難あり」は本当か サマータイム実施は不可能である 2020 年のオリンピックに向けて、限定的(または恒久的)にサマータイムを導入する、というもの。話を聞いたときに耳を疑ったのですが、いやもう絶対に不可能だろう、と私も思いました;。上記に取り上げた立命館大学の上原さんのスライドは非常によくまとまっていて、ホントこれ、と思いましたが、一方で Windows をはじめとするコンピュータシステムでそもそもサマータイムがどのような取り扱いになるのかを知らない人は多いのでは?、と思います。 実はずいぶん昔に国際化対応アプリケーションの開発方法を調べたことがあり、そのときにタイムゾーン(時差情報)をどのように取り扱うのか、をまとめたことがあります。おそらく皆様の参考になるのでは、と思いますので、若干手直しして情報共有してみます。10 年以上前の資料なので、画面のスナップショットがまさかの XP や Vista(!)だったりするのはご容赦、なのですが、考え方は特に変わっていないので、今でも普通に通用する内容かなと思います。(もし何か変わっているところがあったら教えていただけると嬉しいです;。) .NET Framework におけるタイムゾーンの取り扱い   ちょっと長いスライドなので、夏時間(サマータイム)という観点から要点を抜き出すと、以下の 2 つがポイントです。 ① Windows OS 上では、夏時間はタイムゾーンの変更として取り扱われる (p.10) 夏時間に入る=別の国のタイムゾーンに移動したのと同じようなこととして扱われます。イメージとしては、日本国内にいながら、時差のある国へ海外旅行に行ったのと同じような取り扱いになる、と考えるとわかりやすいかと思います。(なお、夏時間などのタイムゾーン情報はレジストリ情報として管理されており、Windows Update によりメンテナンスされています。なので本資料ではカバーしていませんが、 .NET Core で作ったアプリを Linux 上で動作させたりする場合にはまた別の注意が必要になってきます。) ② DateTime 型の加減算処理を行う際は、必ず UTC を介して行う (p.35, 36) .NET Framework 上で日付をプログラミングする際、DateTime 型でプログラミングされている方が多いと思いますが、DateTime 型はオフセット値(UTC からの時差)を持つことができません。DateTime 型は、「見た目の数値」をそのまま加減算処理してしまうため、夏時間前後でのオフセット値の変化に対応できません。このため、DateTime 型で加減算処理を行う場合には、必ず UTC を介して計算する必要があります。(ちなみにこの問題に対応するために導入されたのが DateTimeOffset 型です。)…

1