託児のある勉強会は助かる
ちょうかおり氏（以下、ちょう）： LTも後半になりました。タイトル「時短勤務ママエンジニアの、要件ヒアリング力」をはじめます。みなさんも少し疲れてきていると思うので、リラックスして聞いていただければと思います。
ちょうかおりと申します。2011年にVOYAGE GROUPという会社に新卒で入り、8年ぐらい勤めて、2019年に転職しました。ずっとPHPでコードを書いていたので、Ruby on Rails歴でいうと1年目です。3年目と6年目に産休と育休を取って、時短で働いています。
これは私の子どもたちです。今は託児スペースにいるのですが、とてもルンルンでトイレとかに走っていきました。運営スタッフのみなさん、スポンサーのみなさん、本当にありがとうございます。託児のある勉強会は、とても助かります。
今の会社では、教養としてのプログラミングを教える「TECH::CAMP」というサービスと、未経験からエンジニア転職をサポートする「TECH::EXPERT」（現「テックキャンプエンジニア転職」）という事業をやっていて、私は主に社内のシステム開発をしています。
ちなみに「実はTECH::EXPERT出身だよ」とか、「プログラミングスクール出身だよ」という人はいますか？
（会場挙手）
けっこういますね。うれしいです。ちなみに今日のような話で聞くのはどうかと思いますが、開発しているのが自社のものか受託なのかフリーランスなのか、という割合を聞きたいんですけど、「自社です」という人はどれぐらいいますか？
（会場挙手）
けっこう多いですね。「受託です」という人は？
（会場挙手）
こちらはちょっと少なめですね。では、「フリーランスです」という人は？
（会場挙手）
ありがとうございます。自社の人が大半ですね。そんなみなさんに、ちょっと刺さる話ができればうれしいなと思っています。
ちなみに社長がYouTuberなので、もし気になる方がいればYouTubeも見てみてください。
納期を守るに背景を知る
さて本題です。みなさん「納期、守れていますか？」。
ドキッとした人もいるのではないかと思います。納期前に泣きながら徹夜していませんか？ かくいう私もそうでした。もう少し進捗を増やしたいと思って終電ギリギリまでがんばったり、子どもを産んだあとも、また同じようにできると考えて、無事に自滅したり、「納期を守れない」「成果を出せていない」と落ち込んだ時期がありました。
そんな私がなんとか時短で6年目まで続けてこられたのは、私が1つのことを心掛けたからです。それは「背景を知る」ということ。
エンジニアの仕事の本質は「問題の発見と解決」
ここでみなさんに質問です。エンジニアの仕事の本質とは何だと思いますか？
依頼された納期に間に合うようにコードを書くことでしょうか？ 美しいデザインのLP（ランディングページ）を作ったりすることでしょうか？
私は違うと考えていて、エンジニアの仕事の本質は、「問題の発見と解決」ではないかと個人的に思っています。
私の好きな本『ライト、ついてますか』には、「問題とは、望まれた事柄と、認識された事柄の相違である」という言葉があります。
そう考えると、「問題とは、理想と現実とのギャップ」とも置き換えられるでしょう。では、納期とは何でしょうか？
私は、理想の期待値の1つと理解しています。
最近見たツイートで、「締め切りは相手の都合です」というのがあり、とても的を射てると思いました。
真の問題を解決するためには、依頼者の理想を正しく把握することが大切だと思っています。そこでここからは、そのための要件ヒアリングという文脈で、例を踏まえて具体的なアクションプランを解説します。
背景を知るには、「なぜ？」を聞く
背景を正しく把握する、背景を知るために必要なこと。それは「なぜ？」を聞くことです。もう少し深掘りすると、例えば誰が何のために何をしたいかを聞くことです。
少し具体的な例を挙げましょう。「日ごとの入会者数データをCSVでダウンロードしたい」という依頼がありました。
「Re:dashで出せばええやん」とか、どうやってやるかを考える前に、“なぜ”を聞いていきます。
「誰が使いますか？」「社内の運用担当者が使うんですよ」。「何に使うんですか？」「A社に月次で報告をしています」。
なるほど。そこで少し突っ込んで聞きます。「A社はこの数値を何に使っているんですかね？」。そうすると、担当者は、「さぁ？」みたいな感じなんですよ。
結局A社に確認してもらうと、なくても問題ないことが発覚しました。これは少し極端な例ですが、実際にあったことです。背景を聞かずに実際に作っても、たぶん命が短いコードだったと思います。
ヒアリングで「こうじゃなくてこうだった」を回避
2つ目の例です。「お客様からの書類の提出状況をシステムで管理したい」という依頼が社内で上がりました。
「これって誰が使うんですか？」「CSの担当者です」。
「今はどのように管理しているのですか？」「スプレッドシートで管理しています」。
「それはいつ使っていますか？」「必要書類をお伝えするときです。月次の連絡や未提出の書類回収のときに使っています」。
もう少し聞いてみましょう。
「未提出の場合はどうしていますか？」「お客様と直接話す現場担当者に、回収依頼をしています」。
「最終的には全員分の書類を回収したいということですかね？」「そうそう」。
こうして私がヒアリングした結果、お客様ごとに書類の登録・更新ができるようにし、再提出などの理由を書き込むメモ欄をつけ、さらに、未提出書類の一覧表示、現場担当者へのリマインド機能もつけたものを作りました。実際に作ってみたら当初の納期から遅れてしまったのですが、結果的に、現場の人は大満足でした。
お客様の増加にも耐えられるシステムになりました。最初の依頼を真に受けていたら、リリースしたあとに「あとこれも」みたいなことや「こうじゃなくてこうだった」みたいなことがあったと思うので、調整してよかったと思っています。
納期は信頼。要望は氷山の一角
コツ的なことをお伝えすると、納期についてもいったん聞いておくのがいいです。
これはなぜかというと、やはり信頼関係がベースだからです。期待値の調整はあとからやることにして、いったん聞いておきましょう。
背景や目的、「なぜやるんですか？」といったコミュニケーションが直球でやりづらい場合は、「いつ使っていますか？」とか「どうやっていますか？」と聞くと、「こういうシーンで使いたい」という目的が引き出しやすいのでおすすめです。
またコミュニケーションの前提として、依頼にある要望は、実は氷山の一角だということを頭に入れておくといいかもしれません。依頼者も実装するエンジニアも、意外と最終的にどのような状態がハッピーかは、見えていないことが多いです。
いかがでしょうか？ 少し要件定義のヒアリングのイメージが湧いたでしょうか？
今日、私がお伝えしたかったことは、時間というパワーで解決すること以外にも方法があるということです。
納期ドリブンで、徹夜してコードを書いて勉強してみたいなことがいい時期もあるとは思います。ただ私みたいに、子どもがいるなど、さまざまな理由で時間がない中で成果を出したいと思ったときに、「時間がないから無理だぁ」と諦めるのではなくて、こうした選択肢もあることを思い出してもらえたら幸いです。
まとめです。エンジニアの仕事の本質は、問題の発見と解決です。そのために大事な心掛けとして、背景を知ることがあると思います。
明日からできることとしては、「なぜそれやるのですか？」を聞くことです。今日の他の講演でも、「事業の知識」や「文脈」といった言葉が出てきましたが、これは「背景を知る」という点で似ていると思いながら聞かせてもらいました。
納期は理想の一要素なので、場合によっては恐れずに期待値調整をすると、そもそも作らなくてよかったり、少し伸びてもしっかりしたものを作ってほしいというコミュニケーションが取れたりするので、恐れず調整するといいと思います！
ご清聴ありがとうございました。
（会場拍手）
「念のためほしい」にはどう対応すべき？
司会者：今日の発表は、ひたすらコンテキストや背景といった言葉がキーワードとして出てきますね。それでは質問を。ちょうさんに何か聞いてみたいという方はいますか？
（会場挙手）
質問者1：「なぜ？ を5回聞きなさい。それで深掘りしていきましょう」という話をよく聞くのですが、こうした回数や深さを意識されていることはありますか？
ちょう：なるほど、いい質問ですね。コミュニケーションで、いきなり「なぜ？」と聞いていいのであれば、「なぜやっているんですか？」と、聞いてしまいます。そうではないときは、「いつ使っていますか？」「今の問題は何ですか？」といったことから、やんわりと外堀を埋めていくようにしています。
どこまでやるかという点ですが、時間がないなど、さまざまな状況がある中で、やはり自分が取り組むときに「こうしているんだ」と、コードを書くときに説明がつく状態、腹落ちして取り組める状態になるまでは聞いています。という回答で大丈夫でしょうか？
質問者1：ありがとうございます。
質問者2：要件について質問です。最初の要件定義で少し足りなくて実際に作ったものが不十分というケースもありますが、もう1つ、お客さんに「こういうのを本当に使いますか？」と聞いたときに、「念のためほしい」「今はまだ使ってないんだけど、たぶん使うようになるからほしい」と言われるケースも意外とあります。
「それって今作らなくてもよいのでは？」と思いつつも、強く言われるとつい要件として入れてしまうことがなんとなくあるのですが、こうしたケースはどのように対応していますか？
ちょう：めちゃくちゃいい質問ですね。私もそれでけっこう悩むことがあります。ヒアリングし過ぎると逆に要望を引き出し過ぎてしまうことがあると思っています。だからといって話をしないとその要望も出てこないので、いったん聞いて出すことはいいことだと思います。
と言いつつも、やはり「最初のリリースではここまででいいですか」「1回使ってみて2週間ぐらい様子を見て、問題があれば追加の依頼ください」など、「ここまではスケジュールで必ずやるけれども、そこから先についてはいったん様子を見てから再び依頼をください」というハンドリングをすることはあります。
質問者3：とてもなんか、「あるある……」というお話でした。私もそうした背景を聞くことを心掛けています。例えば「とにかくやってほしい」とか、あるいは「背景を知るために間に入っている人が強固に抑えられてしまう」など、そうしたことは多くあると思うのですが、そうなったときは、どのように対処していますか？
ちょう：すみません、質問が少しわからないです。
質問者3：背景を知るためには、さっきのお話ですと、実際に担当者に聞いたら工数ゼロでというお話だったかと思います。その間に入っている人が、強硬に例えば「とにかくやってほしいんだ」とか、そういうケースです。
ちょう：ありますね。やはり伝言ゲームになってしまうと、こちらも聞きたいことを聞けないですし、向こうも本当にそれを作ってほしいのかというのがコミュニケーションとして難しいですよね。
質問者3：はい。
ちょう：そうしたことは、とても多いと思います。そうですね。すっ飛ばせるなら、直接聞いてしまいたいというのはあります。実は、先ほどの例も、2ヶ月ぐらい、聞いてくるまで待っていました。その間は、他の仕事をしていたりするのですが（笑）。
そうですね。一番は、やはり直接話にいければよいのですが、そうできない場合は、その人にステークホルダーになってもらって、「それはやるように言われてやっているので」とか、「手戻りが発生した場合や、追加の要望が発生したりした場合はあなたが責任を取ってね」と期待値調整をして取り組みます。
司会者：それでは、ちょうさんの発表は以上になります。ありがとうございました。みなさん拍手をお願いします。
（会場拍手）
