エンジニアと初めて仕事をした時の話と、ドラえもんが好きな話 -Relive-
この記事はユアマイスターアドベントカレンダーDAY21の記事です。
https://qiita.com/advent-calendar/2018/yourmystar
せっかくの開発メンバーとのセッション企画なのでいつもと違う開発に関わる話でいきたい思います。
僕が初めてエンジニアと仕事をしてから
今まで学んだことを簡単に書きたいと思います。
あ、
もしエンジニアの方が読んでたら
こちらも前回書いた背伸びブログなので合わせて読んでいただけると嬉しいです。
https://yourmystar-engineer.hatenablog.jp/entry/2018/11/14/080000
僕が初めてエンジニアさんと仕事したのはかれこれ５年くらい前でした。
自分のチームの数字をもっとわかりやすく知りたい。
「ダッシュボードでレポートを管理したい」
そう思って、どうしたら良いか聞いたら
「それは開発案件だよ」と初めてエンジニアと働くという扉を案内されました。
ここで先にお伝えしておきたいのは、
プログラミングがわからない人が、エンジニアと仕事をするというのは、
英語さえわからない人が、フランスの旅行先の飲食店で食べたいものをオーダーするくらい緊張するものです。
簡単にいうと、やり方がわからないんです。
何を聞けばいいかさえもわからない。
そして、役職なんかついていようもんなら、
できてる感じの自分でいないといけないという恐ろしいトラップが用意されています。
このトラップは恐ろしく、
やり方わかんないくせに、
背伸びしないといけないから、
やり方を学ぶことができないんです。
本当に恐ろしいです。
その初めての開発案件と呼ばれる仕事は、
1ヶ月くらい準備して、
1ヶ月くらい開発してもらって無事終了しました。
そして、僕がそのリリースされたダッシュボードの画面を見たのは、おそらく２回くらいです。
いろんなところで開発することの難しさや、
エンジニアとビジネスのコミュニケーションの問題はあると思いますが、
まさに僕のそれは、
最低の仕事を自分が原因で作り出したそんな体験でした。
当たり前のことを話すと、
何かを作るときに「目的」と「課題」と「解決策」が必要だというのは今なら少しだけわかります。
そんなこともわかってない僕が、
フランスの飲食店でオーダーすると、
メインを頼んだつもりがデザートがくるなんてことが起こるのは必然です。
そしてまた少し月日が経って、
自分のアイデアを実現したい仕事ができたので、
開発案件という扉を開ける機会に出会うわけです。
今回は大きなプロジェクトになるのですが、
失敗したことしかないので構えて挑みました。
結果から言うとそこから２年間ずっと、
開発を続けより良いサービスを作っていく体験ができました。
そのカギとなったのは「要件定義」という考え方でした。
まず前提として営業しかやったことない人に
「要件定義」という考え方をすでに持ってると思ってもらっては困ります。
(営業しかやってないのに要件定義の考え方がわかる方もしいたらごめんなさい)
開発チームのプロデューサーという役割の人と
毎日30分のMTGをして要件を定義していきました。
（また前提で申し訳ないですが、営業しかやったことない人が開発のプロデューサーがどんな役割かなんて知ってると思ってもらっても困ります。）
そのプロデューサーは、
毎日僕に問いを投げかけてくれました。
「なんでこれをやりたいんですか？」
「これを実現したら誰が喜ぶんですか？」
「こことここは関係性でいうとどういう関係性だと考えてますか？」
「それって…」
問いを投げかけられ続ける3ヶ月間です。
しかもほぼ毎日です。
やりたいと言ったことに対して、
問いをもらうことで自分の中にも疑問が生まれ、
やりたいと言ったことが体系化され、
自分の中の「なんとなく」がどんどん整理されていきました。
気づいてなかったこともたくさん出てきて、
そこをまた考える。
その繰り返し。
本当にやりたいことが、
まっすぐに、あらわになっていく体験でした。
「目的」「課題」「解決策」
思いつきの解決策を、
目的や課題を明確にする。
それによって、目的に沿った高い効果を発揮できて、
実現可能な解決策に研ぎ澄ましていくこと。
これを「要件定義」と僕は呼ぶのだとそこで学びました。
-------------------------------------------------
「要件定義」とは、そのソフトウェアやシステムに必要な機能や性能を明らかにしてゆく作業のこと。IT関係の開発では「上流工程」と呼ばれている作業・工程の一部にあたり、実際の具体的な開発作業（プログラミング言語を使ったコーディング作業など）や実装作業を始める前に行う作業のひとつ
-------------------------------------------------
Wikipediaはいつもだいたい正しいことを言ってますが、体験しないとここに書いてある言葉の本当の意味なんかわかるわけがないです(笑)
このプロジェクトを進めていく中で、
エンジニアの人は使ってくれる人にもっともっと喜ばれるものを作りたいと思っていました。
それはとてもとてもピュアな想いでした。
使ってくれる人と対峙している僕よりも、もっともっと。
だからこそいいものが作り上げれたと今でも思っています。
ついで話になりますが、
僕が今レポート化をするときに簡単にダッシュボードを開発させたがりません。
自分でスプレッドシートで最低数ヶ月は運用して、そのオペレーションの効率化をはかるフェーズで開発案件にしたがるのは、過去のその失敗からくる教訓です。
「使うもの作らなきゃ」です。
多くの人は、エンジニアは「ドラえもん」だと思ってるのが現実で、
「困ったー。どうにかしてー。」と言えばなんか勝手に解決してくれる。
そんな便利な存在だと思ってるのだと思います。
のび太は「目的」も「課題」も意外にも明確にドラえもんに伝えています。
そして何より二人は常に対話して、ものすごい信頼関係が成り立っています。
ここが抜けると「ドラえもん」ではないので
「四次元ポケット」を利用してやろうとしているだけなんだ
と最近になって気づきました。
子供の頃にドラえもんばかり見きすぎてこんな例えですが、
のび太はワクワクすることをみんなと一緒に楽しみたいから「ドラえもん」は楽しいんです。
エンジニア＝ドラえもん
ではないんです。
そしてさらに一周回って、
僕のできないことができるエンジニアは、
やっぱり僕にとっての「ドラえもん」なんです。
おそらく僕はメガネこそかけてないですが、
ワクワクしたがりで、課題もたくさん。
でも僕が一番似てるのはやっぱりジャイアンなので、傲慢にならず、映画版のジャイアンのように勇敢で男らしい活躍を狙って頑張ります。
僕だって頑張る男なので、エンジニアに限らず、誰かのできないことを補えることだってあるし、目的を一緒に持てれば必ず解決に貢献できると思ってるんです。
その一緒に解決しようと思って取り組むことこそが「ドラえもん」という言葉なのだと思います。
僕のできないができるたくさんの仲間と仕事という冒険を楽しんでいます。
いつも読んでいただき、ありがとうございました。
高山武佐士(38)
ユアマイスター株式会社 取締役事業部長 兼 まかない担当 兼 ジャイアン役希望
ドラえもんが好き。特に好きなのは「ドラえもん のび太の宇宙小戦争（リトルスターウォーズ）」 映画版のジャイアンファンにも関わらず、この映画はスネ夫の大活躍と、武田鉄矢の歌が好きなのが理由。今朝、弊社CTOに「“まかない担当”ってググったら俺の記事が7位にいる！」って自慢したら、「それブログの編集後記に書く気でしょ」と言われたので書くことにしました。