Go to Qiita Advent Calendar 2024 Top
LoginSignup
1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

@MasanoriIwakura

Developers Summit 2023に参加しました！！(Day 1)

Posted at

概要

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年後のために必要そうなこと-

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

バリュー
image.png

デジタル庁設置法
image.png

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

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

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

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

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

image.png

image.png

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

image.png

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

image.png

内製化

image.png

image.png

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

デジタル庁のエンジニア
image.png

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

NewSQLデータベース TiDB
image.png

OSSの活発度を知る方法
OSS insight
image.png

データストアの選択
image.png

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

image.png

image.png

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

image.png

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

ChatGPTの活用について

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

まとめ

image.png

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

自己紹介

小原さん
image.png

川崎さん
image.png

ディスカッション

昼休みで離脱

宣伝
image.png

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

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

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

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

良いプロジェクトは少ない
image.png

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

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

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

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

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

腐ったりんご実験
image.png

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

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

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

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

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

意識しておくポイント

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

Brilliant Jerkにならないために
image.png
(追加で、働く場所を選ぶ)

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

image.png

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

image.png

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

image.png

  • Whatだけでなく、HowやWhenを意識するようにする

    • 「xxは実現できますか？」という質問にどう答えるか
    • 見積もりの技術を磨く
    • 実現する際の課題や必要な前提条件について説明する

  • 働く場(プロジェクト)を選ぶ

    • 理解されない、報われない組織やプロジェクトで長く働くことは人生上のリスクになる
    • ずっとディフェンシブに仕事しているとBrilliant Jerkになってしまう
    • 条件だけで就職先やプロジェクトを選ばないことも重要

image.png

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

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

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

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

image.png

DXにおけるアジャイル
image.png

アジャイルとは
image.png

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

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

チームと組織の関係
image.png

ビジョンの共有
image.png

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

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

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

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

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

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

第一部：アーキテクチャ

スタートアップ初期

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

Visitの基本的な成長モデル
image.png

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

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

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

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

image.png

実際のチーム構成
image.png

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

image.png

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

image.png

image.png

第二部：技術

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

image.png

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

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

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

分析データの扱いについて
image.png

image.png

参考文献
image.png

image.png

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

image.png

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

気づき

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

image.png

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

image.png

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

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

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

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

[原因]

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

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

DevOPsに焦点を当てると
image.png

本当にやれているのか？

対策が進まない原因
image.png

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

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

地図が無いと

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

まとめ

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

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?