Tech Do Advent Calendar、12月17日を担当するせりざわです。
メディアドゥでエンジニアをしていて、今三年目が終わるところです。
今日は架空のプロジェクトを題材に、一年目エンジニアがやりがちな失敗の話をしていきます。
一年目の半ば、あなたはこのプロジェクトに参加する。
研修の一貫か、メンターの気まぐれか、あなたは以下のプロジェクトにOJTとして参加することとなった。
プロジェクト概要
メンバー: エンジニア数名(新人2名ほど)
要求事項: 現在、 Excel + 紙で行われている、「取引先の申請/承認フロー」を電子化すること。
依頼元: 同じ会社の経理部門
技術仕様: 自由に決めてください。
どうやら、現在の「取引申請書」は、Excelを印刷したものらしい。
あなたたちは、経理から参考資料として以下の紙をもらった。
| 申請者氏名 | 炎上マン |
|---|---|
| 申請会社名 | 炎上社 |
| TEL: 01-xxxx-xxxx | FAX: 02-yyyy-yyyy |
| 会社規模: 1000人 | 資本金: 5000万円 |
| 取引理由 | 新規案件の開発協力につき |
| 取引可否 | ---承認印を捺す5つのスペース--- |
| その他 |
研修目的のため、あなたが中心となって「要件定義」をするよう求められた。
「この紙をシステム化すればいいんですか？」→ 
新人にありがちな間違いが、
「この紙をシステム化すればいいんですね。じゃあフロントはテーブルのレイアウトを……DBの設計は名前と取引先名を……」
と、実装の話を始めてしまうことだ。
残念だが絶対にそうではない。
上記の紙を見ただけでわからない点はいくらでもある。例えば、
- この紙は誰が書くのか？(取引先を開拓してくる営業社員？経理？役員？)
- 仮に営業社員が書いて申請するとして、その人が「全ての項目」を埋めないといけないのか？
- この場合、実は「会社規模や資本金は経理が調べてあとで書く場合もあります！」という罠が潜んでいたりする。
- 大体のシステムは「こういう場合もあります」「こういうのでもいいです」に弱い。
- 承認印が並んでいるが、これは本当に役職が低い人順に捺されるのか？
- もしかしたら「社長がとても忙しいのではんこを捺せず、先に取引開始しちゃうことがあるんですよね……。」なんて言われるかもしれない。
- その時の承認者の出社状況の都合次第で捺す順番が違うかもしれない。
- 「部長印」という捺印欄があるものの、部署の構造の関係で部長がいないかもしれない。
どうだろうか？他にも疑問が出てきた人もいるかもしれない。
ここでのポイントは、まずは下記の点を意識して、ヒアリングを進めることだ。
- この業務に関わっている人は誰か？(登場人物の見極め)
- 今回だと営業、経理、役員。
- 現在はどうやってこの業務を進めているか？
- システム化対象(取引申請書)に直接関係しない業務のことも知ることができるとなお良い。
- なぜ上記の形で業務を進めているのか？
- なぜシステム化が必要か？
- システム化やシステム刷新が必要な業務の担当者は、大体何かで困っている。
- 関わっている人全員にヒアリングをする。
ここで、「誰のために」「何を」「どうやって解決する」ことがわかっていると、この後の失敗もしにくいです。
「経理の人がこうしてくれって言ってたのでこういう仕様にしました！」→
これは↑の内容と関連してくる。あなたが要件をfixしようとしている中、次のようなことを言われた。
経理「この承認印のところなんですけど、□□部だけ承認印の数を一つ減らせませんか？」
はいわかりました、とは絶対に言わない。
これについても、聴くべきなのはまずは「なぜか」
結果として、経理が(現在の申請書の)承認印のスペースについて不満を持っていることがわかった。
「実はここだけ、部がなくて本部の下にくっついた組織なんですよ。
でもこの紙の規格は変わらないから、部長印のところが何も捺されてなかったり、
かと思えば現場のリーダーの印が部長でもないのに捺されていたりするんです。
それを解消・統一してほしくて、こう依頼しました。」
「それにこの印はもっとフレキシブルにしてほしいんです！
社長が忙しくて印を捺せなくて、結局申請が最後まで行かずに取引開始してたりするし、
申請書ごとにこの「承認印」をもっと自由に枠ぎめできるようにしたいです！」
さて、これでなんとか経理の人の要望の理由はわかった。
もしあなたがこの情報なしで、要件定義書の片隅になんとなく「□□部は承認印のうち『部長承認』を削る」と記入して持ち帰った場合、設計現場はそれだけで大混乱だ。
「なぜ□□部だけ？」
「他の部はそうではないのか？」
「今後そうなる場合、DBの設計を考え直さないと」
なんとなく聞いてなんとなく記載した場合、あなたは苦し紛れに**「経理の人がそう言ってたので……」**とつぶやくだろう。
これが2つ目のアンチパターンだ。
(完全に余談だが、僕は一年目のとき、当時の上司から「○○さんが言ってたからという理由で私のところに話を持ってこないで」とよく言われた。今思えばもっともだ。)
「経理の人が言ってたのでこういう仕様を入れたんですけど……」～part.2～ → 
さて、これで経理の人の要望はしっかり、理由も含めて理解できた。
「よし！じゃあ理由もわかったし設計に落とし込みましょう！」
……というのをやってはいけない場合もある！！！！
付け足された要望を考えると、↑の承認印は今どういう状態だろうか？
おさらいしてみよう。
- 部署ごとに部長、本部長、経理担当、取締役、社長の印を捺す。
- 部長の印を使わない部署もある。
- 本部長の印は絶対に必要そう。(本部に所属していない組織がないので)
- 社長の印はなしでもOKにしたい。
- 紙ごとにフレキシブルに取引を開始したいので、承認途中でも取引を開始したい！
さて、この「承認印」は本当に必要だろうか？
この状態だと、極論誰も承認しなくても取引が開始されてしまわないだろうか？
それを避けるために新しいルールを足して、「本部長と経理が確認できたらOK！」なんていう要件を足すのだろうか？
なら最初から経理の人が確認して終わり、というフローにしてしまっていいのではないだろうか？
法律や社内規定で問題ない範囲であるなら、この「承認印」を捨ててしまった方がいいこともある。
そしてそれを提案できるのは、全員の業務の進め方を聞き取って、システムとしてどうあるべきかをしっかり考え抜いている「要件定義担当」なのだ。
言われたものを作るだけでなく、時にはシステムを作る専門家の見地から**「これは捨てましょう」と提案する必要もある。**
これを怠ったり、遠慮してしまうと、どんどん要件がたされ、意味のない確認工程がたくさん混ざったいびつなシステムが出来上がってしまう。
そして結果として、「使いにくいシステム」となってしまうのです。
あとがき
実際に取引先管理システムを作ってくれと言われたときの対処法
→経理の人に「CRM システム」でググった結果URLを渡す。
明日は僕の同期のnukomaruから、 A tour of Go に関して記事が上がる……はずです！
よいクリスマスを～。