エンジニアtype - エンジニアのシゴト人生を考えるWebマガジン
  • TOP
  • キーパーソン
  • 旬ネタ
  • コラボ
  • ノウハウ
  • 女子部
  • キャリア

伊藤直也氏×大場光一郎氏に聞く「レガシーなアーキテクチャの見直し方」スケールのカギはHacker Wayな文化が握る【特集:1を100にする開発戦略】

タグ : KAIZEN Platform, アーキテクチャ, クラウドワークス, 伊藤直也, 大場光一郎 公開

 

ゼロイチのフェーズでスピード感を持って書いたコードが、さらにスケールするフェーズになって負債としてのしかかるという話をよく耳にする。

そうだとすると、サービスをスケールしていくためには、どこかのタイミングでアーキテクチャを設計し直さなければならないのか。あるいは、最初から緻密に設計されたアーキテクチャの下に開発するのが筋なのか。

Kaizen Platform技術顧問の伊藤直也氏、クラウドワークスCTOの大場光一郎氏は肩書きこそ違えど、ともに「ゼロイチ後」の成長期に加わった「イチヒャク」の請負人であるということで共通している。

サービスをスケールさせるためのアーキテクチャについて、両氏の考え方と実際の取り組みについて聞いた。

アーキテクチャに「絶対の正解」は存在しない

—— 本日は「サービスがスケールするアーキテクチャとは」をテーマに、お2人の経験から来るお考えをお聞きしたいと思います。

伊藤直也氏

技術顧問という立場上、さまざまな企業から「アーキテクチャの見直し」について相談されるという伊藤氏だが、その見解は…

伊藤 前提として、何年か経っても理想的な形を保ち、開発スピードも落ちないアーキテクチャというのはそもそも構築するのが相当難しい、というのがありますね。

自分が過去にいた会社はいずれも優秀なエンジニアがそろっている企業でしたが、それでもアーキテクチャが理想的な形で運用されているとは言い難いものでした。

システムを作り直したり、課題を認識しつつも一端は目をつむったりしながら、何とかやっていた。他の会社の話を聞いても、だいたいそうかなという印象です。

優秀なエンジニアを抱えた大きな会社はみな、スケーラビリティを持った“正しい”アーキテクチャでシステムを作っていると思い込んでいる人もいるかもしれませんが、それはなかなかないんじゃないかなというのが実感です。どの会社も、技術的負債を抱えながらも、その中でどうやって前に進んでいくかというのをやっている。

まずはこの現実を前提として考えた方がいいんじゃないでしょうか。

大場 僕も直也さんと同じ会社にいたことがありますが、今の時点で考えるとモダンとは言えないようなアーキテクチャでも、思ったより耐えられるものなんだな、というのが振り返っての感想です。「このシステムでも、大規模なトラフィックに耐えられてスケールするのだな」と。

伊藤 そう。「スケールする……」と言った時に意味合いは2つあって。

一つは、ユーザー数、トラフィックに耐えられるという意味でのスケーラビリティ。もう一つは、人が増えても、時間が経っても開発スピードが落ちないという意味でのスケーラビリティです。

前者に関してはやれている会社がたくさんあると思いますが、後者はなかなか難しい課題だと思います。

—— では、その前提に立ってお聞きしたいのですが、挙げていただいた2つの意味でのスケーラビリティを持たせる意味で、実際に取り組んできたことにはどんなことがありますか?

大場 クラウドワークスのサービスに関して言えば、今はRailsの一枚岩のシステムになっていて、それでもまだ伸びしろ、限界を迎えるまでの猶予があると感じています。その猶予の中で組織的にスケールするために、さまざまな挑戦をしているところです。

細かいところで言えば、まずは絡み合った部分のリファクタリングに取り組んでいます。別システムに切り分けることについては、管理コンソールやデータ分析システムを本体とは分割する作業を進めています。

—— Kaizenさんはいかがでしょう?

伊藤 それこそ、流行りのmicroservicesのような形で、中身がいくつかのサブシステムに分かれてHTTP APIで通信をして……といった感じになってきてはいます。

