【Chatwork テックリード 加藤氏】知識の収集だけでは、学びのサイクルは確立しない。かとじゅんさんに聞く これからのエンジニアに必要なスキルとは
Offersでは、あらゆる業界の開発スペシャリストをお招きし、これまでのキャリアや経験を深ぼることで、企業を超えて開発の実践知をつなぐ「#開発の実践知をつなぐ」というインタビュー企画を行っております。
第4回では、Chatwork株式会社でテックリードを務める加藤氏をお招きし、これまでのキャリアやそこから見えるこれからのエンジニアに必要なことを深掘りします。
Chatwork株式会社 テックリード 加藤 潤一 氏
Chatworkのテックリード。10歳で初めてプログラミングに触れる。SIとしてさまざまな現場での業務を経験した後、2011年より某D社、2013年より大手ソーシャルゲーム企業で、それぞれScalaやドメイン駆動設計を採用したシステム開発に従事。2014年7月よりChatworkに参画。現在はChatwork次期アーキテクチャのプランニングや設計、開発に携わる。
東芝の品質管理技術者からSlerの道へ
私は工業専門系の学校を卒業し、新卒で蛍光灯の製造技術や品質管理の技術者として東芝に入社しました。東芝で工場の機械やロボットに対してプログラム制御や統計処理を行う中で、もしかしたらプログラミングが仕事になるかもと思い始め、6年ぐらい働いたのち、Slerに転身を決意しました。
当時は、プログラミングで仕事できるという一般的な認識はなかったため、プログラミングの職種でのスタートではありませんでしたが、プログラミング自体は、実は10歳の頃から触れていて、自分の好きなことでもありました。
マイクロサービスとオブジェクト指向の現場からキャリアがスタート
これまでの経験を振り返ってみても、一番の挫折経験はSler時代の経験です。今までは自由にプログラミングしていただけでしたが、プロの現場では趣味レベルの知識だと対応できないことを痛感し、苦労しました。
その時最初にアサインされたのは、Windows NT上の分散システム(今でいうマイクロサービス)でオブジェクト指向で開発するプロジェクトでした。昨今のアプリケーション開発といえば便利なフレームワークやライブラリを使うのが常識ですが、このプロジェクトではアプリケーションというよりシステムを開発していたので、クラスライブラリを一から作っていました。
技術的挑戦としてWin32のマルチスレッドAPIをラップし、Threadクラス(並行処理を行うJavaのThreadクラスに相当)を開発しました。この作業は、システムの基盤となる重要な部分でした。他にもRPCが可能になるクラスを作ったり、ある一定の周期になったら実行される関数を登録できる簡易的なジョブスケジューラを実装したりと目的やゴールが設定されていて、それを踏まえてクラス内部の設計や実装に取り組んでいました。
設計や実装に行き詰まった際は、オープンソースのコードやメーリングリストに投稿するなどのことをしていました。当時は質問の仕方さえもよく分かっておらず、先輩方から教えていただいていました。言葉で言うのは簡単でも実践するのは難しくて、ハードスキルだけではなく論理的に相手に伝えられるソフトスキルも必要です。
人と話すような仕事よりもシステムを使った仕事をしたいと思っていましたが、結果的にそのためには人間とコミュニケーションする必要があることを思い知らされた経験でもあります。
ですが挫折を経験するのも悪くはないと思います。自分の世界観が通用すると思っていたら世の中の世界観とずれていて、 現場に行ったらそのような考え方では不十分だと指摘される。多くの場合、ここで挫折感を感じますが、諦めなければ復活して戻れるので、自分の世界観を上書きしなおせばいいのです。
その過程でスキルを身につけて、自分に足りないものを理解することが大事です。地道に積み上げて苦労して作ったソフトウェアは、依頼された仕事とはいえ達成感がありました。
ただ、途中の苦労を乗り越えて最終的にゴールできればよいという考え方はリスクが高いので、途中の苦しみや失敗も含めて自分の糧になると捉えて楽しむことが重要です。最後が全てという生き方をすると結果的に自分は何も無かったと捉えがちですが、途中で目的は変わっても良いと私は思っています。
技術的負債の解消のため、大型リプレイスプロジェクトを担当
そこから、グリー株式会社や株式会社ドワンゴなどを経て、2014年にChatwork株式会社に入社しました。入社のきっかけはChatworkで技術的負債が溜まりリプレイスを検討したいという相談を受けたことでした。
技術的負債が溜まっていた背景には、Chatworkが社内システムに相乗りする形で作られていたことが背景にあります。社内システムに載せた状態で2013年に公開・サービス化し、ビジネスチャンスを逃さないため、集中的に開発した代償として技術的負債が積み上がっていきました。例えば、本来3ヶ月かかる開発を2か月で無理に行うと、1か月分の負債が発生します。
このような状況が積み重なった結果、データ量も負荷も増え、社内システムベースのアーキテクチャでは限界に到達しました。 終盤のジェンガと同じで、どれか1個を抜くと崩れてしまうような状況に陥るのは、急成長したベンチャーで起こりやすいのです。そのため、技術的負債を返却する目的の手段としてScalaを使ったリプレイスを行うことになりました。
全機能リプレイスを試みるも、いくつかの課題に直面
ただ、最初のリプレイスでは成功しませんでした。その背景には、技術的問題とPJマネジメントの問題の両側面があります。
技術的問題ついては、最初からChatworkの全機能をリプレイスしようとしてしまい、いつ頃どういったものが出来上がり、それが検証できるのかの見通しがたたないまま進めてしまったことです。開発が大規模で不確実性も高い中で、役割を分担してリスクヘッジしていく体制が当時はありませんでした。
さらにPJマネジメントに関しては、間にいろいろなチームがいたので、プロジェクトの既存チームと直接コミュニケーションが取れていませんでした。移行先のチーム、新しい移行先のシステムのAPIを利用するiOSチーム、 現行システムのチーム、現行システムを利用した腐敗防止層としてのAPIを提供するチームの計4チームありました。
全チームをうまく連動させないと開発効率が上がりませんでした。他にも、プロジェクトの定義が曖昧だったり、 各スプリントごとのレビューが機能していなかったり、サブシステム間の結合が遅れたりして開発が長引いてしまうなどの問題もありました。
現在は、スクラムの体制でリスクヘッジしていますが、当時は技術もプロジェクトのマネジメントも両方私一人でやっていて限界が来ていました。
開発スコープを狭め、技術のリプレイス再起動を決意
これらの状況から、2016年の頭に一旦再起動をする決断をしました。開発のスコープを狭めて、スクラムの体制で回し、不確定要素が高いものにはPoCを事前に行うようにしました。
想定したコンセプトの正しさが未知であれば、ある程度見積もりが可能な範囲まで技術的に検証してから体制を作ってスクラムを回せるようにするために行ったのがPoCです。PoCは、各メンバーがコードベースでのアイデアを持ち寄り、短期間でアーキテクチャ案を決めて取り組みました。
実際に移行するときには、ユーザーへの影響を重視して開発のスコープを絞りました。送ったメッセージが届かない、急な投稿があって処理が遅れることは許されなくて、システムがいつでも使える状態になっていることが大前提です。他にもタスクやファイルアップロードの機能がありますが、 日常的に一番使うのはやはり「メッセージ機能」です。
処理能力が足りなくてこれ以上メッセージが投稿できないといった言い訳はユーザーに通用しません。増え続ける需要に対して十分に余力がある形でサービスを提供していかなければならないので、ユーザーへの影響にフォーカスするのは必然でした。
ただ、最初の期待値が大きかったのである程度スコープを大きく取りましたが、最初の開発の段階でメッセージにあまりフォーカスしなかったのは反省としてあります。スコープの取り方は今でも難しいところがありますが、この経験はよい教訓になりました。
メッセージにスコープを絞ったメッセージ基盤としてプロダクト開発を行い、リリースは2016年末に行いました。十数億レコードのメッセージデータを9時間かけて移行しました。新システムのDBにはHBaseやKafkaという大規模なクラスタと、Scala、そして分散システムのフレームワークとしてAkkaを導入しました。パフォーマンスやスケーラビリティが高いのはもちろん、障害が起きることを前提に障害から回復するように設計しているのが、他と全く違う点です。
本プロジェクトを機に、多くの機能がScalaで実装されるようになりました。ただし、まだ移行が完了していない部分もあるため、引き続き優先度や重要度に応じて移行作業を進めています。
実践・検証ができて、初めて学びのサイクルは確立する
スキルを獲得するスキルが高い人、つまりメタスキルが高い人、学びや経験を得る仕組みを自分で組み立てられる人は、頼りになると思います。例えば、継続的な学習能力や問題解決能力、コミュニケーションスキル、批判的思考などです。
人や本から情報を得たら自分の知識になったと勘違いしがちですが、学びのサイクル的には情報収集しているだけに過ぎなくて、自分の言葉で説明できないと知識とは呼べません。実際に得た情報の考え方を実践して検証することが大切です。しかし、本を読むだけで実践していない人は多いのではないでしょうか。
実際にやった結果を誰かに説明したりとか、 イベントで登壇して話したりとか、何でもいいので実践して検証まで行って初めて学びのサイクルは完結します。本を読んで知識が身に付くなら全員専門家になれるはずです。結局のところ、自分で手を動かして実践しないと自分が使える知識、つまり知恵にならないと考えられます。知識は情報や事実の蓄積であり、学習によって獲得できるものですが、知恵は知識を実践的に活用する能力であり、経験や実践を通じて培われるものです。さきほど述べた過去の経験からも、知識を知恵へと昇華するためには、実践と検証のサイクルが不可欠だと考えています。
実践・検証を通じて、いかに学びを自分のものにするか
今は情報化社会なので情報収集と比較して実践・検証のコスト(手間)が相対的に高くなっています。SNSから実践に値しそうな情報を次から次へと得られることで、結果的に実践・検証が遠のいてしまいがちです。これに慣れてしまうと、実践・検証までに時間をかけると、他の情報を探し始めてしまって、もはや手を動かすことすらできなくなってしまいます。
SNSを見てると情報の方が実践・検証より価値が高いと思いがちで、情報を得たら実践しなくても分かった気になるのは現代病だと思います。情報収集→考え方の整理(モデル化)→ 実践・検証の3ステップが学びのサイクルと言われます。このサイクルにおいて、実践・検証の結果はフィードバックとして次のサイクルに生かすことができます。多くの人は実践をする前にまた情報収集に戻ってしまいます。(ただし、エンタメとして情報消費するという考え方もあるので、必ずしも実践・検証しないことが一概に否定されるものではありません。しかし、何らかのスキルを獲得する目的で考えた場合は、実践・検証がないとフィードバックがないことになるので、学びの観点では問題があると思います。)
実践・検証によって知見を得ている人は、私の考えでは全体的に少ないのが現状です。私自身、ドメイン駆動設計の分野で一定の評価をいただいていますが、それは実際に手を動かし実践してきた結果だと考えています。実践をせずに知識だけを得ている人から見ると、実践している人は貴重な存在として認識されているようです。このことからも、実践の重要性が明らかです。
しかし実際自らが実践に移そうとする際に、躊躇してしまうものです。一つの分野を選んで実践することは、一時的でも他の知識や分野を選ばないことを意味するため、その決断は難しいというジレンマがあります。とはいえ、全ての知識を実践に移すことは現実的ではありません。したがって、優先順位をつけて、自分にとって最も重要な知識から実践していくことが肝要だと言えるでしょう。
信頼できるエンジニアとは、他人の情報や書籍の知識だけに頼るのではなく、実践を通じて得た知見をもとに、仮説や必要な知識を組み立てられる人のことだと私は考えています。
自分に足りないものを補完する能力は今後も求められ続ける
自分の不足している点を自覚して、それを補う能力は今後のエンジニアにとって変わらず重要な資質であると考えられます。 自分に足りないものを測るための一つの指標として、学習の5段階モデル（引用：NLP学び方ガイド、日本NLP協会監修）が参考になります。
このモデルでは、学習の段階を以下の5つに分類しています。(各段階を自転車に乗るという行為で捉えた説明も含みます)
知らないしできない: 自転車という乗り物の存在を知らない状態で、乗ることができないレベル
知っていてもできない: 自転車に乗るにはバランスを取ってハンドルを操作する必要があることは理解しているが、実際にはバランスを取ることが難しく乗れないレベル
考えるとできる: 自転車の乗り方がわかっており、意識して乗ることができるレベル
考えなくてもできる: 自転車に乗ることが習慣化しており、無意識のうちにできるレベル
どこからでも教えることができる: 自転車の乗り方を言語化し、他者に説明できるレベル
このモデルを、ソフトウェア設計やインフラ設計のスキルなどに当てはめることで、自身の現在の習熟度を可視化することができます。そして、業務で求められるレベルとのギャップを認識し、足りない部分を補完していくことが重要だと言えるでしょう。
今後のエンジニアは生成AIが鍵となる
エンジニアとして成長していくためには、実践と検証を通じて学びを自分のものにしていくことが重要です。さらに、自分に足りないスキルを特定し、補完していく姿勢も欠かせません。これらに加えて、近年急速に発展している生成AIの技術は、エンジニアの学習と成長に大きな影響を与えると考えています。
私自身も、最近は生成AIを活用しています。私の得意な言語はJVM系のJavaとかScalaでしたが、最近は生成AIを使いながら、GoやRust、TypeScriptも使っています。今までは教科書的な参考書を読んで自分で実践していましたが、今は生成AIを活用しています。例えば、「Javaではこのような実装が可能で、目的はこういうものなのですが、TypeScriptとNode.jsで同様のことを行うにはどのような方法があるでしょうか？」などとAIに尋ねます。その結果、そうしたら得意な言語と変わらないぐらいに書けるようになりました。
明確で論理的な問いを立てて、達成したい目的に必要な情報だけを抜き出すようChatGPTなどの生成AIにリクエストすると、目的に特化したテキストが生成されます。参考書とかWebのページは自分がやりたいことに最適化されたページではないので、最初から的を絞った問いを作ってChatGPTから抜き出した方が早いです。
基礎を固めるのに入門書を読むのは必要だと思います。しかし、ある程度基礎的なレベルを達成している人は、生成AIに対して自身の意図や目的を論理的に説明する能力が求められるでしょう。もちろん、生成されるテキストには嘘が混じることがあります。だからこそ、実践・検証を組み込んだ学びのサイクルが必要になると感じています。
私の経験上、サーバーサイドでは元々Scalaが主流でしたが、TypeScriptやGoが人気になってきて転職先の企業も多く採用しています。そのタイミングでキャリアチェンジを目指すのであれば、TypeScriptやGoのスキルを効率的に習得するという変化に対応するために、生成AIを自身の学習システムに効果的に組み込むことが重要だと考えられます。
得意な技術を一つ身につけることは非常に大事です。たとえば、Javaを深く理解しているからこそ、Javaでできることを基に生成AIで他の言語やプラットフォームでどうなるのかを尋ねられます。こういった生成AIを活用するスキルは今後必要になってくると思います。
- 加藤さんありがとうございました。
[PR] Offersでは、開発者のための副業・転職を支援するサービスを提供しています。転職や副業を考えている方はぜひ、ご利用ください。
また、「リアルな現場を読み解き、明日へのヒントを導く」をコンセプトにconnpassでのイベントも開催中です。 こちらもぜひ、ご覧ください。
この記事が気に入ったらサポートをしてみませんか？