エンジニアリング界をリードする著名人が「いま話を聞きたい」開発者を直接指名し、日頃なかなか聞けない開発トピックについて語り尽くすオンライントークセッション「DevLounge.jp」。

Session A-2では、グローバルなクラウドプラットフォームのデベロッパーアドボケイトとして活躍する山口 能迪氏が、日頃から飲みながら雑多な話をする相手だというヘイ株式会社CTO、藤村大介氏を招いて、「技術に寄りすぎない話」を展開。山口氏が最近気になっているというOKR(目標管理手法)の話から始まり、やがて藤村氏のフリーランスから社員となってCTOという立場に就いた話、哲学とソフトウェア開発の関連性の話まで、話題は尽きず。ここではそんなトークセッションの一部をダイジェストでお届けします。

山口 能迪

グローバルなクラウドプラットフォームのデベロッパーアドボケイトとして、ウェブからネイティブ、フロントエンドからバックエンドまで多くのサービスに携わる。オブザーバビリティおよびSREの領域で広く開発者や顧客に対し、知識・知見や製品を使った問題解決方法などを提供。また製品の品質改善のために開発チームと協力し、リリース前後における製品の検証や修正、機能提案などを担当する。

藤村 大介(@ffu_)

哲学科を卒業後、業務システム導入の仕事を通じてソフトウェア開発に出合う。その後、スタートアップ業界でソフトウェア・エンジニアとして活動。ブログラミングの傍ら、リーダー・マネージャーとしてチームビルディング、メンタリング、採用、技術戦略策定、クライアントとの折衝を経験。主な経歴はAiming、Quipper、マチマチなど。2020年4月にヘイ株式会社(hey)に入社。現在、CTOを務める。

スタートアップのOKRは中途半端だと上手くいかない

山口：ここ数年、OKRという目標設定フレームワークが話題になっています。僕が所属している会社では、10年前にはすでに定着していましたが、最近は周囲のスタートアップでも導入が進んでいる事例を聞くようになってきました。実際にスタートアップで上手くいくのか気になっていたんです。

藤村さんは現在heyでCTOをされていて、以前はフリーランスとしていろいろな会社を見たり、別の会社に在籍されていたこともあるそうで。そんな経験のなかでOKRについてどのような印象をお持ちでしょうか？

藤村：過去に、自分でOKRの仕組みを作って運用した経験があります。そこで感じたのは、中途半端にやるとあまり機能しないということ。以前在籍していたスタートアップでは、OKRを決めたら、OKR以外のことはやらないことにしたんです。

それくらいハードコアに運用すると、そもそもOKRを決めるのにとても時間がかかるし、喧々諤々にもなる。運用もタイトにやらなければならなくて、毎週チェックして何％積んだのか、積んでなかったらなにが悪いのか、なにか助けることはあるのか、というところまでやるんです。かつ変更するときも周囲にしっかりわかるようにするし、変更の理由もリーズナブルじゃないとみんな納得しない。

事業としてもOKRを無事マークしたら達成、みたいなところまでしっかりやっていました。それはチームが小さかったので、CEOと僕の手の届く範囲でやれたことで上手くいったのかなと思っています。

山口：かなり細かく確認しながら、各人の動きがが動いている方向性を常にOKRに沿った形でやっていたと。最終的な個人の評価も、OKRをそのまま判断基準として使っていたんですか。

藤村：いえ、評価という軸ではあまり考えていませんでしたね。あくまで事業計画に対して、事業の目的を達成するために必要なものをOKRという形で分解する、という感じでした。

山口：なるほど。周りの話を聞いていると、会社によっては評価まで含めてOKRでやっているところがあるみたいで、OKRのスコープではないのではないかと思っていました。

藤村：それは僕も見聞きしたことがあります。会社や事業としてなにを目指すのかというところと、組織の目標と評価も全部含めたフレームワークとしてOKRを捉えている人が多いんだろうなっていう。

山口：そう。うちの会社はOKRを長く運用していますが、藤村さんが過去にやった例ほど細かくは見ていないんですよね。四半期の最初の2、3週くらい経ったときに「どう？」みたいな感じで聞いて、最後に「今期どれくらい達成できたか評価してみようか」という感じでチェックする。

