過激なエンジニア(エクストリームエンジニア)とは


はじめに

「エクストリーム・エンジニアへの道」というテーマでお話を聞く機会がありました。
その内容を参考にした記事の作成を通じて、
いま自分ができることは何なのか、今後自分がどうなっていくかを
整理していくことを目的とします。

講義内容

主にアジャイル開発の手法が取りあげられました。
従来のウォータフォール型とどこが違うのか、
その実態から最終的に将来どういった人物が
技術者として生き残っていくのかといったお話で
午前中は終了しました。

アジャイル開発について私が感じた従来型との大きな違い

従来のウォーターフォール型と大きく違う点としては
ユーザ(これからサービスを提供しようとしている顧客)と開発者が
一体となってプロジェクトを進めているという点でした。

私が知っているユーザや顧客というのは、外部に開発を委託して
請け負った業者が実際に対応していくものです。
当然、受注側には仕事を完了させる義務があり
責任範疇は受注側となります。

しかしアジャイル開発の現場では責任範疇についても異なっており、
ユーザが責任者となる点についても大きな違いです。

ただこれについてはどっちが良いかという話ではなく
環境によって適応していくしかないのが現状じゃないかなと思いました。

アジャイル開発と運用作業

講義を聞いていて、アジャイル開発は
アメリカで慣習化されていて先進的だと
感じたのですが、私が現場で経験した運用作業と
意外な共通点がありました。
それは2人ペアで作業を進めていくという点です。

アジャイル開発の現場で行われてる開発手法に
ペアプログラミングがあります。
これは運用の現場に置き換えるとクロスチェックで
運用作業を進めていく手法とよく似ているなと感じました。

ただ運用作業については定例化されているものが
ほとんどなのでスキル向上につながるかというと
そういうわけではない部分が残念です。

まとめ

かつてトヨタ生産方式で唱えられた「多能工」という言葉が
講義のなかで紹介されていました。
アジャイルエンジニアもこの考え方で、
アメリカのソフトウェア業界で広まっていったことなんだそうです。
なのでアジャイル開発という考え方の元ネタは日本人が発祥ということです。

ウォーターフォール工程が8割を占めている日本の
IT業界でも、現在は少しずつアジャイル化が進んでいるそうです。
そのため、昨今のような分業体制が無くなる可能性があるかもしれません。

そういったときに生き残るエンジニアが
「エクストリームエンジニア」ということなのでしょう。

わたしの今後の方針としては、継続的に週末を利用して個人でできる範囲で
学習を進めていくことと、いろんな人と会って得られる機会が
増えていくように行動を起こしていきたいと思います。

参考リンク(Qiita)

そもそもアジャイル開発ってなんだ
アジャイル開発時におけるプロジェクトの進め方(その1)
[翻訳] スクラムがアジア圏でうまくいかない4つの理由 - Scrum does not work here in Asia