【イベントレポ】エンジニアだから、非エンジニアだからっていうのがもう言い訳かもねと思った話

クラウドワークスさん主催の
現役エンジニアに学ぶ!ビジネス系職種がエンジニアとスムーズに仕事するには? にいってきました。

■イベント概要
日時:2018年10月23日(火)20:00-21:30
場所:株式会社クラウドワークス セミナールーム
プレゼンター:佐藤 元気さん
お題:
①エンジニアと一言に言っても、どのような役割の違いがある?
②エンジニアは普段どんなことをしている?
③何か機能を追加したいとき、どのような手順でリリースまでしている?
④エンジニアが困る瞬間、悲しくなる瞬間
⑤エンジニアとスムーズに仕事するために必要なマインド、心構え
⑥エンジニアと仕事するうえで最低限もっておきたい開発に関する知識、スキル
⑦プログラミングの基礎を学ぶのにオススメの書籍やサービス

感じたこと

今回、CSでエンジニアとの連携をもっと深めたいなあと思ってたの半分、
過去エンジニアのエージェントやってたこともあり
純粋にエンジニアの志向性に興味がある半分での参加でした。
これまでなんとなく「こんな感じかなあ」でやってきたことが
そんなにズレてはなかったな、と確認できた部分と
とはいえ、「なるほど!開発サイドはそんなこと思ってたのかもなのね」
と理解が深まった(気がする)部分双方ありました。
後者は細かいtipsも多かったので後述しますが、総じて、
「エンジニアは別に同じ土俵で戦って欲しいわけじゃなくて、
ビジネス職同士と同じくコミュニケーションで解決できる問題は結構ありそう」かなと。
正直、これまで勝手に壁を感じていた部分もあるかもと反省。
エンジニアだから、非エンジニアだから、と思ってるのが既に旧いのかも。
こわくないこわくない(〇ウシカ風)

お題①エンジニアの役割の違い

■よくある志向性など
・サーバーサイド:ギークなプログラマが多い傾向。システムの仕組み作りが仕事なのでロジカルさは重要
・フロントサイド:デザイナーと近しい部分があり、サービス志向の人は分かりやすく画面が作れるフロントになりがち
・インフラ:作ったものをサーバにあげる(=デプロイというらしい)ことをしないとネット環境では動かない&動くための設定も正しくないといけないので縁の下の力持ち

※最近はフルスタック(全領域ができる)エンジニアを推奨するのが主流
(ビジネス職でいうゼネラリスト的な感じ?)
→幅広く知っているとエンジニア間のコミュニケーションコスト軽減できることが一番大きい

■技術あるある
サーバサイド:
・使える言語は1つでもいい。どの言語もできることは基本同じ。1つの言語を極めると横展開しやすい
 ↑は社内のエンジニアさんも「excel使うかスプレッドシート使うかの違い程度。言語が違うので嫌ですっていうエンジニアは…」って言ってた
・初心者はRubyがおすすめ(書いてて楽しい言語と言われてる)
・Rubyは3年前くらいがピークだった気がするがまだ日本では使用している会社が多い。最近はGo使う会社も出てきた
・言語は保守性(メンテナビリティ)やサクサク楽しく書けるか?などの基準で選ぶことが多い
・Rubyはさくさく書けるがメンテナビリティが△
・JavaやGoはさくさくは書けないが、メンテナビリティが◎(金融システムなどに使用されている)
・Pythonは日本ではメジャーではないが、海外では主流。データ分析、機械学習にかなり使える

フロントサイド:
・html・css・JavaScriptは使えるべき
・フロントサイドは複数言語を組み合わせて使うことが多い。それぞれの言語の役割が違うので知らないとまともなサイトを作れない

お題②エンジニアの普段の仕事

■エンジニアのよくある業務
・コーディング(だいたい5割くらい?)
 └評価は早い/遅いだけじゃない。設計力も大事
・コードレビュー
 └とりあえず動くものはエンジニアなら誰でも書ける。メンテナビリティ/速度パフォーマンスの点で第三者の視点は必須
 └転職する際はちゃんとコードレビューやってる会社か?は確認すべき
・設計
 └踏み込むとビジネス要件に関わる部分
 └優れたエンジニアは事業の方向性、ビジネス要件を理解し先手を打って技術のあるべきを考える
・チームビルディング
 └開発はチームプレー。1人のエンジニアが抱えている状態は適切じゃない
 └バグや課題を早期に言える真理的安全性のある組織作りは超重要