それと個人の評価はまた別軸で、あくまで実績ベース。どれだけ積んだか、どれだけ伸ばしたかで評価することになっています。そのほうがフェアかなと思っていて、もしもOKRの達成度で判断されると、チートする人がいっぱい出てくると思うんですよね。目標を低く書くとか。

藤村：一度、真の「OKR野郎」にやってみてほしいですね(笑)。インテルを創業したアンディ・グローブとかに全部面倒見てもらって、本物を見せてほしい(笑)。

山口：ほんとうに見てみたい(笑)。うちの会社も独自のOKRになってる部分があると思うので本物を知りたいし、いろいろな会社のOKRも見てみたいです。

フリーランスと会社員エンジニアの違い

山口：いま藤村さんはCTOをやっていらっしゃるので、目標管理も考えなければならない立場ですよね。フリーランスのときとは、会社との関わり方は違うものになっていますか？

藤村：違いますね。フリーランスの仕事は会社に対してそんなに影響力がないというか、ほとんどが短期的な関わり方ですよね。フリーランスだけど10年コミットする、みたいなことはあんまりない。だから大きな仕事をしようと思ったら、長期間のコミットをしなければならないと思い、正社員としてやろうと思いました。

「長く関わり続けるからこそ作れる」というのが会社との関係で変わったところですね。

おかげさまで前より一喜一憂しなくなり、上手くいかないことやすぐには解決しないことがあっても、「3年くらいじっくりやって解決するしかない」みたいな腹のくくり方ができるようになりました。

山口：その観点はすごくわかりますね。僕が関わっている製品のロードマップみたいなものを見ても、普通に3年とか5年とかの尺で書いてあって「これは後回しにして下半期くらいにやろうか」みたいなことがありますからね。「だいぶ呑気だな」という気持ちになったりもする(笑)。でも、全体として少しずつ上手く進んでいくのであればいいかな、と思います。そういう捉え方・関わり方は会社組織のなかではありますよね。

藤村：いまの僕の立場だと、全力で呑気に長い時間かかる仕事をやらなければならない(笑)。呑気に、半年は100％無理、1年でもほとんど無理、2年経ったらそういう風向きになってくれたらいいな、というタイプの仕事がたくさんあります。時間がかかるし、すぐには上手くいかないけど、必ずやらなければいけないことを、見える形で進捗させていく必要があるんです。

山口：フリーランスをやっていてheyに移ったのは、そういった長期のコミットをしたいと思ったことが動機ですか？

藤村：そうですね、やはりフリーランスは限界があるので。何かしら大きな成果や代表作のような仕事をしようと思うと、「事業とか会社とか組織とかに骨を埋めてやらなければいけない」という感覚はありました。

山口：最近はフリーランスでエンジニアをやっている人が増えたように思いますが、藤村さんはフリーランスの仕事をどう思いますか。

藤村：僕は別にフリーランスの仕事を否定はしないし、自分でやっていて好きなところもあったのでいいとは思います。ただ、会社に入って3年ぐらいいると「時間がかかる仕事があるんだな」というのもわかるし、そこに自分が参加すると、フリーランスのときより深いコミットメントができるので、思考の幅も広がりますね。物の考え方とか、仕事の見方とか。

偶然プログラミングに出合い、のめり込んでいく

山口：藤村さんは大学で哲学を学んでいて、その後ソフトウェアエンジニアリングを生業にしようと思ったのは、どういうきっかけだったのですか。

藤村：実は、きっかけみたいなものはなくて。大学を卒業して、フリーターをやりながら勉強をして、地方公務員を目指そうと思っていました。地方公務員は定時で帰れるからレコードを買いに行く時間があるなとか、それくらいのことしか思っていなかったんです(笑)。

実際は、大学を卒業できなくて必修の単位を落とし続け、5年生になっちゃって。じゃあ民間企業でも受けてみようかと思い、いくつか企業を受けて、なんとなくよさそうだと思ったところに入ったら、SAP(業務システム)導入の下請けの開発の会社だったんです。そこでプログラミングを始めました。

山口：そこからどのようにキャリアを歩んでいったんですか。

