皆さんこんにちは、ドリーム・アーツ採用担当の山本です。
今回の記事は、サービス＆プロダクト開発本部　夏天のインタビューです！

ドリーム・アーツではすべての社員が「抽象化力」の研修を受講し、日々コンセプチュアルスキルを磨いています。カリキュラムとして、入社1年目に「具体と抽象」研修、入社3年目には「フレームワーク思考」研修を用意しており、日常の業務の中でも「具体」「抽象」「フレームワーク」といった言葉が共通言語になっています。社員たちは実際、抽象化力をどのように活用し、サービスの品質につなげているのでしょうか。同社で製品開発に携わるエンジニアの夏天（シャア・ティエン）さんに聞きました――。

※「抽象化力研修」について、詳しくはこちらをご覧ください。

ユーザーの要望通りに作るだけでは足りない

―夏さんは4年前にドリーム・アーツに入社されました。その時に細谷功さんによる「具体と抽象」の研修を受けたそうですね。

とてもおもしろい研修だったことを覚えています。ただ、受けたときは正直、「エンジニアの仕事に役立つのかな」と疑問に思いました。

でも今では、「具体と抽象」の考え方は開発に不可欠だと思っています。

―それはなぜでしょうか。

以前は「より良いものを作るためには、技術的な知識こそが必要だ」と思っていました。でも実は、何千、何万もの人に日常的に使ってもらえる“いいもの”を作るためには、それだけでは足りないことを実感するようになったからです。

たとえば、ある特定のユーザーから挙がった要望通りの新機能を作ったとしても、そのユーザーのニーズに特化したものにしかなりません。ほかのお客様に喜ばれるものになるとは限らず、汎用性がなくなってしまう。

ですから、そのユーザーからの具体的な要望を抽象化し、背景にある、「そもそも」の課題を考えて、「どんなものを作って実装すべきか」を見極めることが大事なのです。

たとえば、「画面の上の方だけでなく、下の方にも『検索』のボタンをつけてほしい」という要望があがったとして、そのまま受け入れて検索ボタンを追加すると、ほかのユーザーから「近くにある別の機能のボタンと間違って押してしまうので不便」「ボタンの数が増えて混乱する」などの不満があがるかもしれません。

だからこそ、「この要望を挙げたユーザーは、なぜここに検索ボタンがほしいと考えたのか」「そもそも画面の導線の設計に問題があるのではないか」「ほかのユーザーからも、ボタンの配置に関する要望が挙がっていないか」など、視野を広げて俯瞰し、「抽象化」して考えることで、単に言われた通りのボタンを追加するよりも、より多くのユーザーに響くサービス作りにつなげることができます。

特に「SmartDB（スマートデービー）」のような製品の開発では、具体と抽象の発想が欠かせません。

「自分に見えている範囲は狭い」ことを自覚する

―なぜ「SmartDB」では特に重要なのでしょうか。

「SmartDB」は、十数年前に発売されたドリーム・アーツの基幹製品の一つです。長い間にさまざまな機能追加をおこなっていますし、ユーザー数が多いだけでなく、使い方もユーザーによって異なり多岐にわたります。長く携わっている開発者でさえも、すべての機能を把握できているわけではないほどです。ユーザーの使い勝手はシンプルですが、中身は非常に高度で複雑なので、誰かの頭の中だけに頼っていては限界があるのです。

このため、機能改善や追加をおこなう際も、個人の直観に任せて進めるとトラブルが起きやすい。ですから、抽象レベルで論理的に影響範囲を把握したうえで、具体レベルに落とし込んで検討し、作業を進めるといったやり方を取る必要があります。

これからも「SmartDB」の利用者は増えていきますし、関わるメンバーも増えたり変わったりしていくはずです。だからこそ私たちのチームでは、「誰もがすべての詳細を把握する必要はないけれど、全体像は頭の中に持っておくべき」「自分に見えている範囲は狭いということを自覚し、設計書を作成してレビューしよう」という方針で進めています。「自分以外のメンバーにもわかるように」「将来携わる人にもわかりやすいように」と思うと、具体と抽象、特に抽象化を意識せざるをえません。

自分が見えている範囲が狭いことを自覚する（製品開発チーム内の共通認識）

新しい機能を開発すると、どうしても実装したものをそのまま具体的にすべて説明しようとしてしまうのですが、それだとものすごく長くなってしまいます。それに、開発を担当した自分の目線で表現しがちなので、ほかの人が見たときに理解しやすいとは限りません。ほかのメンバーや、別の部署の人でもわかるように伝えるには、自分以外の人の目線を想像し、抽象化することが欠かせないのです。

「抽象度を上げてみよう」「そもそもの目的は何？」

