Developers Summit 2020 Day2(02/14 Fri)参加メモ

Developers Summit 2020 Day2(02/14 Fri)

Developers Summitとは

• 翔泳社さんのイベント。HPはこちら
• #devsumiでTwitterのハッシュタグを追ったりすると会場の雰囲気が分かったりします
• 参加したセッションのメモ
  • スライドが発表されたら、タイトルの部分から飛べるようにリンクを貼る予定です
  • 事前情報は、タイムテーブルのリンクから取得しました
  • 1日目の記事はこちら

①「ともにつくる」を実践するドメイン駆動設計

事前情報

10:00～10:45 14-B-1
成瀬 允宣[GMOインターネット]

ドメイン駆動設計はソフトウェアの利用者を含む関係者すべてが一丸となって開発するためのプラクティスで、まさに「ともにつくる」を実践する手法です。
このセッションでは、今再びソフトウェア開発の現場で盛り上がりを見せているドメイン駆動設計をキャッチアップできるようお話します。
セッションの内容は次を予定しています。

- ドメイン駆動設計とは何か
- ドメイン駆動設計がなぜ必要か
- ドメイン駆動設計の構成要素
- ドメイン駆動設計の経験談
- ドメイン駆動設計と私たちが目指すゴール

さぁ、ドメイン駆動設計を手に取って、「ともにつくる」を実践しましょう！

参加時メモ

ドメイン駆動設計はなぜ必要か

• 非ドメイン駆動設計的開発に潜む問題点
  • 「新しいシステム使いづらいね」
    • 利用者と開発者の断絶の存在」
  • 「大したこと無い修正に時間かけすぎ。あの人バグ多いよね
    • 仕様書はありますか？ないよ
    • 誰か詳しい人いますか？いないよ
    • こうして開発者は旅に出る
      • いなくなる旅、コードを探す旅
  • これらを解決するのがドメイン駆動設計

ドメイン駆動設計とは何か

• ドメインとは何か
  • 「ドメインに何が含まれるか」が重要
    • 利用者が生きる領域
  • ドメイン駆動とは何か
    • ドメインの対象領域をコードに落とし込む
      • 方法論がドメイン駆動設計
      • ドメインとコードを地続きにするためのプラクティス

ドメイン駆動設計がなぜ必要か

• ドメインとコードを地続きにするためのプラクティス

ドメイン駆動設計の構成要素

• 2つのテーマ
  • ①モデリング
    • アクセルとペダルを踏む
    • 荷物を運べる
      • 何が重要なのかはソフトウェアによって、ドメインによって変わる
    • 知識を抽象化することをモデリングという
  • ②パターン
    • モデリングしたものをコード化したものは、ドメインオブジェクトという
    • モデリングしたものをドメインオブジェクトに落とし込むのはパターンという
• ドメインの世界を知るために教えを請うべきは？ドメインの実践者。ドメインエキスパート。
  • 彼らはドメインに渦巻く知識を持っている。
    • 何が重要かについて、ソフトウェアによっての取捨選択が必要
    • 開発者とドメインエキスパートが協力してドメインを捉え直す
      • 重要なのは、開発者とドメインエキスパートがどうやって協力するのか
        • エキスパートが「運送記録を残したい」と言ったら、開発者は運送記録とは〜〜というかたちですか？と確認し、エキスパートから知らない概念をお互いに話す。技術語、固有語ではなく、ユビキタス言語を話す。いつでもどこでも利用可能な言語。
• ユビキタス言語
  • ユビキタス言語は、単語帳では無い。
  • 技術ごと固有語があった時、我々が固有語を話すというわけでは無い。
  • ドメインモデルは、開発者とエキスパートが協力してつくる
  • ユビキタス言語は、開発者が主体となって、エキスパートとともにつくる
• 境界づけられたコンテキスト(文脈)
  • ドメインと言われた時にイメージするもの
  • コンテキストで分ける
  • コンテキストマップを作る
    • チームビルディングもドメイン駆動設計の一部
  • パターンについては、『ドメイン駆動設計入門』をぜひ

