概要

Developers Summit（デブサミ)2023 Inspired
https://event.shoeisha.jp/devsumi/20230209

開催日: 2023/2/9 - 2023/2/10

参加セッション一覧

[2月9日]
・10:00 9-A-1 デジタル庁～
・10:55 9-A-2 TiDBと～
・11:50 9-E-3 元大手企業～
・13:15 9-D-4 ソフトウェ～
・14:10 9-D-5 アジリティ～
・15:05 9-A-6 継続的なサ～
・16:00 9-A-7 開発マネー～
・16:55 9-D-8 IaC活用～

9-A-1 デジタル庁におけるソフトウェア開発のこれからのはなし -今よりもよい10年後のために必要そうなこと-

デジタル庁のミッション・ビジョン

バリュー

デジタル庁設置法

プロジェクト(一部抜粋)

デジタル化・ソフトウェアで目指すこと

労働人口が今後減っていくことはほぼ確実なので、効率を上げて行くしかない。

デジタル化はオンラインで申請できるだけではなく、申請データをより上手に使えるようにすることが大切。
ex.) データ連携、データ活用 ※もちろん、個人情報の取り扱いを考慮する必要がある

行政におけるソフトウェア開発

専門人材を確保し、開発体制を作る
ただし、調達の問題がある

好きに発注できるわけではなく、入札になる
発注する前に事前に仕様書を書き切る必要がある

内製化

作成したコアライブラリをOSS化することも行っていきたい
UKでは実績として行っているものがあるらしい

デジタル庁のエンジニア

9-A-2 TiDBとChatGPTを使えばアプリはもっとシンプル化できる

NewSQLデータベース TiDB

OSSの活発度を知る方法
OSS insight

データストアの選択

1つのデータストアで全て実現することは難しい
→組み合わせることで解決

NewSQLとは？
https://ja.wikipedia.org/wiki/NewSQL

TiDBについて
更新・参照業務と分析業務を1アーキテクチャで実現

ChatGPTの活用について

ChatGPTを活用してクエリを自動生成する機能があるらしい
→Chat2Query

まとめ

9-E-3 元大手企業エンジニアが東大関連スタートアップの創業CTOへ！キャリア・事業・社会課題解決のリアルなここだけの話

自己紹介

小原さん

川崎さん

ディスカッション

昼休みで離脱

宣伝

9-D-4 ソフトウェアエンジニアのためのプロジェクトサバイバル術

書籍紹介
https://www.amazon.co.jp/gp/product/B0BF3TMDSS/ref=dbs_a_def_rwt_bibl_vppi_i0

プロジェクトは人生の質(QOL)に直結する

昔の人海戦術作成はもう通用しない

良いプロジェクトは少ない

経験が無い登山ガイドに一緒に山に登ろう！と言われるイメージ

すごいエンジニアになってすごいテック企業に入れればOKというわけでも無いかも。
最近はレイオフも行われている状況

どうやってプロジェクトのジャングルを生き延びるか？

優秀だけど嫌な奴にならないこと(Brilliant Jerk)

What is "Brilliant Jerk"?
「悪い姿勢xハイパフォーマンス」

腐ったりんご実験

なぜソフトウェアエンジニアは"Brilliant Jerk"になるのか

周りが技術を理解して無さすぎる
- 日本では約7割のIT人材がIT企業に集中している
- 商流が「技術を分かっていない人→技術を分かっている人」になりやすい
技術は曖昧さを許容しない
プロダクト開発の責任を押し付けられる

本人は望まず(自覚なく)Brilliant Jerkになっているケースは多い

現代のプロジェクトはチームプレイである

本来はプロジェクトマネージャーがコントロールすべき

意識しておくポイント

モノの領域のエンジニアがヒト、カネの領域に対するコニュニケーションを意識する
ビジネスサイドとのコニュニケーションを意識する

Brilliant Jerkにならないために

(追加で、働く場所を選ぶ)

マウントを取らない
- 自分の専門領域で自分が詳しいのは当たり前
- 技術に詳しく無い人の話も「要望」や「質問」として一旦受け止める
- 相手を否定しない、上から話さない(言い方を考える)

自分の担当領域をブラックボックス化しない
- できるだけ会話や資料化する
- 情報や知見をチームメンバーや組織に対してオープンにする
- 担当領域のブラックボックス化は中長期的に自分の競争力を低減する

挨拶/雑談をする
- 人は相手がどんな人か分からないと不安になる
- いわゆる「コミュ力」は必要ない
- 服装・エチケットも配慮