ただ、そこだけ切り取ると「きれいなアーキテクチャ」を保つために戦略的にやっているように見えるでしょうが、現場の実情は少し違います。

とある課題があって、それに対する解決策として何とかやり方を見つけて、今のような形に至ったという感じです。

従来は、同じシステムの中に、毎日のように改善したい部分と、お客さまが使うので頻繁にはアップデートできない部分という、デプロイサイクルの違う2つの部分が一緒になっていました。しかしそのままだと会社としてボトルネックになるということになり、2つに切り分けた。

それを繰り返していたら、結果的にサブシステムが5、6個になっていって、改めて見てみると「これはmicroservicesと言えるね」という感じです。最初からその前提で設計していたわけではなく、「このままでは良くない」という課題が出発点になっていました。

—— 「このままでは良くない」と言い始めたのはいつごろだったのですか?

伊藤 Kaizenでは過去に一度、お客さまが使う部分で大きな障害を発生させてしまったことがありました。その結果、エンジニアもその部分を触るのが怖くなってしまって、カジュアルにデプロイしてはいけないという空気になった。

で、それでは日々の改善が必要な部分のデプロイに支障が出るということで、2つに分けるという選択をしました。1年くらい前の話です。

ちょうど「microservices」という言葉が流行った時期と重なりますが、決して「microservicesにしたい」というところが出発点だったわけではない。そもそも、デプロイサイクルが違う部分を疎結合にするといった考え方自体は、特別新しいものではありませんね。

大場 エンタープライズの世界ではSOAとか言われていましたね。

伊藤 体系的な方法論としてはそういったものがあるけれど、現場の感覚としてはもう少し泥くさい感じです。良いアーキテクチャを設計して、その上で組織が前に進むという感じでは決してなく、日々問題に対処していく中でアーキテクチャがそうなっていったという感じです。

もちろん、会社によっては戦略的にやっている部分もあるでしょう。でも、そういう企業も、中の人に直接話を聞けば、同時にレガシーな部分もたくさんあるという話が一緒に返ってくる。そういう部分はなかなかメディアには出ませんから、あまり知られていないだけというのはあるでしょう。

業績の良い会社、目立っている会社ほど、中身はてんやわんやなのではないかと想像しますね。

大場 アーキテクチャを作り直すとなると、今進んでいる開発を止めたり、スローダウンさせたりしなければならない側面もあるわけです。だから、「目の前の課題に直面したからやる」という形でないと、刷新をやる・やらないの判断は難しいですよね。

伊藤 大きなアーキテクチャを採用すると、その分システムが複雑になり、学習コストが上がる可能性もあるし、維持コストも高くつくかもしれない。microservicesを採用するとエンドポイントが増える分、開発効率が下がり、障害発生率が高くなるかもしれない。

そのデメリットと、改修した場合に得られるメリットを比較して、メリットの方が大きい場合にやるという話。なので、そもそも課題を感じていない会社が実施することには、メリットを見いだしにくいでしょうね。

再実装すべきか否かは、現場の課題に向き合った結果

—— 大場さんはCTOとしてクラウドワークスにジョインされて、スケールするためにいろいろと手を打つことを求められるお立場にいらっしゃるわけですが、1年間取り組んでみてどうでしたか?思ったようにいきました?

大場光一郎氏

「レガシーシステムの再実装には相当の覚悟が必要」と大場氏

大場 先ほども言ったように、トラフィック的にはRailsの一枚岩でまだイケるという感触で、今はシステムを分ける以前に整理することがあるという段階です。

その一環として、この6月1日から組織体制を改めました。

クラウドワークスはもともと、開発部と営業・マーケとが完全に分かれた組織構成だったのですが、それを事業ごとの縦割りの組織へと組み替えました。

大企業を辞めて弊社に入るエンジニアには、「前の会社では仕事の幅が限られていてスキルアップが難しかったので、フルスタック的に仕事にかかわれるベンチャーに移った」という人が多い。

その期待に応えようと、以前はエンジニアとデザイナーだけのチームにしていたのですが、会社全体である方向に進もうとなった時に、どうしても企画側とエンジニア側との間に温度差が生まれてしまっていた。