ドメイン駆動設計の経験談

• 炉の話
  • 高温で処理して、焼き入れ、
    • 「焼き入れ」「焼き戻し」「焼きなまし」「焼きならし」
      • 「実は冷やし方にも種類があって」
      • エキスパートとともにつくるのが、ドメイン駆動設計

ドメイン駆動設計と私たちが目指すゴール

• 開発者だけで完結しない、というのがドメイン駆動設計の難しいところ
• 開発者、エキスパート、ステークホルダーが一丸となる必要がある
• パターンとドメインオブジェクトから。賛同者を増やすこと。チームを巻き込む。ボトムアップ。開発者からエキスパートに伝える。そこからエキスパートに
  • 『ドメイン駆動設計』はパターンをまとめた本
• 双方向。ドメインがボヤケテいることに気づくのは実装段階が多い。イテレーティブな開発がドメイン駆動設計。
• 私たちのゴールは、真に役立つモデルをつくりあげて、真に役立つソフトウェアを開発すること。

感想

• 会話の共通基盤を作る。賛同者を増やす。
• ともにつくる、のテーマにぴったりの講演だった

②職種の垣根を越えるコミュニケーションのススメ

事前情報

11:05～11:50 14-F-2
池村 和剛[ゆめみ]/吉田 理穂[ゆめみ]/小川 段[ゆめみ]/戸田 修輔[ゆめみ]

社内はもちろん、外部も巻き込んでコミュニケーションを活性化できる取り組みがあったとしたら？
ゆめみにある『委員会制度』は、会社にいるすべてのメンバーを対象に、組織を横断したタスクフォースチームを作ることができます。よくある部活動などとは違い、会社から予算が出て活動することができる制度です。
今回は、20個ほどある委員会の中でも、様々なメンバーが集う3つの委員会（「Creative Design Commitee」「Liberal Arts Lab」「mirai labs」）の代表者が、コミュニケーションが活性化していく秘密を、実体験や具体例を交えたパネルディスカッション形式で探ります。

参加時メモ

はじめに

• デザイナーが求められているものが細分化、開発者もキャッチアップするものが多いなが、重要なのはコミュニケーション
• ゆめみはガラケーからスマホへのパラダイムを経験しながら20周年を迎えた。
• 次の20年は「スマホはもはや俺の臓器」「デジタルはもはやヒトの臓器」
• 垣根を超えるメカニズム
  • コミュニケーション
  • 制度設計
  • アジャイル組織
  • デジタル

デジタル

• ワークフルライフの考え方
  • 生活の中での活動が複数のワークにつながること
• 組織もアフターデジタル
  • O2OからOMOへ。オンラインマージオフライン
• ゆめみ
  • ワークフルライフ×組織もアフターデジタル

制度設計

• 意思決定プロセス「プロリク制度」
  • 自律、分散、協調
• 委員会制度
  • 各チームと委員会がオープンかつ有機的に機能している

委員会の紹介

①

• 学ぶ
  • 見て学ぶ
  • 参加して学ぶ
    • 登壇することで、ぼんやりしたものをまとめることができる
• Designトレーニング
  • 10人で1週間で同じ画面を作る。10週間で100画面できる。
    • デザイナーの個性が見えてきた
  • 居酒屋での予約アプリとか。社内プレゼンをしたりした。
  • 合宿をしてのハッカソンを企画している
• 蓄える
  • Design databaseの構築。
    • 各案件での学びを他のプロジェクトに伝える。
    • 個人の成長をゆめみとしての成長に繋げる

②未来研究委員会

• インターネットを使わないサービスはNG
• 事業化までは考えない
• 自分がときめかないことはしない
• 遊びゴゴロスタートで構わない
• 一人でやらずに、みんなでやる
  • 挑戦することの楽しさ
  • 新たなメンバーとの交流や繋がりが増えた

③Liberal Arts Lab

• 教養の部分も変化しているのでは
• リベラルアーツ勉強会
• 起点は、内発的動機。それから、共感へ。

ディスカッション

