基本的に私は社内のあるプロジェクトに携わっていて、中長期でプロダクトの開発をしています。社内にはいくつかの事業部が有り、それぞれにエンジニアが在籍していて各々に開発を行なっています。システムの基盤だけは別で、中央集権的に管理されています。おそらくはよくある形式ではないかと思います。
Githubが活発になった
ちょうど昨年から github.com によるプライベートリポジトリによる運用を始めた部署が増え始めました。gitの素晴らしい世界を語りだすと大きく本質から外れますのでとりあえずそこはビールを飲みながら語るとして、兎にも角にもgithubに載ったおかげでコードをレビューしたり他のプロジェクトの活動を追いやすくなりました。私などは息抜きに他のプロダクトのコードを見たり、たまにコードにコメントしたり、たまに各言語の深手の会の方々から突っ込みを受けたりしてします。これはなんというかエンジニアリングにおける血流のようなもので、脈々と流れるgithubのフィードを眺めながらプロダクト開発のスピードを感じたり、Jenkinsは私より働いてるなーと思ったり、Pull Request出したのに取り込んでもらえないからリマインドを送ってみたりと、まぁ楽しく開発しています。そんな中でもやはりWebの会社ですから同じようなコードを実は書いていた、なんてことも発見されやすくなって「じゃあ共通化しちゃえばいいんじゃね？」という気軽な提案が社内グループウェアやIRCで交わされ、気がつけばリポジトリが出来て…なんていう光景を目にするようになりました。あら、何かGithub素晴らしいというようなことをただ書いただけになってしまっていますね。でも本当にこの開発スタイルは良いところが多いのです。あんまりメインで関わっているプロジェクトではないけど一部分連携していてちょっと口出したい、というときにも気軽にissueにコメントしてあれこれ確認したりコードを参照してあれこれ言えるわけですから、本当に便利になったものだなぁと思います。最近ではcommitコメントで大喜利が行われる程に盛り上がっております。
そういう観点で言うと、DIというか、私自身の設計の筋も少しずつ変化してきたように思います。「これ使い回せたらいいなー」から、「まぁこの抽象度は必要そうで、実際にあのへんのプロジェクトとかであとから使えそう」とか、極端に言えばデータ処理なんて全部ストリーム処理とみなしてしまえばHadoop Streamingでのローカルのサーバでも適宜動くような幸せなモノが作れそうだとか、よくそんなことを考えたりしています。
書くコードの量が減った。しかし生み出したものは増えた。
上記の話と関連している点でもありますが、書くコードの量は減りました。でも不思議と生み出すものの価値は大きくなっていて、スピードも上がりました。これは私個人の話です。今のプロジェクトでは「コードをなるべく書かないようしましょう」方針を採用いるのですが、私の中でもこれをより実践できてきたのではないかなぁという手応えを得ています。たとえばSparse Matrixの計算効率調整するのそういえば各プロダクトコードは短くなりましたが、テストコードが長くなってしまうのが最近の悩みだったりします。私はもう少し良いテストについて学ばなければなりません。まだ自分の中にベストだと言い切れるテストの方法が構築されていません。
やることが散らばった。質のことを考える時間が減った。
これは良くない話。比較的多岐にわたる分野のことに手を付けてしまったなぁという反省があります。去年の9月に書いた記事でも色々やったようなことを書いてあるのですが、今もやはりあまり変わりありません。JenkinsやらHiveやらAWSの特性を生かしたデプロイ、それらに加えてmongo周りの調整、R、機械学習周りのことをやったと書いています。この当時私の中で個人的に仕込んでいた統計周りの知識やら機械学習周りのことは今事業にも活かすことができていますから、今振り返るととても良いことでした。ただ、特に今年に入ってから事業を加速させていくために質よりもスピードを重視しなければならない時間帯が増えました。それ自体は悪いことではないのですが、スピードを保ちながら質を担保したソフトウェアを書くということはいつも難しいことですから、当然負債は溜まっていくわけです。負債の匂いを感じることはできているので都度修正していきますが、同じソフトウェアの実装に集中している時間が短いため、あまり成果が大きく出ないという悩みがありました。例えば朝はJenkinsの運用周りとmongoのパフォーマンス調査をして、昼食後の開いた時間にphpでapi周りの仮実装をして、その後にHiveクエリを書いて分析を回しておきながら、夜はMahoutの挙動と運用について調査と実験をする…といったようなことが日常的に起きています。これは望んでやっているので良いのですが、質の高いソフトウェアを書くという点ではあまり良くないのかもしれない、と最近は思うのです。幸い少しずつチームが大きくなるに連れてタスクが別れてきていますから、私はよりデータ周りのことを見ていく時間が増えるかもしれません。とはいえプロダクトの成長を支え、判断をし、適切に、かつ、有効にデータは使わなければなりませんから、やはりプロダクトがどういう方向に進むべきかを知るという意味では今後もしっかりとプロダクトに軸足をおいて取り組んでいくということに変わりはありません。
そしてもう一つの良くないと思っていることは、こういったスピードを出して色々試して形にしてビジネスとして一緒に取り組んでいるチームの皆さんに、プロダクトの質を上げていくことの重要性を伝えきれていないなぁと思うことです。継続的デリバリーが如何に大事か、整然として誰が見てもストーリーの伝わりやすいコードとそうでないコードで機能を追加するの大変さが如何に違うか、チームで開発しやすい環境を作ることがどれだけ将来的にプラスに作用するか、数字を追いやすくプロダクト開発に活かせるようにしていく体制を作ることが如何に大事か、効果を繰り返し検証して調整していくことが如何に大事か…。エンジニアの方々に伝わりやすいことでも、チームに伝えるのにはそれ相応にわかりやすく、費用対効果を伝えるようにしなければならない。これにやはり苦労している部分はあるなぁと最近は思います。比較的よくコミュニケーションを取って一緒に勧められている部分もあれば、「まだそこの部分はリリースしてほしくないんです…。まだデータをとって検証する環境をつくれていないんです…。」というようなところでも気がつけばリリース優先になってしまったりするので、そのあたりは今後どうにかせねば…と思っています。もちろんバランスは必要ですが、総じてアグレッシブだなぁと思うことは多いです。
そういう面で、仕込んできた芽はでてきたけれど、今は芽に葉っぱが生えたような状態のものを、より太陽をたくさん浴びさせて伸ばしていくか、というようなところが今のプロダクト開発における今後の私の最大の関心であるようです。
やっぱりAJITOはすごい
上記のような話をAJITOでし始めるとたくさんの発見があるので、もっと社内の人はAJITOで一緒にビール飲みましょう。まとめ
* Githubはやはり良い。* コードあまり書かない方針は続ける。
* 今後も継続して色々ミドルウェア触るけど、自分の中で線引しっかりして、チームメンバーにもっと共有する。
* AJITOでビール飲みましょう。
