はじめまして。
8月1日付けで入社＆MTL配属となりました黒田です。よろしくお願いします。

前職ではSIerにてアプリケーションアーキテクトとして官公庁様のシステム開発に携わってきました。
具体的にはSOAや(SOAP/HTTPな)WebサービスをJava界隈の技術(Springframework,Struts,iBatis等)をベースに製造し、hudsonを使ったりしてCIでJUnitとかグルグル回す感じで開発してきました。
同じIT業界でも、MTLとは程遠い世界からやって来ました。

そんな遠い世界からやってきて一ヶ月間MTLで働いてみた感想を。
入社早々、ビジネス企画関連の打ち合わせに参加して、何もないところから市場を見出してビジネスを企画し、新規事業を立ち上げるリクルートの文化に触れました。そして、今の私に足りないことも沢山分かりました。
また、MTLメンバー全員に言えることですが情報感度が非常に高い。いったいどれだけアンテナ張り巡らしてんの？ってくらいです。もう毎日が刺激でいっぱいです。自分も今まで以上に感度を上げないと！と思いました。

タイトルの件なのですが、折角なのでSIer時代とのMTLの違いを開発スタイルを軸にエンジニア目線で簡単にまとめてみようと思います。
これから就職活動や転職活動を行おうとしている方々に、「お客様のサービス（業務システム）を開発すること」と、「自分達のサービスを開発すること」での開発スタイルや価値観の違い等の参考になればと思います。
※黒田の経験知に基づくものなので、業界全体の様々な事情を全て網羅したものではありません。あくまで参考程度に。

SIerでの開発「お客様のサービス（業務システム）を開発すること」

・開発スタイルについて

お客様から提示される提案依頼書（RFP）に対して提案書を作成し入札。お客様に提案を受け入れられ受注出来たら晴れて開発を開始します。そして、最終的に納品物として、各種ドキュメント、及びシステムを納品。そしてお金を頂くことになります。
そのため、受注時に最終的に頂ける価格が決まってしまうため、予算の範囲内、期間内で計画段階と差異がなくスコープ（システム化する要件）を満たすシステムを構築することが目標になります。
つまり、当初の計画通り開発を遂行させることが価値観となり、それを実現させるためにウォーターフォールモデルによる開発が採用されます。要件は変わらないものという前提において開発を行います。（その前提が崩れたときに、一般的に言われるデスマーチという状態に遷移したりします。）

・規模感
私がSIerで経験したプロジェクトはどれも規模感的には数百人月とかそういう規模でした。ステップ換算で数百キロStepから数メガStep。1プロジェクトあたり1〜2年で回します。

・体制について
体制は規模が大きいため、
　・インフラグループ
　・業務グループ
　・アーキテクトグループ(黒田所属)
のような専門性に応じた縦割りチーム編成が行われ、それぞれメンバは自身の専門性領域でのミッションのQCDを守り遂行していきます。

・作業内容
私の場合は、アプリケーションアーキテクト担当であったため、インフラの構築や、業務アプリケーションの設計実装はほとんど行いませんでした。やっていたことは、アプリケーション基盤（非機能要件：トランザクション制御、ログ管理、対外システム接続...etc）の設計・実装・試験、開発プロセスの検討、試験計画策定で、プロジェクト全体の開発をスムーズに進めるための基盤作りに徹していました。毎日のほとんどが打ち合わせやレビューで、最近は実務内でコーディングをする機会は非常に少なかったです。基本的に開発規模が大きいため、会社としてもゼネラリストよりも専門性に特化したスペシャリストになるためのキャリアデザインを推奨していました。

MTLでの開発「自分達のサービスを開発すること」

・開発スタイルについて