―ドリーム・アーツでは、全社員が「具体と抽象」の研修を受け、日常の中で活用しているそうですが、どのような場面で役立っていると感じますか。

ドリーム・アーツの社員は、ディスカッションなどでも積極的に意見を言い合うので、議論が白熱することがとても多いんです。つい、具体的な事象をどんどん深掘りしてしまうので、時間がオーバーしてしまったり、話が前に進まなくなることも多い。
でも、そうなると必ず誰かが「少し抽象レベルを上げてみよう」「そもそも、この目的って何なんだっけ？」といった声をあげてくれます。

するとみんな、目線を変える必要性に気づき、抽象レベルを上げて考え始める。それでみんなが納得できる答えにたどり着くことが多いんです。こういうやり取りが、自然に行われています。

エンジニアや営業、デザイナーなど、異なる職種、役割の人が協力する場合は特に、具体と抽象の視点の重要性を実感します。

それぞれの具体的な仕事は「コードを書く」「お客さまとコミュニケーションする」「画面のデザインをする」……など異なります。各自、自分の仕事にこだわりがあるわけですから、全員が一つのテーブルで議論するときに具体レベルの話ばかりしていると、結局は「自分が担当する仕事がどうしたらうまくいくか」ばかりを考えて意見を出してしまうので、ぶつかってしまいます。

でも、抽象レベルの「お客さまに喜んでもらいたい」という目的は一緒なはず。途中で時々、そうした目的意識や共通認識に立ち返り、同じところに立っていることを意識しながら進めれば、異なる立場の人の視点を想像し、補いあったりして協力することができるように思います。

「具体」の視点はあくまでも自分の見え方がベースになっていますが、「抽象」を意識すると、そこから離れ、自分以外の人がどんな風に対象をとらえているかを考えるようになります。コミュニケーションに欠かせない視点だと思います。

―社内コミュニケーションや議論でも、不可欠な考え方なのですね。

はい。先日も、デザイナーと仕事をするなかで、研修で学んだことがとても役立ったと感じることがありました。

これまで製品プロモーションを中心に担当していたデザイナーが、製品開発に初めて携わることになったのです。しかも、複雑な「SmartDB」の画面設計でした。

開発チームのリーダーに、「デザイン面での課題を洗い出し、改善提案をまとめるように」と言われていたのですが、何から手をつけたらいいのかわからず困ったようで、とりあえず思いついた課題を十数個挙げていたのです。しかし、私から見ても全体像が見えず、目についたものをランダムに挙げていたために、視点に偏りも感じられました。

そこで、細谷功さんから受けたフレームワーク思考の研修を思い出し、「フレームワークを使って洗い出したらわかりやすいんじゃないか」とアドバイスしたんです。

フレームワーク思考の研修は、今年2022年の初めに受けたのですが、具体と抽象の”続編”とも”発展版”ともいえるような内容で、フレームワークを使って考えを整理することを学びました。検討すべき範囲のすべてをカバーできるような分類で全体像を描き、その分類を軸にして考えていくのですが、MECE（Mutually Exclusive, Collectively Exhaustive：抜け漏れがない）という状態の分類によるフレームワークの作り方をひたすら練習しました。

フレームワーク思考研修で学ぶMECEとは

「目についた課題、思いついた課題を挙げていく」といった、“具体”から入ると、どうしても抜け漏れが発生してMECEではなくなりますし、視点にも偏りが出ます。ですから、まずは抽象度を上げて、「SmartDB」の利用ユーザーを「利用者」「管理者」などに分類するフレームワークを作るところから入る。それから「それぞれのユーザーごとに課題を挙げていく」という、具体に落とし込んでいくのです。

すると、課題を洗い出すときの視野が広がります。「つい利用者側の課題ばかり挙げてしまったけれど、管理者の課題はないだろうか」と視点を変える必要性に気づくことができる。抜け漏れがなくなりますし、提案をまとめたときにも、ほかの人に全体像が伝わりやすくなりました。

抜け漏れがないことに自信が持てる

―開発の仕事では、フレームワーク思考がどのように役立っていますか。

MECEを意識しながらフレームワークを使うと、抜け漏れがないことに自信を持てるのがいいですね。

新しい機能を追加したり、修正を加えたりする場合には、どこまで影響範囲があるかを考える必要があります。今までは、自分で思いついた範囲が本当にすべてなのか、見落としや漏れがないのか、自信がないままで進めることもありました。でも、こうしてフレームワークを使うと、そこに自信を持つことができます。

実際、想定していなかったところで不具合が出てしまうケースが、かなり減りました。テスターによる試験・検証に移る前、まだ修正コストが少ない早い段階で、自分で不具合を修正できることが多いです。

―フレームワーク思考は、個人での作業だけでなく、複数の人たちでディスカッションする際にも役立ちそうです。

