Picture by ITエンジニアを目指す女子高生たちの学園ライフ4コマ漫画『ぱいじょ！』
こんにちは、谷口です。
ディレクターやプロジェクトマネージャーといった非エンジニア職の方々は、エンジニアとコミュニケーションをとることに難しさを感じたり、考え方にギャップを感じたりしたことがある方もいらっしゃるかと思います。
「エンジニアとわかりあえない…」「エンジニアが何を考えてるのかわからない…」という方のために、エンジニアとのトラブルのもととなるやりとりや、気を付けるとよいことを考えていきますので、非エンジニアの方々の参考になればと思います。
■「どれくらいでできる？」はその場で決められるものではない
非エンジニアとエンジニアのもめごとの原因で多いのが、スケジュールに関することです。
非エンジニア「この機能どれくらいでできる？」
エンジニア「一日でできます」
非エンジニア「じゃあ明日リリースできるね！」
エンジニア「は？無理です」
というようなやりとりをしたことがある方、多いと思います。
非エンジニアの方にとっては「一日でできるって言ったのに何で無理なんだよ！」と思うかもしれませんが、エンジニアにとって「一日でできます」というのは、「明日できます」ということではありません。
これは、その機能の開発には丸一日分の業務時間が必要であるということです。言い換えると、始業時から終業時まで丸一日ほかの業務には手をつけず、その機能の開発だけを行えば一日でできる作業量であるということです。
ですので、相手が今から明日まで他の仕事の予定が全くないエンジニアであれば一日でできるかもしれませんが、会社にそんな人は、まあいないですよね。
ほとんどの人は、先々に渡って前から見積もってあった別の機能やサービス等の開発業務、打ち合わせや会議、その他日々のルーチン業務等が詰め込まれているはずです。それらを全て後回しにしてよいのであれば、一日でできるかもしれません。緊急に必要な機能の場合はそれでよいでしょう。
しかし、これまでに決まっていた仕事を予定通りにこなしながら合間で開発するのであれば、当然一日でリリースまでできるわけがありません。他の仕事とあわせて優先順位をつけるなり、次の仕様変更時に回すなどの調整が必要です。
非エンジニアの方は、ジャストアイデアで「今やってよ」と思うことが多いでしょうが、大概の開発はそんなに簡単なものではありません。
■「どれくらいでできるか」を決めるには「どれくらいでできるか」を調べる時間が要る
そもそも、「この機能どれくらいで追加できる？」と聞かれても、ぱっと見積もれないことの方が多いです。
外側から見ると「ユーザー登録時の情報項目を追加する」というような簡単そうに見える機能追加でも、その情報を追加するデータベースや情報をもとに動作する機能と裏で紐づいていて、多くの機能に影響を与える可能性があります。機能を一つ追加するだけだとしても、本来であれば裏側でどの機能にどの部分に影響が出るか、既存の機能にどれくらい手を入れる必要があるのかといったことを調べた上でなければ正しい見積もりをとることはできません。
■仕様が決まってないとき・見積もる時間がないときは長めに見積もるしかない
繰り返しになりますが、簡単な機能追加ひとつをとっても、その場で見積もりなんでできないことがほとんどです。仕様が固まり切ってない場合なんかなおさらです。
ここで適当に「〇日でできます」と言ってしまっては、エンジニアも自分の首を絞めることになってしまいますので、ほとんどの人はリスクヘッジとして工数を多めに見積もって言うでしょう。仕様も決まってない、見積もりとる時間もないなら余計にそうです。
非エンジニアには「え？そんなにかかるの？」と思われがちですが、必要なリスクヘッジです。
■「前はもっと早くできたじゃん」は禁句
上記のように、エンジニアは仕様が固まってないとか見積もるための調査をする時間がないせいで、リスクヘッジとして長く見積もらざるを得ないことがよくあります。
例えば最初に「5日かかる」と見積もっておいた機能を、2日で完成させることができたとします。
これはエンジニアにとっては喜ばしいことなので、エンジニアは「あ～よかった～！長めで5日見積もっといたけど2日でできた～！」と思います。
対して、非エンジニアは「あいつは2日でできることを5日で見積もりやがった…」と思う。思う人がいる！いるでしょ！で、そういう人は次にまた機能追加があったときに「前回2日でできたじゃん！だから今回の機能追加は2日で！」みたいなことを言います。
前の機能が2日でできたからといって、似たように見える追加機能も2日でできるとは限らないわけですが、ここで「前は2日でできたから」という理由だけでスケジュールを縮めてくる人は、大体が他の部分への影響等を考慮していません。
これが続いてしまうと、エンジニアに「理不尽…」「転職しよ…」と思われてしまっても仕方ないですし、実際にこうした理由で転職を決意してpaizaに登録した…というエンジニアの方も結構いらっしゃいます。
■エンジニアと仕事する非エンジニアは何を気にするべきか
◆目的を説明・共有する
機能追加や変更に関しては、「この操作におけるユーザーの面倒を軽減させるため」とか「競合サービスにこういう機能がついたのでその上位版にしたい」など、理由や目的が必ずあるかと思います。
これを些細なことでも一機能ごとに共有しておくことがとても重要です。「ユーザー登録の途中で離脱してしまう人がこれだけいるので、登録を簡単にしてユーザーを増やすために、ここの項目とここの項目をこう変更したい」とか。
非エンジニア（以下「非」）「Aの機能にBの機能を追加できますか？」
エンジニア（以下「エ」）「できます」
非「Bから来たデータはCから来るデータとひもづけて保存を…」
エ「それは無理」
非（エンジニアの技術的知見を借りたいのに何でそんな端的な返答しかくれないんだよ～できるけどどれぐらい大変とか、無理なことは何で無理とか、別のこういうやり方があるとかも教えてよ～）
エ（聞かれたことには答えてますが…）
というようなやりとりもよくあるかと思いますが……そもそも何が目的でそういう仕様にしたいのかがわからないと、エンジニアも聞かれたこと・言われたこと以上にどう考えたらいいか、どう答えたらいいかがわからなくなってしまいます。ですので、この場合は「このページに来たユーザーのこういう面倒を軽減させるためにAの機能にBの機能を追加したいんですができますか？」というところも踏まえて聞くようにした方が、エンジニア側も「だったらAにBを追加するのは厳しいけど、こういうアプローチもありますよ」というような提案をしやすいと思います。
◆全部じゃなくてもいいから機能に関して理解する
「こんな簡単な機能すぐに追加できるっしょ」と思ってる人は、まあ、ほとんどが内部機能等について詳しく理解していないかと思います。
非エンジニアの方は、「だってエンジニアじゃないし！技術的なことわかんないもん！」と思うかもしれません。しかし前述の例のように、外からはユーザー登録画面にテキストボックス一つを追加するだけに見えても、内部機能からしたらデータベースを大きく作り変えないと追加できないとか、他の連係機能にも影響が及ぶとか、そういうことはものすごく多いわけです。
この影響範囲を知っていれば、「簡単な機能だからすぐに追加できる」とは思えないですよね。
もちろん非エンジニアの人が全てを把握する必要はないにしても、この例だったらデータベースのテーブルにどういう項目があるか知っておくとか、どの機能とどの項目が紐づいているか把握しておくとか、ざっくりとでもいいので理解しておくだけでも、エンジニアとの仕事をスムーズに進めていくことができると思います。
◆毎回毎回ギリギリなスケジュールにしない（なるべく）
スケジュールを決める際はまず間違いなくもめるかと思います。
優先順位をつけるなり、無理そうな機能は次回に回すなり、他の業務を削ったり後に回すなり、いろいろ検討した上で、それでも現実的に無理そうなにおいのするスケジュールを決行しないといけないこともあるかと思います。
そういうときに無理めなスケジュールを飲んでもらうためには、毎回毎回キッツキツのスケジュールにしないこと、なるべく普段は調整して余裕あるスケジュールを組むようにすることが必要です。
「いつもいつも無理なスケジュールでやれって言われる！もう無理！辞めたい！」と思われてしまうよりは、「このひと普段は調整してくれるのに、今回は無理ってことはよっぽどやばいんだな…」と思ってもらった方がお互い良いですよね。
また、普段のコミュニケーションが少ないとスケジュールでもめる確率も上がるので、普段から細かい情報や決定事項を共有しておくことが重要です。
◆（多分）別に怒ってないので怖がらなくてもいい（はず）
エンジニアがよく「緊急時以外はチャットで話しかけるようにしてください」とか言ってるのを見ると「え、こわ…」と思うかもしれませんが、エンジニアの人は他意なく「集中してコード書いたり読んだりしてるときが多いのに、直接話しかける意味とは？」と思っているだけです。
同期・非同期コミュニケーションを問わず、言葉や文面が端的で「怒ってんのかな？」と思うこともあるかもしれませんが、別に失礼なこととか無理なこと言ってなければ怒ってないです（多分）。
コミュニケーションが端的な相手でも、ひるまずコミュニケーション（ここで言うコミュニケーションとは世間話とかいうよりは打ち合わせや情報共有におけるコミュニケーションです）を怠らないようにすることが簡単そうに見えて一番大事なことかもしれないです。
■まとめ
エンジニアはどこをどう作るかを集中して考える仕事ですが、ディレクターは常に広くチーム全体を見渡さねばならず、それぞれのポジションで違うことを気にしているため、ギャップが生じがちです。しかし、双方がチームとして目指すゴール地点は同じなはずです。
チームでのサービスやシステムの開発をスムーズに進めるためには、上記のようなことをちょっと気にかけてもらうといいかもしれません。
ちょいちょい出てきた画像の漫画はこちら
paizaは、技術を追い続けることが仕事につながり、スキルのある人がきちんと評価される場を作ることで、日本のITエンジニアの地位向上を目指したいと考えています。
「paiza転職」は、自分のプログラミング力が他社で通用するか（こっそり）腕試しができる、IT／Webエンジニアのための転職サービスです。プログラミングスキルチェック（コーディングのテスト）を受けて、スコアが一定基準を超えれば、書類選考なしで複数の会社へ応募ができます。
まずはスキルチェックだけ、という使い方もできます。すぐには転職を考えていない方でも、自分のプログラミングスキルを客観的に知ることができますので、興味がある方はぜひ一度ご覧ください。
また、paiza転職をご利用いただいている企業の人事担当や、paiza転職を使って転職を成功した方々へのインタビューもございます。こちらもぜひチェックしてみてください。
詳しくはこちら
