DevLOVE Xに参加したため、記録を残しておきます。

セッション

「嫌われない」を諦めない

speakerdeck.com

全社横断のアジャイル推進組織
- どういうふうに広めているのか(具体的な例)
- 物事を広める、進める上での心構え(普遍的に抽象化した話)

チームの仕事領域

アジャイル関連トレーニング
チームの支援
社内アジャイルコミュニティの構築

3つの仕事領域の関係性

トレーニングで底上げ
特定のチームに入り、課題解決しながら高みを目指す
コミュニティでチームの事例を広めてスケール

画一的な支援内容にはせず、各メンバーの経験・スキル・志向を活かした支援を行う

広める

推進する以上に、リーン・アジャイルを好きになってもらいたい
嫌われることをいとわずに進むこともとても大事
でも何かを広める立場として、嫌われない努力、好きになってもらう努力も必要

リーン・アジャイルの最終的な目標は、組織文化に溶けてなくなること

心構え、接し方

謙虚

何かを知っているからといって、当然何も偉くない
ただの専門性の違い、エネルギーの使い方の違い

敬意

今の現場や人をむげに否定しない
あれ？と思うことがあっても、歴史があり、事情がある

承認

偉そうにも感じるが、良いなあと思ったことを良いなあと言う

アプローチ

聞くことからはじめる
知る
- 深く知る必要がある
手段に固執しない
- 何かを広める組織としては、ミッションに十分な余白をもたせる
- 結果的に100%アジャイルのエッセンスを取り入れている
準備
最初の成功にこだわる
- バイヤーズリモース
  - 自分の決定に自身が持てなくなること
- とにかく失敗リスクを潰す、成功確率を上げる行動をする
- アプローチする範囲もなるべく小さくする
- 質の良い失敗をする
フィードバックを受ける
- 4半期に1度、匿名アンケートを設けている
- 伝わらないのは伝える側のせい志向で考える
プロフェッショナルの専門家であれ
- 常に知識、理解を深めていく必要がある
- チーム内で「Learning Time」をはじめてみた
平易な言葉をつかう
- 難しいことも平易な言葉で伝えられる方がプロ
ポジティブさ
- 基本的にポジティブに。特に相手、チームがネガティブなときはよりポジティブに
- チームがポジティブなときはネガティブに
コミュニケーションに注意を払う

アジャイルをどうやって紹介しているか

Don't just Do Agile, Be Agile
アジャイル方法論を適用しにきたわけではないが、アジャイルが好き
記事
好きかどうかをどう測っているか
- NPSをとっている(+63)

感想

「画一的な支援内容にはせず、各メンバーの経験・スキル・志向を活かした支援を行う」、大事だと思った
心構え、接し方はとても大事だと分かっているつもりでも、つい忘れがち
チームがネガティブなときにネガティブにならないように、心構えから考え直さないといけないなと感じた

エンジニアがUXデザインを学んでみた10年

20190622 「エンジニアがUXデザインを学んでみた10年」 #DevLOVEX chachaki from 将之佐々木

www.slideshare.net

縁について
- つながる／つながらない〉の社会学

エクスペリエンスアーキテクト

セカンドファクトリーのチームモデル

取り組み

AT-ONE
- ユーザサイドとビジネスサイドの両側面をつなげるための仕組み?
3つの視座
- 鳥の目
- 虫の目
- 魚の目

UXデザインとドメイン駆動設計

ヒト/システム軸とか可視性・可触性の軸で見える・見えないものを分析するのが好き

質的分析

解釈は主体的・主観的であり、量的分析を行っている人と対立することもある
質的分析では、意味に関する知見が得られる

レフトウィングとライトウィング

UXデザインでもレフト・ライトあるのではないか

blogs.itmedia.co.jp

感想

UI, UXの中にも様々な分野がある、知らない用語もたくさんだった
- 全体的に勉強不足、UI, UX分野についてもっと体系的に理解したい
UXデザインとドメイン駆動設計の図がとても面白い、自分の興味をマトリクスで可視化できるの、とてもすごいなと思った
- 自分の興味の分野って10年くらい頑張って振り返ったら見えてくるものなのか、最初から分かっているのか気になる
- デザイナーとの会話の質を高める上で、どの部分について会話しているのか、どの分野に興味があるのかなど知っておきたい
疑問：UXが好き ≠ UIが好きがあまり腹落ちできていない、どういう感覚なんだろう
- UIが好きなひとがUXが好きだと思っていた
- 心理学者とかも質的分析が多いのから、UXが好きと近いような感覚？
  - そもそも心理学者の対比になる量的分析学者ってなんだろう
  - アートとサイエンス的な分け方になるのか

エンジニア、エンジニアリングマネージャーとして成長するために必要なこととは？〜成長とは何かを考える〜