最近は、何かディスカッションするときには、進行役の人があらかじめフレームワークを作り、それをもとに議論するのが当たり前になっています。

以前は、ブレーンストーミングというと、思いついたものを片っ端から書き出していくといったやり方が多かったのですが、自分一人だけでやるのはまだいいとしても、複数の人でやると、意見の重複が多くなったり、広がりすぎて収拾がつかなくなったりしてしまいます。

でもフレームワークがあれば、全体像を意識しながら議論できます。「この部分についてはまだ何も意見が出ていないけれど、大丈夫なのか？」と考えながら進められるので、MECEにもなります。

製品チームでのディスカッション

―ほかには、どんな場面で活用していますか。

特に、複雑で大きな機能を複数の人で協力しながら作る場合には欠かせません。まず、どんなタスクがあるのかを洗い出して分析しなくてはなりませんが、そこで抜け漏れがあったら困りますから、「画面の実装」「サーバーとの通信部分」「テスト関連」などのフレームワークに沿って進めます。それからタスクをメンバーに振り分けていく。そうするとMECEになりますし、後でマネジメントもしやすいのです。

プロジェクトマネジメントの強い味方

―こうした「具体と抽象」や「フレームワーク思考」を身に着けたことで、夏さん自身はどのように変わりましたか。

私は入社してからずっと開発の仕事をしていますが、今年から、小規模なプロジェクトのマネジメントを担当するようになりました。先ほどご説明したようなタスクの洗い出しや振り分けも、今は当たり前のようにフレームワークを活用して進めていますが、最初はどうやって進めればいいのかまったくわからず、とても不安でした。どうやってプロジェクトをまわしたらいいのか、やり方がわからなかったのです。

ちょうどそんな時に研修を受け、「フレームワーク」という強い味方を得たんです。キックオフの時、振り返りをする時、など、それぞれどんなフレームワークが使えるか調べ、試してみて、うまくいったものをどんどん使うようにしました。それを繰り返すことで、少しずつ自信が持てるようになってきました。

それから、具体と抽象の視点は、日常生活でもとても役立ちます。何かを人に説明することというのは、仕事以外でもたくさんありますし、人の話を聞いて理解しなくてはならない場面もたくさんありますから。

たとえば、家族から何か相談されている時も、その特定の困りごとについて具体的なアドバイスをしようとするだけでなく、根本的な原因までさかのぼって考えるような会話を意識するようになりました。そうすれば、「もしかしたら相手は、目の前で起きていることに腹を立てているだけでなく、そもそも疲れてストレスがたまっているのかもしれない」などと考えることができます。

普段から、「この人は、目の前の具体的な困りごとについて話しているけれど、それを解決するだけでその人の困りごとはなくなるのだろうか。そもそも、その困りごとの根本的な原因は何だろうか」と考えるようにしています。

見える範囲がどんどん広がっている

―今後の目標はありますか。

「お客さまがこんな機能を求めているようだから、それを作ろう」といった仕事ももちろん必要ではありますが、それだけではなく、具体的なユーザーの行動や言葉を自分で分析し、抽象化して「こんな機能があると、お客さまが喜ばれるのではないか」と考え、提案できるようになりたいです。

また、最初は不安でしたが、抽象化したりフレームワークを活用したりすることで、最近はプロジェクトを最初から最後までマネジメントするといった仕事もおもしろいと思うようになってきました。具体と抽象を行ったり来たりすることで、見える範囲がどんどん広がっていくのはおもしろいです。

自分が設計したツールを通じて、使う人の生活をよりよくしていきたい。そこに一歩ずつ近づいているように感じています。

インタビューに同席した金井の感想

夏が研修を受講した当初は、この思考がエンジニアの仕事に役立つのか疑問を持っていたと話していましたが、本人としては強く意識せずともいつの間にか日々の業務にこの思考が活かされているようでした。
研修の受講を終えた瞬間は「頭ではわかっている（つもり）」だけになりがちですが、製品開発チーム全体でしっかり業務に落とし込まれ、研修で得たものを「実践」していることがわかりました。
「具体と抽象」「フレームワーク」という武器を手にし、自信を持ってインタビューに答える夏を見て、「SmartDB」の開発にさらに明るい未来を感じ嬉しくなりました。

出典：2022年10月12日ドリーム・アーツ コラムより

いかがでしたか？
夏には2020年にもインタビューをおこない、当時の業務や思いについての記事を公開していましたが、マネジメントの経験や抽象化力研修等を通して視野を広げ、製品開発に生かしていっていることを感じます。エンジニアとして、そしてビジネスマンとして成長し人々の生活をよりよくしていくことに邁進している夏のインタビューのご紹介でした！