自分たちで企画立案したサービスを作っているため、もちろん要件は作りながら良いものに改善していくので変更は当たり前にはいります。ここは最初に立てた計画通り最後まで遂行させることに価値を置いていたSIer時代とは正反対です。要件は変わるものという前提において開発を行います。
そのため、開発手法は要件の変更を許容しなくてはならないため、必然的にアジャイル開発になります。
つまり、ウォーターフォールでは固定にしていたスコープ（システム化する要件）を変動させることになります。しかし、QCDはウォーターフォール同様に一定水準を満たさなければならないため、要件の優先度が重要になります。現在、Scrum(アジャイル手法の一つ)で言うところのプロダクトバックログをBacklogを利用し、管理しています。一度に変更を全部取り込んだりしたら、カオスな状況になってしまうので、変更の単位に優先度を付けて、次回のスプリント(開発周期)で反映させる等のやりくりをしています。まさに疑似Scrumのようなことをやっています。それにしてもBacklog凄く便利ですね！バーンダウンチャートも自動で出来るし！☆で「いいね！」されるとほっこりします。

・規模感
数人月（SIerのようにステップ数で規模換算する文化は無いようです。）

・体制について
現在MTLで私は2つのプロジェクトにjoinしていまして（複数同時ということ自体初めてですが）、双方とも
　・クライアント(iPhoneアプリ)　1名
　・サーバ(REST API)　　　　　　1名(黒田)
　・デザイナー　　　　　　　　 1名
という体制(プランナー除く)で開発しております。

・作業内容
サーバ側の実装で例えると、要件定義、設計、開発言語の選定、開発フレームワークの選定等から始まり、クラウド環境へのサーバ構築、業務アプリケーションの開発、ビルドスクリプト作成までなんでもやります。面接時にベンチャー企業のCTOのマインドセットで望むようにと言われた通り、開発に関わる全てのことをやります。SIer時代と比べると開発規模が小さいということもありますが、一人で全てのことをこなす能力が求められると感じました。知識が深いことは重要ですが、それにプラスしてゼネラリストとしての立ち振る舞いも求められるという感想です。

さいごに

私の実体験を載せただけなので、全てのケースに通用するわけではありませんが、開発の仕方は、プロジェクトのコンテキストによってこんなにも違いがあるということは共有出来たかなと思います。 プロジェクトとしての価値観、規模、品質、納期、コスト等の様々なトレードオフ関係のある要素が絡み合った中で、適材適所で開発スタイルは決まります。しかし、一貫して言えることは状況はどうであれやるべきことはちゃんとやるということです。アジャイルだから試験はてきとーでOKかというと、そうではありません。また、ウォーターフォールとアジャイルどちらが優れているとかそういう議論をするものではないと思います。それぞれがメリットデメリットを持っています。

比較的規模の大きなシステムの開発しか経験したことがなかったので、例えるならば、ダムの作り方しか知らない人間が、デザイナーズマンションを作れるのかという不安はありました。しかし、現在製作中のサービスもそれっぽく？動いており、まだ気が抜けませんがなんとかなりそうでほっとしています。
また、MTLはPerlやRuby等のLLと称されるスクリプト言語の有識者が多い中、私が現時点で一番生産性を出せるJava(SpringMVC+MyBatis)で自由に書かせてくれるMTLの度量の大きさに感謝しております。

しかし今以上に素早く、高品質なプロダクトを作れるようにしたいので、日々精進です。
そのためにもというわけで、私は現在、以下のフレームワークに非常に注目しています。
JavaをLLのように扱え、RoR的にコマンドラインから簡易アプリの生成が可能になります。

Playframework
Playframework翻訳サイト

最近はJVM上で動作するモダンな言語も沢山出てきており、Java界隈のものとしては目が離せません。
さくっと作りたいならSpringRooやJRubyでもいいじゃないかと言われそうですが、それはそうなんですが、ここは右脳がコレだ！と言っているので（笑）

これからは今までのMTLにはちょっと無かったような、JavaにおけるLightWeight開発の話題を記事にしていけたらと思っております。
長くなりましたが、今後ともよろしくお願いいたします。