まえがき
非IT企業で社内SEをやっている人です。
私が入社して1ヶ月後にケガで長期入院してしまった上司の代わりに、社員から「こういうシステムって作れますか？」「このツールの設定がわかんないから教えて〜」みたいな相談を受ける窓口となって、要件定義的なことしてきました。
最近この役割を後輩に譲ることにしたので、おもに自分が失敗してきた経験をもとに社内SEが非エンジニアから相談や依頼を受けたときに意識したいことをまとめてみました。
後輩だけでなくこの記事を読んだ人にも役立てていただけると幸いです。
目次
日本語でちゃんとコミュニケーションをとる
日本語も立派なエンジニアリングスキルの1つです。
「スキルアップしたいです！」っていうエンジニアには「まず日本語の使い方を覚えろ」と勧めたいぐらい大事だと思っています。
文法的に正しい表現を学べとか、よくコミュ力と呼ばれるような「他人とたくさんおしゃべりして仲良くなる能力」1を養えと言いたいわけではありません。
ここで言いたいのは、以下の2つの目的を達成するためのコミュニケーションをとるということだけです。
- 相手が言っていることを正しく理解する
- 自分の考えを正しく相手に理解してもらう
具体的なコツはたくさんあると思いますが、日本語が苦手な私が気をつけているポイントを2つだけ紹介します。
IT用語の使用を避ける
エンジニアでない人の大半は技術に興味がありません。
彼らも自分が関心を持つ領域でおおいに価値を発揮してくれているので責める意図はありませんが、IT用語を想像以上に知らないし知ろうともしないので、IT用語は極力つかわないほうが良いと思います。
相手に専門用語を使われる立場になったときのことを考えると分かりやすいので、簡単な例を用意しました。
例
**窓の「サッシ」**って具体的にどの部分だかご存知ですか？
解説はこちらです。
普通だったらこれを読んで
「こんなの一回じゃ覚えられないし覚える意欲も沸かないから、窓の相談をするたびに要点だけ専門家に説明してもらえればいいや…」
って思うはずです。
それなのに「サッシのことも知らないのかよ〜」みたいな態度されたらまずムカつくし話を進めるのも大変じゃありませんか？
窓の修理をしてほしくて専門家に頼んだのであればサッシの定義はどうでもよくて、ただ自分の伝えたとおりに窓が直っていればそれでいいわけです。
サッシの説明をしてほしいと思えるのは
「サッシの修理ってこんなにお高いんですか！？どういう理屈なのか順を追って説明してくださいよ
」
みたいなときくらいですかね。
(例おわり)
このように、相手が理解してくれるかどうか分からない説明を試みてお互い消耗するより、相手が理解できるように言葉を選んで説明するほうが生産的ですね。
ちなみに事前に調べてきてくれてるのか知ったかぶりたいだけなのか、IT用語を使って相談してくる人もいますが、用語を間違えて理解してたりしててなんだか話が噛み合ってない感じになることが多い印象があります。
そういう雰囲気を感じたら、用語を平易な日本語に置き換えてみると良いかもしれません。
一通りの解釈しかありえない文章をめざす
特にテキストでのやりとりの際にめっちゃ気をつけるポイントです。
文法的に複数の解釈が考えられる文章を使っていると齟齬が起きやすくなりますし、そうでなくても相手にストレスを与えることになります。
こういう文章は割と簡単に紛れ込んでしまうものなので、私は送信前に読み返して確認する2ように意識しています。
例
システムAでメールを送信するユーザーをすべて抽出する
システムAで送信するのかシステムAで抽出するのかはっきりしません。
ユーザーがメールの送信元なのか送信先なのかもはっきりしません。
大抵の場合は前後の文脈などから判断できますが、読み解かないといけない感じがちょっと面倒ですね。
語順を並び替えるとか、「で」のようなあいまいな助詞を他のものにしたりするといった工夫をしましょう。
改善例
通知メールの送信先ユーザーを、システムAを使ってすべて抽出する
このほか要件定義で使われがちな「条件」について話すときには意図しない解釈が生まれやすいです。
以下に当てはまる文章はエンジニアではない人が書きがちなので、見かけたらちゃんと相手に確認をとりましょう。
- ANDとORがあいまいになっている
- 必要条件とか十分条件が区別されていない
技術のことはいったん忘れる
技術に関する相談であっても業務的な背景があるはずです。
「ツールの設定を教えて〜」と頼んでくる人の目的はツールに習熟することではないし、「こんなシステム作れる？」と聞いてくる人はシステムの仕様や使われている技術に直接的に価値を感じるわけではありません(興味がある人もいますがたぶん少数派です)。
基本的に相談者が本当に求めているのは業務レベルの問題を解決することです。
でも相談者3は自分が求めていることをなかなか話してくれません。
なぜなら、業務レベルの問題は何なのか相談者もよく分かっていないからです。
したがって、まずはたくさんヒアリングして回答を整理しながら業務レベルの問題とかいうやつを明らかにする必要があります。
話を聞き出すための質問の例
私はこんな質問をすることで相談者に回答を強要しています
- 現状はどういう運用なんですか？
- この技術的問題が解決すると何が嬉しいですか？
- (以前から抱えていた疑問・問題なら)なぜ今のタイミングで相談しに来たんですか？
- そのやり方で解決したいと思ったのは何か理由があるんですか？
詳細を話してもらうと以下のようなメリットも生まれてハッピーです。
- 現実的な解決方法を考えやすくなる
- 解決したらどれほどの価値を産むかがわかる
- どれくらいの工数に抑えられればシステム化する意義があるかがわかる
さらに、相談を受けるたびにこういう質問をするようにしていると自然と相談者も内容を整理しておいてくれるようになり、いつのまにか相談者も要件定義スキルを身につけてしまっていることに気付かされます。すてき！
言われたとおりにやらない
もちろん**「言われたことに反抗しろ！」って意味ではありません**。
相談者に言われたとおりに実行する前に本当に言われたとおりにやるのが最善なのかを考えて、より良い方針を発見したらそれを提案するという意味です。
機械的に質問に答えるだけの人になってGoogle検索窓と同等の扱いを受けるよりは、相談者が本当に求めている答え(どうすれば業務的な問題が解決するか)を探したいですね。
システムを作ってほしいっていう依頼だったら、まずシステム化せずに解決するとしたらどういう案があるのかを考えてみると良いアイデアが出てきたりします。
業務フローをちょっと変えるだけで解決したり、自分で開発しなくてもZapierみたいなサービス連携を使えば十分だったりするパターンもよくあります。
プログラミングせずに解決するなら早いし安いし最高じゃないですか？
「納期」についてもまったく同じだと思っています。
与えられた納期をただ受け入れるのではなく、すべての案件について会社に与える利益を比較した上で優先度を決めてこちらから納期を提案することが重要だと思います。4
ユーザーシナリオを書く
実際に何らかのシステムを作ることにしたときのお話です。
システム導入後に想定される新しい業務フローについて、ユーザーの心理・動作やシステムの応答などを時系列に沿ってまとめたものをユーザーシナリオと呼んでいます。
私はこの記事を参考にテキストベースでユーザーシナリオを作成しています。
ユーザーシナリオを書くと「システムを導入すると実はユーザーの手間が増えてしまう」「用意するつもりだった機能が実は役に立たない」みたいな業務的な観点からの欠陥を検出できる可能性が高まり、本質的な業務改善に繋がるシステムとしての品質が向上します。
例
ユーザーシナリオを作成するときは、システムを使う部分だけではなく業務フロー全体について書くことが重要です。
これを疎かにした私の失敗例を紹介します。
私の会社ではスケジュール管理にとあるカレンダーアプリを使っているのですが、
「営業活動の改善のため、特定の種別の予定をデータ化して分析できるようにしたいよ〜」
という要望があがりました。
そこで私は(いろんな考察の結果)、
「フォームを送信するとカレンダーアプリと集計用データベースにそれぞれ反映される画期的なWeb画面」
を開発しましたが、これを導入した結果、まったく使ってもらえませんでした
直接的な原因は
- Web画面を使うより、もともとのカレンダーアプリでそのまま予定を登録するほうが業務の流れ的に自然だった
- データ化することの有用性を社員に心の底から理解してもらえてなかった
つまり社員にとっては以前より不便になったくせにメリットのない変更になっていたことです。
根本的には、システム化する部分を気にするあまり業務全体における社員の心理を考察していなかったのが失敗の原因だと思っています。
「毎日カレンダーアプリを開く習慣のある社員が別のWeb画面にアクセスするときって面倒くささがあるよな〜」
「背景の説明なくこのWeb画面の利用を促された社員はなんでこれを使う必要があるか分からないだろうな〜」
といった考えを巡らせていれば、もっと直接的に利便性を高めるシステムにするか、システム化する前にデータ化を習慣付けてその価値を認知してもらうかする必要があると気付けていたはずです。
あとがき
次回は上司のお見舞いに行くときの心得の予定です