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
仕事の効率を考える
Search
thotta
December 08, 2021
Business
0
750
仕事の効率を考える
thotta
December 08, 2021
Tweet
Share
Other Decks in Business
See All in Business
【UI/UXデザイナー職】中途採用向け会社説明資料(テックファーム株式会社)
techfirm
0
320
「みんな、笑顔になぁれ」を実現する 職種混合開発組織の目標設定・評価の改善事例
daitasu
0
240
「使いこなせないかも…」を超えて、BackLogを日常にするまでの話(JBUG Live版)
sho_okawara
0
150
株式会社10X - Company Deck
10xinc
89
1.5M
ブラインドスクエア&キーパンチ
chibanba1982
PRO
0
320
株式会社CINC 会社案内/Company introduction
cinchr
6
65k
20250816 「アジャイル」って?~"Do Agile"から"Be Agile"へ~
east_takumi
0
3k
20250913_AWS アカウント 150 超の組織で取り組む Lambda EoL 対応
tsunojun
1
240
開発生産性、なぜ測れない?指標不在の現状と実践的指標導入の鍵
takabow
0
200
“成果”を出すためのプレゼン準備 プレゼン資料作成の前にやること
bunnchinn3
1
130
Steal This Stack: Automate Your Learning Campaigns
tmiket
0
130
RightTouch_mind
righttouch
PRO
0
2.1k
Featured
See All Featured
Producing Creativity
orderedlist
PRO
347
40k
Build The Right Thing And Hit Your Dates
maggiecrowley
37
2.9k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
30
9.7k
Designing Experiences People Love
moore
142
24k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
162
15k
Thoughts on Productivity
jonyablonski
70
4.8k
Building Better People: How to give real-time feedback that sticks.
wjessup
368
19k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
23
1.4k
How GitHub (no longer) Works
holman
315
140k
Balancing Empowerment & Direction
lara
3
620
VelocityConf: Rendering Performance Case Studies
addyosmani
332
24k
jQuery: Nuts, Bolts and Bling
dougneiner
64
7.9k
Transcript
仕事の効率を 考える Technology&Design 堀田 淑子
本スライドは著作権の関係上、 発表時に利用した画像は一部を残して 削除し公開しております。
自己紹介 堀田 淑子 (ホッタ トシコ) バレットグループ 株式会社 Technology&Design Dept. Development Section WEBアプリケーションエンジニア
PHP/JS(Vue/React)/Java/C#... フルスタックを目指す前に日々の進歩へついてくのに必死。ゲームと生き物が好き。
経緯 業務内容:手順が決まっていたり、資料にも残しやすい 進め方、管理方法:人によって様々で言語化も難しい(癖や好みもある) → 企業OJTで教えてもらえるのは主に上。 でも、タスク管理も仕事にとても大切な要素。 BGで複数プロジェクトの開発・リリースを担当することになり重要度が高かった
ITエンジニアは結果と効率重視 一般的にIT関連の専門知識を持ってればいい、というイメージが強い。 しかし、意外と効率化への関心も高く、様々な開発手法やチーミングに関する最適化が模 索されている。 「どうやれば無駄がないか」を考えるのが大好き。 本の表紙などを載せて発表しましたが、著作権があるので削除しました。 「ITエンジニア 本 おすすめ」とかで検索すると HowTo本がたくさん出てきます。
急がば回れ 前ページでも紹介したように効率良い方を選択しがち。無駄なく進めたい。 でも、そのせいで逆に時間のかかる結果になることもあるのでバランスが大事。 → 基準は自分ではなく発注元。 少しでも不安があるなら確認した方がいい。 「やり直しほど時間が掛かることはない」
失敗例 実装だけが完璧でも、コミュニケーションが上手くいってなければ意味がない。 ・仕様変更(業務のやりなおし) 要件定義や確認が不十分で発生する。 見積もりの意味が無くなりスケジュールが崩壊する原因になる。 ・周知が済んでいない状況での運用変更 前とガラッと変わる場合、関係者全員が後にどうなるか分かっていないと”仕様”なのにト ラブルが起きる。 マニュアル準備や説明の時間が必要か、”仕様”で運用が回るのか、を確認。
問題解決のサイクルを小さくする 完了までを短く設定することで、想定外のタスクが出てくることを減らす。 分からないことを調べる時にも有効。 目指すゴールは見据えながらも、進むときには目の前の問題から片付ける。 調べものをしているとまた分からない単語で説明される時、ある程度のイメージが掴め たら戻り、細かいことの理解は後回しにする。 行ったり来たりで少しずつ理解の解像度をあげていく。
正確なコミュニケーションをとる 言葉だけでは難しい場合、画像なども使って資料をまとめる。 イメージが固まってない場合にはいくつか案を出して比較したり、 過程で確認を挟んで軌道修正するのも効果的。 やりすぎるといちいち細かい人になるので注意。
それ、何のための仕事? ちゃんと理解して業務を行う。 経緯〜要件・仕様が分からないままだと、 完成したものの責任を持てない。 言われたからやる、そう決まってるからやる、 は避けること。 そして正しく疑うためにも「なんとなく」や「雰囲気」で 業務を進めず基礎を大切に。
業務にすると? 直近のプロジェクトリリースまでを振り返る。 なんと納期まで2〜3ヶ月の予定! しかも開発人数は3名!(うち1名は新規参画 SES) 限られた時間・リソースでやらなければいけないので、 本当に必要なものは何かを洗い出す(要件定義)を大切にした。 6月末に話があったところ9/18に予定通りリリース完了、 なんと58件の基礎開発を完了しました。 次の9/29にも12件のリリースをしています。
ありがとうございました!