そこで、チームとしてもっと一体感をもって取り組めるようにしようと行ったのが、今回の組織変更です。

エンジニアも、企画側の下請けのようにシステムを作るのではなく、サービスをどうすべきかを考えて、主体的に開発をしていくようになってほしい。一方で、企画側にも「どう作るか」に興味を持ってもらおうということです。

そうすることで、同じ目標に向かって進めるようになれば、システムも今のように一枚岩というよりは、事業ごとの小さいシステムが連携してやっていかなければならなくなると思うので、自然と切り分ける流れになっていくのではないかと思っています。

—— そうした「絵」を描くのはCTOである大場さんの役割なのですか?

大場 はい。そういった「絵」を組織的に描けるように、技術に関して横串で見られる部門として「CTO室」というのを置いています。事業目標には直接結び付かなくても、何かが起こってからでは手遅れになることがある。それこそ、増大するデータ量や計算量に対抗していくためには、先に手を打つことも必要。そのための部署です。

—— 弊誌でも以前、伊藤さんが技術顧問を務めるじげんのプロジェクトを取材したことがありましたが、それと似ていますね。そうやって別部隊を立ち上げるのが、やはりセオリーなのでしょうか?

伊藤 うーん、難しいですね。結局、セオリーはないと思うんですよ。

継続的インテグレーションなどデベロッパー用の環境を整える程度であれば、別部隊による成功事例も多いですが、アーキテクチャの改善まで踏み込んだ話になると、それが正しい打ち手かは判断が難しいところです。

アーキテクチャがどうあるべきかは、日々開発の現場にいて、そのシステムの問題がどこにあるのかを把握していなければ判断できませんからね。問題の理解度と、それをやり切れる力量が求められるので、できるかできないか、その人次第というところもあります。

それにふさわしい人物がいて、その人にやらせたいがために新しい部隊を設けるのであればうまくいくのかもしれませんが、CTO室という部隊を作ることありきだと、うまくはいかないのではないでしょうか。

—— セオリーはないとして、仮にどこかの会社からレガシーシステムに手を付けたいと相談が寄せられたとしたら、お2人であればまず何をアドバイスしますか?

大場 そうした話の例としてよくあるのが、「今あるシステムを別の言語で書き換えたい」というものだと思うんですが、僕だったらまず止めますね。全部を網羅して再実装するというのは本当に難しい。下手すると、より悪いところからのスタートになりかねませんから。

伊藤 でも、実際そういうプロジェクトに取り組んでいる会社、増えてますよね? それを全否定します?(笑)

大場 いえ、それだけの覚悟があるのであれば。

伊藤 まぁ、実際は僕も大場さんと似た立場を取ると思いますが(笑)。まだそういう会社の結果が出ているわけではないので、間違っているとも言い切れませんし。

大場 もちろん、必ず失敗するというわけではないと思いますよ。古い話ですが、Netscapeもソースコードをオープンソースで書き直したけれども、複雑すぎて誰もメンテナンスができず、有用なものと見なされない状況に一度は陥った。一方で、さらにそれを再実装する人が現れて、Firefoxとして“延命”しているわけで。

これは、再実装が寿命を延ばすこともあるという事例ではあります。ただし、それだけ大変なことだ、ということです。

伊藤 ここでNetscapeが出てくるのがジェネレーションギャップだね(笑)。ちょうど『HARD THINGS』を読んだところだからだろうけど。

—— 伊藤さんは多くの会社の技術顧問を務めるお立場ですし、そういう質問を受けることは多いですよね? どうやってアドバイスします?

伊藤 アドバイスになるかは分かりませんが、最優先でやらなければならないのは、現行システムの分析以外にないですね。

「レガシーなシステムが……」という組織でよくあるのが、なぜそれがレガシーなものになってしまったのか? という認識がバラバラだったり、正しくなかったりするケースです。それでは、やり直しても同じことの繰り返しになってしまう。アーキテクチャのせいなのか、組織のせいなのか、その理由を分析することが重要です。

