副業エンジニアの価値をレバレッジする仕組みとしてのグローバル開発チーム

この記事は a-suenami Advent Calendar 2018 - Qiita の 3 日目の記事です。

昨日はベトナムでの開発チーム構築についての経験談を述べましたが、本日はそれに続いて、実際にどのようなことをやろうとしているのかについて書きます。

副業の活性化

昨今、副業が流行っています。これはエンジニアに限らず、あらゆる職種でやっている人が見られます。

企業側としては

  • 他の企業のノウハウを社員の副業によって取り入れる
  • 優秀で高単価な人を顧問やコンサルタントとして受け入れることによって既存チームやプロジェクトのパフォーマンス底上げを図る
  • 正社員として雇用する前のお試し

等が目的だと思われますし、副業する個人側としても

  • 収入源の分散
  • 本業以外の会社での業務を遂行することによる技術習得、視野拡大
  • 転職前のお試し

等のメリットがあると思われます。

これまでコミュニティを介して行われていた知見の共有がより強固に、実際のプロジェクトを通して行われることになり、この流れは僕自身はかなり強く肯定的に捉えています*1

副業と海外開発チーム

エンジニアの副業は企業側・エンジニア側双方にメリットがある反面、プロジェクトマネジメントの観点からは当然難しいところもある。

一番大きいのは断片的な時間を効率的に使えるようにプロジェクト全体のタスクをうまく細分化して、小さく進めていけるようなプロジェクト管理が求められる部分で、これは時間も場所も毎日共有していてハイコンテキストなコミュニケーションをしている正社員を前提にしているとなかなか難しい。

したがって、週 1 〜 数日といった稼働を、より課題が本質的で、経験が必要とされる領域にあて、それ以外の領域をベトナムのチームに任せることで全体的な効率を上げることを僕は今目指している。

事前設計

言語やフレームワークの選定、大きな設計方針の決定(エリック・エヴァンスの DDD、CQRS 等)、その他個々の機能ごとのデザインパータンの採用など、アーキテクチャの設計は本質的に難易度が高く、経験も必要とされる。

また、プロセス設計という意味では Lint やテストカバレッジに対する方針の策定、それをもとにした CI の設定、Working Agreement の明文化など、メンバー数が増えても開発速度が落ちないようにするためのこれらの仕組みも経験豊富な知恵を借りるべきだと思っている。

コードレビュー

コードレビューはプロダクトの問題を発見するポイント、品質を見極めたり向上させたりするポイントとして不可欠なステップである。これらを経験のあるエンジニアに任せることによって品質の向上を図るとともに、必要であれば Lint や自動テストの設計指針にフィードバックすることで、マネジメントコストを極端に上げずにスケールするチームを作ることが可能になる。

テスト設計 / テスト観点洗い出し

コードレビューを正しく行うことによって内部品質は向上するが、リリースに必要な品質は通常テストによって測定されなければならない。このテストケースの設計や観点の洗い出しにはソフトウェア開発やテストの経験が不可欠であり、システムの対象ドメインによってはそのドメイン知識も必要になる。ここをきちんと抑えることで開発チームのパフォーマンスを向上させることができる。

まとめ

昨日の記事ではベトナム人による開発チームの特徴を挙げたが、言葉も文化も違う人たちと同じチームで開発を進めるということの難易度は依然高く、正直日本国内での信頼もまだまだ高くない。

この是正手段として、経験豊富な国内のエンジニアの経験を借りることは有効だと思っており、そのためには今の副業市場の活性化は追い風なのではないかと感じる。

本日の焼肉屋

3 日目の本日は 1, 2 日目と同様渋谷から「いのうえ」をご紹介。

リーズナブルな金額で店内も広く、会食等にも利用できます。焼きすき、焼きしゃぶというすき焼き、しゃぶしゃぶに使うような薄切り肉を鉄板で焼いてご飯に巻いて食べるというのがおすすめメニューです*2

tabelog.com

*1:すえなみチャンスの発想も似たようなものです。今のところ、すえなみチャンスは対価が焼肉ですが。

*2:糖質だけどな!

ベトナムで開発チームを作る(作ってた)話

この記事は a-suenami Advent Calendar 2018 - Qiita の 2 日目の記事です。

タイトルの通り、 1 日目に紹介した「すえなみチャンス」を発想したきっかえでもある、ベトナムでの開発経験について書きたいと思います。

ベトナムでの開発体験

僕は以前、某キュレーションメディアの会社*1で働いていたのだけど、そのときに開発をスケールさせるためにベトナムで開発チームを作るって話があって、僕がそのマネジメントというかそれっぽい任をいただいてしばらくベトナムに住むってことがあった(1年くらいいた)。

今はその会社をやめて主に日本にいるようになったけど、その会社とは別に小さなチームがあって、たまにベトナムには行っていたりするので、その経験談を書こうと思います。

ベトナム人の特徴

ベトナム人の特徴ですが、もちろん「人による」というのは人種問わず当たり前なので、あくまで総論・一般論として、ベトナム人と付き合うときの Tips という風に考えてもらえればと思います。

真面目、従順(≠誠実)

