2022年春の現実逃避旅行 〇日目・一日目

秋学期の授業をこなし、3月頭締め切りの論文をどうにか提出し、卒業後の進路選択も大詰めという、なかなかにストレスフルな日々から現実逃避すべく、一人で関西方面大回りを演じている。せっかくなので旅行記を書いてみる。

つくば → 渋谷

朝5:45に甚大な眠気を抱えながら起床。前日のお酒が「そりゃまだ体内にいますよ」と言わんばかりに脳にも内蔵にも残っており、すこぶる体調が悪い。猫から心配されるレベルの猫背でもぞもぞと布団から抜け出して顔を洗い髪をとかし、自転車でつくば駅へ向かう。6:57つくば駅発の区間快速で北千住へ。北千住からは東京メトロで渋谷に向かう。春休みの日曜日ということで車内は普段より空いており、道中ずっと座れたのは幸いである。

f:id:sudame:20220315171552p:plain
つくば駅:のんきに写真を撮っているが普通に吐きそう

渋谷

8:30から20:00まで渋谷でアルバイト。この日は近年まれに見るレベルの平和な日だった。この日僕の役割は「同僚たちの手が回らない場面への遊撃」だったが、そんな場面もほとんど起こらず、とにかく暇だった。二日酔い、睡眠不足、ド平和、暖かい日曜日ということで、業務中本気で気絶するかと思った。

渋谷 → 東京

どうにかアルバイト業務(というより時間が経過するのに耐え続ける修行)を終え、東京駅に移動。ド暇だったとは言えアルバイトでかいた汗を洗い流したいと思い、東京駅から20分ほど歩いて銭湯「湊湯」に向かう。湊湯前に到着するも、中の様子が全く確認できない外観にビビりまくる。これは実は怪しい店なのではないかと逡巡し、Googleマップの口コミをおさらいする。不審な書き込みが無いことを確認し、一歩踏み込んだら普通の銭湯だった。なんでこんな危険な雰囲気を出すのだ!と思ったが、外から中が丸見えの銭湯はそれはそれで最悪だなと思い直す。

www.minatoyu.jp

風呂から上がり、東京駅に戻って夕飯を物色する。天下の東京駅だし何でもあるだろうと高をくくっていたが、例の憎きウイルスのせいで店という店がことごとく閉まり散らかしている。かろうじて開いていたベルマートでサンドウィッチを買う。食べる場所が無いので、仕方なく八重洲口のバスターミナルの一角に陣取って腰を下ろす。周りにも似た境遇っぽい人々がわんさと落ちている。サンドウィッチは一口で口の中の水分を全部もっていかれるほどパサパサに乾燥していた。苦り切った顔でなんとか食べきる。

f:id:sudame:20220315171826p:plain
東京駅:田舎者なので東京駅を見るとすぐ写真を撮ってしまう

f:id:sudame:20220315171910p:plain
宝町IC:歩いてたらベストタイミングでつくば号が通った

東京 → 大阪

東京から大阪までは深夜バスで移動する。バスの出発は23:20で、2時間ほど待つ必要がある。バスの発着場である鍛冶町駐車場に行ってみると、駐車場前の歩道にビッチリ若者が集まっている。新型コロナの影響で待合室には出発20分前にならないと入れないため、行くあてのない待ち客が溢れかえっていたのだ。極めて楽しそうでハイテンションな若者グループの間に挟まり、全力で肩をすぼめて文庫本を開く。

深夜バスは値段をケチったため、4列シート2階建てという奴隷船のような仕様だった。固く狭い椅子に身を沈める。通路側だったのが多少は救いだった。出発前の状況から薄々察してはいたが、乗客はハイテンションな若者の率が極めて高い。僕の席の前列の客は横一列に並んだ4人の男性グループで、出発直後の消灯後もずっとモソモソ何か話し合ったりふざけあったりしていた。バイトの疲労もあって僕はすぐに寝入ることができたが、周りの乗客は苦労したことだろう。途中の休憩所で彼らが「全然寝れね―よ」と嘆いているのを見たときは「口を閉じれば寝れるんじゃないですかね」と本気でアドバイスしそうになった。次回深夜バスに乗るときは最低料金+2000円くらいの便を選ぼうと強く心に刻みこんだ。

f:id:sudame:20220315172051p:plain
大津SA:奴隷船

大阪 → 高松

なかなか過酷な深夜バスだったが、寝ることには寝れて、身体はバキバキなものの体力は回復した。大阪で少し休もうかとも思ったが意外に動けそうだったのでそのまま駅に入る。券売機で青春18きっぷを手に入れ、神戸線の新快速に乗る。関西のJR新快速はハチャメチャに飛ばすので景色を見るのが楽しい。

f:id:sudame:20220315174552j:plain
大阪駅:紙版のどこでもドア

姫路で山陽本線115系に乗り換える。JR東海でははるか昔に引退した115系(オレンジに緑帯のアイツ)も、関西では現役も現役である。真っ黄色の車体は「塗装費用をケチるため」とも言われ、末期色と呼ばれている。首都圏を走る列車や我らがつくばエクスプレスは座席がペラッペラのカッチカチでとても長時間座っていられないが、この115系国鉄車両だけあってふかふかなのはお尻に優しい。相生で乗り換えて上郡へ。

f:id:sudame:20220315172330p:plain
相生駅:真っ黄色の115系

上郡では45分ほど時間があったので、改札を出て街を散歩する。特に感動的なこともなく、平均的な街だった。駅前の和菓子屋の店主と目が合ったので「デヘヘ」という表情を浮かべながらどら焼きを買う。普通のどら焼きかと思っていたが中から栗が出てきて少し得した気分になった。コーヒーに合う。上郡から岡山へ。

f:id:sudame:20220315172236p:plain
上郡駅:嬉しい栗入りどら焼き

f:id:sudame:20220315172520p:plain
上郡駅:一人旅のためにあるような良い天気

岡山からは快速マリンライナーに乗り換えて高松へ向かう。快速マリンライナーは高松側の先頭車両が指定席やグリーン車になっていて、先頭で景色を見たければ追加料金を払う必要がある。……のだが、岡山側の先頭車両は普通車なので、逆方向(高松→岡山)の移動では無料で先頭眺望を独占できる。お金を払う人がいるんだろうかと心配になる。鉄道で瀬戸大橋を渡るのは何度やっても楽しい。瀬戸大橋は吊橋なので列車が通るとその重みでたわむ。このたわみによるレールの伸縮を吸収する特殊なレールが橋の両端に付いており、目視できると少し嬉しくなる。空は若干曇っており、絶好調な景色とは言い難い。

f:id:sudame:20220315172625p:plain
瀬戸大橋:微妙すぎてコメントにこまる天気

高松

高松での猶予は1時間半ほどなので、この時間で高松を体感してうどんを食べなければならない。伊予鉄沿いに歩いてまずは一軒目のうどん屋。役所の隣に位置していており、ちょうど昼時だったのでとても混んでいた。旅行用の少し大きなリュックサックが邪魔にならないよう小さくなりながらうどんを食べる。イカゲソ天も美味しかった。駅まで戻って、二軒目は駅すぐそばの店に入る。歩いていたら暑くなったので、冷ぶっかけにする。たけのこ天にウインクされたので付ける。時間的には三軒目も行けそうだが普通にお腹いっぱいになってしまったので、少し後ろ髪を引かれるが高松を離れることにする。たけのこ天にウインクされたのが運の尽きだったと思う。

高松 → 倉敷

良い具合に雲が取れ、瀬戸大橋線は帰りのほうが景色が良かった。運転台後ろにべったりくっついた親子を微笑ましく眺める。お母さんもお子さんもやたらと鉄道に詳しい。鉄道好きはこうやって遺伝していくんだなと思う。