speakerdeck.com

組織・チーム
設計
個人

組織・チームにとって、個人がとても大事。環境によってヒトは変わる、やり方の問題。

成長とは何か？

「上」に行く、行かねばならないという無言の圧力
学び：学んだ結果に上下はない、失敗しても学びはある
VUCAの時代、100年時代
- 年齢関係なく学び続ける必要がある
成長とは？ → 自発的に学び、変化し続けている状態
今日は個人の成長についてのセッション

個人の成長

チームや組織に対するアプローチはよくある
個人の成長に対するアプローチは1on1くらいしか見かけない

いろいろやってみた結果、チームだけでなく個人へのアプローチも重視すると効果的ではないかと感じる

ソフトウェア開発はチームスポーツである(Team Geet)
- これはメタファー
- 個人の力と成長も重視してより良いチームを創っていく

エンジニア・エンジニアリングマネージャの共通点の学び

やり方(スキル、能力)とあり方(人間性)
コルブの経験学習モデル
- 志向・実践→具体的経験→内省的観察→抽象的概念化
- 行動を変える→振り返るのサイクル
基本、上の２つ

エンジニアの学び

エンジニアに成長についてインタビューをしている
- 現状の結果と経験について話す

分かってきたこと

学びの比重
- 行動の比重が大きい ≒ 訓練
学びの根源
- 何が学びのモチベーションなのか、人によって違う
- 一つの枠組みで、全員を当てはめるのは不可能
  - 目標設定なども全部人によって変えたほうが良さそう
- 内的要因か外的要因か
  - 内的要因の人はプログラミングをおもちゃ・外的要因の人はプログラミングを課題解決のためのもの
    - 会場では外的要因(プログラミングは課題解決)の人のほうが多かった
    - 右側の人が左側を強いると、辞める
      - 自分はどちらかというと右側かなと思ったので、気をつけないといけない
    - 左側の人が右側を強いると、良い環境ではなくなる
環境と他の人の助け
- 発達範囲
  - 経験を積めば積むほど、周りのサポートが必要になっていく
- 人は無意識で行動している
  - 無意識→意識化→無意識

自分の振り返りを言葉にする

スプリントごとに自分の振り返りをする人はほとんどいない
- チームについてはするのに、個人の振り返りをしないのは矛盾
- 言葉にするのが大事
  - なんか上手くいった、上手くいかなかったみたいなレベルでは駄目
  - 自己認識して、行動を思い浮かべることが重要
振り返りのポイント
- 内容よりも感じたことを言語化することの方が重要
自分のKPTをやってみるとよい
- 毎日やる、やれる量にする
- Slack等で公開してみる
- tryに活かしてみる

エンジニアリングマネージャの学び

自分自身で努力する
人の「あり方」に動かされる
答えが無くなる
矛盾と向き合う

意思決定

自分で答えを出さないといけないから、自分で向き合わなければいけない
ピーターの法則
- マネージャーになることはゴールではなく始まり

EMになったときに重要なこと

オーセンティックでいる
- あなたのままでいる
- それがまた難しい
アンラーニングする
- これまでの経験を捨てる

感想

他の人がプログラミングをどう捉えているのか、気になる
毎日継続できる、日報フォーマットを作りたい
- めんどくさくなって辞めがち
- 普段自分はポモドーロで開発を行っているため、ちゃんと作業記録したい
  - これらの作業も自動で記録されていく仕組みを作っていきたい
  - 内省力を高めるために、ポモドーロを扱いたい
エンジニアリングマネージャーのための話も聞きたいなと感じた

それはYAGNIか？それとも思考停止か？

それはYAGNIか? それとも思考停止か? from Yoshitaka Kawashima

www.slideshare.net

川島さん：そろそろエンジニア歴20年、すごい
- 流しのアーキテクト
感情に訴える系の話が多いため、技術系の話にした

市場に早く出して、改善を繰り返す方のシステム設計

