パラダイムを学ぶことと、実際にデリバリーすることとのバランスについて。あるいは転職報告。
導入
8月1日にグロースエクスパートナーズ株式会社に入社しました。人生で2回目の転職となります。入社してまもなく一ヶ月が経とうとしていますので、本日はその報告を。ブログ、翻訳、プレゼンに続く舞台裏記事の第4段ですね。私とは違う物事のとらえ方をする方々も多くいらっしゃることは重々承知しておりますし、それを批判するものではないこともあらかじめご了承ください。
転職をした理由
私が7月まで勤めていたのは、いわゆる「ITゼネコン」と呼ばれる元請けSIerでした。開発の実務は協力会社さんにお任せしつつ、自分はメールと打ち合わせに埋もれる日々を送っていたわけです。要件定義から保守まで一通り経験できたという意味で学ぶこともありましたし、アーキテクチャ策定やデータモデル設計のようなことも隙を見てやっていたことは事実ですが、ソフトウェアを作るということと自分との間に、どうしても超えられない壁が立ちはだかっているような感覚が拭えませんでした。これを読む多くの方がいろいろな立場で普段職場で目にしているであろう「アレ」と言えば、大体おわかり頂けるでしょう。
それと平行して、DDDやDCIといったソフトウェアのパラダイムを学びつつ、それをアウトプットする作業もここ数年で実を結び始めていました。DDD日本語版の翻訳は自分にとっての1つの大きな成果ですし、DevLOVEをはじめとしたコミュニティでも話をする機会を頂けるようになりました。
要するに「仕事は日々の糧を得るための手段として割り切り、空いた時間で勉強をしつつ、コミュニティに対してアウトプットしていく」という日々になっていたのですが、やはり自分の中にある矛盾が少しずつ大きくなっていきました。
エリックとの約束
4月にDDDの著者であるエリックが来日し、かなりいろいろなことを話すことができました*1。エリックと会うまでは、DDDを理論書としてとらえていたのですが、本人と会って話したことでずいぶんと考えが変わりました。別れる日の夜にエリックに「これまでは翻訳者として批評家としてDDDを日本に紹介してきたけれど、これからはそれを実践していきたい」と伝えたところ、エリックの答えは、"Right thing to do, and you SHOULD do"でした。
野村さんとの会話
その後、ジュンク堂様にてフューチャーセンターファシリテータの野村さんとトークセッションを開催する機会を頂きました。事前準備のときに、「ユーザとのコミュニケーションの中で業務のとらえ方を理解し、ソフトウェアを作っていく*2」ということを話した後で、野村さんから「そういう開発をしてほしいという人がいた場合、どこにいけばいいですか？」と訊かれました。おそらくすごく素朴な質問だったと思うのですが、それに対して「僕に紹介してください」と言えなかったことが、本当に恥ずかしかったことを覚えています。
結局のところ、組織に守られながらその組織に対して文句を言い、自分という人間を認めてくれる人たちの中で夢を語るのは、ものすごく居心地がよく、楽なことでした*3。でもそれは、中学生が小遣いをもらいながら自分の母親をけなし、仲間内でギターを弾いて悦に入っているのと変わらない。「じゃあそれ、路上で、知らない人の前で胸を張って弾けるの？それで金を稼げるの？」
それをやろうと思ったときに目の前に立ちはだかるのは、「生々しい現実」です。要件定義はやったことがあるし、設計も保守もやったことがある。アジャイルや設計手法の本も割と読んでいる。でも、「自分でリードしながら開発をやり切ることができるのか？」と問われたときに、胸を張ってできると言う自信はありませんでした。ユースケース記述のフォーマットを知っていることと、実際にユーザーさんとやり取りをしながら実装可能な設計に落とし込むこととの間には、「ボクシングジムに通うこととリングに立つこと」程度の開きがあります。私にはまだ、師が必要なんですね。
今の会社を選んだ理由
少し前後するのですが、転職自体はDDDを翻訳する前から考えていました。というより「DDD翻訳の仕事が入ってそれどころではなくなった」という表現が正しいですね。今のIT業界では「SIerからサービスを提供する企業へ」という人材の流れが（少なくとも私の周りでは）起きているように感じていますので、それについても少し触れておきます。
私も「実装技術」のようなものにもっと焦点を当てて力を伸ばしたいと思った時期もあり、非SIerへの転職を目指そうと思ったこともありました。しかし、私には「専門的で特殊なアルゴリズムを実装するスキル」はありません。それを育てたいとも思ったのですが、あまりそこをゴリゴリやっている自分の姿をリアルにイメージできなかったのは事実です。おそらく私には「漠然とした物事を言語化する」「物事を抽象的にとらえて、論理的に切り分ける」という作業が似合っているのでしょう。そういう経緯とDDDからの流れがシンクロして、「バリューストリームの中で自分の手を動かしつつ」「企業をお客様として業務に使うアプリケーションを作る」ためには何をしたらいいかを考えるようになりました。
一時は自分で会社を作ることも考えたのですが、尊敬する友人*4から何冊か本をプレゼントして頂き、それを読んだ結果、踏みとどまることにしました。一方で、これができる会社を探そうと思うと、それなりに大変だと思うのですが*5、私の場合は、幸運にもQCon Tokyoをきっかけとしたゆうすけさんとの出会いがあったおかげで、「探す苦労」をせずにすみました。本当にいろいろな方に助けられて今の自分があると思います。
GxPは「DDDでの開発」や「アジャイル開発」を必ずしも前面に押し出している企業ではありません。むしろ「ソフトウェアを作る」ということを、ものすごく真っ当にやっている会社です。手法としてのDDD、手法としてのアジャイルが強調されることはなくても、DDD的モデリングやチケット駆動型の開発がごく当たり前のものとして普通に行われています。これはとても健全で、正しいことだと思うのです。
入社してからの生活
入社してからの４週間でやったことを挙げると、こんな感じです。
- 提案書を書く
- ソフトウェアアーキテクチャを設計する
- タスクスケジュールを引く
- コードを修正して、テスト計画を書いて、デプロイして、テストする
- Jenkinsを立てて、自動テストツールと戯れる
- デプロイを簡単にするためのシェルを書く
- スレート端末と戯れる
- JSONプロトコルのRESTっぽいAPIをアプリに追加する
- Groovyで移行スクリプトを書く
- Lucene in Actionを読み返す
見て頂いてわかるとおり、上流／下流という区別なく、割と何でもやっている感じです。でも、「華々しいこと」は特にやっていません。スタンドアップミーティングもやってないし（朝会はそろそろやる）、顧客の前でドメインモデルを書いたりもしていない。壁にバーンダウンチャートが貼ってあるわけでもない。テストコードは必要に応じて書きますが、ペアプロやいわゆるTDDも特にやっていません（これは声をかければできるかも）。提案書はパワポで書いていますし、表を作るときにはExcelも使います。機能一覧とかテストケースもExcelで書いています。要するに「アジャイル」と「ウォーターフォール」という区別にこだわらず、必要なことを当たり前にやっているだけです。たぶん、「アジャイル」という言葉にこだわるあまりにウォーターフォール的なものを忌避しすぎると、不幸なことになると思うんですよね。
一番大きな変化は、仕事に関してグチや言い訳を言わなくなったことでしょうか。上司は話がわかるし、仕事ができる方々に囲まれている。ミスしていないわけではないし、見落としをリカバリーするために会社に泊まったりもしましたが、それも自分で勝手にやったことです。すべてに自分の手が届くこの状況下では、何かあれば完全に自分の責任ですよね。
まとめ
ソフトウェアをデリバリーすることには、多くの「泥臭い作業」が伴います。そしてその「泥臭い作業」は本に書かれたり、語られたりすることがあまりない。それはたぶん、語るまでもなく当たり前のことであったり、語れるほどには言語化されていなかったり、語るほど面白くなかったりするせいでしょう。だからといって、「そういうこと」をしなくていいわけではない。このあたり、パラダイムと泥臭い作業をひっくるめた「デリバリー」の全体像が見えずに苦しんでいたわけですが、他にもそういう方はいるのではないかと思います。「バリューストリームの中で自分の手を動かしつつ」「企業をお客様として業務に使うアプリケーションを作る」ことができる場所があるんだということは、多くの方に伝えたいメッセージです。
最後に1つ。コミュニティで出会った人と働くことに、少し怖さはありました。プレゼンをするときにはそれなりの準備をしてデキるコっぽく装うわけですが、仕事となれば完全に生身での勝負ですからね。「がっかりされたらどうしよう」とかは当然思うわけです。でも・・・「一番こわいのはこの痛みなの？痛いのってこわい？ あんたいつまでも…大人になってもひとりじゃなんにもできない方がもっとこわいとは思わないの？」ということですよ。
あしたって今さ！