f:id:sudame:20220315172935p:plain
瀬戸大橋:真ん中あたりのがレールの伸縮装置

岡山から倉敷までは引き続き山陽本線115系で下っていく。最初は嬉しかった115系だがさすがにもう無反応で乗り込む。相変わらずふかふかの座席に尻は喜んでいる。尻が喜ぶと言えば、JR西日本の列車は基本的に全列車にトイレが付いているのが素晴らしい。しかもトイレは原則先頭車両に設置されていると決まっているので、異常頻便マンの僕も大安心である。

倉敷

一日目の目的地、倉敷に到着。15時から研究のオンラインミーティングに出席しなければいけないので、駅前をうろついてパソコンを開き声を出せそうな場所を探す。倉敷は到着前に考えていたよりも数段は観光都市で、屋外のそこら中にベンチやら机やらが置いてある。「あちてらす倉敷」という最近完成した官民連携ビルの脇に良い具合の場所があったので陣取る。かなり安定したフリーWi-Fiが飛んでいるのがありがたい。1時間弱ミーティング。後半は少し冷えてきたが、それでも外での作業が気持ちの良い気温である。天気に恵まれて良かった。

f:id:sudame:20220315173046p:plain
倉敷駅:駅前からして観光地

ミーティングを終えて街へ繰り出す。倉敷には美観地区が設定されているらしいのでそこへ向かう。駅に降り立った時点で何となく気づいていたが、カップル率・女性グループ率が異常に高い。普段ゴリゴリ理系の研究棟で10時間以上を過ごしている僕からすれば異次元空間である。人間って男女がだいたい半々ずつ存在するんだったな、としみじみ思う。思えば倉敷観光協会のホームページで「一人旅」のモデルコースがゼロ件だった。そういう街なのである。オシャレな街を歩くオシャレな人たちの間を縫うようにして、全身ユニクロでごめんなさいと思いながら散歩する。

美観地区そのものも綺麗で良かったが、その美観地区にきちんと住民が暮らしているというのがとても良かった。僕が散策したのは16時過ぎくらいだったのでちょうど小学生の下校時間に当たったのだが、小学生の下校グループが美観地区の白壁の家々に一人ずつ帰宅していく様子が見て取れた。僕は観光のためだけの美観地区は冷めた目で見てしまうが、これは良いなぁと思った。

夕食は大通りに面した居酒屋に入った。入店時はガラガラで不安だったが、しばらくしたら満席になった。良いタイミングで良い店を選択できて満足である。焼き鳥がメインらしいので焼き鳥を数本頼み、あとは観光客丸出しのチョイスで、サワラのタタキとママカリ酢を頼んだ。全てとても美味しかったが、サワラのタタキが特に美味しかった。歩き疲れていたので最初の一杯はビールにしたものの、これは料理に失礼だということでさっさと飲み干し日本酒へ移る。またも観光客丸出しで倉敷の地酒「伊七」を選択。地酒は失敗するときは失敗するものだが、これは普通に美味しくて良かった。

f:id:sudame:20220315173229p:plain
倉敷:サワラのタタキ

f:id:sudame:20220315173304p:plain
倉敷:ママカリ酢

一通り飲み食いを終えて気分が良くなったので再び街へ繰り出す。街の真ん中の、小高い山の上にある阿智神社へ行き街を眺める。かなり階段の段数があり酔っぱらいにはなかなか厳しい。ここで転んだら旅が終わると肝に銘じ、九十歳のおじいちゃんばりの歩みで手すりをガッチリ握りしめて階段を降りる。倉敷の街は昼より夜が綺麗だと思った。カップルやグループもどこかに消え、一人散歩している人をちらほら見かける程度である。ただ一箇所、川沿いに和傘が並べられライトアップされている場所があり、そこは観光客が釣れまくっていた。へそ曲がりな僕は足早に通過。

f:id:sudame:20220315173139p:plain
倉敷:夕暮れ一歩手前のエモ雰囲気市街

散歩を終えたらホテルに戻り、大浴場で汗を流して読んでた本の残りを読んで就寝。前の睡眠はクソ硬クソ狭深夜バスのシートだったので、ビジネスホテルのふかふかベッドが大変ありがたく感じる。全ホテルマンに感謝の五体投地をする。

読んだ本

伊坂幸太郎ゴールデンスランバー

www.books.or.jp

現実逃避の旅行にふさわしいかなと思って、首相暗殺の犯人に仕立て上げられた主人公が仙台をとにかく逃げ続けるという本を選んだ。伊坂幸太郎の、最高に伊坂幸太郎らしい本である。何度読んでも伊坂幸太郎は天才だと思う。本の雑誌の書評に「伊坂幸太郎はエクセルを使って本を書いているのではないか」と書かれていたが、まさにそんな感じの風呂敷の広げっぷりと閉じっぷりである(実際にエクセルで本を書いているということはないらしい)。最近Twitterでは伏線回収系の漫画がよくバズっているが、そういうのが好きな人は伊坂幸太郎も好きなんじゃないかと思う。

大学のカリキュラムで「アジャイル開発」をやってきた話

大学のカリキュラムで「アジャイル開発」をやってきた話

僕が在籍している筑波大学には、「enPiT」というアジャイル開発を実践的に学ぶカリキュラムが用意されている。このブログにも今まで何度か登場しているenPiTだが、2021年も参加したので学んだことをレポートする。

enPiTとは

enPiTはもともと文部科学省の直轄プロジェクトで、筑波大学以外にも全国各地の大学で開講されている。公式ホームページから引用すると、enPiTは以下のようなカリキュラムだ。

enPiTビジネスシステムデザイン分野(通称:BizSysD)は、社会やビジネスニーズに対する実用的なソリューションとしてのビジネスアプリケーションやシステムデザインを自ら提案、開発し、顧客の潜在的要求を満たすことのできる人材育成を目指します。

筑波大学では、学生が身の回りの課題を持ち寄り、課題に共感する学生で5人程度のチームを組んで課題解決に取り組む。

enPiTでは、課題の解決はプロダクトの作成を通して行う。プロダクトはwebアプリやモバイルアプリ、物理デバイスなど課題にマッチしたものを選定して良いが、その開発はアジャイルに行う必要がある。

筑波大学ではアジャイル開発の手法の中でも特にスクラム開発に注力している。1回150分の授業時間が1スプリントと定められており、この時間内に「スプリントプランニング」「開発」「レビュー」「レトロスペクティブ」が詰め込まれている。カリキュラムのメインとなる10月からの秋学期には18回授業があるので、150分1スプリントを18スプリント回してプロダクトを完成させる。

学び①:スクラムマスターはスクラムコーチではない

私のチームは大学院生4人で構成されていた。このうち私を含めて2名はenPiTを複数回受講している常連で、さらにもう1人も一度半期だけ参加したことがある学生だった。

チームの半分以上が「スクラムとは何たるか」の基礎的な部分は知っている状態だったので、最初の5回程度のスプリントではチームに明確なスクラムマスターを置かなかった。この理由は、チームのスクラムへの意識レベルが高いのでスクラムマスターをわざわざ置かなくてもスクラムチームになりうるだろうと思ったことと、4人チームでスクラムマスターを置くと開発パワーが下がるのではないかと懸念したことだ。全員がスクラムをきちんと意識すれば上手く回るはず、それより開発の人手確保を優先しよう、というわけである。