正解なんて誰にもわからないんだから、早くだして早く失敗しよう
YAGNI(You ain't gonna need it: どうせ必要ないって！)
- 覚えたら、つい使いたくなる甘美な響き
ビジネスの成長と共にゴールは切り替わっていく
- とにかくスピード → 品質・生産性
- 時間がかかる・工数がかかる・本番障害
ますますYAGNIの判定は重要に
- 「YAGNI=設計をサボって良い」では断じてない
  - あとでクリーンにすることはない。市場からのプレッシャーは常にあるから。(クリーンアーキテクチャ)
設計のサボりとYAGNI
- 基本はリスクマネジメント(発生確率×流出コスト)
2種類の非YAGNI
- それ、そもそも後回しにできない
- 今やっとかないと後々まずい
アーキテクチャ設計にどれくらい時間をかけるかには統計に基づいた研究がある
- プロジェクトの時間=開発時間+アーキテクチャとリスク削減時間+やり直しの時間
- Making Software, How Much Architecting Is Enuogh?
  - コード規模によってパーセンテージは変わる
技術的負債を抑えたYAGNI
- インタフェースを使いDetailを分離する
- 必要になるまで状態をもたない/持つ箇所を限定する
最速インタフェース設計
- 区分値, ステータスを属性にもつデータの塊(Entity的なやつ)
- 開発体制の境界インタフェース
- レイヤ境界のインタフェース
- 同時に変更されるものが、あちこちに分散しているものはSRPに反する
- 有名な句
- 状態(ステート)
  - 更新は最小限に
  - 状態の更新の向きは一方向に
  - 状態をもつ箇所を切り出す
  - 途中の計算結果は必要になるまでもたない。

感想

ソフトウェア開発の基本で、とても重要な事項を学べる良い機会だった
- 意識しなくても、呼吸のようにできるようになりたい
設計の基本はリスクマネジメント(発生確率×流出コスト)という事実を再認識
基本的なことを守ることがとても大事

エンジニア人生と定年退職

エンジニア人生と定年退職、人生100年時代のエンジニアの生き方、デブサミ 2019 【15-A-8】 from Hiro Yoshioka

www.slideshare.net

自己紹介

60歳になって定年退職した方
- 今は東大の情報系の博士課程に入っている
  - 学割もあるけどシニア割もある
大学卒業以来、プログラマとして生きてきた
10年後の自分(生きていれば70歳)
生命表(10年後生存確率)
- 60歳の人は90%
- 現状100歳まで生きるのは、100人に1.76人
- なかなか難しい
- 真理：人はいつか死ぬ
  - 細かいことに右往左往しない方が良いんじゃないかと思っている

「プロの酔っぱらい」が学生になるまで

田舎暮らしに殺されない法
- 定年後のあこがれの田舎暮らしなどないということを戒めた書物
定年後に酒を飲む生活が見えた
- 虚数の情緒という数学の本を読んだ
- 禁酒をした
- ふと文学を読みたくなった
漠然と定年を意識した
本を読む
酒を止める

パラダイムシフト時代に生きる

起こっていることを知らない
起こっていることに気が付かない
起こったあとはアタリマエになる
スマホが出てきて、みんなスマートフォンになった
- 対応できなかった会社は、ある日モノが売れなくなったりする
  - PC → スマホに変わっていることに気がついているのに、動けない
- 歴史は繰り返している
  - マイクロプロセッサ
  - BASIC
  - AppleⅡ
  - 公開鍵暗号など
1970年, 1980年代
- PCの登場
  - IBM PC
- ソフトウェアの国際化(破壊的イノベーション)
  - Unicode
  - HTMLの提案など
1990年
- 転職
  - 終身雇用からのコペルニクス的転回
2000年代
- ベンチャー創業, 41歳
- Web 2.0
- iPhone
- コミュニティ活動OSS, 勉強会
  - カーネル読書会
2010年代
- 震災
- 深層学習
OSS
- パザールモデル
- ライセンス
  - GPN
  - 知財は秘密にするしか価値が守れないと思っていた
    - オープンにすることで価値があがることを理解できなかった
- 勉強会
  - コミュニティ
  - 何で自分の時間を使って勉強会の運営したりしているんだろうという気持ちがあった

ライフ・シフト, ワーク

4回転職
- 多くも少なくもない
- 大学の同期を見てみると、1社の人がとても多い

感想

とても貴重な話
- 歴史・パラダイムについて考える良い機会
  - エンジニアは常に新しいことを継続的に勉強する
学割もあるけどシニア割もあるって、すごいカッコいいジョーク
年齢関係なく、挑戦している人はとてもカッコいい

懇親会

懇親会の際に、「エンジニア人生と定年退職」を発表された吉岡さんに、気になったことを聞きました。

会話から学んだこと・感じたことを書き起こしておきます。

30年エンジニアをやっていても、変わっていること・変わらないことはある
- Systemの根幹の部分は比較的変わりにくい
  - 枯れている知識を学ぶことも重要だと感じた
数学を学習することで、現代のトレンドであるパラダイムを理解することができる
自分はソフトウェア開発をしている中で、深い部分を理解できていない
- そのままでも良いのかどうかが分からない
  - プログラミングは楽になっている
    - コモディティ化するという意味でとても良いこと
    - 一方で深い部分を理解できていないと、パラダイムを把握するのが難しくなる
      - 深い部分を理解するのに、数学の知識は役に立つ
    - そのままで良いのかどうかは、自分がどうしていきたいかに依る