• どのように垣根を超えたコミュニケーションをしている？
  • 普段の案件だけだと関わらないから、委員会などがあれば話すきっかけになる。
  • 雑談はどう生まれる？
    • なぜスラックなどで発信される風土がある？
      • 「否定しない」文化がある。積み上げていくか、修正していくかという方向性しかないという部分が安心する。
      • 結果責任は問われず、遂行責任は問われる
      • 集団の自律
        • イエローカード制度。メンバーと社員。
        • Bad＆New Action制度。悪いことは隠さずにみんなで考える
        • 自由な行動が不利益にならない
        • 一つのことを分担する
        • 答えはない

感想

• 「自分がときめかないことはしない」は大切で、それを全体で出来るための土台作りとして相互理解や風土醸成やチームビルディングが大切なのだろうなと思った。
• 空振り三振を恐れずにチャレンジできそうな会社で良いなと思った。

③自己組織的な開発チームを如何にして作り上げるか

事前情報

12:10～12:40 14-E-3
木利 友一[TIS]

限られた期間、不確実な状況、日進月歩で進化する多様な技術…。
これらを前にしてなお前進しなければならないのが、現在の開発チームではないでしょうか。
本セッションでは、経験したことのない業界に飛び込んだSIerのアーキテクトが、gRPC、Electron、Kubernetes、React+Redux等これまで扱ったことのない技術と日々移り変わる状況に圧倒されながらも、「自己組織的なチーム」をテーマにどのように立ち向かっているかをご紹介します。

参加時メモ

はじめに

• 技術的な話は出てこない
• 銀の弾丸も出てこない
• 学んだことや気をつけるポイントを持ち帰ってもらってともにつくっていきたい
• TIS
  • バイモーダルに対応するSIerへ
• 決済プラットフォームの新規開発
• 不空数の会社から来たエンジニアの混成チーム
• 自己組織的なチームを目指したい

そもそも自己組織化とは

• 外部からエネルギーを取り込み続ける動的な系
• 自然界の自己組織化
  • アリの最短経路発見
    • 群としてのアリは餌への最短経路を発見する
  • 東南アジアの蛍は、群として発光タイミングを同期させることができる
• 自己組織的チーム
  • とは？
    • フラット？自律的？
  • 『Elastic leadership』からの引用
  • 自己組織化のためのフェーズ
    • サバイバルモード
      • 学ぶ時間ない。残業でカバー
    • 学習モード
      • ゆとり時間あり。学ぶ時間あり
    • 自己組織化モード

経験談

• はじめはサバイバルモードだった
  • スケールしなかった。
    • 人数の増加、システムの複雑化によって雑になる判断
    • フロー効率の低下で誰かが待ちになる
    • リーダーとして、自分が把握できる範囲の箱庭をつくろうとしていた。管理職として失敗したくなかった
      • 一人が全てを把握して理解して正しくリードできるほど現実はシンプルではない
• いま
  • 指示不要。リーダーなしで動ける

どうつくったか

• チームの構造化のためには
  • 個人の行動
  • 個人間の相互作用
• 組織知が出来る過程：SECIモデル
  • 経験の共有
  • 行動による学習
  • 対話共同思考
  • 組み合わせ
  • 相互作用できる「場」が必要。個人と個人をつなぐ「場」
• 相互作用できる「場」

  • ファシリテーション

    • 人と人の間の知的相互作用を促進する働き

  • 個人の行動のモチベート

    • 個人を尊重する
      • 全員が完全に同じベクトルを持つ必要はない
      • 不安定化を歓迎する
      • それぞれの経験、考え、経緯に敬意を払う
        • いまその瞬間その人が誰よりも詳しい分野がある
        • その人だけが感じている変化がある
      • 「よさそう」「やってみよう」。チームを進む道を限定しない。
      • 個人の行動を盲目的に信じて良いのか
        • NO
          • 行動に説明責任を伴わせる
            • なんで必要なんだっけ
            • 今やらないとダメなやつ
        • 『みんなの意見は案外正しい』
          • 集合知
            • 「ベストな意思決定は意見の相違や異議から生まれる」

  • 個人間の相互作用のモチベート

    • 考えていることを自由に表現できる場をつくりだす
      • 銀の弾丸はない
      • 一般ピーターの法則
      • 信頼関係
        • フィードバックをしてくれる
          • 肯定否定共感
        • 心理的安全性
          • 人間には学ぶ力がある←→学習性無力感
    • 変化を起こす
    • 結果を振り返る
      • 小さな成功体験
    • 学習性無力感と戦う