ベトナム人の紹介で一番最初に出てくる特徴がたぶんこの真面目さとか従順さだと思う。 彼らは年上だったりポジション的に目上だったりする人にちゃんと従うし、言うこともすごくよく聞いてくれる。僕はマネジメントとかっていうものをほぼ未経験でベトナムに行ったんだけど、メンバーの性格や気の使いどころという観点での苦労はほとんどなかったように思う。ちゃんと言えばやってくれるので。*2

ただ、よく言われる話として「ベトナム人は誠実だ」っていう話もあるんだけど、(もちろん誠実の定義によるんだけど)これは若干違うような気がしていて、言われたことをちゃんとやるということは裏返せば言わなかったことはできないし、言ったことであってもそれが満たされる限りにおいてギリギリまで手を抜こうとする(ように見える)。

まあ、これ自体はエンジニアという職種においてはいい側面もあるし、サボれる部分は積極的にサボってもいいと思うだけど、日本人相手のように「わからなかったら質問してくれるだろう」「定期的にレポーティングくれるだろう」という感覚だと納期ギリギリでやっぱりできませんでしたみたいなことになりかねない。*3

個人主義

これは個人の感覚なんだけど、仕事に対しては個人主義的なところがあるなぁと思う。あえて「仕事に対しては」と前提をおいたのは、ランチとか飲み会とかは結構みんなで仲良く行くし、業務時間外でそういう側面をあまり見ないから仕事や業務成果に対する競争意識みたいなものなのかなと想像している。

僕がベトナムで一番最初に強く違和感を覚えたが Slack の開発チャンネルが全然流れないこと。わからなかったら誰かに助けてもらおうとか、この人に質問しようとかっていうのが自然には身についてなく結構ギリギリまで自分ひとりで何とかしようとしてしまう。この責任感はよい側面もあるのでうまくマネジメントとして活かしつつ、チームメンバーに頼ったほうがいいところは頼りやすいような雰囲気やルール作りをするのが重要だと思う。

見栄っ張り

見栄っ張り、これはすごくある。まあ、日本人が謙虚というか自己主張が弱すぎるだけな気もするけど。

先に書いた個人主義と重なる部分もある気がしていて、仕事とかプロジェクトの成果に対しては自分の手柄と言いたいという志向性の人が多いように思うし、給料や待遇に対する要求も強い。そして彼らはカジュアルに他人に自分の給料を言うので、チーム内で給与格差があると低い方のメンバーのモチベーションは下がるし、マネジメントする側の立場としてはなぜあなたの評価がそうなっているのかを客観的な給与評価テーブル等を作って説明しなければ納得しない。

あと、これは中国人(だったっけ?)もそうらしいんだけど

  • 褒めるときはみんなの前で
  • 叱るときは本人を呼んで 1 対 1 で

というのが鉄則。

彼らの仕事はちゃんと評価してあげるべきだし、彼らのプライドを傷つけるようなことはしてはならない。

ライフラークバランスちゃんとしてる

これは日本のほうが特殊なんだろうけど、ライフワークバランスがしっかりしているなと思う。たまに残業しまくる人もいるけど、基本的に定時にあがって友だちや家族とすごす時間を大事にする。

ベトナムだと家族ぐるみの付き合いも多かったりするらしく、ホームパーティとか旅行とかにプロジェクトメンバーや上司が呼ばれたりする。そこで家族の人たちと仲良くなると結束が強くなるというか、もうちょっと打算的なことを言うとモチベーションの低下リスクや離職のリスクが下がる。

ベトナムでいいチームを作るためにはメンバー自身ももちろんだけど、メンバーの奥さんや旦那さん、ご両親に好かれることだとよく言われる。

ぼくがかんがえたさいきょうのべとなむじんちーむのつくりかた

ベトナム人の特徴を見て「あれ?」って思った人もいるかもしれないけど、ぶっちゃけ普通である。

むしろ日本のほうが特殊な気がしてて、空気を読んでなんとなくいい感じに成果出す人がいたり、長時間労働して帳尻を合わせたり、マネジメントが多少未熟でもメンバーがなんとなくいい感じにしてしまうってことがありえる。

逆にベトナムでチームを作ると成果が出せなかったらたぶんダイレクトにマネジメントが悪いって感じになる。もちろんこれは日本人でチームを作る場合にも意識しておかなければならないんだけど、僕が特にベトナムにおいて意識していることを以下に挙げようと思う。

長いものに巻かれる雰囲気を作る

デザインパターン、その逆のアンチパターン、またなんとかファウラーさんのような有名な人のブログ記事などは積極的に引用して個々のタスクレベルで指示を出していくとよい。

メンバーには正確に何をやって欲しいか、どういう成果を出したいかを伝える必要があって、これは当たり前の話なんだけど、その上で、その実現に向けて実際にどういう方法をとるか、どういうプロセスで進めるかということも伝えられると真面目なベトナム人という性質上、成功確率をどーんと上げることができる。逆に目的だけ伝えてあとは一任するっていう強すぎる裁量は十分にチームが成熟するまではやめたほうがいい。