結果として何が起こったかというと、私のチームの場合、プロダクトオーナーと開発チームの連携が上手くいかないという事態に陥った。プロダクトオーナーも開発チームも真摯にプロダクトのことを考え、短いスプリントの中で最善の努力をしているにも関わらず、微妙に方向性がズレているような感覚があった。私のチームのプロダクトには「ユーザが速く操作できる」「ユーザが金銭的に得をする」の2つの訴求点があったが、この2つの訴求点をそれぞれどれだけ重視するかというベクトルが、プロダクトオーナーと開発チームでズレていた。

ここでの大きな問題は、プロダクトオーナーも開発チームも「なんだか上手くいっていない」ということには気づいていながら、その原因を探ったり積極的に原因を除去しようとしていないことだった。プロダクトオーナーはプロダクトに、開発チームはインクリメントを生むことに責任を持っているので、チームの状況の改善は二の次になっていた。このようなチーム環境では、プロダクトオーナーと開発チームのズレは大きくなる一方だ。

この状況を打破した施策は「スクラムマスターの設置」だった。スクラムマスターはプロダクトに関する議論をプロダクトオーナーとも開発チームとも違う第三者として一段高い視点から眺めることができる。プロダクトオーナーの方針が開発チームに十分伝わっていないことを察すれば「もう少し詳しく聞かせてください」とより詳細な説明を促すことができる。開発チームが苦しそうであれば「このスプリントでこのゴールへは本当に到達できそうですか?」とプランニングの妥当性の再確認を促すこともできる。

さてここで改めてスクラムガイドを読むと、スクラムマスターの役割は「スクラムガイドで定義されたスクラムを確立させることの結果に責任を持つ」ことに加えて「スクラムチームの有効性に責任を持つ」ことと定義されている。前者はチーム内で達成されていたと思う。達成されていたがゆえにスクラムマスターを置かないという判断をしたわけである。しかし、後者は達成できていなかった。私たちのチームは、スクラムイベントを適切にこなしているにも関わらず「有効に」機能しておらず、しかもその状況を放置していた。なぜかというと、「チームを有効に機能させることに責任を持つメンバー」が不在だったからである。

もしスクラムガイドに定義されている役割がスクラムマスターではなく「スクラムコーチ」なのであれば、私たちのチームにその役割は不要だっただろう。しかしスクラムマスターの仕事範囲にはスクラムコーチングすることだけではなく、スクラムチームを有効に機能させることも含まれるのだ。

学び② 時間見積もりは悪か?必ずしもそんなことはない!

アジャイルコミュニティにおいて、様々な文脈で時間見積もりは後ろ指を指されている。GitHubと連携してプロジェクトを管理するツールであるZenHubは、こう言っている

All estimation techniques are flawed, but some were more wrong than others. Time-based estimates done by individuals not doing the work were the most wrong.

(訳: 須田) 全ての見積もりテクニックには欠陥がある。しかし欠陥にも順位があって、最も悪いのは、実際にタスクを消化しない人が行う時間見積もりだ。

このZenHubの指摘には2つのポイントがある。

  • 実際にタスクを消化しない人が行う見積もりは悪だ。
  • 時間見積もりは悪だ。

前者については私も完全に同意する。「実際にタスクを消化しない人」というのは、自分以外の開発チームの誰かだったり、プロダクトオーナー・スクラムマスターだったり、下手をすればステークホルダーだったりすることが考えられるだろうが、いずれにおいても彼らに自分の仕事量を見積もられるいわれは無い。自分の仕事は自分にしか分からない1

一方で、後者に関しては同意しかねる。時間見積もりを悪だと主張する人の多くは、ストーリーポイントを使って見積もることを提案している。確かにストーリーポイントを用いることのメリットもあるだろうが、時間見積もりは必ずしも悪なのだろうか?

私たちのチームでは、当初、タスクを「小・中・大」の3つに分類することで見積もりを行っていた。あるスプリントのレトロスペクティブで、「小・中・大は扱いづらい。プランニングもしづらいが、レトロスペクティブでどの程度見積もりが上手くいったのかを確認することもしづらい」という指摘が開発チームから出たため、見積もり手法の再検討をすることになった。私はスクラムマスターとしてストーリーポイントを使うのが良いと思っていたが、チームは時間見積もりを選択した。話し合いの結果、それまでの「小・中・大」を「5分・10分・20分」にマッピングすることで合意した。

結果的に、私たちのチームで時間見積もりは大成功を収めた。まず、見積もり時の議論が活発になった。「このタスクは手を動かしてコミットするだけだから5分」「ここでは関数を新しく作る必要がありそうだから10分」「調査タスクは20分で一回切ろう」などと具体的な時間に基づいて計画が練られていく。レトロスペクティブも同様に活発になった。「あの関数は10分で書けると思っていたが、20分かかってしまった。次回からはタスクを分割したほうが良さそう」「こっちのタスクは10分でちょうど良かったね」など、次回のプランニングに向けてチーム内で良いフィードバックをかけることができた。

時間見積もりの成功の裏には、チームの体制がある。私たちのチームは個人でのタスク消化をほとんどしなかった。私たちのプロダクトのほぼ全てのコードはモブプログラミング、あるいはペアプログラミングによって生み出されている。時間見積もりに対する批判の主たるものの一つに「人によってタスクにかかる時間が異なるではないか」というものがあるが、私たちのチームにはこれは当てはまらない。チーム全員で、チーム全体が費やす時間を見積もるため、属人化した時間見積もりをする必要は無い。

見積もりの値を「5分・10分・20分」に制限したこともポジティブに働いた。7分, 8分など連続値で時間見積もりをしようとすると、どうしても見積もり自体に時間がかかり、しかも不正確な見積もりになる。私たちは敢えてざっくりとした見積もりを行うことで、見積もりを過剰に正確に行うことを防ぐことができた。また、20分以上を必要としそうなタスクは、往々にして分解が足りていない不明瞭なタスクである。こうしたタスクはより明瞭化して分解するか、あるいは明瞭化の知見がチームに足りていないと判断すれば、そのスプリントで着手することを思い切って断念した。見積もりの目的は正確に行うことのみではない。極力正確に見積もるのはもちろんだが、見積もりの結果どうであったかを後からレトロスペクティブなどの場で確認することこそが本質的な目的である。見積もりに不必要に時間を費やすことはあってはならない。

スプリントのタイムスケールが非常に短いというenPiTの特性も上手く機能したと感じる。一般的な一週間スプリントの場合、一つのタスクは数時間あるいは一日といった単位のサイズになるだろう。こうなると見積もりと実働の誤差が非常に大きくなり、時間見積もりの意味が薄れる。私たちの場合、最も大きなタスクでも20分に制限しているため、仮に実働が見積もりの倍になったとしても20分の誤差で済む。時間見積もりをするためにはスプリント期間を短くする必要があるかもしれない。

以上のような時間ベースの見積もりを繰り返し行った結果、導入当初は時間の余剰や不足が発生したものの、徐々に適切な見積もりができるようになった。チーム全体としてタスクの分割が上達し、またチーム自身のパワーも時間という指標を軸にして理解することができたのである。

このように、私たちのチームでは時間見積もりが非常に上手く機能した。アジャイルの文脈では忌避されがちな時間見積もりも、適切に用いることで十二分に機能するのではないかと思う。

最後に

enPiTは「チームを、チーム自身がいかに改善していけるか」という点に非常に重きを置いた演習講義である。ともすれば開発・技術の一辺倒になりがちな大学でのチーム開発であるが、enPiTはそれらを内包した上でさらに一段上のレイヤーにタッチできることが素晴らしいと思う。このような演習講義に参加できたことを嬉しく思うし、後輩にもぜひおすすめしたい。


  1. 実際には自分にも自分の仕事の本質は分からないだろうが、自分以外の誰かよりは自分の方が分かっているのは間違いない。

スクラムマスターは必要です

先日スクラムマスターは間違いなく必要だなと思う経験をしたので、文章を書いておきます。

