江草陽太
大阪府生まれ。ネットワーク、データベース、情報セキュリティのスペシャリスト。 洛星中学・高校のロボット研究部創立メンバー。ロボカップジュニアジャパンなどのロボコンに出場。 その後、大阪大学工学部電気電子情報工学科に進学。NHK大学ロボコンに出場。学生時代より個人事業としてシステム開発を行う。2014年10月、新卒採用によりさくらインターネットに入社。「さくらのVPS」等のバックエンド開発を担当。IoTプラットフォーム「sakura.io」の開発責任者を担当し、サービス設計と開発を行う。
2016年7月、執行役員に就任。現在は、さくらインターネット全体の技術統括とコーポレートIT、情報セキュリティを担当。宅急便をSlackから発送できるサービスを開始するなど、コーポレートITに関わるDXのサービス化も行っている。
ビジネスサイドと仕様や期限で揉めたり、こちら側の意図がきちんと伝わらないことが多く、手戻りが多いです。ビジネスサイドとうまく付き合うために必要な心がけなどはありますか？
なるほど。これはビジネスサイドと技術サイドの両方に言えることですが、完全にお互いを理解することは難しいと思います。お互いの領域について知ろうとするという心がけはまず重要かなと思っていて、これがないと実際に理解できなくていつまで経ってもすり合わせができないし、議論も進まない。
エンジニアサイドからは「何を売りたいんだ？」をよく聞くことですね。仕様以前に、なぜそんな仕様にしたいと思っているのかというバックグラウンドを聞いて、「それだったら実装上、これは困難で、こういう方法あるいはこういう料金体系にしてもらえれば実装も楽だし、おおむね実現したいビジネスモデルも実装できますよ」と提案できるのがベストかなと思いますね。
仕様を言われて「そんな仕様は実装できひんやろ！」と思いつつ、「それは難しいです」とだけ答えるパターンが一番次の議論に進まないので、（相手が）何をしたいのかを理解するところですかね。
これは裏を返すと、こういうルールの仕様で実装してくださいとお願いするほうも、バックグラウンドとしてやりたいことをきちんと説明する必要があるということだと思います。
それが説明できないのであれば、まだ自分も理解できていないということなので、自分の考えをもう少し整理してほしいなという感じです。お互いが根本的に何をやりたいのかを共有できるような心がけをすることかなと思いますね。
言われたとおりの仕様に実装したけど、実はそれにはかなり設計の部分が含まれていて、その仕様には設計漏れがあって、ビジネスサイドの人が本当にやりたかったことと仕様にすでに差があるパターンがけっこうあるので、仕様を言われた側も「なんでそんな仕様なのかな」と意図を汲みにいくということをしておけば手戻りは減るんじゃないかと思いますね。
そんな江草さんが、エンジニアにおける問題解決において重要視することは何でしょうか。
問題解決で重要視することか。まぁ、根本的にやりたいこと、解決しなければならない課題を理解することかなと思いますね。「こんなことがしたいのでこういうものを作ってください」と言われた場合も、根本的に何がしたいのかをよくよくヒアリングしたら、ぜんぜんそんなに難しいことではなくて、ちょっとした修正で解決できちゃう場合もあったりします。
問題解決をする上では、根本的な理由を聞いておかないと先ほどの手戻りにもつながりますし、根本的なことを聞けば実はもっとシンプルな問題に落とし込める可能性がわりとある。それができるのが、エンジニアの設計能力だと思うので、本質を見て簡単な問題に分解することが重要かなと思います。
これは実際にコードを書く時もけっこう重要で、条件分岐がすごく複雑になっているやつも「もうちょっと簡単に考えたら、簡単な問題の2つぐらいに分類できるんのちゃうの？」みたいなことが実際に実装する上でもあります。複雑そうと思ったやつは、シンプルな複数の問題に分割できることが多いので、シンプルな問題に落とし込むということを問題解決をする時には考えるといいのかなと思っていますね。