このエントリは DevLOVE Advent Calendar 2014 「越境」 の 1/21 のエントリです。もう何日目かわかりませんｗ
僕は 11/12 にも書いたのですが、今月転職（＝越境）したので 2 回目を書くことにします。
ちなみに 1 回目のエントリはこちら。
前日はきょんまるさんの「越境ノススメ のこと。」でした。
ちなみに
このエントリは転職エントリではありません。転職エントリはこちらです。
このエントリでは、それから2〜3週間経ちどんな変化があったのか書いてみたいと思います。
受託開発から自社サービス開発への越境
一番わかりやすい変化はそもそものビジネスモデルの違いでしょう。今まであまり意識しなかったですが実際受託開発からサービス開発へ変わるといろいろな違いがあります。
作った機能の多寡によって売上や利益が決定するビジネスモデルだと作るものの複雑さや作り方は非常に興味の対象になりますが、作るものの意図や作る目的については意識が向きづらいです。もちろんこれは個人の価値観にも依存するのでそれについて真摯に向き合ってる人もいるとは思いますし、前職の会社でも実際そういう人はいましたが、「会社として」「絶対に」向き合わなければいけない課題にはなり得ないのでどうしてもその意識にバラつきが出てしまうものです。
一方、今は目的が達成できさえすれば作り方は基本的に自由にできますし、複雑性のコントロールもわりと可能だったりします。逆に作る目的や事業意図がわかっていないとそれができないので、そういった意図や目的をより強く意識するようになりました。
その結果、この DevLOVE Advent Calendar 2014 「越境」の 1 回目のエントリで書いたようなことが実現しやすい環境になったと思います。
何が必要か/本当に必要かがわかるまでは開発しないか最低限の開発で検証を重ねるのがいいと思いますし、その結果コアドメインが姿を表したらユビキタス言語を構築してモデリングをするべきでしょう。逆にノンコアドメインについてはフレームワークや既存のパターンを使って低コストに済ませてしまうのがよいと思います。
このようなイテレーティブにサービスを開発していくというスタイルは納期と予算が明確に規定されている受託開発では難しかっただろうなと思います。
アジャイル
開発スタイルの組織のあり方も変化がありました。僕が理想としているアジャイルのあり方にひとつ近づいたかなと思っています。
前職でも、カンバンや朝会、TDD、CI などのいわゆるアジャイルプラクティスと呼ばれるものはいくつか取り入れていましたし、ある程度は柔軟で機動力のあるチーム作りやプロセス作りはできていたと思いますが、うまくプラクティスを使いこなせてないと思う点もありましたしまだまだ改善できるなと思っていた部分はありました。
転職してから今僕がいるチームでよかったと思う点はいくつかあるのですが
- スプリントバックログにストーリーが入った時点でチームメンバー全員が実現するべき内容（Definition of Done）を理解している
- 事業戦略や KPI の変化によって組織が柔軟に変わる
- スキルや意識が固定化せず、常に全体観を把握していられる（気がする）
- スキルの違い、役割の違い、得手不得手はありつつもそれを対話で解決できている
- 堅苦しいルールや重たいドキュメントが無駄に増えたりしていない（気がする）
といったことを感じています。
これも事業意図や目的をちゃんと意識しているメンバーが揃っているからこそそうなってるのだと思いますし、サービス開発をしている人たちからすれば当たり前のことなのかもしれませんが、僕にとっては大きな越境でした。
ビジネスとの距離が近い
これも先に述べたことの延長というか結果的にそうであるということなのですが、開発とビジネスの距離が非常に近いと感じていて、僕にとって非常に居心地がよいです。
開発チームが開発で閉じることなくビジネスと近い距離にあればそれだけ設計空間が広がりよいシステムを作れると思いますし、それができる環境であるということを嬉しく思っています。
「ビジネス」というとすぐにマネジメントを想起する人がいますがそんなことは絶対になくてソフトウェアアーキテクトとしてドメインのあり方を理解することは大事ですし、そことの距離が近いことはすばらしいことなのだと考えています。
最後に
まだまだ時期が浅いのでチームのあり方についても事業のあり方についても僕の理解が間違っていることがあるかもしれません。それについてはあらかじめご了承ください。
今回の越境を通してさらなる成長を目指したい所存です。
次は kimKimmy さんです。よろしくお願いします。
