鍋島 理人@Innerstudio

Software is eating the world

• 非エンジニアにとってのDXとはどういうことか
  • テクノロジーがビジネスをドライブするならエンジニアとの関わり合いは避けて通れない

エンジニアとの軋轢あるある

• 双方の不平不満
  • 例）
    • 企画担当「言われたことをやってくれない」
    • エンジニア「指示が曖昧で根拠が不明瞭」・・・
      • ※実際のセッションではもう少し精密な例をいくつか出したいと思います
• 原因として考えられるもの
  • 言語化の不足/語彙の違い
  • 想像力の不足/お互いの仕事への不理解
  • ツールの違い/Github or Backlog?/Slack or メール?
• 必ずしもエンジニアが大正義、という話でもない
  • 例えば、「ぱぱっとコード書いて機能追加して」がそう簡単ではないように、リアルな人や物を動かすのはコードほどクイックには行かない場合も多い

私は何をやってきたのか

• コミュニティ運営・リレーション(LINEDC, デブサミ(2015-2017)など)
• ヌーラボ　社内の開発者と顧客をつなぐ立場（カスタマーサクセスという肩書きでした）
• コミュニティによるイベントプラットフォーム開発に事業側から参加（CloudNativeDays)
• エンジニアと非エンジニアの橋渡し

私が心がけているポイント

• 非エンジニア/エンジニアの共通語彙の確立
  • テクノロジーの言葉<>お金・人・モノの言葉
• 双方の「ペインポイント」の橋渡し
  • 「ここは実装コストがものすごく掛かるから、代替手段を探そう」「操作が煩雑なので、この点を改善することで、ミスを大幅に減らすことができる」など
    • ※もう少し精密な例を挙げたいと思います
• できるだけツールを揃える
  • 例えばエンジニアがSlack / Githubベースなら、そこにできるだけ合わせる
  • 情報の分断が起きないように
• などなど

(以下、時間があれば、許可が取れれば)

• 実際にCloudNative Daysでやっていたこと
  • システム：イベントプラットフォーム（参加者管理〜動画配信〜アーカイブ提供まで）
  • Github Issuesベースでのタスク依頼
  • 主要ドキュメントのリポジトリ管理
  • などなど
• 実際やってみて
  • もちろんうまくいってない点も多々あるが、今後につながる点も

どうしたらできるようになるのか

• 私の場合
  • エンジニアの世界観に飛び込む
    • 分からないなりに技術を試したり、理解しようと試みたり
    • たまにプログラミングしてみたり・・・
    • 仕事の役には立たないけれど、エンジニアが何をしているのか想像力を養うのに役立つ
• コミュニティに参加してみる
  • 自分の関心領域とエンジニアの課題が重なる箇所
    • DevRel Japanもその一つ
  • エンジニアと話す、仲良くなる
• 実際のところ、誰もができる訳ではないと思う。しかし橋渡しできる人は限られているかもしれない。しかし、そのスキルは今後ますます重要になっていくと考える