![#4 [徹底討論] 「技術力」を言語化したい件](https://image.listen.style/img/lD3egmeRvym0UZUckycVRPkCGmS-mq7nKlyKMjga6B8/resize:fill:1200:1200/aHR0cHM6Ly9kM3Qzb3pmdG1kbWgzaS5jbG91ZGZyb250Lm5ldC9zdGFnaW5nL3BvZGNhc3RfdXBsb2FkZWRfbm9sb2dvLzQzNzczMTcwLzQzNzczMTcwLTE3NDkwMzEwNjEwMDktZjdlNmU2NGRmZWMxYy5qcGc.avif)
技術力の定義と文脈
こんにちは、ひびのです。 こんにちは、リドルです。
今日のお題は、自分が起票した、「技術力を言語化したい」というテーマで話していきたいと思います。
そんなに楽しいものでもないんですけど、 技術力を言語化したくないですか?
いや、なんか難しいなと思って。 これちょっと前提を整理したいんですけど、ITエンジニアの技術力ですか?
おっしゃる通り、そうです。 ITエンジニアの技術力、何かなと思って。
普段のディスカッションとかでも、漠然と技術力っていう言葉は使われるじゃないですか。
でも実際何を持って技術力なのかなって、最近ふと思ったんですよ。 仕事の話ですか?
個人的には仕事に限らないんじゃないかなとは思ってます。 もちろん、例えば個人開発だったりとか、
趣味レベルの開発でも生きてくる力、どちらかというと仕事でも生きる、 プロダクトに関わらないが開発全般で生きてくる技術なのかなとはなんとなく思っています。
例えば、一般的なウェブアプリの開発において、いろんなスキルがあると思うんですけど、
そことは全然関係ない、本当にニッチなジャンルの技術があれにあったとして、しかもめちゃくちゃ詳しい。
それは何か技術力高いに入れたほうがいいですか?
文脈によりそう。 仕事もプライベートも関係なくって話だったので、今のとおり完全に自由じゃないですか。
じゃあ前言撤回させてください。 文脈によるんじゃないかなと思っています。
文脈制限しましょうか。どれにします?仕事にします?プライベートにします?
じゃあ僕らみたいなウェブ系の企業での、具体的にチームでのプロダクト開発というところにしましょう。
その前提に立つと、ウェブ系の技術に全く関係ないニッチな領域でものすごく尖ってる技術。
個人的にはそこで培った尖っている技術力、力をプロダクト開発に生かせるなら、それは技術力高いと言えるんじゃないかなと思っています。
例えば自分が前職にいた技術者の方で、Wi-Fiにめちゃくちゃ詳しくて、Wi-Fiってどこに設置するかで性能がめちゃくちゃ変わったりとか。
いろんな種類があったりしますし、そういうのって実際のウェブ系の開発の時にはほとんど役に立つ機会は少ないかな。
転用もしづらい。今回のケースにおいてはあまり転用しづらいから技術力的にはちょっとって感じになる。
今思ったのが、例えばWi-Fiという技術を扱うにあたっても何かしらトラブルシューティングをしなきゃいけないタイミングがある。
そのトラブルシューティングの力を、例えばプロダクト開発運用に生かせるとなったら、それはやはり技術力が高いのではないかなと思いました。
トラブルシューティングとか転用できる力があれば良いってなると、やっぱり抽象度が高い話なんですかね。
技術力の要素
そうですね。抽象度、多分いろんな要素があるんでしょうね。抽象度が高いソフトスキル的なところもあれば、具体的にこの言語に詳しいという領域もあるだろうし。
例えばプロダクトで、いわゆるリアクト、ネクスト、テイルウィンドウを使ったフロントを書いていて、状態管理は何でもいいんですけど、プラスクラウドフレアで動かしているとしましょう。
バックエンドはJavaとかで書いていて、データベースは最近入りのNewSQLで書いています。構成があった時に。
入ってきた人が、例えばビュービューとかネクストをやっていて、裏はレイルズしかあったことないです。RDBMSしかあったことないです。
ただ、なんとなく感覚が分かるので、トラブルシューティングもなんとなくできますみたいな感じだったら、スキルはあんまちだけど技術力はあるみたいな。
自分はそう評価していいかなと思っています。
ただ開発スピードは知っている人より遅いってなるとどうですか?
その時点では、その文脈の中では技術力は低いが、ただ一方で1ヶ月その業務に従事したら、技術力高いレベルにいくんじゃないかなと思いますね。
例えば今の話で、その職場ではリアクトが使われているが、その人はVueの経験者であるみたいなところでも、
結局例えばHTML、CSSみたいなブラウザに関する知識だったりは、当然Vueを業務で使っていた人として持っているわけじゃないですか。
その知識は直で転用できるものですし、あとはリアクトを覚えればそこでは生きてくる技術力になる。
じゃあその人があんまり新しいのを覚えるのが得意じゃなかったらどうですか?
うーん、なるほど。それは困りますね。
そうですね、困りますよね。半年経ってもリアクト、コンポーネントってどうやって書くんだっけかなみたいな。
さっき問題解決、例えば一要素として問題解決力がある。それは確実にそうだろう。
一方でまた別の要素として新しい技術を習得する吸収力。そこも技術力っていう括りの中では重要な要素なんじゃないかなと思い始めてきました。
実践における技術力
基礎ができた上でのキャッチアップ力が高くないとダメそう。それを合わせたものを技術力と呼べるかなっていうイメージですか?
今のところはその2つはまず重要な要素ではあるだろう。で、今何か他にないかなっていうことを考えてるんですけど。
ブリリアントジャークっていう言葉あるじゃないですか。仮にそんだけキャッチアップもできて基礎力もあるけど、一緒に仕事はちょっと微妙かなみたいな感じのすごい人がいたとして、それは技術力には関係ないですか?
自分のイメージではブリリアントジャーク的な、例えばその人の振る舞いですかね。そこは技術力に該当して語られることは少ないんじゃないかなと思ってます。でもまあまあ見えてきた気がしますね。
ただその人の性質というか振る舞いとかはあまり関係なくて、単にその人が保有している基礎スキルと応用力、キャッチアップ力に限定している。
それに聞きずっちゃいますかね。
自分の中で技術力を評価しようと思うと、今の要素的に言うとどの辺がまだまだ伸びしろありそうですか?伸ばしていかないと思いますか?
どちらかというとまず今挙げた2つの要素の中では問題解決力の方かなと思っています。これまでいくつかのサービスに携わってきて割と技術的な幅は広いと自分では思っているんですよ。技術的にこれまで触ってきた幅。
一方で問題解決力、他の人よりも早く解決するみたいなところはまだまだ伸びしろがある。あるいはチームの中では不得意な部類なんじゃないかなと自分では思っています。
例えばインフラとバックエンドとフロントがあったときにどこに問題があるかわからないときにどこにあるかを特定する話なのか、リアクトのどこで問題が起きているかわからないという2種類の話があるとするとどっちの話?
後者ですね。というのも今のレイヤー分けでフロントエンドバックエンドどっちに問題があるかって技術的な知見の幅が広ければある程度特定は容易というかそれこそ問題の切り分けはしやすい分野だなと思うんですが
一方でフロントエンドの具体的にこの部分がエラーを起こしているとか何か誤った挙動をしているってなかなかそれこそ僕らが関わっているようなサービスだとフロントエンドバックエンドそれぞれのコードベースもかなり大きくなるって言うだろうし
なかなか念入りにスピード感を持って精度の高い特定をするってなかなか容易なことではないんじゃないかなと僕は思っています
確かに大きくなるとやっぱり時間はかかりますよね
そうですねそれで言うとリドルさんは前の部署で同じチームで働いていてかなりその大きなコードベースの中でも問題の特定がうまい人だなって僕はずっと思っていたんですけど何かコツとかあるんですか
フロントエンドをあまりやっていなかったっていうのは大きいかなと思っていてバックエンドはログから特定が結構容易なんですよね
状態を持っていないのでログが出た時間とログが出たところの行数エラーが出たときのコードベースの行数がわかれば基本的にはここだってまずわかるじゃないですか
あとはその時のリクエストのパラメーターというかそういうものをデータベースなりログからうまく持ってこれればあとは自分でデバッグ環境で1行ずつデバッグしていけばなんとなく状態がわかるので割とサーバーって容易なのかなと思ってますね
なるほど
ただやっぱり構成図を頭に入れておくとかどういう通信経路なんだろうみたいなのは知ってることが前提になるのでそのなんか全体感みたいなのが知ってるっていうのは結構アドバンテージかもしれないですね
はいはい例えばサーバーで言うと大まかなアーキテクチャがあって大まかにどういうドメインに分かれているかみたいなところを最初に理解しておくのが大切っていうことですね
そうですねそれもありますしインフラ含めた全体の構成もありますね単純にリクエストを受け付けて返すだけじゃないケースも結構多いかなと思っていて
マイクロサービスだったら複数のシステムが連携して動きますし外部サービスと連携してみたいなこともあるのでその辺全部頭に入れた上でってなるとちょっとハードルあるかもしれないですけど入っていれば結構早いかも
なるほど 例えばさっきリクエストパラメーターを見てという話があったじゃないですかもう一つ
リクエストパラメーターをすべてログ取ってるシステムってそんなにないんじゃないかなと思ってて
そうですね
もちろん個人情報も含まれているだろうしという点で
例えばじゃあリクエストパラメーターとして受け付ける値のバリエーションがかなり広いことが想定されるみたいなところで
エラーが起こったどういうところを最初に当たりつけますか
まずリクエストパラメーターが付いているということは基本的にgetのリクエストの場合はログインgetのURLが残っているのでそれでわかりますよね
これがポストの場合になると確かにわからないんですけれども結局リクエストが飛んできたときにいろんな条件分岐があって
DAVにアクセスしたりとか処理があるわけじゃないですか
ここでログが出ているということは少なくともこの条件分岐が入っているからこれ入ってるはずとか
データベースにこう書き込まれているならこの値を持ってきているはずということは想像つくので
そこからの逆算だったりあとは仮説検証みたいなことよく言われますけど
ここに来るということはおそらくこうなはずみたいな仮説を立ててそれが当たってるかどうかで
このケースじゃないということはあとこっちのケースだよねみたいなのを地道に頭の中でやったりします
エラーが出た箇所にたどり着く上ではこのif文を通っているだろうみたいなところを整理していくということですね
なるほど確かに
一方でフロントエンドとかモバイルって状態が再現しづらいというか
ファイアベースのクラッシュアナリティクスみたいなものを使って
前モバイルの方のバグとかもウォッチしてましたけど
結局何かこう正しくないって言うと語弊があるかもしれないですけど
何か善良のログが残ってるわけじゃないから
その時の状態が分からなくて何で起きたのかがよく分からないみたいなことが結構あるなと思っていて
そうなるとそっちのトラブルシューティングは本当に大変だなって思いましたね
自分がよくやるのはでもそれこそクラッシュアナリティクスとか
あとWebフロントエンドだとどうだろうセントリーとかが使われることが多いのかな
それと同じくやっぱりエラーが発生したファイルの共通っていうのは記録されるものじゃないですか
かつフロントエンドだと状態を持っていることは多いが
データベースみたいな永続化されたデータを持っていないことの方が多いので
データを壊す心配がないっていう点でひたすらプリントデバッグを仕込んで
こういう状況で再現するかのあたりをつけるみたいなことはやりますね
実際に動かしてが多いかな
リアクトの使い方の話になっちゃいますけどIDとかで開いたときに
全然デバッガーが使えないんですよね
はいはいはいデバッガーそうですね
これ止まってくれみたいなステップ実行したいんだよね
それこそリアクトだと本当に何十回何百回とレンダリングが繰り返されているみたいな状況の中で
ステップ実行がうまく動かないみたいなことは全然ありませんね
それ動かないから困るんだよ
自分もそれに嫌気がさせてプリントデバッグ主義者になったところはあります
でも環境レンタはコンソールログ入れると怒られるから
はいはい
リンターで
あーそうですね
ガチガチでやってたりするとそもそもコンソールログ残っているとリンターが落ちてコミットできない
そう
そういう意味では割とwebフロントエンドアプリもそうですけど
手元に完全に再現できる環境があるっていうのは大きいですね
例えばサーバーだとどうだろうサービスによっては
ローカルで動かす環境がしっかり整備されてないみたいなことあると思うんですよ
あとそれから仮にサーバーのみの動作環境があったとしても
フロントエンドからのリクエストを再現できた方が動作確認しやすいとか
その点webフロントエンドだと例えばAPIのレスポンスは形式さえ決まっていればMockすればいいしとか
最悪MockしたMockする用のデータをベタ書きして再現するとか
そうですねレスポンスもね
割と脳筋な動作確認ができてしまうっていうのは一つ自分は気に入っているところではありますね
技術力の要素
ちょっと話を戻すと技術力の中に問題解決能力とキャッチアップ力基礎力
キャッチアップ力基礎力
3個
3個
問題解決能力のうちバックエンドの方とかインフラの方はもっと伸ばしていきたいよねっていうところですね
基礎力はどうですか
基礎力
自信を持って基礎力ありますっていうのは難しいですね
難しいですね
思いますそれ
コンピューターサイエンスがもう一回勉強すると忘れてるわみたいな
文字コードとか不合格集合とか一生覚えられない
毎回覚えてすぐ忘れる
毎回失敗するたびに勉強します
確かに
学生時代にいわゆるコンピューターサイエンス専攻じゃなかった人が働き始めてからもう一回大学行くみたいなこと
たまにSNSでも見かけるじゃないですか
やっぱりみんなそういう思考になっていくんですかね
でも確かにそこに行けば学べるんじゃないかなって思う人多いんじゃないかなと思います
自分も検討したことありますし
本当ですか
結局コンピューターサイエンスで学ぶだけだったら結構書籍というかネットの情報でもほとんど足りることがわかったので
まあいいやって思っちゃいますけど
でもインク人多いですね
確かに確かに
そういう意味でもソフトウェアエンジニアの人だと基礎力に課題を持っている人は意外と多いかも
課題自分と課題に思っている人は
そうかもしれないですね
この前ストリートコーダーっていう本を読んだんですけど
それはどっちかっていうと理論として学ぶ大学のコンピューターサイエンスと現場で実際にしようとされるコーダーとしてのスキルは全然違うものだと
現場ではこういうテクニックがめちゃくちゃ使われるけど
理論側では一切学ばないよみたいな
おっしゃる通りですね
すごい特殊な例を出すとGOっていう言語があって構造体が定義できますと
構造体の中にイント型とかストリング型とかが定義できるんですけど
こういう順番で定義するとメモリが一番最適化されるよみたいなのがあるんですって
それはGOの本で読んだんですけど
だから理論的に言えばそういうのを守ってやった方がメモリ効率もいいし
微差でしょうがスピードとかもちょっと速くなる可能性があるんですね
実際のプログラマーそんなことやらないじゃないですか
カリカリチューニングとかあるかもしれないですけど
ほとんどのケースは一切気にしないし
何だったらABCD順とか追加者順とか
自分たちが読みやすい順にすることが多いと思うんで
その辺は実際の現場でやることと理論が違うんで
現場だけで学んだ人だと逆に理論の方が薄くなっちゃうので
そういう基礎力みたいなところが足りてないのかなっていう
学習のアプローチ
印象になってしまうというか課題と思ってしまう人が多いんじゃないかなと思います
なるほど今の話聞いてると
理論と実践バランスよく使えるのが一番ですね
そうですね
そういう意味だと実践はもう
実践はこなしている
じゃあ理論か理論に戻っていくのが
もう一回大学入り直すかな
そこなの結論
理論はもうやってるんですよね
息を
思い出すだけってことですか
不真面目ながらも
全部忘れたと思います
理論を思い出しつつ
応用力というか問題解決能力を上げて
応用力は大丈夫なんですか
他のものに転用する力というか
他のものに転用する力
これまでいくつかのサービスに携わってきて
その都度その現場で使われる技術はキャッチアップできているので
そこは個人的には課題感は持っていませんね
いいですね
技術力を分解した結果
基礎力と応用力と問題解決力に分かれて
そのうちの基礎力と問題解決能力は
今後もうちょっとやっていこうという
もっと鍛えたいと思っています
素晴らしいと思います
頑張ってください
頑張ります
リドルさんはこの3つだとどこを伸ばせそうですか
もし伸ばすとしたら
全部ですね
全部ですか
基礎力は足りてないんで
今コンピュータサイエンス勉強してるんですけど
2年間くらいかけて道をやろうと思ってて
42東京
GitHubにコンピュータサイエンスを自分自身で学ぶみたいな
英語のこの本読めみたいな感じの
すげえ長い学習コースがあって
それこそフロントエンドスキルマップみたいな感じですか
あれじゃないくて
本当にOSはこれとか
最初まずやったのがSICPっていう
LIPを使った
問題集みたいなやつ
後にアルゴリズムを勉強して
OS勉強してシステム設計勉強して
数学勉強してみたいな
すごい肉厚の数年かかったみたいなコースがあるんですけど
それをちょっとずつやるっていうので
基礎をなんとか固めようとして挫折してます
今の話聞いてて
いわゆる情報工学科みたいなところを
調ばすみたいな
本クソ高い
指定された本をこの前買ったら3万下だった
そんなにもするんですか
買ったんですか
買いました
絶版になってて中古でしか買ってなくて
元々1万8000円くらいだったのが3万になってて
高いと思って
地域の図書館とかにもなかったでしょ
ないですないです
1000ページくらいなんですよね
めっちゃ熱い
それをやってるのが基礎力で
応用力は
最近はつけてないかもしれないですね
本当ですか
でもリドルさんはそれこそ
自分と同じチームにいた時に
その時からサーバーエンジニアだったけど
フラッターを勉強し始めて
だいぶフラッターの開発
試作開発をリードできるくらいにはなってた
いやなってないです
なんとなく書けるんですよ動くものは
ただ性能が出せるかとか
ちゃんと裏側の向き分かってるかって
俺は知らないんで
確かにその時の同僚ですごく
フラッターの第一人者みたいな人は
やっぱり知識の厚さが違いましたもんね
なんちゃって書いてるだけなんで
レビューでコメントいただいても
そうなんですね意外と書いてないんですよ
そうなんだみたいな
そこで初めて知るみたいな
それはその言語に対する知識の
あんまり薄さというか
なんとなくAI使っちゃうと
もっとなんとなくできちゃって
そこは課題ですね
確かに
あとは問題解決能力で言うと
ある程度大体のことは分かるんですけど
もっと大規模になってきたりとかすると
自分が観測しきれない範囲だったりだとか
もっと根深い問題
カーネルのこの設定がちょっと
このバージョンだとおかしかったですとか
みたいなものはカーネルのこと知らないので
全然
Linuxのこと言うってことないので
多分問題解決に相当時間がかかると思いますし
より深い問題とかは
まだまだ今後の活躍に期待したい
という感じですね
なので全方位に伸びしろを感じます
日々勉強ですね
そうですね
本当に
そんな感じで
まとめましょう
はい
三島さんの中では
今後の成長
今回技術力ってものを取り扱って
主にビジネスの現場において
プロダクト開発
ウェブのプロダクト開発っていうところに限定すると
技術力は基礎力と応用力と
問題解決能力であるという風に考えました
そのうち基礎力と問題解決能力は
もっとやっていきたいということで答えられたので
今後も頑張ってください
頑張りましょうお互い
ありがとうございました
ありがとうございました