• タックマンモデル
• エラスティックリーダーシップ

感想

• 「言われてみれば確かになあ」と思うことを、言語化して発信すること、言ってくれることは価値があると思った
• そしてその「言われてみれば確かになあ」の中に書籍や情報を適切に引用していることで、新たなものにも出会わせてもらえて良かった（例えば、Elastic leadershipを私は知らなかったため知るきっかけになった）。

④プロダクトを10年運用するチームをつくる

事前情報

13:05～13:50 14-B-4
粕谷 大輔 [はてな]

世間に認められたプロダクトは、その後長い年月をかけて運用していくことになります。その長い期間の間には、チームメンバーが入れ替わったり、上司が変わったり、アプリケーションそのもののアップデートやアーキテクチャの刷新もあったり、さまざまなことがおこります。それは新規開発の経験だけからは決して想像しえないことばかりです。
Mackerelというサーバー管理サービスが運用された5年間を例に、次の5年を見据えた「10年続くプロダクト」を維持するチームづくりについて考えていきたいと思います。

参加時メモ

変化し続ける周辺環境とシステム

• 「動いているシステムは触るな」完
  • これは昔のプロダクトの運用をうまくいかせるためのプラクティス
  • 今はそういう時代でもない
    • OSやブラウザのアップデート
    • 新たに発見される脆弱性
• システムを更新し続ける
  • CI/CDの整備
  • 監視の整備
  • DevOpsの構築

人の入れ替わりへの対処

• 本題のチームの話
• 10年間、人が入れ替わらないチームはなし
• 異動や退職など、そもそも新陳代謝も重要
• 人の入れ替わりによって失うもの
  • 掛け替えのないひび
  • プロダクト固有のスキルやドメイン知識
    • 失わないようにするために、スキルマップ、障害対応演習、式年遷宮

スキルマップ

• チームのスキルバランスの可視化
  • 「失われた」に気づける
• リスクを事前に察知できる
• チームから失われたスキルを身につける
• 学習目標の指針になる
• コツ
  • 評価に使わない
    • 心理的安全性
  • 他のチームと比べない
  • 項目の粒度を気にしない
  • 定期的なメンテナンス
• 効果の実感
  • いくつかのスキルが危うくなることが見て取れる
  • 具体的にどこが弱くなったのか明らかになった

障害対応演習

• 属人化しがち
  • そもそも緊急事態なので、丁寧に教育している時間がない
• 新規メンバー目線
  • 何しているかわからない、何を学べばよいかわからない

式年遷宮

• 伊勢神宮
• ソフトウェア
  • 定期的に手を加えることが大切
  • 技術継承
  • 技術的負債の返済
  • モダンなソフトウェアへの適応
  • フルスクラッチをしないために定期的にエンジニアリングする
  • ポジティブな理由をモチベーションにする
• エンジニアの技術継承
  • 以前：新規構築時のメンバーが一番詳しい
  • 以後：式年遷宮に参加したメンバー 一番詳しくなる
  • これで継承ができていく

技術的負債とシステムのスケール

• サービスの成長速度
• Mackerelの式年遷宮

感想

• スキルマップやってみたい
• 式年遷宮、いろんな視点がいろんな部分に役立つのだなと思った

⑤テクノロジーとクリエイティブがコマース体験を変革する

事前情報

14:10～14:55 14-F-5
河野 貴伸[フラクタ]

