エンジニアの @tmtysk です。弊社はUX/UIデザイナーとソフトウェアエンジニアで構成された請負型のWebサービス開発企業ですが、外部パートナーとプロジェクトチームを構成することも多いです。
請負型の開発会社にとって、社外の開発パートナーと一緒に仕事をするというのはどのような意味があるのでしょうか。今回は、とある請負開発プロジェクトでご一緒させていただいたソフトウェアエンジニアであり、株式会社スマートアルゴリズムの代表でもある @mokichi さんをお招きし、弊社のエンジニア @junara と、開発PM兼エンジニアを務めました私 @tmtysk とで、一緒に参画したプロジェクトについて語ってみました。その模様をお届けします。
弊社がどのように外部パートナーとの協業を進めているか、どんなプロセスを大事にしているか、感じていただくきっかけになれば嬉しく思います。
@tmtysk mokichi さんには、弊社で請負している某システムの開発・運用プロジェクトに、3年弱関わっていただいています。弊社プロジェクトチームに参加いただいて、率直な感想はどんなものでしょうか。
@mokichi とにかく、規模が大きなプロジェクトに参加させていただいていると思っています。機能の多様さ、データ量の大きさは、これまで私が関わったプロジェクトの中でもトップクラスのものだと思います。今回のプロジェクトは、旧システムからの移行切り替えもありましたが、旧システムでは、いわゆる「運用で解決」していた複雑なシナリオも多くありましたので、一時期は大変だったな、という印象があります。
一方で、働きやすいプロジェクトだなとも思っています。要件定義して、見積もりして、実装して納品、といったような関わり方ではなく、長期間、プロジェクトの一員として参加させていただいています。参加にあたって、クライアントとのコミュニケーションは tmtysk さんに一手に引き受けていただいていましたし、開発スタックやDevOpsを随時モダンなものに整えていく文化もあったので、コミュニケーションレイヤがエンジニアリングの部分だけに集中できたというのも良かったと思います。
@tmtysk ありがとうございます。弊社としても mokichi さんのようにレベルの高い方に、長期に渡って参画いただけていることに、とても感謝しています。 junara さん、mokichi さんのような方に参加していただいていることについては、率直にどう感じていますか？
@junara とにかく安心感がありますよね。心強いというか。何か詰まったり、ハマったりしたとしても、拾ってもらえるのではないか？という安心感があります。
具体的なエピソードもあります。対象のシステムで扱われていた、複雑な要件をもった機能開発のシーン。会計系の機能で、重要度が高い箇所でした。
ある程度設計が進んだ後で大きな設計変更が必要になったために、ちょっと設計を変えると他の箇所で矛盾が出てしまうような、変更のアプローチがわからなくなってしまったことがあったのですが。あれこれ試行錯誤していたなかで mokichi さんに相談したところ「何を達成したいのか？」というシンプルな問いから、設計変更の課題を整理していただき、スマートに解決に持っていただけました。あれは、ありがたかったですね。
@mokichi あの機能は、たしかに複雑でしたね。元のユースケースがそれなりに複雑だったということも関係していそうです。新システムで扱えるデータ形式を整合・成立させつつも、旧システムで運用カバーしていた領域の移行データも扱えるようにする必要がある。ここに、先ほどもお話したのですが、扱うデータ量の大きさという難しさも載ってきていましたね。
@tmtysk データ量に起因する課題について、もう少し詳しくお聞きできますか？
@mokichi はい。よくあるアプリケーションチューニングですと、真っ先にN+1問題の解決に目が付けられたりするのですが、今回は移行データの全体量やバッチ処理の単位がそれなりに大きかったために、処理実行にメモリを食いすぎる問題が発生していましたね。バッチ処理では発生しがちな問題ですが、工夫のしがいがあるところではありました。
@junara mokichi さんの設計は、エレガントですよね。いま仰ったような対応箇所のコードを読んでいると、純粋に楽しかったです。「こんな風に書くんだ」と。移行処理やデータの一括修正など、1回しか使わない処理であっても、再利用性が考えられていて、整然としているな、と思いました。
他にも、私も設計の勉強をしてきましたが、デザインパターンなど、本では読んだことがあっても、うまく実案件の実装コードに落とせていなかったのですね。mokichi さんには、そういった、生きたサンプルを幾つもプロジェクトに持ち込んでいただきました。おかげで、私も1件、Strategyパターンを使った汎用のバッチ処理を設計・実装できたのですが、これは自分でも、うまく応用できたな、良い設計ができたなと思っています。
@tmtysk 「良い設計」興味深いですね。私も mokichi さんの設計は、スマートだな、と感じることが多いです。その秘訣はどこにあるんでしょうね。
@mokichi 秘訣、になっているのかはわかりませんが、私の癖として、処理の単位ごとに冪等性が担保されるような設計をしている箇所はあると思います。何度やっても同じ結果になるようなアルゴリズムにまとめることで、間違って実行されても、気軽に再実行できる。そういう設計を心がけていますね。
@junara なるほど、たしかにそうですね！そこに使いやすさを感じます。結果、インタフェースもわかりやすくなっており、自分の設計から呼び出すときも、思ったように動いてくれる。運用で発生しそうな例外処理も考慮されているので、気軽に使えるんですよね。
mokichi さんは、大抵、何を振っても応えてくれる安心感があるのですが、今回のプロジェクトで、「これは無理だな」って感じたことは無かったのでしょうか。
@mokichi 基本的には無かったですね... 「これは大変だな」って感じる話は何度かありましたが、「無理だな」と感じることは、ほとんど無かったように思います。あったとしても、基本的には「代わりに、このようなやり方ならできます」という代替案を複数提示することを心がけていますね。問題を、別の近い問題に置き換えたり、近似的な解にもっていったり。ひょっとしたら、そのような提案をさせていただいたことはあったかもしれませんが。
@tmtysk mokichi さんの技術力はもちろん、仕事観や仕事力も感じられるようなお話ですね。気づきの多いお話をお聞きでき、とても刺激になります。
junara さん、mokichi さんとご一緒してきて、今後の私たち、ビルディットとしての課題をどのように考えていますか？ mokichi さんのような方とお仕事をご一緒することで、どのような効用がありそうでしょうか。
@junara 外部の強い方に、強い仕事をしていただけると、自分たちも常に目標をupdateして「チャレンジしてみよう」という気持ちになれますよね。そういった機会が無いと、不本意ではあるのですが、手堅い仕事で固めてしまう、まずは要件を満たすベースラインを押さえることだけに意識が行ってしまいがちです。
強い方と一緒に仕事ができることで、「自分も、もうちょっと背伸びしたタスクに取り組めるのでは？」という意識になれます。さらに言えば、こういった環境を自分たち自身でつくっていく、「良いコード」をより意識していくきっかけや文化を自分たちで作り出していく、こういった環境づくりが、私たちの課題になるように思いますね。
@tmtysk ありがとうございます。チームに良い刺激をいただきながら、より良いチームを目指していくという営みを続けていきたいですよね。
mokichi さん、最後に、弊社のチームにメッセージをいただけますでしょうか。
@mokichi そうですね。こういったふりかえりの場もそうなのですが、ビルディットさんは、社内体制の強化や育成に重きを置いた社内プロセスをつくっていっているように感じています。
技術者として、押さえるべきことをしっかりと学ぶだけでなく、学習を続けられる環境に身を置き、技術力を高め続けることは、とても重要なことだと思っています。tmtysk さんも同じ経営者ですので、ビジネスを考えなければならないこともあると思いますが、開発会社において、そういった学びのプロセスを維持運用し続けることは社会的な意義のあることだと思っているので、そういった考え方をブラさずに、今後も続けていってほしいなと思います。応援しています。
@tmtysk ありがとうございます。最近、弊社のビジョンメッセージを「一人ひとりの成長が、世界をより良くする」と置いたばかり*1です。このメッセージを掲げ続けられるように、全社で取り組んでいきたいと思います。
今回の記事では、外部パートナーの mokichi さんを交えたエンジニア鼎談をお届けいたしました。
冒頭ご紹介したとおり、mokichi さんも開発会社の代表であるのですが、弊社での請負プロジェクトに長きに渡ってお付き合いいただき、とても感謝しています。私たちは、単に請負上の足りないリソース/工数を外部から補填するという考え方はもっていません。その領域に強い方とご一緒することで、仕事を通じながらも、より貪欲に自分たちの成長機会を創り出していきたい。そんなパートナーシップに対する考え方を、記事からもお伝えすることができたなら嬉しく思います。
mokichi さんにもコメントいただきましたが、私自身、このようなプロセスを運用できる環境を、会社として確立していくことは意義のあることだと思っていますし、こういった価値観は(弊社の専売特許とは思っておりませんが)弊社だけでなく、多くの会社で共有していければ良いなと常々思っています。
この記事を読んで、こういった価値観の組織をつくっていきたいという方はもちろんですが、あわよくばビルディットの内部から体制構築に参加していきたいという方にお会いできるなら、とても嬉しいです。想いを同じくする多くの方とご縁になっていきたいと思っています。ぜひ、弊社の他のブログ記事や、ホームページもご覧になってみてください。
(@tmtysk)
*1:このエピソードについては別記事 https://inside.bldt.jp/entry/2020/04/02/071607 で紹介しています