このときに目的や期待する成果物の説明はともかくとして、そのための方法論の部分は個人による実力差や志向性が非常に出やすい部分で、ある程度世の中に知見がある(つまり、困ったときに本人が自分で調べることができる)方法をマネジメントとして指示してあげるほうがうまくいくケースが多い気がする。*4

最初はコミュニケータはちゃんといたほうがいい

ベトナムのベンダーはエンジニア以外にコミュニケータという通訳兼ディレクターのような人がいることが多い。会社によってはブリッジ SE (BSE)などとも呼ばれるが、この BSE という人は技術もわかる人を指す。

僕もベトナム人エンジニアと英語で直接コミュニケーションして開発チーム大きくしていくぜ!グローバルチームだ!と思った時期もあったけど、これがなかなか難しい。もちろん僕の英語力の問題は多分にあって、それはがんばらないといけないんだけど、比較的大きな機能開発ならともかくとして、小さなバグ修正とかニュアンスを伝えるのが大変な機能改修とかはたくさんあって、そういうのもすべて間に日本人が介在するのではスケーラビリティが生れないし、何よりどちらもノンネイティブ言語なのでコミュニケーション効率がよくない。

なので、コミュニケータは(少なくとも初期は)いたほうがいいと思う*5

年功序列であることを意識する

ベトナムは日本以上に年功序列である。わかりやすいのが人の呼称で、相手が年上の場合と年下の場合で違う。*6

なので、それをちゃんと意識して採用、育成、評価、権限委譲をしたほうがよくて、特にチームリーダーはそのチームで一番の年長の人にできると望ましい。優秀な若手、無能な年長者は扱いが難しく、後者は当然だとして、前者もポジションを与えにくいという意味で頭を抱えることがある。優秀な若手は優秀な年長者がいる前提においてはマイナス要因ではないので、とにかく無能な年長者だけはチームに入れないというのを意識しておくといいと思うし、仮にそこで失敗するとリカバリーが難しくなる*7

まとめ

ベトナムでの開発チーム構築は難しい側面も多々ある一方で、エンジニア不足が叫ばれる今の日本において大きな選択肢のひとつになっていって欲しいと思っており、僕は今もそういう世界を夢見てがんばっている。

「オフショは品質が〜」みたいな話はいろんな方面から聞くのだけど、その要因の結構な部分がマネジメントに起因するところもきっと多く、ベトナム人のエンジニアと仕事をしている僕の立場からすると彼らの技術力に由来していると思われたくはないという個人的な感情はすごくある。だからこそ、適切なマネジメントのもとで、彼らの能力が最大に発揮される仕組みを作って、日本、ベトナムの両国におって Win-WIn になるような世界にしていきたいなと思っている。

今日の焼肉屋

2 日目の本日の焼肉屋は昨日と同様に渋谷から「焚火家」をご紹介。

肉のヒマラヤという巨大な肉塊を焼けます!

https://tabelog.com/tokyo/A1303/A130301/13130110/

*1:リアルで僕を知ってる人はほとんど知ってると思うけど、まあいろいろ世間にはご迷惑をかけたので一応伏せる

*2:もちろん他の観点に対する難しさはある

*3:もちろん真面目で従順というのはあるので、レポーティングにしろ、コミュニケーションにしろ、ルールとか原則を設ければやってくれる。あくまで「自発的に」できるかどうかという話。

*4:その判断こそがプログラマの仕事だろって言う意見もあると思うけど、少なくとも僕はまだその領域に達してない。

*5:ちなみにコミュニケータはできれば女性がいい説を僕は唱えてるんだけど、それを声を大にして言うとジェンダー的に云々って言われそうなので今回は割愛。聞きたい人は飲みにでも誘ってください。

*6:年上の男性は anh, 年上の女性は chi, 年下は男女ともに em という。

*7:チームを分割するくらいしかとれる手がなくなる

すえなみチャンス紹介と目指していること

この記事は a-suenami Advent Calendar 2018 - Qiitaすえなみチャンス Advent Calendar 2018 - Adventar の 1 日目の記事になります。

初日の今日は、僕がやってるすえなみチャンスという試みの紹介と目指していることについて書きたいと思います。

すえなみチャンスとは

詳しくは以前書いたこちらの記事を参考にしてください。

a-suenami.hatenablog.com

平たく言うと、僕が知りたいことをペアプロ等(最近はペアプロじゃなくて普通にスライドとか使って教えてもらうっていうことも増えてきた)で教えてくれる代わりに焼肉を奢りますという試みです。

ブログに書いたのは上記の一回だけですが、その後も各方面の猛者の方々に殴られながら教えていただきながら、おいしい焼肉を食べています。

初回の増田さん以降は出演許可(?)をもらってないので*1実名は出しませんが、テーマでいうと

など開催しています。

きっかけ

きっかけはまあくだらなくて、TL のみなさんが焼肉奢れっていうから「じゃあ、代わりにいろいろ教えてくださいよ」って言ったらチラホラ本当に教えてくれる人がいて、このスキームは結構いいなって思って実際に始めた感じです。

