paiza開発日誌

IT/Webエンジニア向け総合求人・学習サービス「paiza」(https://paiza.jp ギノ株式会社)の開発者が開発の事、プログラミングネタ、ITエンジニアの転職などについて書いています。

「工数一日」は「明日できる」じゃない!エンジニアと非エンジニアのギャップとは

f:id:paiza:20160524133231j:plain
Picture by ITエンジニアを目指す女子高生たちの学園ライフ4コマ漫画『ぱいじょ!』
f:id:paiza:20140916135428p:plainこんにちは、谷口です。

ディレクターやプロジェクトマネージャーといった非エンジニア職の方々は、エンジニアとコミュニケーションをとることに難しさを感じたり、考え方にギャップを感じたりしたことがある方もいらっしゃるかと思います。

「エンジニアとわかりあえない…」「エンジニアが何を考えてるのかわからない…」という方のために、エンジニアとのトラブルのもととなるやりとりや、気を付けるとよいことを考えていきますので、非エンジニアの方々の参考になればと思います。

■「どれくらいでできる?」はその場で決められるものではない

非エンジニアとエンジニアのもめごとの原因で多いのが、スケジュールに関することです。

非エンジニア「この機能どれくらいでできる?」
エンジニア「一日でできます」
非エンジニア「じゃあ明日リリースできるね!」
エンジニア「は?無理です」

というようなやりとりをしたことがある方、多いと思います。

非エンジニアの方にとっては「一日でできるって言ったのに何で無理なんだよ!」と思うかもしれませんが、エンジニアにとって「一日でできます」というのは、「明日できます」ということではありません。

これは、その機能の開発には丸一日分の業務時間が必要であるということです。言い換えると、始業時から終業時まで丸一日ほかの業務には手をつけず、その機能の開発だけを行えば一日でできる作業量であるということです。

ですので、相手が今から明日まで他の仕事の予定が全くないエンジニアであれば一日でできるかもしれませんが、会社にそんな人は、まあいないですよね。

ほとんどの人は、先々に渡って前から見積もってあった別の機能やサービス等の開発業務、打ち合わせや会議、その他日々のルーチン業務等が詰め込まれているはずです。それらを全て後回しにしてよいのであれば、一日でできるかもしれません。緊急に必要な機能の場合はそれでよいでしょう。

しかし、これまでに決まっていた仕事を予定通りにこなしながら合間で開発するのであれば、当然一日でリリースまでできるわけがありません。他の仕事とあわせて優先順位をつけるなり、次の仕様変更時に回すなどの調整が必要です。

非エンジニアの方は、ジャストアイデアで「今やってよ」と思うことが多いでしょうが、大概の開発はそんなに簡単なものではありません

■「どれくらいでできるか」を決めるには「どれくらいでできるか」を調べる時間が要る

f:id:paiza:20160524150956j:plain
そもそも、「この機能どれくらいで追加できる?」と聞かれても、ぱっと見積もれないことの方が多いです。

外側から見ると「ユーザー登録時の情報項目を追加する」というような簡単そうに見える機能追加でも、その情報を追加するデータベースや情報をもとに動作する機能と裏で紐づいていて、多くの機能に影響を与える可能性があります。機能を一つ追加するだけだとしても、本来であれば裏側でどの機能にどの部分に影響が出るか、既存の機能にどれくらい手を入れる必要があるのかといったことを調べた上でなければ正しい見積もりをとることはできません。

■仕様が決まってないとき・見積もる時間がないときは長めに見積もるしかない

繰り返しになりますが、簡単な機能追加ひとつをとっても、その場で見積もりなんでできないことがほとんどです。仕様が固まり切ってない場合なんかなおさらです。

ここで適当に「〇日でできます」と言ってしまっては、エンジニアも自分の首を絞めることになってしまいますので、ほとんどの人はリスクヘッジとして工数を多めに見積もって言うでしょう。仕様も決まってない、見積もりとる時間もないなら余計にそうです。

非エンジニアには「え?そんなにかかるの?」と思われがちですが、必要なリスクヘッジです

■「前はもっと早くできたじゃん」は禁句

f:id:paiza:20160524151612j:plain
上記のように、エンジニアは仕様が固まってないとか見積もるための調査をする時間がないせいで、リスクヘッジとして長く見積もらざるを得ないことがよくあります。

例えば最初に「5日かかる」と見積もっておいた機能を、2日で完成させることができたとします。

これはエンジニアにとっては喜ばしいことなので、エンジニアは「あ~よかった~!長めで5日見積もっといたけど2日でできた~!」と思います。

対して、非エンジニアは「あいつは2日でできることを5日で見積もりやがった…」と思う。思う人がいる!いるでしょ!で、そういう人は次にまた機能追加があったときに「前回2日でできたじゃん!だから今回の機能追加は2日で!」みたいなことを言います。

前の機能が2日でできたからといって、似たように見える追加機能も2日でできるとは限らないわけですが、ここで「前は2日でできたから」という理由だけでスケジュールを縮めてくる人は、大体が他の部分への影響等を考慮していません。

これが続いてしまうと、エンジニアに「理不尽…」「転職しよ…」と思われてしまっても仕方ないですし、実際にこうした理由で転職を決意してpaizaに登録した…というエンジニアの方も結構いらっしゃいます。

ITプログラマー・エンジニア転職のpaiza

■エンジニアと仕事する非エンジニアは何を気にするべきか

f:id:paiza:20160524155252j:plain

◆目的を説明・共有する

機能追加や変更に関しては、「この操作におけるユーザーの面倒を軽減させるため」とか「競合サービスにこういう機能がついたのでその上位版にしたい」など、理由や目的が必ずあるかと思います。

これを些細なことでも一機能ごとに共有しておくことがとても重要です。「ユーザー登録の途中で離脱してしまう人がこれだけいるので、登録を簡単にしてユーザーを増やすために、ここの項目とここの項目をこう変更したい」とか。

非エンジニア(以下「非」)「Aの機能にBの機能を追加できますか?」
エンジニア(以下「エ」)「できます」
非「Bから来たデータはCから来るデータとひもづけて保存を…」
エ「それは無理」
非(エンジニアの技術的知見を借りたいのに何でそんな端的な返答しかくれないんだよ~できるけどどれぐらい大変とか、無理なことは何で無理とか、別のこういうやり方があるとかも教えてよ~)
エ(聞かれたことには答えてますが…)

というようなやりとりもよくあるかと思いますが……そもそも何が目的でそういう仕様にしたいのかがわからないと、エンジニアも聞かれたこと・言われたこと以上にどう考えたらいいか、どう答えたらいいかがわからなくなってしまいます。ですので、この場合は「このページに来たユーザーのこういう面倒を軽減させるためにAの機能にBの機能を追加したいんですができますか?」というところも踏まえて聞くようにした方が、エンジニア側も「だったらAにBを追加するのは厳しいけど、こういうアプローチもありますよ」というような提案をしやすいと思います。

◆全部じゃなくてもいいから機能に関して理解する

「こんな簡単な機能すぐに追加できるっしょ」と思ってる人は、まあ、ほとんどが内部機能等について詳しく理解していないかと思います。

非エンジニアの方は、「だってエンジニアじゃないし!技術的なことわかんないもん!」と思うかもしれません。しかし前述の例のように、外からはユーザー登録画面にテキストボックス一つを追加するだけに見えても、内部機能からしたらデータベースを大きく作り変えないと追加できないとか、他の連係機能にも影響が及ぶとか、そういうことはものすごく多いわけです。

この影響範囲を知っていれば、「簡単な機能だからすぐに追加できる」とは思えないですよね。

もちろん非エンジニアの人が全てを把握する必要はないにしても、この例だったらデータベースのテーブルにどういう項目があるか知っておくとか、どの機能とどの項目が紐づいているか把握しておくとか、ざっくりとでもいいので理解しておくだけでも、エンジニアとの仕事をスムーズに進めていくことができると思います。

◆毎回毎回ギリギリなスケジュールにしない(なるべく)

f:id:paiza:20160524184402j:plain
スケジュールを決める際はまず間違いなくもめるかと思います。

優先順位をつけるなり、無理そうな機能は次回に回すなり、他の業務を削ったり後に回すなり、いろいろ検討した上で、それでも現実的に無理そうなにおいのするスケジュールを決行しないといけないこともあるかと思います。

そういうときに無理めなスケジュールを飲んでもらうためには、毎回毎回キッツキツのスケジュールにしないこと、なるべく普段は調整して余裕あるスケジュールを組むようにすることが必要です。

「いつもいつも無理なスケジュールでやれって言われる!もう無理!辞めたい!」と思われてしまうよりは、「このひと普段は調整してくれるのに、今回は無理ってことはよっぽどやばいんだな…」と思ってもらった方がお互い良いですよね。

また、普段のコミュニケーションが少ないとスケジュールでもめる確率も上がるので、普段から細かい情報や決定事項を共有しておくことが重要です。

◆(多分)別に怒ってないので怖がらなくてもいい(はず)

f:id:paiza:20160524175938j:plain
エンジニアがよく「緊急時以外はチャットで話しかけるようにしてください」とか言ってるのを見ると「え、こわ…」と思うかもしれませんが、エンジニアの人は他意なく「集中してコード書いたり読んだりしてるときが多いのに、直接話しかける意味とは?」と思っているだけです。

同期・非同期コミュニケーションを問わず、言葉や文面が端的で「怒ってんのかな?」と思うこともあるかもしれませんが、別に失礼なこととか無理なこと言ってなければ怒ってないです(多分)。

コミュニケーションが端的な相手でも、ひるまずコミュニケーション(ここで言うコミュニケーションとは世間話とかいうよりは打ち合わせや情報共有におけるコミュニケーションです)を怠らないようにすることが簡単そうに見えて一番大事なことかもしれないです。

■まとめ

エンジニアはどこをどう作るかを集中して考える仕事ですが、ディレクターは常に広くチーム全体を見渡さねばならず、それぞれのポジションで違うことを気にしているため、ギャップが生じがちです。しかし、双方がチームとして目指すゴール地点は同じなはずです。

チームでのサービスやシステムの開発をスムーズに進めるためには、上記のようなことをちょっと気にかけてもらうといいかもしれません。


ちょいちょい出てきた画像の漫画はこちら
paiza.jp




paizaではITエンジニアとしてのスキルレベル測定(9言語に対応)や、プログラミング問題による学習コンテンツ(paiza Learning)を提供(こちらは21言語に対応)しています。テストの結果によりS,A,B,C,D,Eの6段階でランクが分かります。自分のプログラミングスキルを客観的に知りたいという方は是非チャレンジしてみてください。

http://paiza.jp


プログラミング入門講座|paizaラーニング

PHP入門編Ruby入門編Python入門編Java入門編JavaScript入門編C言語入門編C#入門編アルゴリズム入門編