例えば、なぜ似たような実装があちこちにできるようなシステムになっているかを追求した結果、「障害を起こしてはいけない」という厳しいルールがあるのに十分なスケジュールが取れていないという現状があるとします。また、影響範囲を狭めるためにあえて既存実装を流用しない、そんなケースもままあります。これらは技術ではなく、組織の問題ですよね?

きちんと分析しないと、組織の問題なのに技術で解決しようとして空回りする、なんてことが起こるわけです。

レガシーになっているシステムの課題を整理するというのは、嫌なことに目を向ける作業だから、中の人はなかなかそれをやろうという話になりにくいし、冷静にできない。だから僕のような外の人の力が必要になる場面があったりするのかなとも思います。

逆に言えば、外の人ができるのは中の人の背中を押すくらいなので。

システム刷新に先立つのは「挑戦しようと思える土壌づくり」

直也氏×大場氏

理想のアーキテクチャを追うより、挑戦しようと思える土壌づくりが先決という見解で2人は一致した

—— そういう作業は長い期間を掛けて行わなければできないものですか?

伊藤 時間を掛けないと難しいでしょうね。ただ一方で、僕は以前の勤め先で、自分が担当していたシステムをフルスクラッチで作り直すということを何度かやっているんです。1年掛けてコードを再実装した時もありました。その時は、最初1人でやり始めて、基盤が全て整ったところからチームでやる体制にし、3カ月掛けてやりました。

今振り返ると、状況的に、当時の自分の立場じゃなかったらできなかっただろうなと思います。それは実力がどうという意味ではなく、CTOという“わがまま”が許される立場だったからという意味で。システムの作り直しみたいな賭けが必要になる場面で、全員を説得するのは大変な作業だっただろうし。

最初の部分を1人でやったのも同じ理由で、アーキテクチャの基礎的な部分を決めるのには、どうしても試行錯誤が伴うので、「これだ」と言えるところまでは1人でやりたかった。

ただ、そうやって作り替えたシステムでも、今ではレガシーになっているでしょう。結局そうなっちゃうんですよ。これは正解のない問題なんです。現場の対症療法しかない。

ただ、重要なのは、変更しやすい体制やカルチャーをあらかじめ作っておくと、やりやすいというのはあると思います。Facebookなんかがいい例だと聞きます。

―― どの辺が?

伊藤 彼らは「Hacker Way」をポリシーに、ダメだったら作り直せばいいと考えている。Done is better than perfect。完璧を目指してやれないぐらいだったら、突き進めということみたいですね。

Facebookが採用しているPHPなんて言語がまさにそういう言語ですしね。PHPと言えば、グリーの開発文化も、自分がいた当時はそんな雰囲気でした。

—— それはやはり、PHPコミュニティでの活動で名を知られているグリーCTOの藤本真樹さんが築いたもの?

伊藤 開発組織だけじゃなくて、会社全体がそういう感じでしたね。良く言えば変化に寛容、悪く言えばやんちゃ(笑)。グリーに入って新鮮だったのは、アーキテクチャはいろいろ課題も積もっているのに、それなりのスピードでモノを作っているということ。

ある人は勢い重視で書いているのに、その横に座っている人は文句を言いながらでも同時にそれを直している。それで全体としてはすごいスピードで前へと進んでいる。

「コピペしてはいけません」、「誰かが書いたコードは書き換えてはいけません」といったルールがあまりなかったんです。あるのはコードとコミット権限だけ。そのカルチャーはいいなと思っていました。

堅苦しい組織的なルールをあまり作らないというのはポイントかもしれませんね。

—— 大場さんも同じ時期にグリーにいらっしゃいましたよね?

大場 はい。ソースコードもそうですが、課題もオープンで、関わり方は自分で決められるという文化があったように思います。

伊藤 その当時のグリーのエンジニアは、自分たちのコードが理想的で素晴らしいものだとは思っていなかったと思いますよ。でも、文句は言いつつも手は動かしていた。それが正しい姿のような気がしますね。