※業務のウェイトは自分の役割や強みに合わせて変化する
※インフラはコードというより設定、あと業務として深夜メンテがある場合も

■強みを活かしたキャリアパス
・技術を極める
・エンジニアのマネジメント/組織作り
・エンジニアリングがわかる事業側(プロダクトオーナー)

(参考)非エンジニアが採用でスキルを見極める方法
結論、エンジニアはエンジニアに見極めてもらうのが早い!
依頼する際は求めるものがマネジメントなのか、技術なのか、事業サイドなのか、見極めて欲しいポイントを明確に伝える

お題③機能追加の手順

■前提、価値を生まない開発はやるべきじゃない
コードの数を増やすことはサービスにとってマイナス
システムが複雑だとパフォーマンスが落ちる
■具体的な手順
1.データ分析・ユーザーインタビューなどの調査をもとにユーザーに価値提供できる仕様案を磨く
2.プロダクトバックログでの開発優先順位をきめる
3.優先順位に則り開発、テストしてリリース
※テストすごい大事。テストちゃんとやってる会社かどうかは確認すべき
※ビジネスサイドは納期が気になるのわかるが、
納期を聞かれても正直、わからないが回答。最後までどんな伏兵がいるかわからない。なので、納期を優先するならスコープを狭くする/スコープを優先するなら納期を延長するのどちらかを選択すべき。両方を同時に叶えることは無理が前提だと分かって欲しい

お題④エンジニアが困る・悲しくなる瞬間

■要は、外注扱いされること
・発注側と受託側のコミュニケーションになっている
・期限、進捗を共有するのがエンジニアの責任、役割になっている
・作る目的について深く練られていない、説明が不十分

ではその反対は
・なぜ作るのかを説明する、ビジネス・エンジニア双方で話し合う
・期限、進捗を達成するのは企画、開発双方の責任
優先度の低い仕様を削ったり、早めに仕様を詰めた方がいいところがないかなどエンジニアに相談しながら進める(任せっきりにしない)

(参考)エンジニアとビジネスの相互理解のためにできること
・ユーザーインタビューにエンジニアにも同席してもらう
・朝会にビジネス側も参加する(進捗・課題を共有する)

(参考)高速PDCAを回すために
・リリースのスピードを優先する場合、まずコアな機能に絞ってリリースする場合もある。まずは価値提供を最短ですることを重視(期限>スコープ)
・開発体制を変えるケースもある。例えば、スクラムのベロシティである程度進捗を可視化することはできる

お題⑤エンジニアと仕事する心構え

■自分の職種の強みでパフォーマンスを出すこと
・エンジニアに合わせているだけと成果が出ない(新人PMあるある)
 └自分の強みで価値を出しエンジニアを共感・納得させることで巻き込む
・前提、腹割ったコミュニケーションができていることが大事
 └表面的な事象ではなく価値観のズレが根底の課題になっている場合も
 └噛み合ってないな。。と感じたらまず腹割って話し合うとうまくいくことも多い

(参考)自分の強みで価値を出すことの具体例
CSであれば圧倒的に顧客を知っていることが強み
説明のためにはリーンキャンバスなど
マーケティングのフレームワークを使うと理解しやすいかも
ビジネスとしてユーザーに貢献できることをわかりやすく示すことが大事

お題⑥エンジニアと仕事するのに必要なスキル

■同じ土俵に立ってくれなくていい。必要なのは理解
・開発プロセスに対する理解
・見積り/期限/チームビルディングに対する考え方への理解
・webアプリケーションの全体像に関する理解
 (UI変更に対する工数負荷、apiとはなにかなど関連用語の理解)

(参考)工数がかかる開発の具体例
DB構造の変更が入るものはおおがかり 例:検索システムのカテゴリ追加
フロントの画面を軽く変えるなどは比較的簡単
ただし、そもそもシステムの構造がサグラダファミリア状態だと
簡単な変更もテストに時間がかかるなど結果的に負荷が大きい

(参考)一緒に仕事しにくい人
・聞く耳を持ってくれないひと
・エンジニア的なカルチャーに慣れていない価値観の人
→大体のことはコミュニケーションで解決できる!(心強い…!)

お題⑦おすすめ本

SCRUM BOOT CAMP THE BOOK
エンジニアと一緒にチームとして仕事をするための本(プログラミングの本ではない)
イラスト図解式 この一冊で全部わかるWeb技術の基本
アプリケーションのおおまかな全体像をつかみやすい本

この記事が参加している募集

イベントレポ

この記事が気に入ったらサポートをしてみませんか?