いままで「eコマース」とクリエイターの間には「モノを売る」以外には強い繋がりは存在しませんでした。しかし、2020年、その常識は覆されます。「eコマース」は「デジタル・ネイティブ・コマース」へ。その進化には「リアルとオンラインが統合された、連続したブランド体験」が必要不可欠であり、その体験を生み出すクリエイターの力が不可欠になります。海外、国内の様々な事例をご紹介しながら、クリエイターの皆さんを新たなる「コマースの世界」へご案内します。

参加時メモ

はじめに

• フラクタ「日本のブランド価値の総量を増やす」
• ECのイメージ
  • 自由度が低そう
  • 進行管理が大変そう
  • めんどくさそう
  • 個人情報が怖い
    • 頑張っても評価されなそう
    • 喜ばれなさそう
    • つまんなそう
• 違う！違うんだ！
  • 今まではそうだった
  • これからは違うんだ
  • そういう話を今日はします

これからは違うんだ

• koala
  • ヘッドレス・コマース
  • それぞれに異なった外部サービスを利用し、APIで統合している
    • 新たなサービスに一部分だけ載せ替えることができる
• USにおけるD2Cの成長を支えた
  • テクノロジーとクリエイティブ
  • リアルとオンライン、すべてのクリエイティブが求められている
• Eコマースからコマースへ。
  • それはデザインの自由度のレベルの話ではなく、技術的な制限の話でもない
  • データをクリエイティブに活かす
    • デザイナーとクリエイティブの共創
      • だれのためになにを届けるべきなのかをともに考えることができる
    • クリエイティブ・リバランス
      • とりあえず手当たり次第作るではなく、力の入れどころを見極める
        • どこに手を入れて、どこに手を入れないのかをデータで判断できるようになってきている
• 自身は３DCGや音楽制作をやっていた
  • クリエイティブが今の仕事に生きている
  • 体験が求められる時代
  • フラクタが考える「ブランディング」とは
    • シンボリック・エクスペリエンス
      • UIより広く、ブランドより狭い
      • 味覚、嗅覚、触覚、聴覚
        • Slackの音
          • ガイドラインがまとめられている
        • 体験の連続性を忘れない

最後に伝えたいこと

• ビジネスを理解することの重要性
  • コマースはビジネスの全体像を最もインスタントに理解し、体験できる
    • 損はないスキル
• これからの時代、日本国内だけでの需要はジリ貧
  • 日本のものをもっと世界へ売っていく。越境EC。
• 世界中の人たちに使われて愛される可能性
  • それもまたこれからのコマースの魅力
• Eコマースの世界に入ってきてください。大歓迎です。
  • 一緒にコマースの世界を変えていきましょう！

感想

• 「リアルとオンライン、すべてのクリエイティブが求められている」というのが印象に残った
• あまり普段接点がない分野の講演で新たな知見を得ることができるのがデブサミの良さだと思う

⑥はブースを回ったりしました

感想

• オーティファイさんのデモを見せてもらったり、ジョブディスクリプションについてのお話をしたり。
  • ジョブディスクリプションを読んだだけでは分からない温度感があるということが発見だった。
• ブース出展企業さんと「ブース出展」や「カジュアル面談のスタイル」の話をしたり。
• 去年デブサミに初参加した際は「ブースに近寄ることすら怖い」と思っていたが、エンジニアが他社のブースに踏み込んで行くのは面白いなと思った。
  • 「ブースに近寄ることすら怖い」の原因は、「営業さんの押しが強かったらどうしよう、プロダクトを売りつけられるのでは」というものかも知れない。
  • しかしその企業がブース出展した目的は「プロダクトの紹介」がメインではなくて「他社エンジニアに知ってもらうきっかけづくり」かも知れない。

⑦Hackが好きなエンジニアが組織をHackしてみる考えと実践を経てきたヒストリー

事前情報

16:20～17:05 14-C-7
萩原 北斗[うるる]

「エンジニア」と一言で言っても、実はその実態は様々な姿を持っています。
この様々な姿があるからこそ、「エンジニア」をバックグランドに活躍している方々は自分の身の振り方を迷うことが多いのではないかと推察しています。
私もそのような迷いを持っていた状況から、現在はエンジニアリングマネージャーを務めるに至っています。
わたし自身と私のチームの相棒がどのような身の振り方をしてきたか、その中でどのようなことを実施してきたかを、組織の考え方の型にはめた形で振り返ってみます。
これまで実施してきたことが再現性の高いものとなるよう、状況も含めて詳細にお伝えできるように考えています。

