Upgrade to Pro — share decks privately, control downloads, hide ads and more …

新人的ソフトウェアサバイバルガイド:荒野に向かい、瓦礫にぶつかり、迷子になり、広野に赴く

notch_man
August 26, 2023

 新人的ソフトウェアサバイバルガイド:荒野に向かい、瓦礫にぶつかり、迷子になり、広野に赴く

この資料はScrum Fest Sendai 2023で発表した資料になります。

プロポーザル:https://confengine.com/conferences/scrum-fest-sendai-2023/proposal/18648
イベントHP:https://www.scrumfestsendai.org/

[概要]
私たちは無限の可能性がある価値あるプロダクトを作るためにこれまで学んできた!
私たちはこう習った、道具もある、よしっ!これで行くぞ!!
(と、威勢の良かったチームが1ヶ月後にアマゾンの奥地に迷い込み連絡が途絶えた...)

現代のソフトウェア開発は荒れ地を整え、価値のある建物を作り、継続的に繁栄するように外敵から身を守る・手入れをしなければならないです。そのため、とても難しい問題になっています。そのために、新規のソフトウェア開発は様々なステークホルダーの様々な想いを整理し、ゴールを定め、バックログを組み立てる必要があります。ただ、そもそも要望が曖昧だったりゴールが変わったりバックログは捻じ曲げられる事が多々あるでしょう。私たちのような新米開発者も、このような荒れ放題の要求から本質を見定めて価値のあるサービスを作ることが求められます。

ここで朗報、私たちはベテランから荒れ地を整えるための道具や知恵を多く教わってたばかりです。これを上手く使えば、どんな荒野でも怖くない!しかし、実際に現場に向かうとたくさんの知らなかったことに出くわします。そもそも、チーム内でも学んだ事に対する理解が異なっていることもあります。例えば「チームビルディングをやりましょう!」と聞くと、各々自分が学んだときに使った唯一無二の方法を持ち出してくるでしょう。そうして、チームビルディングも出来ていたはずなのに、ストレートに意見が言えない、認識の差違などが生じます。

私たちは5月からとあるハッカソンに参加するためにチームを結成しました。メンバーは実務経験や大学で開発経験を多く身につけてきた人たちでした。しかし、いざチームとして走り出すと「音信不通になった」「お腹が壊れて動けない」「絶起しました」という些細なことがきっかけに全体のでコミュニケーションが上手くいかなくなりました。そして、提出ギリギリまでアイデアがまとまらず右往左往する状態に。数々のアイデア発想フレームワークを学び、多くのアンチパターンを経験してきた私たちが何故このような状態になったのか?私たちは何も分かりませんでした。

本セッションでは、これまで異なる環境でソフトウェア開発について学んだ筑波大と東京理科大との合同チームが「荒野を頑張って整地しサービスの起案ができる」チームになるまでの軌跡とそこから得られた「新たな旅人」へ道しるべとなる知見をお話します。教科書をなぞれば上手くワークした環境から、自分たちの足で立ったときに直面した「チーム間のコミュニケーション」「お互いの前提知識・認識」の違いを克服するために試みたことについて紹介します。また、これから自分の足で前に進む事になる新人の方の生存戦略を考えるきっかけになったり、シニア層の研修プログラムの設計だったりコミュニケーションなどに活かせるお話をします。

notch_man

August 26, 2023
Tweet

More Decks by notch_man

Other Decks in Technology

