2024.10.01
自社の社内情報を未来の“ゴミ”にしないための備え 「情報量が多すぎる」時代がもたらす課題とは?
リンクをコピー
記事をブックマーク
江草陽太
大阪府生まれ。ネットワーク、データベース、情報セキュリティのスペシャリスト。洛星中学・高校のロボット研究部創立メンバー。ロボカップジュニアジャパンなどのロボコンに出場。その後、大阪大学工学部電気電子情報工学科に進学。NHK大学ロボコンに出場。学生時代より個人事業としてシステム開発を行う。2014年10月、新卒採用によりさくらインターネットに入社。「さくらのVPS」等のバックエンド開発を担当。IoTプラットフォーム「sakura.io」の開発責任者を担当し、サービス設計と開発を行う。
2016年7月、執行役員に就任。現在は、さくらインターネット全体の技術統括とコーポレートIT、情報セキュリティを担当。宅急便をSlackから発送できるサービスを開始するなど、コーポレートITに関わるDXのサービス化も行っている。
設計力ですね。設計力だと思います。ビジネスサイドのやりたいことをシステムの仕様に落とし込むという設計力もそうですし、それが決まったとしてきれいなコードに落とし込むためのコーディングの設計力もそうです。この2つはたぶん今後も重要だと思います。
特に後者はコードレビューをする時にも重要です。こんなコードを書いてほしいと仕様を言ってAIに任せてもきれいなコードにはならないので、設計力は今後もすごく重要だし、それができれば生成AIがもっとすごくなってもエンジニアとして活躍していけるんだろうなと思いますね。
これはよく聞かれるんですよ。(自分自身に設計力があるのは)たぶん過去にいろいろなシステムを見てきたからかなという気はします。ダメなシステムから「あ、なるほど」と思うようなシステムまで見てきました。
OSSのソフトウェアもそうだし、仕事で関わったシステムもそうだし、仕事で関わることになってしまった他者が作った微妙なシステムなどでアンチパターンを知ったり、良い話を知ったり「そういうやり方はダメなんだね」という選択肢を得たりしてきたなという気はしますね。AIが学習する過程と一緒ですね。
決まりはないんですよね。プログラムから設計する上でやりがちでなのは、自分が一番良いと思っているものをそのプロジェクトに当てはめてしまうことです。やはりトンマナや、やりたいことごとに使うべき言語、使いやすい言語、適切な言語、フレームワークは変わってきます。
ふだんはこれがベストだと思っていても、やはり別のプロジェクトにおいては違う選択をしたほうが良いこともあるわけで、そういったところを押し付けないように周りを俯瞰して見るのは重要ですかね。
あと、私がプルリクをもらってコードレビューをする上で一番よくあるのが、英語の単数形と複数形が間違っているとかですね。これは些細な問題ですが、usersという変数なのにユーザーの配列じゃなくて、そのあとusers.idとかになってきてコードが読めなくなるとか。変な日本語みたいな感じですよね。ユーザーならuserで入れてほしいし、user.idにしてほしいとか。あとは関数名が動詞になっていないとか。
「この関数名が何をするのかが名前からじゃわからん」みたいな、そういった細かなところも含めて、きちんと周りとのトンマナを合わせてやる能力がいると思うので、インプットは大事ですね。自分が新規のプロジェクトに参加するとしたら他のプロジェクトを参考にするし、既存のコードだったら他の人が書いたコードはきちんと見る。それに合わせて書こうという感じで、インプットが重要だなという感じがします。
ぶっちゃけそのへんによくあるシステムのプログラミングって、生成AIができて当たり前で、ほとんど頭の中にあるコピペなんですよね。こういう場合はこういうロジックみたいなものがあるので、周りに合わせつつ、やりたいロジックを頭の中でコピペして生成するというところは生成AIがやっていることと一緒だなという感じがします。そうすると、やはり決まったルールでやるというよりは、いっぱいインプットした中から吐き出すという、生成AIがやっている処理のほうがいいんだろうなとは思いますね。
江草さんが今気になっている技術や言語を教えてください!【一問一答】
新しい技術への取り組み方を教えてください!【一問一答】
どんなエンジニア組織が理想ですか?【一問一答】
チームで開発する上で一番大事なことは何ですか?【一問一答】
エンジニアのチームビルディングで大事なことは?【一問一答】
「働きやすさ優先組」と「仕事の成果優先組」が同じチームにいたらどうする? 江草陽太氏が考える、エンジニア組織における“働きやすさ”の課題【一問一答】
“EMを目指すエンジニアが少ない問題”はどう解決する? メンバーに目指してもらうために効果的なこと【一問一答】
多くのマネージャーを悩ます“エンジニアの評価設定” 適切に評価するために必要な「物差しの指標」【一問一答】
仕様や期限で揉めがちな「ビジネスサイド」と「技術サイド」 互いにうまく付き合うために必要な心がけ【一問一答】
江草陽太氏が考える、自身のエンジニアとしての強み “課題を簡単化するスキル”を身につけるために必要なこと【一問一答】
エンジニア間でも大きく差が出る「生成AIをうまく活用できる人」と「できない人」 江草陽太氏が考える、AI時代に求められる能力【一問一答】
需要がなくならないエンジニアであり続けるために 生涯現役で活躍するために必要な“設計力”の鍛え方【一問一答】
「自分の顧客理解の進みがどうも遅く感じます…」 相手のビジネス・事業ドメインを素早く理解するためのコツ【一問一答】
「リモートワークで先輩の仕事ぶりが見えない…」新卒2年目エンジニアの悩み 他人と自分のスキルの差を知るための方法【一問一答】
エンジニアに“経営の視点”は必要? 「経営やプロジェクトのことは知りません」とならないほうがいい理由【一問一答】
2024.10.29
5〜10万円の低単価案件の受注をやめたら労働生産性が劇的に向上 相見積もり案件には提案書を出さないことで見えた“意外な効果”
2024.10.24
パワポ資料の「手戻り」が多すぎる問題の解消法 資料作成のプロが語る、修正の無限ループから抜け出す4つのコツ
2024.10.28
スキル重視の採用を続けた結果、早期離職が増え社員が1人に… 下半期の退職者ゼロを達成した「関係の質」向上の取り組み
2024.10.22
気づかぬうちに評価を下げる「ダメな口癖」3選 デキる人はやっている、上司の指摘に対する上手な返し方
2024.10.24
リスクを取らない人が多い日本は、むしろ稼ぐチャンス? 日本のGDP4位転落の今、個人に必要なマインドとは
2024.10.23
「初任給40万円時代」が、比較的早いうちにやってくる? これから淘汰される会社・生き残る会社の分かれ目
2024.10.23
「どうしてもあなたから買いたい」と言われる営業になるには 『無敗営業』著者が教える、納得感を高める商談の進め方
2024.10.28
“力を抜くこと”がリーダーにとって重要な理由 「人間の達人」タモリさんから学んだ自然体の大切さ
2024.10.29
「テスラの何がすごいのか」がわからない学生たち 起業率2年連続日本一の大学で「Appleのフレームワーク」を教えるわけ
2024.10.30
職場にいる「困った部下」への対処法 上司・部下間で生まれる“常識のズレ”を解消するには