参加時メモ

うるる

• NJSS：入札者情報速報サービス
  • 情報を人力で収集している
• 人のチカラで 世界を便利に

本題

• エンジニアたるもの、組織づくりもエンジニアリングしよう

きっかけと面白さ

• グロースハック
  • 仕組みづくりと振り返り
  • 自分が作った仕組みがユーザーに影響を与える実感

Hackの定義

• Hackの意味に込めること
  • 構造におけるスキマを知ること
  • 構造のスキマを埋めること
    • 小技的なものではない
    • 構造を知り、そのスキマに入り込む

組織をHack

• マネジメントの仕事を通した苦悩
  • エンジニアとして開発業務
    • プログラム
  • マネージャーとして開発業務
    • ヒト、プロジェクトいう概念
  • 不確実性の高いものを相手にするので不安が大きい
  • 対面する課題の抽象度が高く、仕事の成果がわかりにくい
    • なんかしんどい
  • どうしたらいいのか考えた
    • 開発業務をしていた時のようにマネジメント業務に取り組んでいこう
    • 見えないものを見えるようにする、それによって構造を理解する
    • 構造を理解した上で、スキマに入り込む

具体的な取り組み

ケース1：機能する組織を作っていく

• 過去の苦い経験
  • 新しくメンバーを増やしたとしてうまくいくか、なにをしたら良いか
• マネージャーを招き入れた。地に足つかない感じで見ていたが、構造を知ったり、スキマに入り込んだりしたらどうなるかなと思った
• 構造を理解する
  • 組織に必要な3要素
    • チェスター・バーナード
    • 共通の目的：組織としてなにを目指すか
    • 協働の意欲：協力
      • 心理的安全性も必要
    • 共通の目標
• スキマを埋める
  • 共通の目的：組織の方針を定める、見直す
    • More Value Keep Value
    • N-Dev Spirits
  • 協働の意欲＋コミュニケーション：自分たちの行動指針を自分たちでつくる
• 私の相棒がチームのために実践したたくさんのこと
  • 経験に由来された根拠があった
    • マネジメントとか
      • 経験が少ない人は、まず知識を入れてからのほうがいいかも
    • 組織の成功循環モデル
      • ダニエル・キム

ケース2：エンジニアの組織を会社の武器にしていく

• 経営層に技術畑出身者が少なく、今後の開発組織のあるべき姿を考えていく役割
  • 自社のエンジニアの存在価値は？
    • 開発だけやっていてもダメでは？
    • 価値提供のための役割は開発だけではないはず
• 構造を理解する
  • プロダクトマネジメントトライアングル
• スキマを埋める
  • 不在の役割の埋め方をすり合わせる
  • その中で個人のキャリア戦略をプロットする
  • 官僚型組織とプロダクト型組織の関係整理を進めていきたい。道半ば。
• エンジニアたるもの、組織づくりもエンジニアリングしよう
• クライテリア思考
  • 判断基準や尺度
  • 見えないものを見えるようにする
  • とりあえず書き出してみると、スキマの認識合わせもしやすい
  • 新卒エンジニアの育成戦略
  • プロダクト開発組織において押さえておくべきポイント

感想

• ヒトや組織やチームビルディングに関する抽象度が高い問題について具体的に取り組んでいくためには、エンジニアリングの考え方など自分が既に知っている方法や手法をヒトや組織に置き換えて当てはめて試行いくと良いのかもと思った。
• 組織づくりもエンジニアリングしよう！

⑧キャリアトランスフォーメーションをみんなで考えよう～開発者から事業責任者、役員へのキャリアパスはどうよ～

事前情報

17:25～18:25 14-A-8
石井 智康[石井食品]/市谷 聡啓[ギルドワークス/エナジャイル]/黒田 樹[リクルートテクノロジーズ]/【司会】岩切 晃子[翔泳社]