そして始めてみると、いろいろな想いがうまく言語化できたような気がします。

知識やノウハウをもっと流動的にできないかと考えている

すえなみチャンスは自分の名前を使ってるくらいなので基本的には僕が僕自身のためにやってることで、僕自身の学習効率とか僕自身の満足度とかが重要なんですけど、最近はもうちょっとエモいことも考えていて、なんというかエンジニア不足が叫ばれてる中で、限られたリソースの中で未知の技術にチャンレンジしなければいけないとか、フルタイムでなく副業ベースの組織でナレッジをためていかなければいかないとかのソリューションとしてお手本にならないかと考えていたりします。

すえなみチャンスがゆるくコミュニティになるといいなと思っている

すえなみチャンスは僕が僕だけのためにやってることなので、公共の何かを口にするのは大変おこがましいのだけど、僕としてはなんかこれが何らかのコミュニティになったりするとおもしろいなーと思っていて、来年はそういうチャレンジもやっていきたいと思っている。*2

とりあえず、それの第一歩になるかどうかはわからないんだけど、以下のようなイベントを開催するので興味ある人はぜひ配信を見てもらえればと思います。

connpass.com

本日の焼肉屋

a-suenami Advent Calendar 2018 - Qiita ではすえなみチャンスにちなんで、毎回僕のこれまで行った焼肉屋の紹介をしようと思うのだけど、初日の今日は渋谷の太樹苑というところを挙げました。

僕は職場が渋谷だったことが今までの人生で一番長く、焼肉屋と言えばここっていうくらい何度も行ったところなのです。*3

塩カルビという肉があって「焼き方ご存知ですか?」と毎回聞かれます。(トングで叩きながら焼く)

ご賞味あれ。

tabelog.com

*1:拒否されたわけでなく、ブログ書くのが面倒でそもそも聞いてない

*2:具体的にどうするかは未定

*3:決して安いとか不味いとかってわけではないので、何度も行きすぎて当時の同僚たちが「太樹苑はもう飽きた」と言うほど。

流行り(?)のすえなみチャンスを実施した 〜ペアモデリングとペアプロと焼肉と〜 #すえなみチャンス

経緯

何故なのかまったくわからないんだけど、数ヶ月前からTwitter界隈で謎にタカられるようになった。 以下のようなハッシュタグまでできてもう収拾がつかない状態であった。

twitter.com

これはこれでネタとしておもしろいし、僕もいろいろ勉強したいこともあるので逆に利用してやろうと思って、

というツイートをしたのがもう半年くらい前。

ついに先日お声がけいただいた。

まさかの増田さん!!

というわけで、先日、増田さんの事務所にお邪魔していろいろ勉強させていただきました。

やったこと

ざっくりやったことはモデリングとそれの簡単な実装。

僕の前職がメディアの会社だったので、記事をコンテンツの中心とするサービスを真面目にモデリングするとどうなりますかねぇ、というのがテーマ。

ざっくりこんな感じ。

f:id:a_suenami:20180526174257j:plain

モデリングのあとは実際にコードに落とし込むためにペアプロ…のはずなんだけど、相手が増田さんなので言語はJavaで、普段僕はRuby使いなので言語にもIDEにも慣れてないということで、増田さんがずっとドライバーで僕がずっとナビゲーターって感じだった。

増田さんと一緒にモデリングペアプロ(?)をやった感想としては

  • 業務プロセスとかデータ構造が複雑になりそうなところへ嗅覚がすごい
    • メディアだと編集から公開にいたるいたるプロセスが複雑でしょ、とか、例えば画像コンテンツがあったときにその画像と記事はどっちが主役なの、とか
    • 複雑になりそうなところをあらかじめ抽象化しておいて具象クラスは差し替え可能なように設計しておきましょう、とか
  • 型名(クラス、インターフェース、Enumなど)の命名が早い
    • たぶんこれまでの経験からある程度パターン的なものがあるんだと思う
    • 変数名は型名と違ってかなりスコープが限定される*1ので、結構気分で命名するらしい

という感じでした。

焼肉

ペアプロ(?)のあとは近くのトラジにいきました。もちろん僕のお金です。

肝心の焼肉の写真を撮り忘れたので店の前の写真で失礼…

f:id:a_suenami:20180526203347j:plain

焼肉を食べながら感想戦というかむしろこっちが本番なんじゃないかというくらいモデリングとか昨今の技術トレンドに対するお話とかしました。 増田さんのこれまでやってきた仕事や今やってる仕事の話も聞けてすごく楽しかったです。(小並感)

すえなみチャンス参加者募集

なんか初回からすごい人が出てきてしまったのでアレなんですけど、 #すえなみチャンス は引き続きやっていこうと思ってるので随時募集中です。

やることは簡単で、僕とペアプロしてその後焼肉に行く、それだけです。

僕は今時間的な自由は比較的ある*2ので、自分の技術的な幅を広げたくていろいろなことをやってみたいと思っています。 iOS/AndroidアプリとかWebフロントエンドは特に強く募集してます。

*1:増田さんの場合は特に…

*2:無職という説もある

