このエントリは DevLOVE Advent Calendar 2014 「越境」 の5日目です。
つい先日申し込んだのに予想外に早くバトンがまわってきました。笑
前日は @azumi さんの「【マンガ】旅行サービス開発のデザイン現場へ。種を持ち帰る『越境』の旅」でした。まさかマンガとは！笑（楽しく読ませていただきました。）
@azumi さんは産業技術科学大学の人間中心設計プログラムにいらっしゃるのですね。弊社の社員も現在通っていて、一緒に学んでいるようです。
さて、僕は昨年に引き続き今年も DevLOVE Advent Calendar に参加させていただきます。 昨年のエントリはこちら。
現場の反対はまた別の現場 #DevLOVE - assertInstanceOf('Engineer', $a_suenami)
自己紹介
すえなみと申します。漢字で書くと末並です。「末波」とよく間違われますが「末並」です。
とても希少な名字なので勉強会等で「すえなみ」と名乗ってる人間がいたら間違いなく僕のことだと思ってください。
オンラインでは a_suenami とか a.suenami とかで活動してます。
Twitter: https://twitter.com/a_suenami
Facebook: https://www.facebook.com/a.suenami
所属は渋谷にあるファクトリアルという会社で、受託開発のお仕事をしています。Ruby、PHPあたりがメインの開発言語です。
よろしくお願いします。
最近考えていること
先日、こんなことをつぶやきました。
最近は「機能を実装すること」よりも「機能を実装しないこと」に興味がある。アジャイルとかリーンの考え方がやっと定着したってことかな。
— 末並晃＠糖質制限 (@a_suenami) 2014, 11月 9このエントリではこれについて掘り下げて書いていきます。
多くの機能を効率よく実装するということ
僕が現在働いているファクトリアルという会社はWebアプリケーションの受託開発をメインのビジネスとしています。
受託開発でソフトウェアの開発をやっていると、基本的には実装した機能の多寡によって売上げが決定する*1ため、
- 多くの機能を効率的に開発する
- 機能ごとやプロジェクトごとに属人性が生じないようにする
- 社内のエンジニアであれば誰でも保守できる
ということに意識が向きがちです。
こういった状況の中で、僕がどういう風なものに興味を持ち、どういった越境を経験したかご紹介します。 なお、ここで紹介する内容は会社の変化にある程度は連動しますが、基本的には僕個人の成長の軌跡でありファクトリアル社とは関係がないことをご了承ください。
フレームワーク/パターン指向
僕が現在の会社に入社してまず経験したのは盤石な社内フレームワークの存在でした。
当時は、今ではほとんど亡きガラケーサイトの開発プロジェクトが多く*2、
などハマりどころがある程度決まってたため、そこをフレームワークで面倒見てくれるようになっていたのです。
実際、そのフレームワークの仕組みに乗っかることで開発はかなり楽だったと思いますし、僕が入社した当時、少なくとも僕はそのフレームワークに助けられていました。
また、フレームワークでフォローできていないところは「こういった場合はこう」といったようなノウハウが社内で共有され、ある程度パターン化されており、それらの組み合わせであらゆる問題を解決できる組織体制だったと思っています。
ドメイン駆動設計
僕が今日紹介したい 1 つ目の越境はドメイン駆動設計との出会いでした。
ガラケーのプロジェクトが減ってきたとき、弊社では盤石だった社内フレームワークの新規利用をやめ、Ruby on Rails を使いはじめました。
そして、その最初のプロジェクトはとある会社の業務システムでした。それまでの弊社では広報のためのキャンペーンサイトやコンシューマ向けのメディアサイトなどを多く扱っていたので、それらとはまったく違うものを開発するという、そんなプロジェクトだったのです。
開発するシステムの性質も開発に利用する言語もフレームワークも今までと違うという状態で、文字通り暗中模索で開発を進めていたのですが、そのプロジェクトに関わり始めてからちょうど 1 年経った頃に自分の意識の変化に気づきました。
それまでは「今使ってるフレームワークはこういうことは得意だけどこういうことは苦手だ」とか「こういう問題はこれまでのプロジェクトで解決できた経験があるけど、こういうことはやったことがない」とか、そういった利用しているフレームワークや過去の経験に基づくパターン化された知識に基づいて仕様を（ある種、誘導的に）調整していたのですが、このプロジェクトでは顧客の業務内容を考慮し「これは重要な機能だからしっかりと要求を定義して柔軟に変更できる設計にしよう」「こちらは些末な機能のはずなのでフレームワークに任せてサクッと実装しよう」と考えるようになりました。
ただ、当時の僕では技術力のほうが追いついてなく、それを実際にプロダクトにできる設計の能力もプロジェクトへの提案力もなく、もっとこの思いを具体的な力にしたいと思って手にとったのがエリックエヴァンスのDDD本だったのです。
エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)
- 作者: エリック・エヴァンス,今関剛,和智右桂,牧野祐子
- 出版社/メーカー: 翔泳社
- 発売日: 2011/04/09
- メディア: 大型本
- 購入: 19人 クリック: 1,360回
- この商品を含むブログ (132件) を見る
- 作者: Eric Evans
- 出版社/メーカー: 翔泳社
- 発売日: 2013/11/20
- メディア: Kindle版
- この商品を含むブログ (2件) を見る
これは今考えても僕にとって大きな出会いです。
初めてDDD本を読んだときにはデザインパターン本程度にしか思っていませんでしたが、いろいろな勉強会への参加を通して学びを深めていくうちに、ユビキタス言語の構築を通してチームのコミュニケーションを円滑にする手法だと捉えるようになりましたし、コアドメインとノンコアドメインを区別するために必要なことなんだと考えるようになりました。
そして「開発しない」という越境
さらに最近になると、そもそも「開発しない」という選択肢があるのではないかと思うようになりました。まさにアジャイルでいうところの MVP ( Minimum Viable Product ) をきちんと定義しようという話であったり、小さいリリースを繰り返そうという考え方そのもので、そこで行き着きいたのが冒頭のツイートです。
先に述べた業務システムは現在でも保守し続けていますが、何年もやっているとよく使われる機能とそうでもない機能が結構はっきりと出てきます。僕らが顧客企業にどれだけ寄り添えていたかと考えるともちろん反省するべき点もありますが、それでも僕らなりに業務理解に努め、それにあった形で設計・実装を進めたつもりだったため、この状況には正直思うところが多々あります。
ソフトウェアを開発するというのはそれがどんな機能であれ、どんな仕様であれ、基本的には高価なものです。要件定義に始まり、アーキテクチャを設計し、実装してテストをし、保守し続けるというコストを支払う価値があるのかどうか、それをもっと低コストで検証できる手段があればそちらをとる方が圧倒的に業務上は優位でしょう。
「それは Excel でできませんか？」「それは静的な HTML ではダメですか？」「その機能は年に何回利用しますか？」 こういった問いを最近は自分に、チームメンバーに、そしてそれを通して顧客に、本当によく問いかけるようになりました。
これが僕にとってドメイン駆動設計に次ぐ越境でした。
まとめ
僕の経験の中で 2 つの越境を紹介しましたが、これらは排他的なものではなく、相互に補完的なものだと思っています。
これらは言うなれば三種の神器のようなもので、何が必要か/本当に必要かがわかるまでは開発しないか最低限の開発で検証を重ねるのがいいと思いますし、その結果コアドメインが姿を表したらユビキタス言語を構築してモデリングをするべきでしょう。逆にノンコアドメインについてはフレームワークや既存のパターンを使って低コストに済ませてしまうのがよいと思います。
開発する/しない、フレームワークを用いる/ドメイン分析をする、というような一見真逆と思われるようなツールや手法を組み合わせることによってプロダクトのあり方を、ひいてはプロジェクトや顧客の業務そのものを最適化していくことができるということに気づいたのが僕にとっての「越境」です。
特に「開発をしない」という主張はプログラミングが好きな僕たちプログラマには難しいことかもしれません*3が、だからこそ、僕らがそれを主張することに意味があるのだと思っています。
バトンタッチ
次は @taniyang さんです。どんな越境の話が聞けるか楽しみです。
