江草陽太
大阪府生まれ。ネットワーク、データベース、情報セキュリティのスペシャリスト。 洛星中学・高校のロボット研究部創立メンバー。ロボカップジュニアジャパンなどのロボコンに出場。 その後、大阪大学工学部電気電子情報工学科に進学。NHK大学ロボコンに出場。学生時代より個人事業としてシステム開発を行う。2014年10月、新卒採用によりさくらインターネットに入社。「さくらのVPS」等のバックエンド開発を担当。IoTプラットフォーム「sakura.io」の開発責任者を担当し、サービス設計と開発を行う。
2016年7月、執行役員に就任。現在は、さくらインターネット全体の技術統括とコーポレートIT、情報セキュリティを担当。宅急便をSlackから発送できるサービスを開始するなど、コーポレートITに関わるDXのサービス化も行っている。
SESのWebエンジニアとして働いており、開始から3ヶ月ほどです。まだまだ案件の理解が追いついておらず、作業者レベルの業務しかできていないなと感じています。
ゆくゆくは顧客をリードしていけるようになれたらなとは思っており、案件理解を進めるために業務で発生した疑問について聞いたり、チーム内勉強を開くなどをしているのですが、どうも自分の理解の進みが遅く感じます。
顧客理解をより素早く進められるコツや、そのために良いチーム内勉強会のネタなどはありますか？
SESというのは、派遣型の開発に参加してシステム開発をしているという環境ですよね。今（自分が）いるさくらインターネットは、お客さんの要件に合わせてなにかを設計するという受託はしていないので参考にはならないんですけど。
副業だったり、大学時代は大学の教科のシステムや研究室のシステムを作ったりしていて、その時はよくお客さんのところに行って、ヒアリングをしたり、相談したりしていたので、（質問者の環境は）たぶんそれに近いというイメージでいます。
相手がやりたいビジネス、やりたい事業ドメインの知識を得るという点では、確かに最初は「え？ そんなビジネスあるの？」「そんな需要があるの？」と、システムが想像できないんですよね。そういう場合は、1つは相手としゃべること。ただ、しゃべる上で一方的にヒアリングをしてもたぶん理解は進まないと思うんですよね。
対面でのコミュニケーションで相手のものを理解するという上でのコツはけっこうあると思っています。「U-22プログラミング・コンテスト」の最終審査会では、作品を作った方との質疑応答もあるのですが、自分の理解が正しいかどうかを相手に確認することも含めてコミュニケーションを取ることが重要です。「そうおっしゃっていることは、こういう理解をしたんだけど、じゃあこの違うパターンにおいては、こういうことで良いですか？」みたいな感じ。
自分の認識が合っているとすれば、別の問題についてはこういうことだけど、それで合っているか、みたいなことを確認する。「あ、そうそう。そういうことです」と言われたら自分の理解が合っているというチェックになるし、「いや、それはそうじゃなくてこうなんですよ」となったら、自分の理解を正しい方向にずらすための材料になる。
なので、こちらから違う条件や違うパターンを質問してみて「そうです」ないし「それは違うんです」みたいなコミュニケーションを取ることが大事かなとは思いますね。
もう1つ、相手がいない場合。例えば、帰ってからオフィスでとか、誰よりも理解を深めるためにという場合、その分野のことを一般的な情報として調べる。
あるいはできるなら、同じようなシステムを見る、ですね。そういったものが役に立つかなと思います。例えば施設の予約システムを作るのが初めての場合「他の予約システムはどうなっているんだろう」と、やはりいっぱい見てみるべきです。
ものによって違いがあるんです。「あのシステムは複雑やな」とか「なんか特殊なルールが入っているな」とか。システムの作りも理解しつつ、その後ろにある「なんでそんな変なルールがあるんだろう」を見ることで、そういう業界もあるのね、というのがだんだん見えてくるので、そういうことの繰り返しかなと思いますね。これは個々人ですることだと思います。
これを勉強会で他人に伝えるのは、また難しいんですよね。自分が理解できてしまうと、相手は何がわからないかがわからないという状況になってくるので、相手に伝えられなくなるんですよ。勉強会を開いても自分がお客さんと同じ立場になるわけです。
自分は当然わかっていて、相手が何をわかっていないかわからないから、一方的に説明をしてもわからないというお客さんと自分の関係が、自分と別のメンバーとにすり替わるだけなので、その場合は相手の理解を進めるように、いろいろなパターンを提示するのも1つの手です。
この条件の場合は、特殊パターンを提示するとかですね。それで相手の理解が正しいか確認するというのもあるし、「じゃあこういう場合はどうやと思う？」と聞いてみるとか「別のパターンだったらこうですよね？」とあえて相手に聞いてみる。相手に違うパターンについて考えさせて、「どう？」とか。そういったことをすると良いのかなという気はします。
きれいに説明できる資料に落とし込める能力があればいいんですけどね。それはまた人による。理解できる能力があっても資料に落とし込めるかどうかはまた別の話で、それができるなら、それを使って勉強会をしたらいい。お客さんが説明をするよりも、エンジニアのほうがよりわかりやすい説明ができると思うのでそうしたらいいし、それができない場合には、いっぱいコミュニケーションを取ることになるのかなという感じです。