背景:明確なスクラムマスターを置かない

僕が通う筑波大学には、チームを組んでプロダクトを企画立案し、スクラムを用いてアジャイルに開発をするという授業があります。僕はこの授業を大変気に入っており、学部3年生のころから修士1年生の今まで、3年連続で関わっています。

今年の10月からは、修士1年の大学院生4人でチームを組み、「レジ前でどの決済手段で支払うべきか迷う数秒間を消し去る」ようなサービスを作っています。4人のうち僕を含む2人はこの授業との関わりが深く、必然的にスクラムもある程度身に付いています。残る2人は知識としてはスクラムを知っているけれど身に付いているわけではない、といったレベルです。

僕たちのチームでは、チーム結成からしばらくの間(2ヶ月程度)、明確なスクラムマスターを置いていませんでした。もともと見知った4人のチームだし、比較的小規模のチームだし、明確なスクラムマスターがいなくてもスクラムは回ると思ったのです。また、メンバーの半数がスクラムを良く知っているので、スクラム的に困ったことがあればこの2人がスクラムマスター的にチームの行動を修正できると思っていたというのもあります。

結果的に、我々のチームはプロダクトオーナー1名+開発チーム3名という体制でプロダクトを作っていくことになりました。

起こったこと

見た目上は上手く動く

最初のスプリントを開始してから「やはり明確にスクラムマスターを置こう」という結論に至るまで、我々のチームのスクラムは見た目上は上手く動きました。見た目上、というのは、スクラムイベントを実施したり、プロダクトバックログを整備したり、スプリントバックログを管理したりすることはできた(できているように見えた)、ということです。実際、なにかイベントを省略するような方向にチームが動いたり、イベントが長引きすぎて開発時間が圧迫されるというような問題が起こったりすることはありませんでした。スクラムの見た目が上手くいったのは、この開発が授業の一環であるということもあり、チーム全員の「スクラムをやるんだ」という意識が強かったという理由が大きいと思います。

また、この授業では我々チームを観察して神の視点からアドバイスをくれるメンターや教員という存在がありますが、彼らからスクラムの取り回し方について特に大きな指摘をされた記憶も無く、客観的に見てもスクラムっぽい何かは動いていたのだと思います。

プロダクトバックログがブレる

我々のチームにはたしかにプロダクトバックログは存在し、そこにはプロダクトバックログアイテムが順序情報を持って並んでいたのですが、その順序の論理的背景をプロダクトオーナーしか正確に理解できていないという状況に陥りました。プロダクトオーナーはスプリントプランニングの際に毎回どういう理由でその順序でプロダクトを作るのか説明するのですが、開発チームとしてはその説明がイマイチ腑に落ちないのです。開発チームからもいくつか質問や指摘が出るのですが、毎回毎回延々と議論をするわけにもいかず、最終的には「まぁプロダクトオーナーがそう言うなら……」といった空気でタスクスライスに取り掛かっていました。

いま振り返って考えてみても、開発チームの懸念は間違いではなかったと思っています。我々のプロダクトはモバイルアプリで、アプリ起動の導線として「アプリアイコンのタップ」か「ホーム画面ウィジェットのタップ」が設定されています。後者のウィジェット起動はプロダクトオーナーの意向で比較的早期に実装されていましたが、プロダクト全体として見れば、ウィジェット起動による嬉しさ(=価値)を提供できていないような気がします。ウィジェットの実装はもう少し後で良かった、それよりも先に実装すべきものがあった、というのが現在のチームの認識です。

このように、プロダクトバックログのコンテキスト、文脈が上手くチーム内で共有できておらず、プロダクトバックログが(ひいてはプロダクトそのものが)ブレるというのは我々が直面した課題です。

開発チームがブレる

開発チームは、毎回スプリントの最初にプロダクトオーナーを交えてスプリントの計画を立てます。我々のチームも例外ではなく、このスプリントプランニングは比較的丁寧に行っていたと思います。プロダクトオーナーから次回のレビューまでに達成したいプロダクトバックログアイテムを示され、開発チームはプロダクトバックログアイテムをタスクに分割して作業量を見積もり、スプリント内での達成が難しそうであればプロダクトオーナーと協議して妥協点を探る、という基本的なプランニングを確実にこなしていました。

プランニングはそれなりに時間をかけて行われていたにも関わらず、我々のチームでは、作業内容の微妙なズレやコードの衝突が頻発しました。「この関数なんだっけ」「めっちゃコンフリクトしちゃった」というような会話が毎スプリントのように行われ、スプリントが進むと謎のデッドコード(=プログラム中の実行されない部分)が生まれてしまったりもしました。

上手くいっていたかのように見えたプランニングですが、実は開発チームの中で真の意味での合意が取れていなかったのです。このように開発チームは毎スプリント微妙にブレ続け、無駄の多い開発を続けてしまいました。

対策したこと・結果

我々のチームは、見た目上は上手くスクラムが動いているように見えるにも関わらず、プロダクトや開発がブレるという事態に陥りました。プロダクトに関しては毎回スプリントゴールをより明確にしようであったり、開発に関してはコードレビューを徹底しようであったり、いろいろなカイゼン案がでましたが、どれも根本的な処方箋にはなりませんでした。

最終的に、我々に足りないのはスクラムマスターではないかというチームメンバーの発言にもとづき、専任のスクラムマスターを置くことにしました。チームにメンバーを追加することはできないため、開発チームのうち一人(僕)をスクラムマスターに転任させることになりました。開発チームの頭数が減るとチームの直接的な推進力が落ちてしまうのではないかという懸念もありましたが、結局、ほとんど専任でスクラムマスターを置くことになりました。

スクラムマスターを置いた結果、これまでに出ていたようなチームの症状はかなり改善されました。スクラムマスターを置いた日のレトロスペクティブ(振り返り)を見ても、「コミュニケーションを良く取れた」「専任のスクラムマスターを置くのは良かった」「スプリントプランニングで詳細に詰めることができた」などのポジティブコメントはあったものの、「開発力が足りなかった」といった当初予想されていたネガティブコメントは上がりませんでした。

現在のところ、我々のチームとしては、スクラムマスターの設置は非常に効果のあった施策として受け入れられています。

考えたこと

スクラムマスターはプロダクトオーナーの伴侶である

我々のチームでこういった経験をするまで、僕はスクラムマスターを「チームがスクラムガイドから逸脱しないようにするコーチ」だと思っていました。このような認識から、スクラムを知識として知っているチームではスクラムマスターは不要なのではないかと考えてさえいました。しかし、スクラムガイドに「スクラムマスターは、さまざまな形でプロダクトオーナーを支援する」「スクラムマスターは、さまざまな形でスクラムチームを支援する」とあるように、スクラムマスターはプロダクトオーナーや開発チームを支援するためにいるのです。

スクラムマスターは、プロダクトオーナーの最高の壁打ち相手であるべきだと思います。プロダクトオーナーはプロダクトに集中するあまり、自分の頭の中だけで論理を完結させてしまいがちです。スクラムマスターはそんな孤高なプロダクトオーナーから話を聞き出し、プロダクトオーナーの考えを開発チームが納得できるようなプロダクトバックログに落とし込むことを支援する必要があります。

もちろん、こうした壁打ち相手を開発チームが行うことができれば良いとも思います。しかし開発チームはスプリント期間中開発に忙しく、プロダクトそのものを責任を持って考えることは難しいです。また、開発チームの人数は一般に複数人ですから、開発チームと壁打ちをするときは自然とミーティングの開催が必要になります。ミーティングはヘビーで取り回しづらいイベントです。であれば、日常業務としては、プロダクトオーナーはスクラムマスターとの対話を通してプロダクトやプロダクトバックログを洗練させ、開発チームとはスプリントプランニングの場で深く議論をするほうが効果的で健康的でしょう。

