Slide 1
Slide 1 text
新人的ソフトウェア開発サバイバルガイド：
荒野に向かい、瓦礫にぶつかり、
迷子になり、広野に赴く
スクラムフェス仙台2023
のっちまん, こしむ, はるか
Slide 2
Slide 2 text
@notch_man8600
大学4年生（CSM）
最近のマイブーム
Python,レガシーコード,ウイスキー
スクラム,オレオレFW,クラッチ板の摩耗
Slide 3
Slide 3 text
@55koshimu
#ジェンダー#地域の情報格差
#デザイン #広報 #ポケモン
Slide 4
Slide 4 text
@white_light___9
一生のマイブーム
食
Slide 5
Slide 5 text
5
私たちは何を学んできたか？
● ソフトウェア開発のいろいろ...(のっちまん)
○ 概念設計やUMLを描いて単体・結合テスト...までのWFを1年かけて学んだ
○ 筑波大ではenPiTをやったり、開発チームを立て直したり、CSMを取ったり...
● UI/UX、激ゆるフロントエンド(こしむ)
○ 学びの軸は「必要な情報が必要な人に伝わる社会にする」
○ ↑を叶えられるようなデザイン(グラフィックとチームのデザイン)を勉強中
○ スクラムにデザイナーを上手いこと入れられないかなあ
○ 筑波に入りenPiTを受けて、あまりの無力さに横転
● デザイン（はるか）
○ チームとして他者と共創していく中での立ち回り
○ デザイン思考
○ 大学二年生の授業アプリ開発をして、、、
○ 多くのエキスパートを繋げられる橋渡し役になれるよう、多種多様な知識を蓄えたい期
Slide 6
Slide 6 text
6
我々はどこで出会ったの？
Agile PBL祭り！
各大学のこれまでの成果とその高い
教育効果を紹介し、学生社会人を問
わずプロジェクト実践者の相互学習
と交流を目的としたイベント。
(公式HPより)
Slide 7
Slide 7 text
7
What is it?
新人集団が教えが通用しなくなってから
前に進むまでに取り組んだこと
Slide 8
Slide 8 text
8
What is it?
新人エンジニアがプロダクト開発の現場を
生き残るための戦略を知る
Slide 9
Slide 9 text
第1章：荒野に向かう
Slide 10
Slide 10 text
10
アジャイルにはどうやって出会ったの？
● 最近は大学でもアジャイルが学べる
○ さらにはスクラムを取り入れたプロダクト開発も経験できる
○ ◯◯設計や◯◯図を書かない”ソフトウェア開発プロセス”を学べる
● ポジションも多数あり、それぞれの視点で学びを得られる
○ 受講生（一周目）
○ 受講生（二周目以降）
○ TA・SA・メンター
● 最近は運営側にもまわるようになった
○ Coderetreat in Fujimi - connpass (参加学生、スポンサー募集中！)
Slide 11
Slide 11 text
11
0 -> 1の方法論を使ってサービス起案をした経験
● 身近な困りごとを考えて、解決策を考える
● その上でスクラムを取り入れたプロダクト開発を行う
○ ただ理科大ISDは経営学部の必修授業。開発経験はおろかパソコンの操作が怪しい人も。
○ ということで(?)かなりのゆるふわスクラム
○ 筑波大enPiTは情報学部、院の選択授業で、プログラミングの素養はある印象。モチベも高い。
○ ただチーム開発初めてのメンバーも多かった。
● 授業の一貫として行うので、時間的制約はかなり苦しい
○ 理科大は週2コマ(180分)を5週くらい
○ 筑波大は夏合宿(320分×4日)がメイン
Slide 12
Slide 12 text
チーム開発学んだ！
手を動かしてプロダクトも作った！
Slide 13
Slide 13 text
分かる！出来る！余裕～！！！！
ここをこうして、
こうすればいいんでしょ！！
Slide 14
Slide 14 text
私たちはムキムキエンジニア💪💪💪
Slide 15
Slide 15 text
ハッカソン、
出ちゃうもんね～～～
💪💪💪
Slide 16
Slide 16 text
結果…
一次で落ちた！＼(^o^)／
Slide 17
Slide 17 text
第2章：瓦礫にぶつかる
Slide 18
Slide 18 text
18
チームがワークしなくなるまで
ムキムキエンジニア3人でハッカソンに出たのに
一次審査で落ちた！
Slide 19
Slide 19 text
19
チームがワークしなくなるまで
Why?
Slide 20
Slide 20 text
20
チームがワークしなくなるまで
● 教わった通りにやっても、なんか上手くいかない
● 得意不得意を悪い方向に活かして、タスクの巻き取りが大量発生している
● 言葉やプロセスに対して持っているイメージ・ニュアンス、違くない、、？
● 気がついたらゴールがずれている、目指しているものが違う
● →これズレてない？と意見できる人間がいなかった
以上の問題を抱えているのに
終始楽観的である(大問題)
Slide 21
Slide 21 text
21
チームが上手く機能しなくなった原因って？
● お互いのお作法のギャップを把握・吸収できなかった
○ 筑波大enPiT&etc…で学んできたやり方、理科大で学んだやり方
○ ここではこうやったから、は通用しない
○ バックグラウンドの違いを活かすつもりが、お互いを配慮しすぎる結果に、、
● タスクの終了条件が不明瞭
○ コミュニケーション不足
● 教科書に沿ったやり方しかわかっていなかった
○ とにかくマニュアル思考
○ 非 臨機応変
● 知識に依存しすぎた考え方
○ わからないことは当然あるので、その解決方法を自分なりに取りに行ければ良かった
Slide 22
Slide 22 text
22
チームが上手く機能しなくなった原因って？
● お互いのお作法のギャップを把握・吸収できなかった
○ 筑波大enPiT&etc…で学んできたやり方、理科大で学んだやり方
○ ここではこうやったから、は通用しない
○ バックグラウンドの違いを活かすつもりが、お互いを配慮しすぎる結果に、、
● タスクの終了条件が不明瞭
○ コミュニケーション不足
● 教科書に沿ったやり方しかわかっていなかった
○ とにかくマニュアル思考
○ 非 臨機応変
● 知識に依存しすぎた考え方
○ わからないことは当然あるので、その解決方法を自分なりに取りに行ければ良かった
Slide 23
Slide 23 text
23
瓦礫にぶつかる
● 自信の喪失
● やる気の喪失
● 存在意義の喪失
迷子！
Slide 24
Slide 24 text
第3章：迷子になる
第3章：迷子になる
Slide 25
Slide 25 text
25
スクラムを学んだ人が陥りやすい誤ったスクラムの進み方
～振り返りによって可視化された悩み～
● 状況に対する受け止め方が分からない
○ 他の人がすごすぎて…自分は何もできない…死…
○ 苦しいフィードバックを受けて、プロダクトではなく自分が否定されているように感じる。
そのために潰れてしまう…死…
● 教科書的に書いてあった「やり方」を試しても上手くいかない
○ 特にプロダクトバックログアイテムの作成。情報の粒度や終了条件がわからない
● 軌道修正をしてくれる人がいない
○ 今回新人だけチームだったのもあるけど「賢い愚者」がいない環境で突っ走るのは苦しい
Slide 26
Slide 26 text
26
迷宮の脱出方法を考えてみた
● スキルセットを初期段階で共有する
○ 初めにスキルの棚卸しを行う。あなたはいま今何が出来て、何を身に着けたいのか？
○ スキルレベルの違いも大事。差があることは悪いことではない。
● (適度に)型を外れに行く
○ 教科書的学びに縛られる必要はない
○ というか教科書通りにやって上手くいく場面の方が少ない
● ものごとを見る上で、どのような視点を重要視しているか共有する
○ 教えてもらった人、場所によってやり方が違うのは当たり前
○ だから重要視するものも違う。そしてその違いを受け入れる
Slide 27
Slide 27 text
第4章：広野に赴く
Slide 28
Slide 28 text
28
広野に赴く
● 思う存分に腕を振るってプロダクト開発をするぞ！
● しかし、おそらくそれは難しい
○ 荒れた野原を整地し緑豊かな土地にすることはとても難しい
○ 手元の攻略本もチュートリアルでしか頼りにならない
● 攻略本を読み込んだが故に書いていない事象に戸惑ってしまう
○ 現場なんて攻略本に書いてあることのほうが少ないが...
視界は荒野と化し、瓦礫は散乱し、右も左も分からない迷子になり
プロダクト開発は上手く進まなくなる
Slide 29
Slide 29 text
そこで編み出した生存戦略
Slide 30
Slide 30 text
30
新人的ソフトウェア開発サバイバルガイド
● 色々と乗り切った私たちが編み出した1つの生存戦略
● 新人が現場をサバイブするための1つの行動指針
○ あるいは、こういう人が教えてくれたら良かったという願望
● チームが成長していく前段階として持っておきたい心構え
○ チームと会話をする前に個人の面持ちを整わせる
● こういう心持ちで日々頑張っているという共有
Slide 31
Slide 31 text
新人的ソフトウェア開発サバイバルガイド
（個人編）
Slide 32
Slide 32 text
32
新人的ソフトウェア開発サバイバルガイド（個人編）
● 「教えは絶対」という呪縛に対する抵抗
○ 教えられた通りにやっても上手くいかない現実との苦悩
○ 一方で、それしか知らない上にそれに頼らざるを得ない葛藤
● 教科書に書かれてることをやれば上手くいくという発想を捨てる
○ なぜなら、それが出来ているなら誰も困らないから
○ 「教え」はある視点から事象を切り取って体系化されたもの
■ 目先の問題に適応できるかは分からない
● 瓦礫の撤去のやり方を先輩から学ぶ
○ 現実に起きている問題に対して行動を起こす
○ 適切に知恵を授かりながら瓦礫を撤去していく
Slide 33
Slide 33 text
33
サバイブするための知恵の借り方
● まずは行動をしてみる
○ そして、失敗する
● 先輩からのフィードバックを率直に受け入れる
○ 鋭いFBを受けると防衛本能が働いてしまう
○ 現状の行動に対する指摘を「勇気」を持って受け入れる
● 改善ポイントを”具体的”に聞き出す
○ 何が原因か、次回からどうすれば良いのか？
○ あなただったらどうするのか？
■ あるいは、先人の知恵を探ってみる
○ 具体的な行動に落とし込めるまで解像度を高める
Slide 34
Slide 34 text
34
知恵を授かる時の落とし穴
● フィードバックを真に受ける
○ 完璧に主義になると必要以上に神経質になる
○ 行動の改善に繋がる種を掴み取っていく
● フィードバックと評価を取り違える
○ フィードバックはあなたという人に対する評価ではない
○ 「行動」に対する率直な意見、あるいは改善のためのアドバイス
● フィードバックを受ける目的を見失う
=> 良いフィードバックを受けるための行動に変わってしまう
Slide 35
Slide 35 text
新人的ソフトウェア開発サバイバルガイド
（チーム編）
Slide 36
Slide 36 text
36
チームで広野に赴く
● 新人 vsシニアのギャップを超えて価値を生み出すチームへ
○ レベル100のシニアとレベル5の新人
● あれこれ指導するが中々上手くいかない
○ 大学で学んだよね？(あるいは新卒研修でやったよね)
● チームとして見ると、新人の育成をやりつつプロダクトを開発する必要がある
○ 新人とシニアが上手く噛み合ってプロダクト開発をつくる（理想）
○ 指導に対するコストの捉え方
=> 個人に知恵を授けることをコストと思わないマインドセットを持つ
Slide 37
Slide 37 text
37
スクラムの教えから、経験させる勇気を得る
● スクラムの教えを信じる
○ 複雑な問題に対応する適応型のソリューションを通じて、⼈々、チーム、組織 が価値を⽣み出す
ための軽量級フレームワークである [3]
○ スクラムを構成するのは、作業に必要なすべてのスキルや専門知識をグループとして備える人た
ちである。また、必要に応じてそうしたスキルを共有または習得できる人たちである。
● プロダクトとは価値を提供する⼿段である... [3]
○ プロダクト＝ソフトウェアなどの製品だけではない
○ チームの存在も手段になりうるのでは？
● チームを価値を提供する手段と捉え、学ぶ機会をインクリメントの一部とする
[3] Schwaber,k & Sutherland,J. (⾓征典訳)「スクラムガイド」,Scrum Inc. Japan, 2020
(https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf) 2023年8月25日参照
Slide 38
Slide 38 text
38
教えてもワークしない原因を探る
● これまでの学習や研修を乗り越えてきた人が何故動けないのか？
○ ex.) 今回作成したテストケースは概ね良かったですが、欲を言えばXXもあった方がいいですね。
ただ、今回はそこまでやるのはヘビーだと思うので不要だと思います
● テストケースの作成の知識
○ 正常系や異常系のテストケースを作らないといけない[※]
● 「欲をいえば...」では伝わらない
○ トレードオフの基準は何だろう？
■ なぜ、あった方が良いのか？
■ 無くても良いがあった方がより良い
○ 別の似たようなケースでは必要ですと言われてしまうオチ
[※] 色々ありますが私が読んだのはこの本です：
小川秀人, 佐藤陽春, 森拓郎, & 加賀洋渡. (2023). 土台からしっかり学ぶーーソフトウェアテストのセオリー . リックテレコム .
Slide 39
Slide 39 text
39
教科書的な学びだけでは動けない
● 「知識」と「知恵」の取り違いが不幸を生む
○ 知識：知恵を学習や実験により再構成し普遍寄りの形になった経験 [※]
○ 知恵：事象に直面した時に物事の道理を判断・処理する能力 [※]
■ 経験によって身に付く
● 「知識」と「知恵」のコンテキストを捉えるのが難しい
○ 「知識」は学問を通じて一定量を積み上げることができる
○ 「知恵」は現場に出ないと分からない
=> 未知の問題を解決するときは「知識」と「知恵」の双方が必要
※デジタル大辞泉より,https://dictionary.goo.ne.jp/word/%E7%9F%A5%E8%AD%98, https://dictionary.goo.ne.jp/word/%E7%9F%A5%E6%81%B5/, 2022.8.25閲覧
Slide 40
Slide 40 text
40
新人的ソフトウェア開発サバイバルガイド（チーム編）
● 新人がサバイブするために
○ 現状を悲観的に捉えない術を身につける
○ 上手く知恵と取り込み、知識と結びつけレベルアップしていく
● チームがサバイブするために
○ 新人の成長もプロダクトの成長だよという気持ちでコストを払う勇気
○ 学んだ知識を活かすための知恵を授ける
● お互いのギャップを把握しコミュニケーションを図る
○ 「知識」と「知恵」の取り違いに気をつける
○ 「知識」の場合は出典を示す
○ 「知恵」の場合は背景を教える
■ ex.) 巷のFWに反してオレオレFWにする理由を聞いてみた[※]
[※] https://www.youtube.com/watch?v=P62qpuZA3aU
Slide 41
Slide 41 text
まとめ
Slide 42
Slide 42 text
42
失敗したことで、こんな学びがあったよ
● 教わったことがそのまんま使える現場はない
○ もちろん教わったことが生きる場面は沢山あるけど、その時々で臨機応変に動くことが重要
■ 「こんな道具を手にしたけど、ここではどう使っていこうか？」
● 失敗することは恥じることではない、
ただ「失敗しちゃった～」でストップするのは超勿体ない
○ 新人的な価値とは何か？を考える必要がある
■ プロダクトグロースへの貢献はシニアに比べるとできない
● 失敗した経験を持って生き残ることが大事
○ 潰れちゃったら元も子もない
○ だから生き残りの術を考えてみたよ!(^^)!
Slide 43
Slide 43 text
43
ソフトウェアサバイバルガイドのおきもち
● 生き残るための術を身につける
○ 継続的にスキルをキャッチアップする姿勢を身につける
● ある場面において価値を提供できる人材になる
○ 新人的な価値とは何か？を考える必要がある
■ プロダクトグロースへの貢献はシニアに比べるとできない
■ しかし新人だからこそ見える部分は必ずある。慣れによってシニアが見落としてしまう部分を拾え
るのが新人の価値 (こしむ論)
■ 第三者でもない、でも卑近でもない、新鮮で必要な意見を提供できる（はちゃ論）
● チームが成長する経験が価値貢献
○ プロダクトが成長するのであればチームも成長する、チームが成長すれば個人も成長する、個人が成長
すればその個人が入っているチームも成長する、チームが成長すればプロダクトも…
Slide 44
Slide 44 text
冒険の始まりはできないことだらけ
今の状況は誰もが通る道であると状況を上手く理解する
鋭く刺さったフィードバックは成長のチャンス
上手く受け止めながら経験を積んでいく
これまでの学びや経験を活かしつつ
新たなマインドセットでインプットする
つぶれない、絶対に...
プロダクトに貢献できるよう成長していく
Slide 45
Slide 45 text
EOS
(end-of-slide)