正しいアーキテクチャを勉強し尽くして、適用して失敗するよりは、目の前の課題解決に専念して、その過程でアーキテクチャもそれっぽくなっているという方が、考え方がオープンソースっぽいし。時代を振り返っても、そっちが勝ったということで証明されている。

もちろん、中には優秀な社員がいて、丁寧にアーキテクチャを考えられる人もいると思いますが、多様性によってそれを担保するという感じでいいのではないでしょうか。

—— ただ、エンジニアに限らずクリエイターとして仕事をしている人には、「アーキテクチャはこうあるべきだ」みたいに、原理主義的に物事を考える人も少なくないですよね?

伊藤 ルールに過度にこだわる人が上に立つと、組織が保守的になっていきがちだと思うので、プラクティカルな人により大きな権限と裁量を持たせるべきではないかなと個人的には思います。

大場 一方で、そういう保守的な考え方の人が向いているプロジェクトもあると思いますよ。

伊藤 それは確かに。

大場 例えばお金を扱うところだったり、プライバシーに関するところだったり。ただ、答えがない中でとにかく前に進むことが求められるようなところでは、直也さんの言うように清濁併せ吞む、汚れ仕事でも選ばず受け入れるような人の方が活躍しやすいのではないでしょうか。

互いにCTOという立場を経験している2人は、「柔軟にスケールできるようなカルチャーづくり」をどう行っているのか?

—— そういうカルチャーづくり、チームづくりをする上で、お2人が心掛けているのはどんなことですか?

伊藤 組織としてどういう行動を「良い」と言うかにかかっていると思います。

例えばトップの影響力が強い組織だと、その人が日ごろチームメンバーのどんな行動を褒めたかとか、そんなことで文化が決まったりしますよね。

他人のコードを無理矢理にでも書き換えてうまくいったケースを褒めれば、それが良しとされる文化になるし、もう少し調整もうまくやらないとダメと言えば、そういう文化になる。

自分の場合で言えば、プラクティカルにやって仕事の成果を出せる人のことは評価するけれど、乱暴に手を出して結局最後までやり切らない人とか、ごちゃごちゃ言うだけで結局やらない人はあまり評価しません。

そういう小さなことの積み重ねが組織の価値基準を作っていって、それがひいては文化になっていくのかなと思います。

—— そうなると、お2方のような立場だと一つ一つの発言の責任が重いですね。

伊藤 エンジニアリングって、基本的にはそうやって先輩とか上に立つ人とかの背中を見て進んでいくものではないですか? その意味では、やっぱりグリーの文化というのは藤本さんが作ったものなのかもしれないですね。

—— 大場さんはクラウドワークスでCTOというお立場になられて、チームづくりに関する動き方や考え方は変わりましたか?

大場 大切にしているのは、失敗を奨励するということです。障害を起こしたら激詰めされるような文化ではなく。そもそも人間は失敗を冒すものですし、失敗をしているってことは挑戦しているということでもある。失敗をしても成り立つシステムにすることは心掛けています。

—— すでにある会社に、ゼロからそういう文化を作ることは可能ですか?

伊藤 自分の経験から言えば、ある程度より大きい会社ではなかなか難しいというのが正直な感想です。以前、けっこうな規模の大きな会社さんと仕事したことがあるのですが、やっぱり大企業になると組織を短期間で変化させるのは難しかった。

通常、僕が依頼されるのはせいぜい全社員で200人くらい、エンジニアが50人とかその程度の会社ですが、そのくらいの大きさまでであれば、それほど難しい話ではないかなというのが実感です。CTOがメンバー1人1人やマネジメントをする立場の人と話すことで、組織構造やルールなど、ボトルネックになっている部分を探るんです。

よくあるのは、「こういうルールがあるから、それはできない」と社員が思い込んでいるゆえに行動できていないのだけれど、実際にはそんなルールは存在しなかったというケース。この場合、ルールを変えたり、なくしたりするだけでもうまくいきます。

—— なるほど。そうやってプラクティカルな土壌を作りながら、目の前の課題を解決していく中で、自然とアーキテクチャ自体も変わっていくということですね?