このように、スクラムマスターはプロダクトオーナーの伴侶であるべきだと考えます。

スクラムマスターは開発チームの伴侶である

孤高なプロダクトオーナーに対比して、開発チームは文字通りチームです。チームで物事に取り組むに当たって最も重要なことは、チーム内で質の高い合意を取ることです。このためにプランニングの会議を行うわけですが、人間というのは難儀な生き物で、当事者として会議に参加すると、何も物事を理解していないにも関わらず何か分かった気分になってしまうものです。ここで必要なのがスクラムマスターです。

スクラムマスターはスプリントプランニングの会議に非当事者として参加します。スクラムマスターは開発をしませんしプロダクトバックログに対する責任も負っていませんから、非当事者です。スクラムマスターは非当事者のファシリテーターとして会議を客観的に俯瞰し、不明点がありそうなメンバーがいたら質問を促し、自分自身が理解できていないポイントがあれば話題を掘り下げ、会議の参加者に真の意味での理解を促します。

またスクラムマスターはスプリント期間中開発チームを眺め、非当事者の視点から、改善できるところが無いか観察します。サッカーの中継を見ていると、「なんであんな開いてるスペースに走り込まないんだよ!」「どう見ても今シュートできただろ!」と怒り出したくなるシーンを多数見かけます。しかしフィールドに立つ選手たちは、そんな状況を露知らず、地面をかけずり回っています。スクラムでは、フィールドをかけずり回る開発チームを観戦し、「いまシュートいけそうだよ」と直接声をかけられる観客、スクラムマスターが存在します。

スクラムマスターはプロダクトオーナーの伴侶であると同時に、開発チームの伴侶でもあるべきです。

まとめ

  • スクラムマスターがいなくてもスクラムっぽい何かはできたが、プロダクトオーナーと開発チームがそれぞれ孤立して上手くいかなくなった
  • スクラムマスターはただのスクラムコーチではなく、プロダクトオーナーの伴侶であり、開発チームの伴侶である
  • スクラムマスターは必要だ

23歳の1年間と24歳の1年間

本日、9月23日は僕の誕生日である。せっかくなので、23歳として生きてきた2020年9月23日から今日までの1年間を振り返る。

23歳の1年間

大学を卒業

一年の浪人生活を経て2017年に入学した筑波大学情報科学類を、2021年3月に無事4年間で卒業した。1年生のころは広く浅かった人間関係も徐々に狭く深くなり、結局卒業時に「コイツは仲の良い友達だ」と言える人は両手に収まる程度になった。プライベートでの人間関係がそれほど得意ではない僕にとっては上出来の大学生活だったと言えると思う。

卒業論文を執筆

筑波大学情報科学類を卒業するためには卒業論文を執筆し、発表会の場で研究プレゼンを行わなければならない。僕は「アバタを介したコミュニケーションにおける表情模倣の影響評価」というタイトルで論文を書いた。正直、出来の良い論文ではないのは目に見えているし、実際評価も上から2番目の「A」に留まったが、初めて論文を書くという経験ができて新鮮だった。いつも締め切り直前に大慌てになる僕にしては珍しく、余裕を持って書き終えることができたのも成長ポイントだと思う。

大学院入学

筑波大学情報科学類の直上の組織にあたる、筑波大学情報理工学位プログラムに進学した。学部入学時の浪人の苦々しい経験は学部生の4年間ですっかり薄れたと思っていたが、大学院入試に向けて勉強していると嫌でも当時を思い出してしまい、かなり精神ゲージを削られた。しかしそれでも無事に合格を勝ち取ることができ、現在は大学院生活を謳歌できている。ありがたいことである。一緒に勉強していた友人が推薦で不合格になってしまい、僕もとても心を痛めたが、彼も僕と同じ一般入試で無事に合格し、今では毎日のように研究の進捗を話している。入学試験はいつでもドラマチックだと思わされた。

国際学会デビュー

卒業論文を英語化した上で再解析等の手直しをし、体裁をまとめて Artificial Life という国際学会に提出したところ、極めてギリギリの評価ながらアクセプトされた。当然落ちるものと思っていたので、心底驚いた記憶がある。オンラインとは言え、一般書の著書を持つような研究者に向かって自分の研究を英語で発表するのはとても緊張した。質問の英語を聞き取れずに指導教員から助け舟をもらうという失態を犯ししばらく意気消沈していたが、今になって考えると、きちんとコメントも貰えたし、指導教員の研究仲間からの評価も良かったようだし、それほど悪い結果ではなかったのではないかと思う。ところで、Artificial Life の2021年学会はコロナが無ければチェコプラハで開催予定だった。プラハ、行きたかったな……。

アルバイトでちょっと偉くなる

大学1年生の末から続けている小学生向けのプログラミング教育バイトで、勤続年数が物を言い、いわゆるバイトリーダー的な役職に抜擢された。時給が低かったり意思決定が不透明だったりと不満も多いものの、好きな仕事で評価されるというのは純粋に嬉しい。それまでは生徒を観察することが多かったが、この役職に就いてからは他のアルバイトを観察する時間が増えた。それなりに責任を負う場面も増えて大変さもあるが、今のところ楽しめているので御の字である。

Twitterアカウントを捨てる

大学に入学してから卒業するまで、僕は2つのTwitterアカウントを運用していた。1つは本名でやっているアカウント、もう1つはハンドルネームでやっている砕けたアカウントである。普段は後者を使っていた。僕はかなりTwitterが好きで、相当の頻度でツイートをし、時々バズを見せつつ1500人弱のフォロワーを抱えていた。元から治安が良いとは言い難いTwitterというプラットフォームだが、最近は目に余る投稿が増えてきた。Twitterを見ていて面白いなと思う機会よりも、気分が悪くなる機会の方が圧倒的に多くなった。たかがSNSに気分を害されるのは不健全だと思い、半ば中毒のように使い倒していたアカウントを削除した。Twitterだけで繋がっていた大学の知人などとは連絡が取れなくなってしまったが、人間関係は一期一会だから、まぁ仕方ないと思うことにしている。

会社を潰す

僕は友人と会社を持っていたが、その会社を潰した。僕は以前から友人たちとチームを組んでアプリやサービスの開発を行っており、あるときそのメンバーの一人がチームを法人化したいと言い出して立ち上がった会社だった。僕は当時から法人化に反対の立場だったので、会社という形が無くなっても特に寂しさなどは感じなかった。法人というのは、立ち上げるよりも潰す方が面倒なものらしい。立ち上げの方が気分が良いというのはあるのだろうが、実際の事務手続き上も、会社を畳むときのほうが煩雑だったと思う。ちなみにこれは純粋な愚痴であるが、会社としての本社があるつくば市に最も高頻度で滞在しているのがメンバーの中で僕だったので、役所に行ったり郵便物を受け取ったりする実務はかなり僕が行った。法人化に反対していた僕が法人を畳むために駆けずり回るというのは皮肉なものだなぁ、と思った。

ISUCONに出る

ISUCONとは、LINE社が主催する「いい感じにスピードアップするコンテスト」である。中途半端な状態のwebサービスを渡され、それを要件に合うようにスピードアップ、チューニングするというコンテストだ。先に書いた、会社を潰した例のチームで参戦した。チーム名は「haigyo」、廃業である。我ながら良いセンスだと思う。普段は高レイヤのコードばかり書いているので、webの中では比較的レイヤの低い部分を触れたのが楽しかった。狙った作戦が上手くハマらず予選敗退となってしまったが、良い勉強の機会になったので来年もぜひ出場したいと思った。

