VOYAGE本でフルサイクル開発者( Full Cycle Developers )を知って、考えた
ソフトウェア開発業界に10年以上携わっていますが、
私は明確になりたいと思う職種がありませんでした。
私がやりたいことは多いです。
- ユーザーの声を聞いて、何が課題を発見・解決したい
- フロント・サーバサイドを含めてシステム設計・開発したい
- デプロイフロー・保守においても取り組みたい
ウォーターフォールでいうところの
- 要件定義
- 設計
- 開発
- テスト
- リリース
- 保守
この全て開発工程に関わりたいと思っていますが、
これにあたる職種はない1認識でした。
先日購入した『Engineers in VOYAGE ― 事業をエンジニアリングする技術者たち』で
フルサイクル開発者という職種を知り、この職種を目指したい気持ちとなりました。
この記事では、フルサイクル開発者について調べた際のメモを書き残します。
参考資料
先にお世話になったものや、
フルサイクル開発者に触れている資料をおいておきます。
個人的におすすめ(特に参考になったの)は、
Full Cycle Developer ~ さういうエンジニアに私はなりたい~ - ナガモト の blog
の記事です。
- 出典
- 本
- ブログ記事
- Podcast
- スライド
フルサイクル開発者( Full Cycle Developer )とは
Full Cycle Developer ~ さういうエンジニアに私はなりたい~ - ナガモト の blog
の記事でもわかりやすく述べられている通り、
ソフトウェアのライフサイクル全体を担うエンジニアのことを指します。
成功させるには?
Netflixでは、
以下の体制でフルサイクル開発者の体制を実現させたとのことです。
- 集中型チーム(スペシャリスト): 開発者ツールの開発
- フルサイクル開発者: 開発ライフサイクルを回し、開発者ツールを使う
開発者の考え方を統一する
ただしこの体制を成功させるために、
フルサイクル開発者の考え方を変えることが不可欠だったようです。
https://techlog.voyagegroup.com/entry/2019/02/04/171325 から引用
フルサイクル開発者モデルを取り入れるには考え方を変えることが求められる。ある開発者が活躍の場として主に設計と開発、そして時々はテスト、と考えたとしよう。この見方は運用を邪魔者とみなし、"本当の仕事"に早く戻るために運用やサポートの問題に対して短期的な視点での対応をすることに繋がる。しかし、フルサイクル開発者の"本当の仕事"はライフサイクル全てにわたる問題を解決することだ。
自分の今の担当領域はアプリケーション開発です。
日頃、タスクを進める中で、
- こっから先はQAにお願いしよう(他の開発を進めよう)
- ディレクターさんにユーザーと仕様詰めをお願いしよう(他の開発を進めよう)
のようなシーンが思い浮かびます。
これらを当事者意識に変え、実施および改善をおこなっていく必要があります。
「フルサイクル開発者としての取り組みに価値がある」ようにする
https://techlog.voyagegroup.com/entry/2019/02/04/171325 から引用
このモデルを成功させるためには、チームはそれが価値あるものになるよう真剣に取り組む必要があるし、コストについても意識的でなければならない。
開発メインだった場合は、以下のようなコストが追加されます。
- ビルド・デプロイ周りの管理コスト
- 保守(本番環境)対応コスト
- 不得意領域やツールのトレーニングコスト
- 集中型チームとのコミュニケーションコスト
個人だけではなくチーム全体が対象。
また、担当領域が増えるということは、
以前より専門的な学習・仕事が行える機会が減少するため、
スペシャリスト志向の方には辛く感じるかと思います。
おわり
フルサイクル開発者とは、
個人でなくチームとして機能するものと理解しました。4
自分は「ユーザーと近い位置で仕事をしたい」という気持ちから
フルサイクル開発者になりたいと興味を持ったのですが、間違っていました。
が、職種名関係なく、
フルサイクル開発者という手法を学んだだけでも良しとしたいと思います。