無限のメモリ空間と絶対に落ちないプロセスを仮定して「ビジネスロジック」をあぶり出す

先日、前職の上司から「そろそろプロフィールに"詩人"を追加するべきだ」と言われました a-suenami です。今日も今日とて詩人業を行なっていきますよ!

ビジネスロジック」とは何か

最近、業務で、比較的中長期的なアーキテクチャの見直しだったり、新機能の設計だったりをさせてもらう機会が増えた。

コンポーネントをどういう風に分割するかとか、それぞれのコンポーネントを主にどのチームでメンテナンスしていくかとか、そういうのを考えるのは楽しい反面、かなり熟慮に熟慮を重ねないといけないものでもあるのでかなり責任を感じるというのもある。

まあ、そんなこんなでいろいろうーんうーんって悩んでいると昔(たぶん DDD コミュニティだと思うけど)誰かに言われた「無限のメモリ空間と絶対に落ちないプロセスがあったとして、それでもそのコードを書かないといけないのならそれがあなたのドメインだ」という言葉だ。

モデリングをしているとドメインロジックとかビジネスロジックとかって言葉はよく出てくるんだけど、これは結構なかなか人によって解釈が違っていたり、明確な定義がなくて難しい。エリックエヴァンスの DDD 本ではユビキタス言語というパターンがあって、それがちゃんと構築できてる前提であればドメインか非ドメインかわかりやすいんだけど、あれをちゃんと実践するのはすごく大変だ。僕も何年か前にあの本を読んで以来、チーム内でいろいろ試みてみたけどいまだに手応えのある成功体験はないし、プロダクトオーナーを含むチーム全体を巻き込んでいかないとかなり厳しい。

で、もうちょっと簡単にそれがビジネスロジックなのか or not を判別したいことがあって、それをもとにその振る舞いをどこに実装していくべきかって考える感じのことがある。まあイメージとしては軽量 DDD というか、少なくともエンジニア同士では認識が揃っていて、何かを実装しないといけないときにそれをどこに定義すればいいかを迷わなくてもいい仕組みくらいだと思ってもらえるとよいと思う。もしそれを修正しないといけないことになったとしたときに、それがビジネス都合なのか、アーキテクチャ都合なのかをちゃんと区別して、決してそれが混じらないということが実現されるだけでもかなりシステムのメンテナンスは楽になる。逆に、どっち側の変化によっても同じオブジェクトやメソッドが修正されるという状態は明らかにオブジェクト指向設計の単一責務原則に反しているし、障害が発生したときの問題切り分けが著しく難しくもなるので基本的に避けたい。

もちろんそうやって分割されたオブジェクトやメソッドのうち、ビジネス都合で定義される側のクラスやメソッドがユビキタス言語になってるほうがなおよいけど、まあそこは一旦エンジニア同士で伝わればいいよねっていう妥協もアリだと最近は思い始めた。*1

そして、その判別方法が「無限のメモリ空間」と「絶対に落ちないプロセス」を仮定することによる思考実験である。たぶん厳密には「断線・遅延しないネットワーク」も必要なのかもしれないけど、まあ要するに永続化やキャッシングから解放されたときにそれでもそのコードは必要なのかっていうことで、これはなかなか結構おもしろい思考実験である。

僕たちがどれだけ永続化に関するコードを書いているか

これ、実際にやってみるとわかるんだけど、実際に考えてみるとほとんどのコードは必要なくなるってことに気づく。僕らが一体どれだけ永続化とキャッシュに振り回されてるのかってことだ。