24歳の1年間

就職先がほぼ決まる

2022年の4月からは大学院修士課程の最終学年となる。今のところ博士課程にストレートで進学する気は無いので、2023年3月に大学院を卒業した後は就職ということになるだろう。ということは、24歳の夏ごろまでには就職先がほぼ確定しているはずである。話が進行中なので社名は伏せるが、ありがたいことに、これまでインターンに行った企業など、すでにそれなりの手応えがある企業がある。自分が行きたい企業に行くことが大前提ではあるが、実利的には、なるべく早い段階で就職先を確保したいと思っている。就職活動よりも有意義な時間の使い方はいくらでもあるはずである。

論文を最低一本は通す

大学院生として生活している以上、論文を出さなければならない。論文を出さないと自分自身のモチベーションを維持できないというのに加えて、良くしてくださっている指導教員や研究室にも申し訳ないというのもある。現在進行中の研究プロジェクトは、まだすぐに論文を書ける状態ではないというのがもどかしいところではあるが、少なくとも24歳の夏ごろには何かしらを成果として出したいと思う。

一人旅をする

僕は一人旅が好きで、長期休みになると青春18きっぷを手に適当な場所にぶらぶら行っていたものだが、コロナの影響で23歳の間は結局どこにも行かなかった。今後コロナが落ち着く保証はどこにも無いものの、今日までの1年間よりは状況はマシになると信じたい。コロナ禍は孤独だと思っていたが、オンラインで一瞬で人に会えてしまうため、逆に一人きりになるタイミングが激減した。一人旅をすれば、強制的に自分だけの時間を作り出すことができる。絶対的に自分しかいない事由な時間を捻出するためにも、24歳の1年間のどこかでかならず一人旅をしたい。ちなみに次は山陰に行きたいと思っている。

Chatworkサマーインターン2021に参加してきた

8月16日から9月3日までの3週間、Chatwork社のインターンに参加してきました。面倒くさがって超遅筆になりましたがレポート書きます。

lp.chatwork.com

参加の経緯

僕は今まで、実際に仕事をしてみないことには得られるものも少ないだろうということで実務に参加するタイプのインターンに絞って参加してきており、BEENOSで Nuxt.js を使ったwebアプリを書いてみたり、freeeで既存サービスのPWA化をしてみたり、日本経済新聞社で新規サービスのAndroid版を立ち上げたりしてきました。実務系のインターンはそれはそれで楽しいし好きなのですが、今夏はオンライン参加で実務的なことをするのも辛そうだということで、インターン用コンテンツのあるインターンを選ぶことにしました。

そのようなことを考えながら毎年お世話になっている「魔法のスプレッドシート」を眺めたところ、文字通り365日バイトで使っているChatworkがピッタリのインターンを募集していたので応募候補に入れました。

調べてみるとChatwork社には最近だいくしー(@daiksy)さんが入社してエンジニアのチーム力を高める取り組みが活発になっていたりDDD本のレビュアーでもあるかとじゅん(@j5ik2o)さんがテックリードを務めていたりと、技術的にもかなり楽しそうな会社なことが分かり、応募することにしました。

2021年のChatworkサマーインターンにはフロントエンドコース(React)とバックエンドコース(Scala)があり、どちらに応募するか迷ったのですが、Scalaは1文字も書いたことが無いな、ということでフロントコースを選択しました。

応募から参加まで

選抜は面接が2回で、コード試験等はありませんでした。エントリーシートもエンジニアとしては標準的なもので、特に困ったことはありませんでした。

面接では応募動機やChatwork社を知った経緯といった一般的なものから技術的な話まで色々なことを聞かれました。1回目の面接は人事の方と面談でしたが、2回目はエンジニア採用の人事の方と人事ではないエンジニアの方の2名で、エンジニアリング的にも少々突っ込んだ話をしました。僕がスクラムあたりのエンジニアのチーム論が好きだという話をしたところかなり話が広がりました。面接の後半で面接官に「実は僕は認定スクラムマスターなんですが」と明かされ、ヤベー変なこと言ってないかと変な汗をかいたのを覚えています。

7月12日には無事に参加確定のメールが届きました。しばらくしてから参考図書が2冊届いたので(1冊は物理本、1冊はPDF)参加までにざっくり目を通しました。

www.books.or.jp

booth.pm

時間を取れなかったので隅々までは読めなかったのですが、特に読まなくても参加自体に問題はありませんでした。ただちゃんと読んでから参加すれば「なるほどな~~~」となる機会は増えただろうな、とは思います。

インターン開始よりかなり前に連絡用のChatworkのグループチャットに招待され、好きな天ぷらを紹介したりしました。ちなみにしそ好きは2人でした。

Screenshot 2021-09-11 at 16-56-40 Chatwork - [新卒] サマーインターンシップ 2021 事前・事後連絡用.png

前半戦:講義パート

3週間のインターンのうち最初の1週間は講義パートとして、インプットに当てられていました。最初に書いた通り僕は今まで実務系のインターンにばかり参加してきたので、インターンで講義があるというのは初体験でとても新鮮でした。Chatwork社の宣伝が多いのかと思いきや、会社についての説明は最初の1-2時間程度のみで、残りは新入社員向けのような技術講義でした。講義パート前半の基礎的な内容は知っていることが多く正直少々退屈に感じることもありましたが、後半はそのようなこともなく楽しく聞くことができました。

前半の基礎講義は「ブラウザにURLを入力してからページが描画されるまでをざっくりと追ってみよう!」とか「セキュリティの基礎の基礎」とか、そういった内容でした。学部生時代のネットワーク系の講義の良い復習になりました。

後半になると「TypeScriptの型でゴリゴリに遊んでみよう」とか「スクラムってなんだよ」とか「丸一日かとじゅんさんがDDDについて語ります」とか、かなり楽しいコンテンツが揃っており、一切飽きずに参加できました。特にかとじゅんさんのDDD講義は密度が高く、これだけで参加した価値があったなという気持ちになりました。

講義と聞くと面倒くさいなと身構えてしまいそうですが、現役エンジニア社員による大プレゼン大会を1週間聞き放題だと思えば面白さが伝わるんじゃないかと思います。

後半戦:チーム開発パート

3週間のインターンのうち後半の2週間はチーム開発パートとして、チームでスクラムを組んでチャットアプリを開発するパートに当てられていました。

このパートは事前に用意されたコードベースをチームで改造(追記?改良?)して新機能を付加するというパートです。Scalaで書かれたバックエンドのコードやReactで書かれたフロントエンドのコード、プロダクトバックログの一部、ストーリーが提供され、それに沿ってチームで開発を進めていきます。

チームは学生参加者4名とメンター(新卒社員と内定者)3名、社員1名で構成されており、開発で手を動かすのは学生とメンターの7名です。主体は学生で、困ったときにはメンターが相談に乗ってくれたり、(恐れ多くも)学生の指示に従ってコードを書いてくれたりする形でした。社員はプロダクトオーナーの役割で、基本的には沈黙して我々を眺めており、必要に応じてチームが呼び出して相談をするスタイルでした。といっても社員の立ち回りはチームによって違いそうで、他のチームではもう少し登場回数が多そうな印象でした。

コードベースはインターンのために相当練られて作られており、バックエンドもフロントエンドも「Chatwork社員が考えた最強のDDD」みたいなコードになっていました。講義で説明されたコマンドクエリ責務分離(CQRS)もコードとして実装されており、なるほどアレはこういうことかという気持ちになれました。