伊藤 そうだと思いますよ。(ソースコードを)書き換えたいという熱を持っている人が中にいれば、土壌さえできれば、いずれ活躍するタイミングが来ますから。そうやって徐々にアーキテクチャも変わっていくというのが健全じゃないですか? 方法論が先に来ると、ロクなことがない。

結局はやる気と熱意を持っている人が最後までやり切れるかどうかに掛かっているので、そういう人が熱を保てる環境を作るというのが、マネジメントとしては正しいのかなと思います。

—— よく分かりました。ところで、大場さんはクラウドワークスで、伊藤さんはKaizenで、組織をどう良いものにしていくかということに取り組んでいらっしゃいます。以前はお2方ともサービスづくりをやってきたというキャリアを考えると、今のお仕事って純粋に楽しいんですか?

伊藤 大場さんは立場上、楽しいと言う以外ないよね(笑)。

大場 組織のステージが変わっていく中にいるというのが一番楽しいですね。直面する課題がどんどん変わり、今までのやり方が通用しなくなるので、経験が全て成功につながるとは限らない。新しい組織、メンバーで立ち向かわないといけない。しかも、かなりスピード感のある中で、です。そこが楽しいと感じています。直也さんはどうですか?

伊藤 僕はかつてCTOという立場だった時に、「こうだったらいいな」と思っていた環境を実際に作ろうと思ってやっています。当時はメンバーを率先してコードを書いたり、サービスを作ったりしたかったんですが、組織づくりや採用で忙しくなって、次第にできなくなっていった。

最近、CTOの仕事というとマネジメントの側面がクローズアップされることが多いですが、本来はそうではなく、プロダクトをとことん磨き込むのがCTOだということが分かってきて。米国のCTOは実際にそういう人が多いらしいんです。日本のCTOがやるようなマネジメントタスクは、CTOの脇にそれを専門とする部長のような人がいて、その人が全部やるらしいと話に聞きました。

なので、自分のかかわる組織をそういう風にしてみようとも思ったんですけど、そういう組織構造にしたいっていうモチベーションを一番持っているのは他ならぬ自分なので、だったら技術顧問としては「組織づくりにまつわること」を全部引き受けてやろうというのが今です。

そんなわけで、CTOがプロダクトをやった方がいいと思って、いろいろと試行錯誤してやっています。

—— 技術的な話から組織の話まで、貴重なお話をありがとうございました。

取材/伊藤健吾 文・撮影/鈴木陸夫(ともに編集部)

>>特集:1を100にする開発戦略




人気のタグ
業界有名人 スタートアップ 開発 SE 転職 エンジニア プログラマー Web スキルアップ ソーシャル アプリ シリコンバレー キャリア プログラミング Android 起業 えふしん スマートフォン アプリ開発 SIer 技術者 UI btrax Webサービス クラウド Apple スペシャリスト CTO Twitter Brandon K. Hill ギーク 英語 村上福之 Facebook Google デザイン IoT SNS ツイキャス 世良耕太 モイめし IT 30代 採用 赤松洋介 コーディング 20代 UX 勉強会 プロジェクトマネジメント Ruby ITイベント Webエンジニア 中島聡 ビッグデータ 法林浩之 ウエアラブル iOS 五十嵐悠紀 LINE ドワンゴ ひがやすを ロボット 受託開発 モノづくり IT業界 コミュニケーション イノベーション ハードウエア MAKERS tips ゲーム 女性 ソーシャルゲーム Webアプリ SI インフラ iPhone 女性技術者 高須正和 マイクロソフト 研究者 UI/UX トヨタ 自動車 ノウハウ チームラボ 息抜き システム ソニー プラットフォーム Java メイカームーブメント オープンソース 和田卓人 エンジン グローバル 開発者 教育 イベント サイバーエージェント ソフトウェア 女子会 コミュニティ メーカー 家入一真 スーパーギーク 増井雄一郎 GitHub 人工知能 IPA 40代 日産 テスト駆動開発 ソフトウエア 音楽 TDD ニュース モバイル PHP TechLION

タグ一覧を見る