逆に言うと、そのレイヤーの心配ごとが軽減すれば僕たちはもっと自分たちのビジネスに集中できるし、ちゃんとしかるべきクラスだかオブジェクトだかに隠蔽してあげてビジネスロジック層からは意識しなくて済むようにしてあげるべきなんだよ。設計ってそういうことだと思うんだ。僕が ActiveRecord を Dis るのは(おっと誰か来たようだ

システムは何故バグるのか

これは完全に僕の経験則だけど、システム障害において、ビジネスロジックにバグが混入していたというケースは実はそんなに多くない。エンタープライジーな開発現場を経験してないので、そもそもこのレイヤーのロジックが薄いプロジェクトしか知らないというのはあるのかもしれないけど、それにしたって永続化やキャッシュに関するバグ、ミドルウェアや連携システムの冗長化不備がほとんどである。

その中でも本当に多いのは

  • キャッシュに関する何か
    • リフレッシュされてなくて古いキャッシュを参照する、等
  • 失敗可能性(要するに NULL 参照)の考慮漏れ
  • 永続化したデータの取得遅延
    • まあ、平たく言うとスロークエリ

で、僕は勝手にこれを三大バグ発生要因と呼んでいる。(あくまで勝手に)

永続化もキャッシュもなくてよくて、NULL もない、そんな理想郷がもしあるならその世界で実装されるシステムの障害は激減するはずだ。

ビジネスロジックは意外と薄い(かもしれない)からこその創造性

これは仮説だし、僕自身まったく検証できてないんだけど、それを念頭に読んで欲しい。

思考実験として仮定した無限のメモリと落ちないプロセスは実際には実現不可能だけど、コンポーネント分割を工夫して永続化に関する関心事をあるレイヤーで隠蔽することはできるし、そうするべきでもある。それによって、少なくともビジネスロジック層から見れば永続化を意識しなくてよくなるので、先に述べた理想郷が仮想的には実現できる。

で、このときに気づくんだけど、実際にはビジネスロジックなんて予想外に少ない。もちろんドメインによると思うけど、Web アプリケーションにおける参照系の機能(つまり Web ページの閲覧)なんてだいたい DB に入ってるデータをそのまま画面に表示するだけだったりするし、あるとしたら表示整形くらいでそれはビジネスロジックというよりはプレゼンテーションのロジックだ。僕は今メディアの会社にいるのでなおさらだけど、ビジネス = プレゼンテーションみたいなもんである。

そういう状況にエンジニアが放り込まれたらどうなる?

エンジニアは本質的にコードを書きたい人種が多いんじゃないかと僕は思っている。そんな人たちが永続化の関心事が隠蔽されていて「コードを書く必要がない」環境に置かれたら、どうやったら自分たちはもっとコードが書けるか、こういう機能が実現できたらいいんじゃないかっていう創造性が発揮されるんじゃないかなと。これは予想というよりも自分と一緒に仕事をしてくれる人たちにそれを期待したいっていう意味も込もってるんだけど。

もちろん一定数のエンジニアには低レイヤーへの憧れみたいなものもあると思うし、僕も若い頃には Linux コマンドを使いこなして、呪文のようなバイナリを見たり、まるで MySQL と会話しているかのような先輩エンジニアに尊敬の念をよく抱いたものである。ビジネスロジックが意外と薄いということは、逆に言えばシステムの根幹をなすのは永続化部分のコードだとも言えるのでそこに興味を持つのは自然なことだし、その場合は隠蔽された先の、永続化に関するコンポーネントの実装に携わればよい。

重要なのは、今自分が何のコードを書いているのかちゃんと意識すること。

ビジネスを加速していくために新しい機能を実装するか、その人たちを支えるために適切に永続化を隠蔽するか、趣味・嗜好も得手・不得手あるだろうし、会社やチームの都合でどっちがより重要なフェーズかってのもあると思うけど、少なくともそこが適切に分離されていて、どちらかをやっているときはもう一方を意識しなくていい状況は最低限実現していきたよねと思った週末なのであった。(いい感じにまとまった。たぶん。)

追記 2016/09/25 16:01

きょんさんからコメントいただいたので追記。

このエントリで「ビジネスロジック」という言葉を使ったのは単にわかりやすいと思っただけなのと、代替できるわかりやすい他のワードが思いつかなかっただけである。今となっては反省している。

僕自身も普段の業務において「ビジネスロジック」という言葉はあまり使わないので、とりあえず Twitter ではしれっと弁明しておいた。

ただ何て言うんだろうな… まさにきょんさんが言っている「適切に分割して、適切な注意を払え」っていうのがこのエントリで一番伝えたかったことで、それはどんなシステムでも必要なことだろうし、ましてオブジェクト指向パラダイムを持つプログラミング言語を使っていれば息を吸って吐くようにできないといけないことではあるんだけど、実際にはそれができてない人やチームがあって、そのときにわりとわかりやすい分割の方法論としてのこの思考実験を提案したかったっていうのがたぶん正しい。

このエントリで言っている「ビジネスロジック」というのは適切な命名が難しいので長ったらしい文章で説明するしかないけど「非機能要件を隠蔽して機能要件のみを抽出したもの」のことで、これは技術的バックグラウンドのない人のメンタルモデルに近いはずだし、ユースケースはここで抽出された語彙を使って記述されるべきだよねって僕は思っているので、そのためにはまずそこを分割して語彙を手に入れないといけないというのが主な主張。

ちなみに「ユーザーストーリになればより非機能的な部分がふえてくる」というのはきょんさんのコメントで初めて気づいた。確かにそうだ。

さらに追記 2016/09/25 16:16

もしかして機能的・非機能的という分類自体がもう必要なくて、やはり時代は ActiveRecord なんだガハハみたいな意見があったり、そういうデザインパターンや組織パターンがあるのだとするとそれはそれで興味深い気もする。

システムというのは必ず何らかの要求にもとづいて構築されるもののはずで、従来(汎用機〜クライアント・サーバ時代まで?)はその要求の内容として機能的なものが支配的で非機能的なものはエンジニアが何とかすればよかったけど、今はそうじゃなくてむしろ非機能的な部分こそがビジネスの中心を担うことがある(実際、僕の今いる会社とかはその可能性がある)のだとすると、その非機能要求が一体どういう言葉で誰の手によって作られて、どういう伝達をされて、どのようにして実際のチームの開発プロセスに取り込まれていくべきなのかという議論は大変興味深い。

十分な性能、十分なセキュリティ、安定稼働、こういったものは今までは UX のなんとか品質モデルでいうと「当たり前品質」とかって呼ばれるものだったと思うんだけど、むしろこれが「動機付け品質」になりうるのだとすると、そのときの組織のあり方やアーキテクチャのあり方はどうあるべきなんだろうな〜とちょっと思ったりする。

*1:DDD界隈の方々、すいません。マサカリは甘んじて受ける覚悟です。

知っていてこだわらない、それがいいソフトウェアエンジニアの条件なんだと僕は思うんだ

週末の午前中、カフェでアイスコーヒーを飲みながらふとポエムでも書いてみようかと思い立ってしまったので、ちょっと前からよく考えていることを書く。本当に思いつきで書くので乱文になる可能性が高いけどご容赦いただきたい。そもそもブログを書くこと自体が相当久しぶりだ。

僕ももう 30 をすぎて、プログラマの世界ではさすがにもう若手とは呼べなくなり、教育っていうのはおこがましいけど、まあ自分より若い人たちの指導みたいなことをやらないといけない立場になってきたからこそ、「いいプログラマとはどういう人なんだろう。この人たちはどういうことを学べたら幸せだろう。」ということをよく考えるようになった。そういう話をする。

プログラマは手段のスペシャリストである

世の中には目的・手段論みたいな論調が存在する。 「それは手段だよね。目的をはき違えたらダメだよ。」という話はいたるところでよく耳にするんだけど、僕はこれを結構ナンセンスな話だなと思っている。目的と手段というのはスコープによって異なってくるし、そういう意味ではかなり強く文脈に依存していると思うからだ。

例えば「大学受験に合格する」という誰かの想いがあるとする。これは高校 3 年生や予備校生にとっては目的になりうる。そのために彼らは一生懸命勉強しているんだから。でも長い人生の中においては大学に入学するということ自体が別の何かに対する手段だ。 ビジネスの現場においてある人が目的だと思っている KPI の達成だって究極的には利益を上げるための手段だし、その会社の存在そのものが営利とは別の何かを成し遂げるための手段かもしれない。事業の数字をきちんと作るというのはプロジェクト内では目的だけど、株主総会では完全に手段だ。目的・手段論なんてそんなもんだと僕は思う。

目的と手段なんて今その状況において対象としているスコープに依存する。だからそれが目的なのか手段なのかなんて気にしなくていい。まして我々が生業としているプログラミングなんて多くの場合において手段だ。プログラミングが目的のケースなんて計算機科学の研究者くらいじゃないだろうか。(そしてそれも別の応用研究から見れば手段だ。)

昔、誰かが「プログラマは手段のスペシャリストだ」と言ってたんだけど、これはその通りだと僕も思っていて、だから僕らは、偉い人に「それは手段だよね」って言われても堂々と「ええ、だってそれが僕らの専門性ですから」って言い返せばいい。手段のスペシャリストだからこそ、目的が何であれ、僕らはそれを達成することに注力すればいい。それが僕らの仕事なんだよ。

手段へのこだわりがエンジニアをスペシャリストにする

ただ、プログラマに関して言うと、いやプログラミングに限らずソフトウェアエンジニアリング全般がそうだと思うけど、ある分野に精通してそれを手段として使いこなせるようになるためにはそれなりの時間と経験を要するし、それは結構狂気に似た没頭が必要だと思う。それこそ「目的なんか知るか。俺はこの技術が使いたいんだ!」っていう態度が結果的にその人をその技術のスペシャリストに導くことも多いし、自分が置かれている状況を理解していわゆる"大人な選択"をするようでは没頭しているとは言えないことも多い。

そういった手段へのこだわりや情熱を持たず、その時点での目的に対して必要最小限の技術の使い方しか学ばず、早い段階でバランスのとれたエンジニアに成熟してしまった人は、平時には高いパフォーマンスを発揮するんだけど、目指すべき方向性が変わってしまったときや緊急の対応が必要な時に頼りにならない。

僕はそういう「大人で、聞き分けのいい」ソフトウェアエンジニアになりたいと思わないし、自分の後輩や同僚にもそうなって欲しくないと思う。

知っていてこだわらない、それがいいソフトウェアエンジニア

例えば、初めて自転車に乗れたときの感動を今でも覚えている人はいるだろうか。かっこいい乗り方、速くこげる乗り方、疲れない乗り方、子どものころにはそんないろいろな方法を練習した人も今では単に移動の手段で使っている人が多いのではないかと思う。

目的だったものが手段になるということはそういうことだと思う。かっこいい自転車の乗り方も知ってる、疲れないこぎ方も速くこげるこぎ方も知ってる、だってかつてはそれに強いこだわりをもって必死に練習したんだから。でも今は単にある場所まで移動したいだけだからそのために必要最低限の使い方をするんだ、と。

エンジニアリングもそうなんだよ。あるプログラミング言語の得意とすること・苦手とすること、データストアとして RDB が得意なこと・NoSQL が得意なこと、各アプリケーションフレームワークの設計思想、そういうのは熱狂的なまでのこだわりとそれなりの量の経験の先にしか身につかない気がするんだけど、さらにその先にそれを手段として使いこなせるようになるんだと思っていて、そのときにこそ熱狂的な情熱からちょっと冷めて物事を俯瞰的に見れるようになるんだと思う。

もちろん情熱を失ったほうがいいと言いたいわけではないし、必ずしも俯瞰的な見方をしたほうがいいというわけでもない。ある領域へのこだわりや情熱は個人の嗜好性の範囲ではずっと持ち続けていいと思う。 ただ多くの開発現場がチームでプロジェクトを進めていく以上、チームで目的とすることとそれを実現する手段の整合性は重要で、そのためには目的と手段のスコープの切り替えが大事になってくると思っている。 そういう意味で、熱狂的な情熱と周辺領域まで含めた俯瞰的な視点の切り替えを繰り返していくことは大事で、その結果だんだん目的と手段のスコープの切り替えが上手になっていって、手段としての専門性の深さと目的との整合性をうまくとれるような、そんな理想のエンジニアになれるんじゃないかなと思うんだ。

僕が理想とする「知っていてこだわらない」エンジニアというのはそういう人で、僕自身も今後もそれを目指していくし、僕が若者に伝えていきたいこともそういうことなんだよなぁ。

TDDBC 仙台 5 に行ってきた #tddbc

2015/11/14(土) に TDDBC 仙台 5 に行ってきたので忘れないうちに書いておきます。

きっかけ

TDDBC 仙台には 2 年前に TA として参加したんですが昨年は参加してなくて仙台の皆さんにはすっかりご無沙汰してしまっているなと思っていたところで今年もやりますというアナウンスが TL に流れてきた感じでした。

そこでサポート言語の中に Go があることを確認して参加を決めた感じです。 今仕事で Go を使ってるのでもっと慣れておきたかったのと、Go のテスト文化は特殊すぎるので一度 TDDBC で議論してみたかった感じです。

前日と当日朝の様子

前日こんな感じだった僕です。すごく無計画ですね。

しかもちゃっかり花金も満喫してます。

結果がこれです。

というわけで、運営のみなさんや僕とペアを組む予定になっていた方*1には本当にご迷惑をおかけしました。すいません。

慌てて東京駅に向かい新幹線に乗り込んで、何とか午後のコンテンツから参加させてもらいました。

お題

TDDBC 仙台といえば毎回 takehiro_i さんが作成してくれているお題がひとつの楽しみだったりするわけですが、ご多分に漏れず今年もとてもおもしろい課題でした。格子点を扱う課題だったのですが、すでに全文公開されているので詳細は以下を参照してください。

TDD Boot Camp(TDDBC) - TDDBC仙台05/課題

僕も参加者として課題を解いたのですが個人的におもしろいなーと思ったのは以下のあたりでした。

  • 課題が段階的に公開される
    • これは以前の仙台開催のときもそうでしたね。
    • 実装するべきものの全体像がはじめはわからないので TDD のフィードバックループをまわしやすいお題提供のしかただと思います。
  • 早すぎる最適化 v.s. 拡張可能な設計 ファイッ
    • 上記のお題提供のされかたと関係しますけど、全体像がわからないから現状書かれたテストをグリーンにしたあとにどこまでリファクタリングするかというのがペアによって個性が出てたと思います。
    • ある程度抽象化してその抽象化したものに名前をつけて別の型や別のメソッドとしていたり、次の課題以降でどういう拡張があると予想して設計判断をしていたり、逆にグリーンにした後にほとんどリファクタリングせずにほぼベタ書きのままのコードが残っていたり。
    • いろいろな設計判断があっておもしろかったと思いました。
  • 型設計や責務設計の重要性がフィーチャーされやすいテーマ
    • 格子点とその集合をどういう型として設計するかとかそれぞれの責務をどういう風に考えるかというところが重要になる課題だったかと思います。
    • そういう意味で言語の文化や個性がよく出てた気がします。
    • 今回はなかったですが関数型のパラダイムが色濃い言語だったらどうなったのかちょっと興味があります。

で、お前は結局何やってたの

盛大な寝坊 & 遅刻のために本来やろうとしてた Go でのペアに入れなかったのですが、スタッフさんとペアだった JS 組があったのでそこでペアチェンジして ES6 でお題を解いてました。 僕の ES 力が低すぎて若者に迷惑をかけたところもあると思いますけど、TDD 的な視点でいろいろ教えることはできたんじゃないかなーと思います。

とてもモダンな JS 環境で TDD できてテンションあがったのでこの流れでフロントエンドエンジニアを目指すのもいい気がしますね。

懇親会 & LT

終わったあとは会場であるメンバーズさんのオフィスでそのまま懇親会兼LT大会が執り行われました。 和室っぽいスペースがありゆったりとした雰囲気でLT聞いたりディスカッションをしたりできました。

僕も LT しました。思ったより好評でよかったです。

www.slideshare.net

お礼

TDDBC はもう何度も参加してますがそれでも本当に毎回新しい学びがあり、今回も参加してよかったと思います。 スタッフの皆さん、会場を提供していただいたメンバーズさん、本当にありがとうございました。

一応 Go でやってみました

元々は Go で参加するつもりだったので、ペアプロはできませんでしたがソロで自分なりにやってみました。意見募集です。

*1:Goで普通にペアができる予定だったらしい