チームとして何を開発するか、どういう手順で開発するかといったことは学生メンバーにほぼ丸投げされており、月曜日に1日をかけて開かれるスプリントプランニングでその週に開発する内容やスプリントゴールを話し合います。毎日の開発はデイリースクラム(朝会)から始まりデイリーレトロスペクティブ(反省会)で終わります。僕たちのチームはレトロスペクティブをKPTでかなり徹底的に行い、毎日チームの何かしらが改善されていくのが実感できてとても楽しかったです。週の最後にはスプリントレビューとして、Chatwork社のCTOや各部門マネージャの前で一週間の成果を報告しました。CTOはもちろんのこと、デザイナーやプロダクトマネージャ、開発マネージャなど様々な方から様々な視点でレビューを貰えたのでとても良い刺激になりました。

開発パートを通して、やはりチーム開発は楽しいなという感想を持ちました。個人開発では自分の考えの範囲でしか開発が進みませんが、チーム開発ではチームメンバーで共有した広い考えに基づいて開発が進みます。チームメンバーの考えを良い具合に束ね、チームとしての出力を大きくするためにも、やはりチームマネジメントというのは意味があるなと思いました。

技術的には、今まで何となく知識としては持っている程度だったDDDを実際に実践できたところは学びが大きかったと思っています。ソフトウェアのモデリングではついつい実装に話が落ちてしまいがち(DB的にどうするかとか、JavaScriptのオブジェクト的にどうとか)ですが、そこをぐっと堪えて真のモデルを見抜くことが大事だし難しいなと思いました。

会社について

ヘラヘラモードと真面目モードの緩急が素晴らしくてメチャクチャ良い会社だなという印象でした。社員間の仲がとても良くしょっちゅう冗談を言い合っているのに、それでいて全然馴れ合いではないというのがすごいなと思いました。インターン途中のCTO面談で「これって自然発生した文化なんですか、それとも意識してるんですか」と聞いたところ「当然意識して作っている。真に社員が考える組織ってなんだろうと思ったらこれが最適解かと思った」といった旨の答えが返ってきて、はえ~~~~となりました。

また、バックエンドはともかくとして、フロントエンド開発でもただ最新技術を追い回すのではなくきちんと丁寧に「ソフトウェア」をやっているという印象があり、その点も大変に好印象でした。他社のインターンを見ても、フロントエンドでDDDといった設計を全面に出しているところは少ないのではないかと思います。

最後に

インターン用に用意されたインターンなんてなぁ、と最初は思っていましたが、良い意味で期待を裏切られたインターンでした。3週間と少々長めでヘビーなインターンですが、来年以降インターンを探す皆さんにはぜひオススメしたインターンです。

インターンを企画・運営してくださったChatwork社のみなさん、大変ありがとうございました!

おまけ

インターンに参加した給料で自宅デスクトップPCのメモリが倍増し、OpenCommで快適にオンライン会議に参加できるようになりました。インターン万歳!

最近のお気に入りの音楽

暇なので(暇ではない)、最近のお気に入りの音楽について紹介することにする。ジャンルはとてもバラバラ。 特段音楽について造詣が深いわけではないのでご容赦を。

Binker and Moses

www.youtube.com

イギリスのジャズバンド。サックス奏者の Binker Golding とドラマーの Moses Boyd のデュオで活動している。踊るサックスと緩急のついたドラムの絡みが気持ち良い。

普段僕はジャズは全然聞かないのだけれど、bandcamp で音楽の発掘をしていたらビビッと来てそれ以来気に入って聞いている。彼らのライブ映像も良い。ジャズのライブは、ロックやポップのライブに比べて緩急が際立っていて楽しいように思う。

www.youtube.com

ところで、Binker and Moses について調べているときに見つけた、同じくイギリスで活動している、チューバ奏者の Theon Cross という人もとても良い。チューバのソロ奏者はなかなか珍しいのではないだろうか。あの巨大な金管楽器を軽やかに弾きこなしていて大変気持ちが良い。

www.youtube.com

Cloud Nothings

www.youtube.com

アメリカのロックバンド。どこかでたまたま3枚めのアルバム「Here and Nowhere else」を聞いてから追っている。かなり正統派な音を鳴らしているので、誰でも聞きやすいのではないかと思う。なんとなく、Oasis を好きな人は Cloud Nothings も好きになれるんじゃないかと思っている。

最近は bandcamp 上で活動している様子。僕は応援の意味も込めてサブスクライブ登録して月に数百円送っているが、サブスクライブすると毎月特典の音楽が送られてくる。季節感のある曲も多くて、毎月の配信が楽しみになる。

cloudnothings.bandcamp.com

こういったバンドには珍しく彼らはグッズ販売にも精力的で、bandcamp内のショップでTシャツやカセットテープ、レコードなんかを購入できる。どれもバンドをよく表現したもので、良いなと思う。金儲けではないのだろう、価格も安い(日本だと輸入になるので高いが)。

Thousandaire

Cloud Nothings を書いたのでついでといった気持ちで紹介するが、Thousandaire というバンドも似た傾向のバンドでお気に入りである。ただ、2020年6月に1枚アルバムを配信したのみで、その後は活動しているのかも生きているのかも不明である。彼らは Cloud Nothings とは違って「俺たちはミュージシャンなので、セールスマンもいないしTシャツも作らないぜ」と言っている。

もったりした気だるいギターが気持ち良いので、もう少し活動してほしい。

thousandaire.bandcamp.com

Downright Sin などはとてもかっこいいし聞きやすいのに、今調べたらYouTubeの再生回数が驚愕の15回だった。YouTube Music からの自動アップロード動画であるのも原因の一つのだろうが、もう少し伸びても良いのではないかとは思ってしまう。

www.youtube.com

ただ、こういうマイナーだけどかっこいいバンドを気軽に見つけられるのは良い時代だなと思うし、 bandcamp は良いwebサービスだな、とも思う。

King Gnu

www.youtube.com

別にインディーズばかり聞いているわけではなくて、最近はどメジャーな King Gnu を聞いたりしている。正直、ロックのような売り出し方をしているのに激烈に商業的なポップ曲というあたりで、King Gnu は僕の嫌いなアーティストに分類されるはずなのだけれど、ポップさに負けて聞くようになってしまった。

CDを買おうと思ったらプレミア価格が付いていたので手を出せなかったが、King Gnu は前身の Srv. Vinci 時代がとても良いと思う。

www.youtube.com

Srv. Vinci 時代のほうが好き勝手音楽をやっている感じがするとは思うが、別に追っていたわけでもないので良く分からない。ただ、King Gnu は常田さんが売れるような曲を書こうとして曲を書き、狙い通りに売れているのではないかな、とは思う。

最近のバンドに多い、バカ売れした上でミュージックビデオに金をかけるという手法は好きでもあるし嫌いでもある。King Gnu はその点ではどちらかと言うと好きになれない側である。

irucaice / いるかアイス

www.youtube.com

ボーカロイドからは、いるかアイスが最近のお気に入り。もうムチャクチャにポップで良い。Twitterのプロフィールに「✧キラキラハッピー曲作り✧」とあるが、まさにその通りの曲ばかり。上にYouTubeリンクを貼った Brand New Day という曲が音ゲーのプロジェクトセカイに収録されて有名になった。ただ、いるかアイス本人はTwitterのフォロワーも6000人程度であり、もう少し有名になっても良いのではないかと思う。曲が一人でバズってしまうとアーティストになかなか目が行かないのだろうか。

Brand New Day が良い曲なのはそれはそうだが、いるかアイスは1枚めのフルアルバム iceQuarium が良いなと思う。ミライリライターは1音目から強烈にポップ。

いるかアイスは同人レーベルの On Prism Records の主催もしている。このレーベルが出しているアルバムの収録曲はどれも強烈にポップで、聞いていて楽しい。一応ダンスミュージックジャンルのレーベルということになっているが、それほどダンスダンスはしていないかなとは思う。