スクラムに舵を切る開発現場が急増していますよね。スクラム開発チームのメンバーが会社を超えて盛り上がっている一方で、プロジェクトの統括責任者である「プロダクトオーナー」は、スクラムの定義では担当領域が広すぎる上に、学ぶためのまとまったドキュメントが、アメリカ本国にもない状況です。そのためか、イベントで書籍の販売をしていると、開発者の方々から、プロダクトオーナーに役割を変えたいと思ったときに、「どの本がPO入門書ですか？」と問い合わせをいただくことも増えてきました。

個人的には、ぜひ開発者サイドからPOやらプロダクトマネージャーやら、事業サイドを目指す人が増えてほしいと思っています。開発がわからないPOは、POにとっていちばん大事な仕事である「開発チームにどの順番で何を作ってもらうかを都度決定するとともに、全体の進捗を明らかにすること」を実行するのが現状難しいと考えるからです。 
そしてまた、開発者から役員を目指す人も増えてほしいと思っています。ITだらけの世の中になった今、経営の視点に、エンジニア目線がますます重要になってくると思うからです。

今回、開発者→PO→事業責任者とキャリアトランスフォーメーションをしてきた方々に、ご自身が開発者からPOになった経験談や、事業責任者から見た、POの役割や開発チームの役割を話して頂き、デブサミ参加者にキャリアチェンジの足がかりや、開発チームとPOのコミュニケーション改善に役立てていただけるようなセッションになれればと思っています。

参加時メモ

はじめに：【司会】岩切 晃子さん[翔泳社]

• 【司会】岩切 晃子さん[翔泳社]
  • ITエンジニア本大賞のメインリード
  • 全社会人に覚えておいて欲しいこと
    • 26歳のときに入社GURU
      • 友人に「ひとまずのめり込め」とアドバイスを受けた
      • みんなが取り乱しているのを見て、これはなんとかしたい、と思ったのがマネジメントへの原点
      • 先ずはマネジメントに関心を持って欲しい。チームのためにも、みなさんの人生のためにも
  • 日本のビジネスサイドの意思決定遅くない？
  • 「チーム」の範囲が狭くない？
  • Companyともにパンを食べる
    • 監視ではなく無関心ではない状態で働くのがだいじ
  • 開発チームとビジネスサイドがKPI共有してますか？
    • 開発チームが腕を上げて力をつけているスピードに、ビジネスサイドが合っていない
    • 開発者もどんどん口を出して経営判断に参加して欲しい
  • 企業、家業、昇進の3人から知見を聞き、みなさんの背中を押すセッションをすることが今回のゴールです！

自分のハンドルは自分で握れ：市谷 聡啓さん[ギルドワークス/エナジャイル]

• 大事なことは最初に
  • その場その場の環境に何となくで身を委ねるのではなく、自分が良いと思った方向に身を委ねて
• 2003年24歳
  • n次受け
  • 組み込み系
  • 時代の流れを気にしてなかった
  • でも、これでいいんだっけ？
  • 本当にいいのかわからない。だから外に出よう
  • デブサミで圧倒された
  • 「目の前の最適化に陥るな」
    • 別の視点を持たないと
  • デブサミ
    • 自分と世の中のDiffを取るための年に1回の場所
    • そこに行けば先輩の背中が見える。遥か遠くに。
• 追い求めていたこと
  • 「自分が作ったソフトウェアを使ってくれる人の近いところで仕事をする」
    • 意味を実感したい
• 2013年
  • 間違ったものを正しくつくる問題
    • 作り方がどれほど上手くても、作っているものがそもそも間違えていたら？
  • なにをつくるべきかは、顧客、プロダクトオーナー、自分ではない誰かが考える？
    • 踏み込んだら、誰も正解を持っていなかった。
  • 自分のあり方を世に問うために、自らの会社を作ることを選んだ
• なぜ、経営者を選んだのか？
  • 自分がこれ(アジャイル)で価値を出せると信じで。しかし結果が出なかった。
  • 自分ですべて背負うしかなかった。
  • 自分自身を賭けて、踏み出すことを選んだ。