Transcript

  1. 5 私たちは何を学んできたか? • ソフトウェア開発のいろいろ...(のっちまん) ◦ 概念設計やUMLを描いて単体・結合テスト...までのWFを1年かけて学んだ ◦ 筑波大ではenPiTをやったり、開発チームを立て直したり、CSMを取ったり... • UI/UX、激ゆるフロントエンド(こしむ)

    ◦ 学びの軸は「必要な情報が必要な人に伝わる社会にする」 ◦ ↑を叶えられるようなデザイン(グラフィックとチームのデザイン)を勉強中 ◦ スクラムにデザイナーを上手いこと入れられないかなあ ◦ 筑波に入りenPiTを受けて、あまりの無力さに横転 • デザイン(はるか) ◦ チームとして他者と共創していく中での立ち回り ◦ デザイン思考 ◦ 大学二年生の授業アプリ開発をして、、、 ◦ 多くのエキスパートを繋げられる橋渡し役になれるよう、多種多様な知識を蓄えたい期
  2. 11 0 -> 1の方法論を使ってサービス起案をした経験 • 身近な困りごとを考えて、解決策を考える • その上でスクラムを取り入れたプロダクト開発を行う ◦ ただ理科大ISDは経営学部の必修授業。開発経験はおろかパソコンの操作が怪しい人も。

    ◦ ということで(?)かなりのゆるふわスクラム ◦ 筑波大enPiTは情報学部、院の選択授業で、プログラミングの素養はある印象。モチベも高い。 ◦ ただチーム開発初めてのメンバーも多かった。 • 授業の一貫として行うので、時間的制約はかなり苦しい ◦ 理科大は週2コマ(180分)を5週くらい ◦ 筑波大は夏合宿(320分×4日)がメイン
  3. 21 チームが上手く機能しなくなった原因って? • お互いのお作法のギャップを把握・吸収できなかった ◦ 筑波大enPiT&etc…で学んできたやり方、理科大で学んだやり方 ◦ ここではこうやったから、は通用しない ◦ バックグラウンドの違いを活かすつもりが、お互いを配慮しすぎる結果に、、

    • タスクの終了条件が不明瞭 ◦ コミュニケーション不足 • 教科書に沿ったやり方しかわかっていなかった ◦ とにかくマニュアル思考 ◦ 非 臨機応変 • 知識に依存しすぎた考え方 ◦ わからないことは当然あるので、その解決方法を自分なりに取りに行ければ良かった
  4. 22 チームが上手く機能しなくなった原因って? • お互いのお作法のギャップを把握・吸収できなかった ◦ 筑波大enPiT&etc…で学んできたやり方、理科大で学んだやり方 ◦ ここではこうやったから、は通用しない ◦ バックグラウンドの違いを活かすつもりが、お互いを配慮しすぎる結果に、、

    • タスクの終了条件が不明瞭 ◦ コミュニケーション不足 • 教科書に沿ったやり方しかわかっていなかった ◦ とにかくマニュアル思考 ◦ 非 臨機応変 • 知識に依存しすぎた考え方 ◦ わからないことは当然あるので、その解決方法を自分なりに取りに行ければ良かった
  5. 25 スクラムを学んだ人が陥りやすい誤ったスクラムの進み方 ~振り返りによって可視化された悩み~ • 状況に対する受け止め方が分からない ◦ 他の人がすごすぎて…自分は何もできない…死… ◦ 苦しいフィードバックを受けて、プロダクトではなく自分が否定されているように感じる。 そのために潰れてしまう…死…

    • 教科書的に書いてあった「やり方」を試しても上手くいかない ◦ 特にプロダクトバックログアイテムの作成。情報の粒度や終了条件がわからない • 軌道修正をしてくれる人がいない ◦ 今回新人だけチームだったのもあるけど「賢い愚者」がいない環境で突っ走るのは苦しい
  6. 26 迷宮の脱出方法を考えてみた • スキルセットを初期段階で共有する ◦ 初めにスキルの棚卸しを行う。あなたはいま今何が出来て、何を身に着けたいのか? ◦ スキルレベルの違いも大事。差があることは悪いことではない。 • (適度に)型を外れに行く

    ◦ 教科書的学びに縛られる必要はない ◦ というか教科書通りにやって上手くいく場面の方が少ない • ものごとを見る上で、どのような視点を重要視しているか共有する ◦ 教えてもらった人、場所によってやり方が違うのは当たり前 ◦ だから重要視するものも違う。そしてその違いを受け入れる
  7. 28 広野に赴く • 思う存分に腕を振るってプロダクト開発をするぞ! • しかし、おそらくそれは難しい ◦ 荒れた野原を整地し緑豊かな土地にすることはとても難しい ◦ 手元の攻略本もチュートリアルでしか頼りにならない

    • 攻略本を読み込んだが故に書いていない事象に戸惑ってしまう ◦ 現場なんて攻略本に書いてあることのほうが少ないが... 視界は荒野と化し、瓦礫は散乱し、右も左も分からない迷子になり プロダクト開発は上手く進まなくなる
  8. 32 新人的ソフトウェア開発サバイバルガイド(個人編) • 「教えは絶対」という呪縛に対する抵抗 ◦ 教えられた通りにやっても上手くいかない現実との苦悩 ◦ 一方で、それしか知らない上にそれに頼らざるを得ない葛藤 • 教科書に書かれてることをやれば上手くいくという発想を捨てる

    ◦ なぜなら、それが出来ているなら誰も困らないから ◦ 「教え」はある視点から事象を切り取って体系化されたもの ▪ 目先の問題に適応できるかは分からない • 瓦礫の撤去のやり方を先輩から学ぶ ◦ 現実に起きている問題に対して行動を起こす ◦ 適切に知恵を授かりながら瓦礫を撤去していく
  9. 33 サバイブするための知恵の借り方 • まずは行動をしてみる ◦ そして、失敗する • 先輩からのフィードバックを率直に受け入れる ◦ 鋭いFBを受けると防衛本能が働いてしまう

    ◦ 現状の行動に対する指摘を「勇気」を持って受け入れる • 改善ポイントを”具体的”に聞き出す ◦ 何が原因か、次回からどうすれば良いのか? ◦ あなただったらどうするのか? ▪ あるいは、先人の知恵を探ってみる ◦ 具体的な行動に落とし込めるまで解像度を高める
  10. 34 知恵を授かる時の落とし穴 • フィードバックを真に受ける ◦ 完璧に主義になると必要以上に神経質になる ◦ 行動の改善に繋がる種を掴み取っていく • フィードバックと評価を取り違える

    ◦ フィードバックはあなたという人に対する評価ではない ◦ 「行動」に対する率直な意見、あるいは改善のためのアドバイス • フィードバックを受ける目的を見失う => 良いフィードバックを受けるための行動に変わってしまう
  11. 36 チームで広野に赴く • 新人 vsシニアのギャップを超えて価値を生み出すチームへ ◦ レベル100のシニアとレベル5の新人 • あれこれ指導するが中々上手くいかない ◦

    大学で学んだよね?(あるいは新卒研修でやったよね) • チームとして見ると、新人の育成をやりつつプロダクトを開発する必要がある ◦ 新人とシニアが上手く噛み合ってプロダクト開発をつくる(理想) ◦ 指導に対するコストの捉え方 => 個人に知恵を授けることをコストと思わないマインドセットを持つ
  12. 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日参照
  13. 38 教えてもワークしない原因を探る • これまでの学習や研修を乗り越えてきた人が何故動けないのか? ◦ ex.) 今回作成したテストケースは概ね良かったですが、欲を言えばXXもあった方がいいですね。 ただ、今回はそこまでやるのはヘビーだと思うので不要だと思います • テストケースの作成の知識

    ◦ 正常系や異常系のテストケースを作らないといけない[※] • 「欲をいえば...」では伝わらない ◦ トレードオフの基準は何だろう? ▪ なぜ、あった方が良いのか? ▪ 無くても良いがあった方がより良い ◦ 別の似たようなケースでは必要ですと言われてしまうオチ [※] 色々ありますが私が読んだのはこの本です: 小川秀人, 佐藤陽春, 森拓郎, & 加賀洋渡. (2023). 土台からしっかり学ぶーーソフトウェアテストのセオリー . リックテレコム .
  14. 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閲覧
  15. 40 新人的ソフトウェア開発サバイバルガイド(チーム編) • 新人がサバイブするために ◦ 現状を悲観的に捉えない術を身につける ◦ 上手く知恵と取り込み、知識と結びつけレベルアップしていく • チームがサバイブするために

    ◦ 新人の成長もプロダクトの成長だよという気持ちでコストを払う勇気 ◦ 学んだ知識を活かすための知恵を授ける • お互いのギャップを把握しコミュニケーションを図る ◦ 「知識」と「知恵」の取り違いに気をつける ◦ 「知識」の場合は出典を示す ◦ 「知恵」の場合は背景を教える ▪ ex.) 巷のFWに反してオレオレFWにする理由を聞いてみた[※] [※] https://www.youtube.com/watch?v=P62qpuZA3aU
  16. 42 失敗したことで、こんな学びがあったよ • 教わったことがそのまんま使える現場はない ◦ もちろん教わったことが生きる場面は沢山あるけど、その時々で臨機応変に動くことが重要 ▪ 「こんな道具を手にしたけど、ここではどう使っていこうか?」 • 失敗することは恥じることではない、

    ただ「失敗しちゃった~」でストップするのは超勿体ない ◦ 新人的な価値とは何か?を考える必要がある ▪ プロダクトグロースへの貢献はシニアに比べるとできない • 失敗した経験を持って生き残ることが大事 ◦ 潰れちゃったら元も子もない ◦ だから生き残りの術を考えてみたよ!(^^)!
  17. 43 ソフトウェアサバイバルガイドのおきもち • 生き残るための術を身につける ◦ 継続的にスキルをキャッチアップする姿勢を身につける • ある場面において価値を提供できる人材になる ◦ 新人的な価値とは何か?を考える必要がある

    ▪ プロダクトグロースへの貢献はシニアに比べるとできない ▪ しかし新人だからこそ見える部分は必ずある。慣れによってシニアが見落としてしまう部分を拾え るのが新人の価値 (こしむ論) ▪ 第三者でもない、でも卑近でもない、新鮮で必要な意見を提供できる(はちゃ論) • チームが成長する経験が価値貢献 ◦ プロダクトが成長するのであればチームも成長する、チームが成長すれば個人も成長する、個人が成長 すればその個人が入っているチームも成長する、チームが成長すればプロダクトも…