藤村：最初の会社を辞めたあと、フリーランスを経験しながら何社かスタートアップで働きました。しだいに自分でRubyを触り始めて勉強をしているうちに良さを感じ、Rubyで仕事をしたいなと思うようになりました。それで次の就職先も決めずに会社を辞めて、Railsを使っているスタートアップに入り、Webプログラマーになったという感じですね。

山口：そうだったんですね。自分の周りの哲学系の人だと、考えるプロセスが好きで、その一環としてソフトウェア開発に興味を持ったという人がたくさんいたので、そういう感じなのかと思っていました。

藤村：違いますね(笑)。20代半ばまで、社会のこととか真面目に考えてこなかったんですよ。就職してしばらくして「あ、仕事って一生するんだ」っていうことに気付いたんです。自分が楽しめる仕事を考えるうちに、「プログラミングがいいかも」と思い真面目にやるようになりました。

山口：プログラミングに運よく楽しめる要素があったんですね。

藤村：そのとおりです。偶然の賜物というか。ただ、後付けとしては、論理学なども学んでいて、その隣の隣ぐらいにプログラミング言語理論とかがある。それで30歳くらいのときにすごいHaskellにハマって、ハスケル・カリーとかの理論を勉強しているうちに、今度はフレーゲという哲学者たちが出てくるんですね。それで、「あれ、これ大学のときにやったやつだ」とそこで伏線が回収されるみたいなことはありましたね。

他業界の知見がエンジニアリングに結びつく

山口：全然関係ないことがキャリアになにかしら影響を及ぼしたり、なにかいいインパクトを与えるのはおもしろいし大事ですよね。

最近はソフトウェアエンジニアリングが単純にサービスを作るだけでなく、他業界にも入り込んでいる。「なんとかテック」みたいな形で。僕は大学で機械情報を学んでいたので、自動車のことや重機のことは少しわかる。車の自動運転もそうですし、センシングによって重機の自動制御の統計データを取る仕組みの話など、周辺知識があるから、自動車や建設機械業界の動向や変化の理由がわかることがあります。藤村さんも自分で得た知識が仕事につながったことはありますか。

藤村：僕の場合、専門が哲学だったので、直接役に立つことは一個もないです(笑)。ただ、哲学の世界にはどの理論がいいのかを評価する基準があるんですよ。理論評価の基準、ベストプラクティスみたいなもの。ある本を読んでいて「ソフトウェアを作っているとき、設計を評価するために使っている基準とほぼ一緒だな」と感じたことはあります。

山口：それはどういうことですか？

藤村：僕が読んだ本だと、哲学における理論の評価軸が5つあるんです。

まず正確性。これはソフトウェアでいうとデータと合っているか、対象となる問題を解決できているかとか。次が整合性で、設計内部で整合性があるかっていうところと、設計の外側にあるものとの整合性が取れているか。あとは単純性。これは一番わかりやすいと思うんですが、できるだけ少ない資源で物事を解決できているか、短いコードでできているか、いらない設計が入っていないか。

そして包括性。できる限り対象領域の多くのものを解決できるようになっているか。最後が一貫性で、これ設計だとちょっと難しいかもしれないですけど、場当たり的になっていないか。普通に読み下せる理論で書いてあるかどうか、ですかね。

山口：なるほど。確かに当てはまる部分はあるなと感じますね。

藤村：こういう理論とか問題に対するアプローチの一般の型みたいなものは、自分の引き出しに入っている気はしますね。

思うのは、たとえばオブザーバビリティのあり方の背景って、過去のいろいろな学問で積み重ねられてきた視点が入っていて、技術書にはそういう話は載っていないですよね。いまあるテクノロジーやベストプラクティスの背景にある、元ネタになっているものが何か、みたいなところを知るのは面白い。

それに今後、これまで体験したことのない、時代の先にある問題を解決するときのバックボーンにもなると思います。好奇心を広げていろいろな本を読んだりすると、将来巡り巡って役に立ち、ディープな問題解決ができるんじゃないでしょうか。

当日のアーカイブはYouTubeでも配信中。イベントレポートではお届けしきれなかった話が盛りだくさん。気になった方はチェックしてみてください。

次のセッションはこちら

前のセッションはこちら

イベント詳細はこちら