Whatだけでなく、HowやWhenを意識するようにする
- 「xxは実現できますか？」という質問にどう答えるか
- 見積もりの技術を磨く
- 実現する際の課題や必要な前提条件について説明する
働く場(プロジェクト)を選ぶ
- 理解されない、報われない組織やプロジェクトで長く働くことは人生上のリスクになる
- ずっとディフェンシブに仕事しているとBrilliant Jerkになってしまう
- 条件だけで就職先やプロジェクトを選ばないことも重要

プロジェクトワーカーにとって最高の褒め言葉

結論
良いプロジェクトに参加して良い人生を送ろう！

(とても良いセッションだったので書籍買おう)

9-D-5 アジリティ実現に必要な組織プロセス変革の極意と実践事例～実践現場目線で考える、チームに寄り添う組織を実現する方法教えます～

DXにおけるアジャイル

アジャイルとは

これまでの取り組みで分かったこと

NECが考えるアジャイルでの成功とは
チームと組織が調和して一体隣、市場のニーズに応じて迅速な価値提供が再現性高く実現できるようになること

チームと組織の関係

ビジョンの共有

諸事情により、途中まで参加

9-A-6 継続的なサービス発展のための技術とアーキテクチャの取り組み

近年翻訳された書籍
→変化し続けることを前提とした知識セット

疎結合なチームとアーキテクチャ

Q. チームにアーキテクチャを組み合わせれば良いのか？
A. それだけでは十分ではない
→チームの方も変わるため

アーキテクチャ、チームの両方を一緒に進化させ続ける

第一部：アーキテクチャ

スタートアップ初期

試行錯誤を最速にできる状態
herokuを使用していたのでインフラチームが存在しない

Visitの基本的な成長モデル

成長モデルに対して、アーキテクチャの対応

個人向けに異なる水平展開
モバイルアプリも独立してデプロイされる

実際は上記のようにすぐに移行はできなかった

成長すると新たな課題が出てくる

実際のチーム構成

最初からマイクロサービスで作成する手法も取ってみた
システム的には上手くいった。
しかし、システムが多くなるので重要なサービス価値から遠くなってしまった(チームがサービス価値と向き合いづらくなる)

レイヤードアーキテクチャで全体を分割

第二部：技術

レイヤードアーキテクチャのように階層にする

アプリとシステムをつなぐ技術

アーキテクチャに正解は無い

システムの基盤
APIで会話することに組織が慣れておく必要がある
→これができると複数のプロダクトを連携させるような展開もできる

分析データの扱いについて

参考文献

9-A-7 開発マネージャー1年目が語る、開発マネージャーのお仕事

マネージャーに任命されてから書籍を漁った

気づき

工数をしっかり測定し、ボトルネックや改善できる点を見つける
- Toggleを利用して工数を計測
- 測定結果から振り返り、将来の参考値として利用できる
毎日進んでいる感がないとモチベキープが難しい
- TODO分解で着実にゴールに迫る
  - 達成すると何が嬉しいのか？
  - 自分のキャリアとの結び付け
やることが多すぎる、何からやるべきかが分かっていない
- 緊急度、重要度から優先順位を設定する
２番目に踊る人になるといいことがある
- 二人目に踊るやつがいる組織は強い
できないことができるようになることが成長の一つ、日々確実に成長するには
- 毎日何かしらのコードを書く
- 毎日プロダクトのコードに触れる
- 必要そうなコニュニティに突撃する
- 個人開発で気になる技術に触れる
- 業務中に練習時間は取りづらい
  - 業務中や業務関連のもので経験をスキルとしてして上げて行くことが重要
    - 学んだことを即実践投入
      - inputからoutputまでの間をあまり置かない
    - 日次振り返り
      - 自力でできなかったことを書き出す
      - TODOリストにする
      - 消しこむ

9-D-8 IaC活用やDevOps実践からみる、抜けてはまずいプロジェクト推進に必要な「運用設計」の考え方

優れたパフォーマンスの企業は全体の2割以下

運用とデリバリーパフォーマンスの関係性

モニタリング・インシデント対応
改修
デプロイ

モニタリング・インシデント対応が悪化すると全体の復旧にかかる時間が増える
→運用パフォーマンスが上がらないと行けない

[原因]

開発と運用の連携が取れていない
目標が高すぎる
作業ミスが多い

パフォーマンスを上げる取り組み

DevOPsに焦点を当てると

本当にやれているのか？

対策が進まない原因

DevOPsに対する投資効果
よく投資対象から外されてしまうが、これだけの効果が見込まれる
→まずは必要性を訴えて行く必要がある

共通ゴールに対する地図が必要

地図が無いと

なんでもIaCでやるものだと思い込む→管理工数が増加
どれだけITスキルがあればいいか不明→対応が属人化

まとめ

運用設計は開発が始まる前に着手しよう
作成した運用設計を関係者と共有しよう
企業としてトータルコストを削減できる！！