Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
スタートアップチームで学んだエンジニアの心構え / The attitude of t...
Search
mtskhs
January 31, 2020
Technology
1
1.7k
スタートアップチームで学んだエンジニアの心構え / The attitude of the engineer who learned from the start-up team
presentated at NTT Tech Conference #4
mtskhs
January 31, 2020
Tweet
Share
More Decks by mtskhs
See All by mtskhs
EMがマジ価値を届けきるために考え行動したこと / Engineering Manager's thoughts and actions to deliver outcome
matsu0228
0
8.9k
Cloud Firestore With Go
matsu0228
0
940
Goとの歩み / History with Go
matsu0228
0
120
ReactNativeにおけるパフォーマンスチューニング/ Performance tuning in ReactNative
matsu0228
2
1.5k
Goにおける API Client実装パターン / API Client implementation pattern in Go
matsu0228
8
8.4k
expo開発におけるCI/CD / CICD on development of expo
matsu0228
0
890
SpoLiveの爆速開発を支えるGAE/Goノウハウ / Practice of GAE&Go supporting SpoLive super fast development
matsu0228
1
240
Report of AgileTestingDays2018
matsu0228
0
550
OrganizationTheory of engineering
matsu0228
0
710
Other Decks in Technology
See All in Technology
サプライチェーン攻撃に学ぶModuleの仕組みと セキュリティ対策
kuro_kurorrr
3
790
Oracle Base Database Service 技術詳細
oracle4engineer
PRO
11
77k
[2025-09-30] Databricks Genie を利用した分析基盤とデータモデリングの IVRy の現在地
wxyzzz
0
400
C# 14 / .NET 10 の新機能 (RC 1 時点)
nenonaninu
1
1.2k
CData MCP ナイト!「CData × Oracleで実現する新しいデータ活用 ― 国産SaaS 連携から MCP Server for Oracle Database まで」
shisyu_gaku
0
190
日経が挑戦するデータ民主化 ~ セルフサービス基盤がもたらす利点と苦悩~/nikkei-tech-talk-37
nikkei_engineer_recruiting
0
210
業務自動化プラットフォーム Google Agentspace に入門してみる #devio2025
maroon1st
0
170
避けられないI/O待ちに対処する: Rails アプリにおけるSSEとasync gemの活用 / Tackling Inevitable I/O Latency in Rails Apps with SSE and the async gem
moznion
2
1.8k
AIが書いたコードをAIが検証する!自律的なモバイルアプリ開発の実現
henteko
1
230
WebアプリケーションのUI構築で気を付けてるポイント
tomokusaba
0
160
AIコーディングとエンジニアリングの現在地 / A Snapshot of AI Coding and Engineering(Sept. 2025)
ar_tama
0
160
AIを導⼊しても、 開発⽣産性は"爆増"していない なぜ?
kinosuke01
4
3.6k
Featured
See All Featured
RailsConf 2023
tenderlove
30
1.2k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
252
21k
Faster Mobile Websites
deanohume
310
31k
A Modern Web Designer's Workflow
chriscoyier
697
190k
Building a Scalable Design System with Sketch
lauravandoore
462
33k
Docker and Python
trallard
46
3.6k
Fireside Chat
paigeccino
40
3.7k
GitHub's CSS Performance
jonrohan
1032
460k
Building Better People: How to give real-time feedback that sticks.
wjessup
368
20k
Practical Orchestrator
shlominoach
190
11k
4 Signs Your Business is Dying
shpigford
185
22k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
48
9.7k
Transcript
スタートアップチームで学んだ エンジニアの心構え NTT Tech Conference #4 Hisayuki Matsuki Twitter: @mtskhs
about me • 松木久幸(@mtskhs) ◦ Backend Engineer / Gopher ◦
スポーツAI解説アプリ(SpoLive) ◦ GoにおけるAPI Client @Go Conference Autumn ▪ https://speakerdeck.com/matsu0228/api-client-implementation-pattern-in-go ◦ Agile (シリコンバレーで3ヶ月働いて体感した自立型組織のススメ) ▪ https://speakerdeck.com/matsu0228/organizationtheory-of-engineering 2
3
SpoLive ラグビー・サッカーの試合に対応中 4
Contents 自分が重要だと思う 心構え について • #1 共通認識 • #2 集中
• #3 楽しむこと 話さないこと • 技術的なトピック 5
#1 Common Ground 開発で一番難しいのは? 6
#1 Common Ground 開発で一番難しいのは? 何を作るか 決めること 7 詳細まで認識を合わせること • 背景・目的をメンバーが常に理解しておく
• どのような効果が見込めるか把握することで、実装コス トを踏まえた提案をできるようにしておく 正解は誰にも判断できない(常に変化が求められる) • 常にプロダクトのフィードバックを把握し、今後の改善を 回しやすくする手段を考える
#1 Common Ground 開発で一番難しいのは? 何を作るか 決めること 8 価値向上のために、時には「発散」が必要 • サービス価値のために良いものを作る
• 既存の仕様を捨ててでも価値を提供する • プロダクトチームに、これらの思考ができるメンバー(UXデ ザイナー 等)が必要だし、エンジニアが持っていると強い ◦ 会話をすることにより、その思考を学習する c.f. 書籍 正しいものを正しく作る
#2 Concentration • 限られたリソースでサービス改善・運用するためにはどうす ればよいか? ◦ 集中 ( = やらないことを決めること)
が重要 • 技術選定 ◦ できる限り、運用・監視が不要なように ◦ e.g. GAE / firebase + expo • 開発の進め方 ◦ セットアップなどは自動化して、ドキュメントよりも動く環 境を整える c.f. アジャイルマニュフェスト 9
#3 Enjoy • プレッシャーがキツイ・・ 前向きに変換するには? ◦ 仕事を 楽しむ こと! •
自分に限らずメンバーが主体的になるためにも ◦ c.f. エンジニアリング組織論への招待 承認欲求を満たす ことの大切さ • ドッグフーディングは当然に、フィードバックや周りの声を聞く ◦ フィードバックの仕組み化(アプリ内で評価を促す・分析基 盤の構築) c.f. スポーツ解説アプリ SpoLive における分析基盤の構築 https://qiita.com/mtskhs/items/ca10f926900303f09bf8 10
Summary • サービス価値向上のために、共通認識をもち自律的に動け る組織となることが大切 ◦ 決めるための、前提知識を共有しておく ◦ メンバーの成長のための会話。役割をオーバーラップで きると強い •
集中するために小さく保つ ◦ アーキテクチャ選定 • 楽しくやる ◦ ドッグフーディング・フィードバックを受ける・周りに発信し てみる ◦ 楽しさを見つける(スキル向上・対外発表) 11
参考書籍等 • 正しいものを正しく作る ◦ https://www.amazon.co.jp/dp/B07SGCH8R6 • エンジニアリング組織論への招待 ◦ https://www.amazon.co.jp/dp/B079TLW41L •
アジャイルマニュフェスト ◦ https://agilemanifesto.org/iso/ja/manifesto.html 12
参考書籍等 • 正しいものを正しく作る ◦ https://www.amazon.co.jp/dp/B07SGCH8R6 「6−2 視座、視野を越境する」 にて、 普段感じていたモヤモヤ(決めたどおりに作る ことは容易だが、それでよいのか)が言語化さ
れて腑に落ちました。 また、チーム内のUXデザイナーとの会話で今 までにない視点(現状仕様が〜だから、ではな くあるべき姿を考える)で考えることができまし た。 13
参考書籍等 • エンジニアリング組織論への招待 ◦ https://www.amazon.co.jp/dp/B079TLW41L 「2-3 心理的安全性の作り方」のアクノレッジメ ントとストーリーテリングの項目で、「承認」の大 切さが述べられている ある行動に対するフィードバック・承認により、
よいチームになっていくことができることを実感 している。 14
参考書籍等 • アジャイルマニュフェスト ◦ https://agilemanifesto.org/iso/ja/manifesto.html ドキュメントも大切だが、「動くソフトウェア」も大切とする考え 方。プロダクトは変化が大きいので変更されにくい「ドキュメント」 よりも「すぐ動かして確認できること」が大切だと感じる。 15