• 正しいものを正しくつくる
  • 自分自身を駆り立てるための言葉
• つとめ
  • 大きなことを無理に口にしなくていい
  • 自分の場所を今よりもよりよくするためには
  • 自分はなにをする人なのか、自分を再定義する

エンジニアの事業承継：石井 智康さん[石井食品]

自己紹介

• 略歴

事業承継

• 事業承継ができない故に廃業になってしまう企業が多い
• 自分の人生vs家業
• ソフトウェアの企業に入った
  • SIにおけるエンジニアのお仕事
  • システム構築そのものが、越境的行為である
    • お金の世界、コンピュータの世界、人の営みの世界
    • これを行き来
  • 徐々に管理者側に
    • WBS、エクセル、、
    • 開発したいからこそベンチャーに入ったのに、調整ばかりしている
      • 「私は本当にエンジニアなのだろうか」
  • フリーランスになった
    • 自分でお金を取ってきてみよう
• いいチームで開発したい
  • 技術的負債
  • チームマネジメント
  • 顧客価値の提供
  • PL
  • 採用
  • 評価
  • これ、経営の話では？となった
  • Joy.inc
• 自分の人生と家業が何となく近づいてきた
  • 「事業承継はベンチャーの一つの形」星野リゾート星野代表

エンジニアが家業を継ぐメリットと問題点

• VUCAの時代とか、それ以前の問題
  • インフラやばい
• トライアンドエラー、チームマネジメントは役立つ
  • コンウェイの法則
  • ただし、上から行かない
    • 傾聴＝課題から入る
    • IT業界の常識を捨てる
• 副業から始めてもいいんじゃない？

偶然の出来事の流れに身を任せエンジニアからマネジメントの道に進んだ話：黒田 樹さん[リクルートテクノロジーズ]

結論

• 自分のキャリアにおいて中途半端なビジョンを持たない。
  • 流れに身をまかせる。
  • 巻き込まれ力を高める。
  • 好奇心を持ち食わず嫌いをしない。

一般論

• キャリアを考えるとき
  • キャリアアンカー理論
    • 山登り型
  • 計画された偶発性理論
    • 川下り型
• 「お前のWillは何なんだ」を空白で出している
  • へぇ〜ボタンを押し続けたい。知的好奇心
• 「いい波が来た時に沖にいることが大事」

経験談

• 20代
  • しっかり系アーキテクト
• 30〜35
  • SoE＆ビジネス
• 35〜38
  • SoE＆SoR 開発のマネジメント
  • みんなが見えていないぼんやりしていることを構造化、言語化して見えるようにして、適切な課題を設定する仕事

ポイント

• 様々なパラダイムを理解することで、局所最適から全体最適へ

パネルディスカッション

マネージャーに向いている人、経営者に向いている人

• 視座を変えることができるかどうか。それを器用にできるか。
  • いろんなことを経験できるのが醍醐味。
• わからない。ないのかもしれない。
  • ただ、向いてないと言えない立場になってる。やるしかない。
  • 向いている向いていないよりも、覚悟ができるかどうか。
  • 学びながらやっていくしかない。
• エンジニアは全員向いていると思う
  • 組織図はクラス図に見える

実現したいと思っていること

• いいチームで開発したい
• へえ〜ボタンを押し続けたい

時間

• 持続可能性を考えている
• 一人の時間をつくる
• 筋トレ教リングフィットアドベンチャー
• 自分に優しい時間をつくる

組織をつくるにあたって意識していること

• いろんな人に対する敬意
• 歴史を重んじる
  • 何でもロジックツリーに落とさない
• ひとのときを思うこと
  • どう時を刻んできているのかに関心を持つ
• 属人化していない、イキイキした組織をつくる
  • チームメンバーの健康
  • 会社の安全
  • 給料

感想

• 自社のインフラエンジニアに感謝しようと思った。
• 「みんなが見えていないぼんやりしていることを構造化、言語化して見えるようにして、適切な課題を設定する」が印象に残った