onprism-rec.com

Clown Core

www.youtube.com

完全に頭が狂っている系のバンド。ミュージックビデオでは野外でウンコしていたり簡易トイレの中でドラムとサックスが暴れていたりする。音楽は決してとっつきやすいものではないが、激しくかっこいい。パンクである。

ドラマーとサックス奏者は誰なのか不明という体裁になっているが、 Knower の Louis Cole と Sam Gendel らしい。Knower はまったくテイストが違うが、これはこれでかっこ良い。少なくとも Louis Cole は変態だということは良く分かる。

www.youtube.com

ところで、Clown Coreの大変聞きやすいところとしては、1stアルバムの Clown Core は13曲を収録したフルアルバムであるにも関わらず13分で終わるという点である。狂っているので1曲が短いのだ。

https://open.spotify.com/album/1VPYwjMqtz6hV963WJHHSE?si=JGC2JLsmR7SonGe0PFTZ5w

こういう逝っちゃてる系バンドは短命で終わるのが世の常であるし、もう3枚もアルバムを出しているのでそろそろ寿命な気もするが、もう少し生き延びて欲しい。

以上。

筑波大学enPiTにKibelaを導入した話

筑波大学enPiTにKibelaを導入した話

この記事はenPiT Advent Calendar 2020の4日目の記事です。

昨日は筑波大学enPiT教員、渡辺先生の「enPiT筑波大の小ネタ:実況チャット」でした。実況チャットは楽しいです。リアル授業ではなかなか発言しづらい人が発言できたり、Slackだと誰かの発言に対して様々リアクションできたりと、何かと便利です。コロナが終わった後、コロナ禍で獲得した便利グッズを逆輸入できたら環境が成長するなぁ、などと考えております。

はじめに

enPiT Advent Calendar 2020の初日の投稿では勢い余って自己紹介を忘れたので、この場でご紹介をば。

僕は筑波大学情報科学類4年の須田という者です。ネットでもリアルでも「すだめ」と呼ばれているので、皆さんもそう呼んでください。enPiTは昨年は受講生として受講し、今年は学生メンターとして運営側に関わっています。学生メンターとしての面白さは明日同級生の日高が書いてくれると思いますのでお楽しみに。

今年はメンターとして、筑波大学enPiTに「Kibela」なるものを導入しました。本稿ではKibelaの紹介や導入の意図、導入した感想などを紹介していこうと思います。

チームで得た知見を共有したい!

enPiTはチーム開発を軸とした内容の講義です。enPiT全体での作業は1年を通して10回弱の特別講義に限られ、その他のほとんどの時間は学生5人程度で構成されるチームとして活動します。通常の講義であれば、学生が受ける感想や意見、獲得する知見にはそう大きな偏りが生まれるものではありません。線形代数の授業を受ければ行列の操作ができるようになるし、解析学の授業を受ければ微分方程式が解けるようになります。

しかしenPiTのようなチーム開発を主体とする授業では、チームごとに得られる知見や感想が大きくバラけてきます。一人一人の学生が自らのチームに特化した学びができるのはenPiTの大きな利点ですが、せっかく似たようなことをやっているチームが複数あるのにも関わらず一人の学生は一通りの道筋しか学べないのは非常にもったいないことです。

これはおそらく教員も学生メンターもうっすら思っていたことだったようで、それが故に2020年度はMiroを使ったりSlackを活発にしたりDiscordを使ったりと様々な工夫がなされました。その中の一つに、僕が導入を提案したKibelaがあります。

Kibelaとは?

Kibelaとはチーム内でドキュメントを書いて共有するためのサービスです。

kibela

日本の株式会社ビットジャーニーという会社が運営しており、Markdownでもりもりとドキュメントを書いてチーム内で共有するというwebサービスです。日本企業が開発したということもあり日本語入力が非常にスムーズな他、フォルダ分けでドキュメント整理が楽だったり拡張MarkdownでPlantUMLが描けたりと、ドキュメント共有サービスの中でもかなり使いやすいサービスだと思います。

そしてなにより、Kibela非営利団体であればスタンダードプランを無料で利用することができます。大学組織は当然非営利団体ですから、enPiTを始め様々な学校でのチーム活動にはもってこいのサービスです。

どう使ったか?

筑波大学enPiTでは春学期(この期間、学生は基礎的な技術力を付けるため各自で自主的に学習します)の途中でKibelaを導入して、積極的に活用するように呼びかけました。すると、以下のようなコンテンツが続々と投稿されました。

  • 教員・学生メンターからは

    • JavaScriptでゲームを作成するワークショップ記事連載
    • .NET Coreでwebアプリを作るワークショップ記事連載
    • 昨年の経験を活かした様々な活動の提案や呼びかけ記事
  • 受講生からは

    • 自主学習中に生じたバグの対処を投稿するフォルダ
    • 「自分のために自分がやったことを淡々とノートに残すところ」フォルダ
    • 各種様々な環境構築記事

もちろんこれ以外にも様々な記事が投稿されました。

また、集中的に開発を行う夏休みの集中講義(通称「夏合宿」)では、メンターが応じた技術的な質問とその回答をまとめておく「メンターQ&A」という記事集も作られ、大いに活用されました。

ところで、夏合宿では毎日各チームで1日の反省会が開催され、得られた感想をKeep・Problem・Tryの3つに分類していくというコーナーがあります。反省会の結果はオンライン上のホワイトボードに残るのですが、これを全部スクリーンショットに取って毎日Kibela記事としてまとめたところ、かなり評判が良かったです。分散しがちな知見を少しの手間でまとめるという方向で活用できた点も良かったところの一つだと感じます。

秋学期はそれまでよりもさらにチームの独自色が強くなることもありKibelaの活用頻度は下がりましたが、12月現在では累計81件もの記事が投稿されています。

使ってみてどうだったか?

まず受講生が各自で技術研鑽にあたる春学期で印象的だったのは、受講生が記事を書くことをモチベーションとして学習に当たれたということです。実際、Pythonのwebフレームワーク「Django」を勉強していた学生は自分の学習成果をシリーズ形式でまとめてくれましたし、「React Native + Expoでメモアプリをサンプルに沿って作成してみた」などというQiitaに投稿してもおかしくないようなボリュームの記事が受講生の手によって公開されたりもしました。

また、夏合宿で行ったメンターQ&A記事集は、分散しがちな各チームへの技術支援を一箇所にまとめられたという意味でもなかなか良い試みだったのではないかと思っています。

得られた知見としては、やはりこういったドキュメント化された知見の共有は強い推進役がいないとなかなか浸透しないということがあります。春学期から夏合宿にかけては僕もかなりの頻度で「文字化しよう!」「ドキュメントを書くのは偉い!」「僕も書くからみんな書こう!」と引っ張っていたのですが、秋学期になってからドキュメントを書く文化はかなり下火になってしまいました。どうやって組織にドキュメント共有の価値観を浸透させるかという点は課題かもしれません。

また、今思うこととしては、このKibelaを来年以降も引き続いて使うことでenPiTとしての知見が例年蓄積され数年後には何か面白いことになるのではないかと思います。筑波大学enPiT関係者にはぜひぜひKibelaを引き継いで活用していただきたいという思いでおります。

まとめ

  • ドキュメント共有サービス「Kibela」はいいぞ
  • チーム型の講義ではチーム間での知見の共有が大切だと思うぞ
  • 筑波大enPiTでKibelaを使ってみたが、かなり手応えが良かったぞ
  • ドキュメント共有を文化として定着させるには努力が必要かもしれないぞ

明日のenPiT Advent Calendar 2020は学生メンター日高の「半年間メンターをやって思うこと。」です。お楽しみに!