会社での開発体制改善中
ここ5年程はWeb業界で働いていてWeb業界で現在2社目。
前職の最後の方ではそこそこ業界で有名になった企業。現職は上場している企業なわけですが、両方とも開発体制、手法がひどい。
端的に言えばいきあたりばったり開発です。
ディレクタに当たる人たちが、まともに仕様書を作れないから仕様書を作らない or 作っても要望書というか夢リストになるだけの書類しか作れない、でも自主的に勉強もしない。
そしてそういう人たちだけが出世する会社。
でもエンジニアはそれなりにスキルがある人たちが多いという現場なので、エンジニアが空気を読まされて、なんとか物をつくってリリースするという最悪な状況。
当然エンジニアの仕事もドキュメントは少なくというかほぼ存在しない、テストコードもほとんど書いていない。
最近はDevOpsとかも取り入れていますが、それはエンジニアだけの改善策であってディレクタが変わらない。
マジで最悪。
とはいっても、現在の職場の人たちはそれでも知りたいという気持ちはあって、エンジニアが勉強会を開くと参加もしてくれる。
最近だと会社のサービスを例に1からサーバ構成とか、Rails(うちはRailsが基本です)の仕組みを教える勉強会を開催すると参加はするし、質問ももらえる。
つまり、少なくとも現職勉強しないのではなくて、勉強方法が分からないのだと思う。意欲はあるのだから。
さて、最近自分は完全に新規のプロジェクトを担当している。しかも会社としては初のチャレンジ部分だ。
当然ながら仕様はきちんと決める必要があるし、テストも大事だ。エンジニアよりもディレクタの人数が多く、相変わらず夢物語も多い。
ここいらで何とかしたいし、何とかして良い効果がでれば開発手法も横展開したい。
で、どうするかだが、悩んだ結果大まかな部分はウォーターフォール型で開発すると宣言して、実際の開発ではスクラム開発を採用するという、かなり変則的な方法をとった。
ウォーターフォールとはいっても話は簡単で、はじめにきちんと仕様書をつくる。仕様書を作る段階では何回もチェックをいれて修正を行ってもらう。その次に開発を進めて、最後に一斉にテストだ。ウォーターフォールっぽい。
もちろんこれがきちんとしたウォーターフォールだとは思っていないが、目的はきちんと仕様書を書かせることにあってそのための方便として'ウォーターフォール'という言葉を使わせてもらった。
ここをきっちりしないと、開発が進まないので彼らからしたらかなり厳しい要求をした。仕様書はダメ出ししまくり上司だろうが関係なし。
結果出来たのは仕様書とは言えないが、仕様書になりかけの要望書と言ったところ。
前職合わせても、ここ数年のWeb業界で見たなかでは確実に良い出来でしょう。
でもこのままウォーターフォールで開発を行うとテスト段階でバグが出まくるし、そもそも開発時間が少ない。そこでスクラム開発の出番だ。
今回入ってもらうスクラムマスタに当たる人と相談して、時間がないので出来るだけスクラムそのもので余計な時間を取らないように相談した。また、がっちりスクラム開発の枠にはめてもいない。
結果、今回はこうなった。
- 基本エンジニアのみにスクラム開発を適応させる
- スプリントは1週間
- ディリースクラム
- 日報、これは少しから導入しているので継続中
- KPT
- 週末の振り返りなどのMTG
- これだけはディレクタも参加する
- ホワイトボードでタスク管理
- 反対が多いのでPivotal Trackerなどのツールは使わない
- エンジニア側では別途仕様書を作成する
- 古い言い方だと内部仕様書
- Rdoc/YARD等で細かい部分のドキュメントを作成する
- Rspec等でのテストコード作成
- Jenkinsでの自動テストを実施する
まだまだ走りだしたプロジェクトだが、そこそこ前には進んでいると思う。
すでにいくつか良い意見ももらったり、効果も出てきていると思う。
個人的にはアジャイルやスクラム開発は両手を上げて賛成はしていない。
だって、OSSとかだとこんなことしなくても開発できているプロジェクトもあるし。そもそもこの業界にいてエンジニアではないにしろ勉強しない奴がいる事自体がおかしい。
もちろんテストコードを書いたり、Jenkinsでの自動テストとか好きな部分もあるのは確かだ。TDDは精神力を多大に浪費するのでしんどいけどw
良い結果が出始めている事なのは確かなので、開発の管理が出来ていないと悩んでいる方たちはこういうフレームワークをうまく取り入れれば良いとおもう。
