orangeitems’s diary

クラウドで働くインフラエンジニアの日々の感想です(ほぼ毎日更新)。

これからのITを知りたい人はアジャイル開発を知るべき

f:id:orangeitems:20200226003604j:plain

 

アジャイル開発を知るべき理由とは

私は、インフラエンジニアでかつ、どちらかと言えばまだレガシーな世界にいるのですが、このところ、こんな言葉をよく聞きませんか?

・継続的インテグレーション
・テスト駆動開発
・バックログ
・スクラム、スプリント

これらはモダンな開発技法であり、かつこれからはKubernetesなどコンテナを利用した新しいインフラが支える、と言う声が大きくなってきました。

でも、どうにもピンと来なくて、いったい開発者は何をやりたいんだろう・・と思って時間を過ごしてきたのですが下記のIPAから出ている資料を見て腑に落ちました。

 

アジャイル領域へのスキル変革の指針 アジャイル開発の進め方(PDFファイル)

 

 

全体で34ページくらいの資料でスルスルっと読めます。

ぜひ、アジャイルをやったことのない人、しかも開発者だけではなくインフラエンジニアにも読んでほしいです。

開発環境やKubernetesなどの最近の進化は、全部この話をベースにしているということが良くわかりました。逆に言えば、アジャイルを知らずに、要素技術をいくら知っても、何のためにそれがあるのか断片的な情報ではさっぱり腑に落ちません。

何度か読んでもらえれば、いろいろ見聞きしていた新技術が、アジャイルのどこに当てはまるか合点がいくはずです。

 

考:アジャイル

アジャイル型の開発がウォーターフォール型に変わって人気になっているのは存じています。インフラエンジニアとしたら遠い向こうの話だとばかり思っていました。勝手に開発エンジニアが騒いでいるだけ・・だと思っていたらここ最近ブームとなりつつあり、それではこれまでの開発エンジニアやインフラエンジニアのような分業はどうなるのかということについて考えを巡らせてきました。

このアジャイルの考え方に染まるのであれば、

 

開発チーム=

実際に開発を行うチームのことで、開発者たちを指す。従来型では、役割ごとに、タスクや役割が決まっているのが一般的である。スクラムでは、ビジネスアナリスト、プログラマー、テスター、アーキテクト、デザイナーなどの明示的な区分けはない。個人の専門分野はあってよく、むしろ強みを持ち寄り、その垣根を超えて貢献しあう。機能横断的な様々な技能を持った人がプロダクトを中心に集まり、自律的に行動する。開発チームはバックログに入っている項目を完了状態にし、プロダクトの価値を高めていくことに責任を持つ。

 

という、概念の中に入り込む必要があるのでしょう。つまり、これまではインフラしかやりませーん、で良かったのが、開発チームの中でインフラを活かして貢献するという立場になります。チームの中でインフラ担当、と言い切るのではなく、インフラの強さを活かしてチームで活躍するというニュアンスとなっています。

これが、あのコンテナの世界の、インフラと開発者が曖昧な世界を作り上げている根拠なんだと理解しました。いいかどうかはともかくとして、この話と一致します。

何となくこの、アジャイルの開発チームという役割が見えにくい一単位と、今のモダンと言われているKubernetesのもやっとしているところが完全一致しているように思えてなりません。

ビルドとかデプロイとか言われているところも、同じですね。そうか、Kubernetesやコンテナと、アジャイルはこんなに仲がいいのねと感心した瞬間でした。

ちなみに、プロダクトオーナーと言われる存在は、営業とプロジェクトマネージャーを足したような存在だな、とも思いました。スクラムマスターは、PMO(プロジェクトマネジメントオフィサー)にも似ているな、と。

開発チームのリーダーが、プロジェクトリーダーになりそう。

バックログという言葉自体は、課題管理ツールとして使っていたバックログで認知はしているものの、プロダクトの面と、スプリントの面で両方課題管理するんだというのはまぁこれはピッタリ当てはまるので、何も違和感はありません。

ということで、アジャイルとは言え実際のウォーターフォールでのプロジェクト管理とはそこまで乖離はありません。ただ上流から下流へ一気に降ろすのではなく、ぐるぐる回し続けるということの具体的根拠がこんなに短時間で学べる資料はなかなかないなと思っています。

一方で、このスキルセットが「ぐちゃ」っとなっている開発チームの中でどうやってコラボレーションしていくかは想像しずらく、例えばインフラエンジニアの私はどういうふうに強みを出していくのか、というところは経験してみる必要があるのかもしれないな、とも思いました。逆に言えば、一人で小さなスプリントを廻すようなことを疑似体験、つまり開発からインフラ・デザインまで全部ひとりでやってみれば何かつかめそうな気がしました。

このように、アジャイルと、Kubernetesやコンテナによる開発、そしてクラウドが協調することで、モダンなことができるんだということを理解しました。

 

すごく気になること

アジャイルを知ることの大事さ、をまとめましたが、そのうえで大変気になること。昨今、企業がどんどんテレワーク/リモートワーク体制に入っているのですが、これはアジャイル開発にとっては非常にマイナスだと思います。

フルリモートで、スプリントがまず回るんだっけ?という素朴な感想です。メンバー単位で役割分担をあいまいにしているために仕事の振り分けが非常にやりにくそうに思いました。

また、デイリースクラムするにしたって、リモートで膝を突き合せた議論は本当にできるんでしょうか。

プロダクトオーナーは、開発者と密に情報交換し、プロダクトバックログのリファインメントが心地よくできるのでしょうか。また、なかなかステークホルダーとも会いにくくなるだろう・・と。

 

自律的なチームで、人の能力を最大限に発揮する

アジャイル開発に限った話ではありませんが、組織やプロジェクトにおいて一番大切なものは 人 です。

自動化が進んでも、やはり人間でなければできないことはたくさんあります。特にアジャイル開発では、ムダな作業を極力減らし、空いた時間で人間の能力を最大限に活用できるようにすることが求められます。

 

 とあるように、人のつながりが大切っぽいアジャイルに対して、昨今のリモート化は非常に影響があるのではないかな・・と思いました。

ウォーターフォールで定型的に仕事をこなしていれば、リモートで済むのは大体わかるのですが・・。このアジャイルは特に、その場にチームメンバーが一緒にいるからこそ、強い開発チームが醸成されるんじゃないか。そしてプロダクトオーナーやスクラムマスターが機能するのでは。そしてステークホルダーに密な更新を共有できるのでは・・。

そういった意味で、アジャイルがこれからどうなっていくのは興味を持っています。2020年。つまづくのか、それともITを活かしたリモートワークがアジャイルを乗り越えるのか。

これだけのことを考えさせてくれるぐらい、いい資料なのでぜひ、お時間があるときにお読みください。