enPiT雑感

enPiT雑感

はじめに

今回勝手にenPiT Advent Calendarを始めることになった。初日の12月1日には何を書こうか迷ったが、まずはenPiTのおおまかな説明とそれにかける思いを書いていこうと思う。

なお、11月は31日まであるので今日は12月1日である。決して遅刻投稿などはしていない。立派な成人として遅刻などするわけがない。当然である。

enPiTとは何か

enPiTは、文部科学省の企画による大学(院)生を対象とした事業である。お役所の文章によると、その目的

情報技術を高度に活用して社会の具体的な課題を解決できる人材の育成機能を強化するため、産学協働の実践教育ネットワークを形成し、課題解決型学習(PBL)などの実践的な教育を推進し広く全国に普及すること

らしい。さすがお役所、具体的に何が行われているのか1mmも理解できない名文だ。文部科学省に代わって、enPiTで何をやっているのかをこの後の文章で紹介していく。

なお、enPiTは4つの分野から構成されているが、この文章で触れるのは「enPiT BizSysD」と呼ばれる分野である。「enPiT」もさることながら、 「BizSysD」も意味が分からない。お上はenPiTを普及する気があるのだろうか?

筑波大学のenPiT

筑波大学の enPiT は、実体としては週に2回、1回2コマ分の計4コマ講義として開講されている。情報学群の共通科目として開講されており、科目としての分類は学類によって異なるが、僕が所属する情報科学類では主専攻実験(学類3年生が必修するプレ卒業研究のようなもの)として分類されている。

enPiTは講義と言っても学生が行儀良く黒板を向いて席に座り教員が教壇に立って指揮棒を持ち……という日本の大学の一般的な講義とは異なる。この講義では、学生は5人前後のチームを組み、チームごとに課題を設定して課題を解決するための作品を勝手に制作していく。これがenPiTである。

ここまで見れば、工学系・情報系の大学にありがちな、ただのチーム開発形式の実践講義であるかに見えるが、enPiTは異なる。そもそもただのチーム開発形式の講義であれば僕がわざわざこんな文章を書くわけがない。enPiTには僕に筆を執らせる魅力がある。

僕はこんなモノを作れます(ドヤ顔)が通用しない世界

先述のように、工学系・情報系の大学では、個人・チームに関わらず何らかのアプリケーションを開発するタイプの実践講義が広く開講されている。他大学の友人を見ても、2年生か3年生でそういった講義を1つ2つ受講するのは王道パターンらしい。しかしそういった開発系の実践講義は、往々にして「スゲェ技術を使って作った人が勝ち」というような空気が生まれがちだ。大学は学術機関であるから、それ自体は悪いことではないと思うが、優秀な大学生の頭を「スゲェ技術を使ったゴミ」を作るのに使うのは少々もったいないようにも感じる。せっかく作るのであるから、「スゲェ技術は使っていないかもしれないが、価値はあるモノ」を作りたい。

enPiTは後者の立場を取る。すなわち、「スゲェ技術は使っていないかもしれないが、価値はあるモノ」を作るにはどうすれば良いのかを考え、学んでいくのがenPiTである。このように書くと「大学とは知識・技術を身につける場であるから、スゲェ技術を使いこなせる実践講義のほうが良いのではないか」と思われる方もいるかもしれない。たしかに僕もそう思っていた時期があったし、そういう考えもありだろう。ただ僕は、技術は最終的には使われるためにあると思う。とすれば、技術そのものを学ぶことが大切である一方で、技術を上手く活用する術を学ぶのもまた大切なのではなかろうか。

圧倒的な技術を持っていたとしても、作っているものがゴミであれば言葉通り宝の持ち腐れだ。逆に、圧倒的な技術は無いにせよ、「こういったものを作りたい、こういったものには価値があるはずだ」という思考ができれば、それから必要な技術を身に着けても遅くはない。我々に必要なのは「技術をいかにして使うか」というスキルである。

enPiTは「技術を使う技術」を学ぶことができる貴重な場であると感じる。

アジャイルスクラム・その他イケイケ用語について

Twitterで新興の起業家のアカウントを見ると、必ずと言って良いほど「アジャイル」やら「スクラム」やら謎のイケイケ用語が出てくる。そんな謎のイケイケ用語に嫌悪感を示す人も少なく無いだろう。僕も2年前まではそのうちの一人だった。

enPiTでは、上述のように価値のある作品を作るためにはどうすれば良いかということを学ぶ。ここで使われる手法がアジャイルである。アジャイルは、簡単に言ってしまえば「短いスパンで開発とレビューを繰り返し、それによって常にそのとき考えうる最高に価値のあるものを作り続ける」という手法である(と、僕は認識している)。

筑波大学のenPiTでは、夏の短期集中講義(夏合宿と呼ばれている)や秋学期のメイン開発にアジャイルの考え方を導入している。夏合宿は毎日、秋開発は1週間に一度(2020年度は毎日)、作っている作品のレビューを行う。レビューは他のチームのメンバーや教員・メンターを相手に行い、どれだけ進捗が出なくてもどれだけチームが混沌としていても毎回必ず行われる。このレビューによって、作っている作品やチームそのものが否が応でも評価される。チームメンバーは毎授業で何かしらの評価を受け、それを踏まえて自分たちで作品やチームを考え直し、次の授業では改善案を導入して開発を行い、またレビューで叩かれる。これを繰り返すことによって、作品やチームは着実に成長していく。講義ではなく、体感としてアジャイルを学ぶことができるのがenPiTである。

本稿はアジャイルスクラムの紹介記事ではないので詳細は省くが、アジャイルと同じようにスクラムもまた自然とenPiTに取り入れられ、実体を持って活用されている。

アジャイルスクラムは数冊本を読んだところで理解できる代物ではない。そもそも、アジャイルスクラムはそれ自体が目的なのではなく、チームや製品(作品)を効率良く成長させるための手段に過ぎない。先の「スゲェ技術」の話とまったく同じである。enPiTを受講した学生は、Twitterの胡散臭い新興起業家が言う薄っぺらい「アジャイル」「スクラム」などではなく、もう一歩深い部分が見えた上で「アジャイル」「スクラム」を理解できる。これもまた、enPiTで得られる大きな学びの一つである。

へー。ジャンボ文字iitsukaだったわけですね。

これはenPiTの担当教員である川口先生の発言である。iitsukaは僕の同級生のenPiT受講生。enPiTの情報伝達はSlackを用いて行われる。「へー。ジャンボ文字iitsukaだったわけですね。」は趣深い発言であるということでSlackのemojiに登録され、事あるごとに活用されている。

前置きが長くなったが、このエピソードから何を言いたいかというと、教員とSlackで気軽にキャイキャイと話せ、発言を悪ノリでSlackのemoji化してもお咎め無しというレベルには打ち解けられるということだ。これはenPiTそのものではなく筑波大学のenPiTの歴代関係者が築いてきた文化・空気感の賜物なのだろうが、これほど学生と教員の距離が近い講義は極めて珍しいと思う。少なくとも僕はenPiT以上に距離が近い講義を知らない。

これまで述べてきたように、enPiTのメインの目的はより価値のある製品(作品)を作ることである。だが、複雑混沌としたこの世界で、何を作れば価値があるのかなどということは神にも分からない。神にも分からないのだから、教員や学生メンターが分からないのは当然である。教員や学生メンターができることは学生開発チームに対して感想を述べること、疑問を投げかけること、一緒に議論すること、その程度だ。一方的に「こういうものを作れば良い」などということは口が裂けても言えない。学生開発チームと相互にコミュニケーションを取ることは学習のキモ、生命線である。したがって、コミュニケーションのハードルの低さは学びの質の向上に直結する。

学生と教員のコミュニケーションが活発になると、自然と議論が生まれる。夏合宿が終わったあと、(2020年度はコロナの影響もあり)オンラインで打ち上げが実施された。一講義に打ち上げがあるという事自体がなかなかレアだが、その打ち上げが24時近くまで続き、しかも時間が深まるにつれて学生と外部講師との間で激アツな議論が交わされるようになるというのは貴重な環境であると言わざるを得ない。

enPiTの今後

他にも外部講師陣の圧倒的な豪華さや学生メンターの働きなどいろいな魅力を紹介したかったが、今回はこのあたりでおしまいにすることとする。

ところで、これだけ熱く書いてきたenPiTだが、enPiTは2020年度で事業が終了し2021年度以降はenPiTとしての講義は開講されない。目下、筑波大学においては、enPiT関係教員のご尽力により同じような内容の講義が開講される予定だという(そこそこ確実な)噂もあるが、何にせよenPiTの終了は経済面や規模の面から大きな損失である。

最後にポエムなことを書こう。自分の両親が僕ほどの年齢のころ、社会はもっと単純だった。良くも悪くも世間としての価値観が狭く、一例を出せば「男はこういうもの」「女はこういうもの」という今よりも圧倒的に固定された価値観があった。しかし現代に目を向けると、価値観は確実に大爆発を起こしている。何が価値のあるものであるか、その指標は混沌としていて、「こうしておけばOK」という軸は既に無いも同然である。そんな社会において価値のあるものを作っていく難易度は間違いなく上がっており、「価値とは何か」というあまりにもフワウワとしたことを考えるスキルは今後ますます必要になると確信している。

enPiTは「価値とは何か」に対する答えをくれる講義ではないが、「価値とは何か」を考えるきっかけと考え方のヒントを与えてくれる。それも、口先だけの感情が独り歩きした価値観ではなく、モノを作るということを通して実体を持った価値観を考えることができる。今後、enPiTという名前は無くなるが、同じところを目指す講義が維持されることを、一元受講生としては願ってやまない。

Agile PBL 祭りに参加してきた

Agile PBL祭り」というイベントに参加してきました。なかなかエモーショナルなイベントだったので、主催者の皆さまへのお礼も兼ねてレポートしたいと思います。

(イベントのアルバムから、SATE SATE様より)

Agile PBL 祭りとは

イベントのホームページから引用すると、Agile PBL 祭りは

昨今、大学におけるPBL(Project Based Learning)型教育でのアジャイル開発の実践事例が増えてきました。

各大学のこれまでの成果とその高い教育効果を紹介し、学生社会人を問わずプロジェクト実践者の相互学習と交流を目的としたイベントを開催します。

というイベントです。

主催の筑波大学渡辺先生やAttractorの永瀬さんの記事に理念なども含めてイベントへの思いが熱く書かれているので、詳細はそちらに譲ります。

参加した理由

僕は筑波大学の主専攻実験としてenPiTというものを履修していました。この実習は文部科学省の事業の一環で、「課題解決型学習(PBL)等の実践的な教育を推進し広く全国に普及させることを目的としてい」るものです。enPiTでは、実際に自分たちで課題を見つけ、それを解決するプロダクトを作っていきます。作っていく過程にアジャイルスクラムを導入し、プロダクトがより課題にマッチした解決法となりチームがより効率的に動けるようにするにはどうすれば良いのかを学習していきます。

僕が所属していた実験チーム「シスコーン」は読みたい論文をサクサク探すことができる「CatchApp」というプロダクトを作りました。

チームとプロダクトは嬉しいことに身に余る高評価をいただき、今回のイベントにはチームとしてイベントに招待されていました。

ところで、当初Agile PBL祭りが開催された2月20日と21日はAndroidの日本最大カンファレンス「DroidKaigi」に参加する予定でした。見たいセッションもたくさんあり楽しみだったのですが、こちらは新型コロナの流行を受けて中止に。

来年もAgile PBL祭りを開催していただけるなら日程をズラして欲しい(傲慢)

何をやったか

お気持ちは後ほど書くので、まずはやったことを淡々と書きます。

イベントのメインは各大学から集まったPBLの実践者によるセッションと、成果プロダクトのデモ展示です。参加登録のためのconnpassにもそんなことが書いてあります。

セッションでは成果プロダクトそのものの説明だけではなく、そのプロダクトを作る中で何を考えたか、チーム開発の効率を上げるために何をしたかも発表しました。

僕が所属する筑波大学からは3チームの参加でしたが、南は沖縄の琉球大学、北は北海道のはこだて未来大学と、全国の大学からの参加がありました。

チーム名 大学名
使ってもらって学ぶフィールド指向システムデザイン 公立はこだて未来大学
シスコーン 筑波大学
旬のどんぐり 筑波大学
スクラムで研究プロジェクト 筑波大学
イマギレ7 東京工芸大学
じぃ 広島大学
momi 広島大学
kit~と 九州工業大学
WeBSTORY 琉球大学
vip 琉球大学
PiPi 琉球大学

セッションとセッションの間には一時間程度プロダクトのデモのためのフリータイムが設けられています。他のチームのプロダクトをフラフラと見て回ったり自分のチームのプロダクトの説明をしたり、プロダクトとは関係なく先生や社会人の方と雑談をしたりしました。

昼食後には特別セッションとして、会場を提供していただいたDMM.comさんからDMMでのアジャイルの取り組みについてのプレゼンと、スクラムコーチきょんさんからのスペシャルセッションがありました。

イベント終了後には急遽後夜祭が開催され、「参加者のカオスをそのまま居酒屋にブチ込んだらこうなる」としか言えないような飲み会となりました。

参加してみて

Agile PBL 祭りの参加者は僕のような学生だけではなく、大学の教員やアジャイルコーチなどを仕事とする社会人、アジャイルを導入している企業に勤めている方など様々です。学会や技術単位のイベント、就活イベントなどと違い、参加している人のバックグラウンドが多様だったのは今回参加してみて楽しかったところです。

僕たちのプロダクト「CatchApp」はプロダクトそのものだけではなく過程も身に余る評価をいただき、参加者のいろいろな方から感想や意見をもらうことができました。

学生や大学教員からは「ぜひ使いたい」「学生に紹介してみたい」という声が多く聞かれてとても嬉しかったです。一方大学とは直接関係の無い社会人からは「今後このプロダクトはどうするつもりなのか」という大変現実的な質問もいただき、僕たちのチームとしても今一度考えさせられました。一旦区切りを迎えたプロダクトを今後どうコントロールしていくかという部分でも、教育者・学生・エンジニア・マネージャーなど、いろいろな方のそれぞれの立場から数多くの意見を聞くことができ、大変に有意義でした。

印象的だったのは、毎日アジャイルを実践している社会人たちはもちろんのこと、学生が全員とても熱意を持ってアジャイルスクラムについて考えていることでした。イベント終了後には飲み会があり、僕も参加してヘラヘラと話をしていたのですが、はこだて未来大学の学生さんから「スクラムってスクラムガイドに従っていればスクラムだと思う?」といきなり質問されてびっくりしました。彼はなかなかに苦労したスクラムマスターだったとのことですが、飲み会の場においても同期の学生とガッツリそういった話ができるのは新鮮でした。

このイベントは参加者のネットワーキングも主な開催目的として設定されていました。スクラムアジャイルやPBLといった分野からは離れますが、ネットワーキングの面からも個人的には成果がありました。

僕はバイトの関係もあり小学生へのプログラミング教育に興味があります。そこで、参加者の中で実際に小学校でプログラミングを教えたことがある方(株式会社オープンストリームの宮田さん)にお声掛けしたところ、色々と興味深い話を聞かせてくれました。小学生にプログラミングを教える際にはモブプログラミングを用いるのが良いのではないかという話で、大変参考になりました。

(イベントのアルバムから、SATE SATE様より)

コンピュータ関連のイベントではしばしばあることですが、水面下でのTwitterハッシュタグ実況も活発で、これも楽しさの一面でした。例えばDMMさんによるランチセッションの最中、

とツイートしたところ、即レス2人、あとから1人と、3人の方からそれぞれ答えをいただくことができました。どの方もこのイベントが無ければ一生関わらなかったかもしれない方々で、イベントに参加した意義があったなと感じました。

今後について

予想以上に楽しかったAgile PBL祭りですが、PBL教育の先行きはそれほど明るいものではありません。PBL教育の主軸である文科省プロジェクト「enPiT」は、どうやら来年で予算が終了するようです。筑波大からは何も公式情報が出ていないので詳しくは書きませんが、主専攻実験としての現enPiTも今後形が変わっていくとの噂も耳にします。

僕個人としては、ぜひともPBL型の教育は継続されて欲しいと思っています。

現代の社会は従来と異なり、大学を出て大企業に就職すれば安泰という話は通用しづらくなってきていると思います。それと並行して、モノを世に送り出すハードルはかつてなく低くなり、アイデアと技術さえあれば(企業の大小や個人と集団に関わらず)誰もが同じようにプロダクトを評価されるようになってきていると実感しています。

そんな社会の中では、今までの大学における学習のように自分の個としての力を伸ばす学習だけではなく、プロジェクトに基づいて社会に働きかける力を養う学習も極めて重要な学習要素なのではないでしょうか。こういった学習は企業に入ってからするものだという向きもあるようですが、僕としては、社会の様々な面倒ごとから切り離された状態で理想的なプロジェクト運営を学ぶというのは大学にしかできないことだと思っています。

そういった考えから、僕はenPiTは非常に良い実習だったと思っています。大学と企業が非常に良いバランスで関わりあい、現状での最適解に近い学習ができたのではないかと感じています。全員にこのタイプの実習が楽しめるということは無いとは思いますが、PBLだからこそ楽しめるという学生も多いはずです。今後このタイプの実習の規模が縮小するようなことがあれば少なからず残念だと思ってしまいます。

今後に向けて何ら具体的な案を出せず大変歯がゆい気持ちですが、何とかこのタイプの教育が継続されることを、強く願います。

最後に

末筆になりましたが、今回イベントを主催していただいた川口先生、國田先生、永瀬さん、渡辺先生、こういった場を設けていただいてありがとうございました。

僕個人は来年度はメンターとしてenPiTに関わっていくつもりです。来年度もAgile PBL祭りが開催され、また別の視点からイベントを眺められることを心より期待しております。

最後の最後に

enPiTについてのポエムも書こうと思って書き始めたのですが、ダラダラと長くなりそうだったので別の投稿に分けます。多分今年度中くらいには「enPiTを受講して」みたいなタイトルの記事が上がるはず⋯⋯。たぶん。

2020年こそは丁寧な暮らしを実現したい

明けましておめでとうございます。

年末に「彼女欲しい〜〜〜!」とばかりツイートしていたらバイト先で後輩に「須田さん、最近彼女欲しいツイート多くてキツいっす」と言われその場で自害しため、年を越せなかった須田です。みなさんいかがお過ごしでしょうか。

さて、僕は丁寧な暮らしに憧れがあります。常に整った机の上、探しものの無い暮らし。いつでもキッチンは小綺麗で、友人の急な来襲にも一切動じない暮らし。そんな暮らしはなんと素敵なことでしょう。

ところで、僕の現状はこんな感じです。

ダメだ。おしまいだ。 ツイートの端々から足の踏み場もない部屋が想像できてしまう。

僕のツイートをよく見ている人なら、料理のどアップ写真がたびたびアップロードされることにお気づきのはずでしょう。

料理画像がなぜ毎回どアップなのか分かりますか?そう、 部屋が壊滅的に汚いため、引きで撮ると映り込みのせいでとてもツイートできないから です。この写真も、よく見るとステンレスのコップが2つとガラスのグラスが1つ写り込んでいますね。1人で食べてるのになぜコップが3つも写っているかというと、そういうことです。あれは何日前のなんだろう。我ながら汚ない。

これでは女の子に急に 「須田くん、今日、お部屋行ってもいいかな……?」 と言われても断らざるを得ない……ッ!

僕にそんなことを言ってくる女の子はこの先90年は現れなさそうなので心配する必要は全く無いのですが、現実問題、もう少し暮らし向きはなんとかしたい。気づけば年は変わって2020年。2020年こそは丁寧な暮らしを実現させてやる……!2020年の夏はきれいな部屋で彼女と一緒にオリンピックを観戦するんだ!!!

計画

僕のことを多少知る人はご存知の通り、僕という人間は承認欲求マシマシ人間かつTwitter駆動人間という、どこに出しても恥ずかしいタイプの人間です。そのことを逆手に取り、2020 年丁寧な暮らし計画では、Twitterで承認欲求をやんわり刺激することで暮らしを矯正する作戦にしたいと思います。

具体的には、毎日自分の「暮らしの丁寧度」を自動でツイートするようにしましょう。1日のうちにこれだけはやりたいな〜と思う項目を洗い出し、100点満点で点数を付けておきます。その内の達成できた項目の合計が「暮らしの丁寧度」です。

丁寧項目は1ヶ月に1回見直す予定ですが、とりあえず初月たる1月はこんな感じにしてみました。

  • 22時以降はTwitterに投稿しない : 30点
  • 平日は毎日NHKのニュース英語をやる : 20点
  • 1日30分以上は紙の文字を読む時間を確保する : 20点
  • 平日は毎日掃除機をかける: 10点
  • 8時に起床する : 10点
  • 25時には就寝する : 10点

なかなか継続が難しそうな項目もありますが、「22時以降はTwitterに投稿しない」とかは超楽勝ですね。そんな、いくらTwitter駆動人間と言ったって寝る前の2, 3時間Twitterを我慢するくらい余裕中の余裕です。

ちなみに 平日は毎日NHKのニュース英語をやる は英語教師の母に教わった学習法です。今年はTOEICも受けなきゃいけないし、英語やらなきゃな、という気持ちです。

完成

2日間程度コーディングしまして、1月4日の深夜から稼働を開始しました。目標に「25時までに寝る」というものがあることを踏まえて、深夜3時に集計&ツイートということになっています。

初日の成果は60点。さて、その内容を見てみると……?

「22時以降はTwitterに投稿しない」とかは超楽勝ですね。そんな、いくらTwitter 駆動人間と言ったって寝る前の2, 3時間Twitterを我慢するくらい余裕中の余裕です。

余裕中の余裕でした。

ちなみに、設定した丁寧項目は1月2日から試してみているのですが、なかなかバランスも程よく、我ながら良い設定だったと思っています。

これから障害が起きない限りは毎晩3時に丁寧度がツイートされる予定ですので、見かけたらそっといいねでも押してください。ツイート見てるんだぞアピールをされればされるほど僕の暮らしが丁寧になるはずです。

まとめ

  • 2020年は丁寧に暮らすぞ
  • コーディング書き初めもできたぞ
  • 22時以降にツイートしないのは疼く右手を抑えるのが大変すぎるぞ
  • いいねしろ

末筆ではありますが、僕に関わってくださっているみなさん、本年もよろしくお願いいたします。

蛇足

しょうもないことしかやっていないので敢えて書きませんでしたが、一応どうやって作ったか書いておきます。本当に大したことをやっていないのでアレですが。

構成

以下のような構成になっています。

フロント側

丁寧度を計算するためには「今日は何ができたのか」を登録することが必要です。寝る前にまとめて登録するのでも良いかと思ったのですが、せっかくなので達成したらその都度登録したいです。

webアプリにしてブラウザから登録するのでも良いかなと思ったのですが、ブラウザをいちいち立ち上げて登録するのは面倒臭がって3日坊主になりそうだとも思ったのでFlutterを使ってモバイルアプリ化しました。PWA(普通のアプリと同じように開けるスゲェwebアプリ)という作戦もありましたが、Flutterを選んだのははまぁ気分です。

見ての通り、チェックマークをポチポチすることで達成/非達成を登録できます。押した瞬間にFirestoreに保存されるので、ギリギリでの達成も大丈夫です。

ところで、今回GitHub ActionsとFirebase App Distributionsを連携させて(無駄に)CI/CD化しました。GitHubのmasterブランチに新規コミットがPushされた瞬間テストとビルドとデプロイが走り、問題なければFirebase App Distributionsでビルド済みのアプリが配信される仕組みです。

GitHub Actionsは初めて使ってみましたが、個人開発でもモリモリ使えるほど気軽でびっくりしました。FlutterやFirebase App Distributionsのようなある程度名のあるサービスならば、既存のActionsをつなぎ合わせるだけで動作してくれます。素晴らしい。

Firebase App Distributionsも初体験ですが、そもそも個人開発では全くメリットを感じないサービスなのでなんとも言えません。ただ、Firebase中心のモバイルアプリならば、他のテスト配信サービスを使わなくてもFirebase単体で全然行けるんじゃないかと思いました。

サーバ側

こちらはフロント側にも増して何もやっていません。

超良くあるであろう構成で、Firestoreにデータを保存、Google Cloud PubSubで定時実行をトリガーしてメインの処理はFunctionsにやらせるという流れです。

今回はOGP画像は動的に生成するのではなく、事前に全部生成しておいて使いまわしています。点数は0点から100点までの整数値ですから、101枚画像を生成して全部サーバに投げておけばOKですね。画像の生成にはPython/Pillowを使いました。

OGP画像はTwitterに投稿したときに目を引きやすいように(クソ迷惑)、背景色をキツめにしてみました。丁寧度に応じて背景色が変化します。

特に黄色、めちゃめちゃ目が痛いですね。出さないようにしていきたいものです。

今後

一応、少し手を加えて(固定値になっているところをゴニョっとして)やれば僕以外も使えるようにはなっているので、使ってみて超絶効果があればサービス化するかもしれません。超絶効果は無いであろう上に大した成果物でもないのでサービス化しないと思います。

ところで、ここまでの開発はCI/CDやFunctions、PubSubを含めてすべて無料枠で実装できました。ここから5000ユーザ弱くらいまでなら無料枠の中でギリギリ対応できそうな気がします。せっかくだし普段使っていないAWSやAzureを使ってみようかとも思ったのですが、やはり個人開発では価格面からもFirebaseを使うのが最適解な気がしました。

最後に

2019年は何かと理由を付けてダラダラする日々が多かったように思います。2020年は大学も4年生となり研究室生活も始まることもあり、今まで以上に学びのある年にできればなと思っています。

これが新年だけのボヤキに終わらぬよう、せいぜい頑張る所存でございます。

2020年も、何卒よろしくお願いいたします。

須田のスクラム元年の所感

この投稿は Jsys Advent Calendar 2019 の 21 日目の記事です。

前の投稿は soyoil 氏のゲームボーイサウンド入門でした。記事内にある再生ボタンを押した瞬間 PC がぶっ壊れたのかと焦りましたが仕様でした。

はじめに

こんにちは。Google Home に「仕事に合う曲を流して」とお願いしたところ「Google Play Music で仕事 OFF モードの J-POP を流します」と返され、すこぶるポップな曲が流れる自室でキーボードを叩いている須田です。皆さまいかがお過ごしでしょうか。

主専攻実験でenPiTを履修したのを皮切りに、2019 年は僕にとってスクラム開発元年でした。今回は、スクラムに初めて触れた人間がスクラムで成功したり失敗したりした話を書きたいと思います。

スクラムとは

スクラムとは、ソフトウェアの開発技法の一つで、近年盛んに取り入れられている技法です。原典はこちらです。公式認定の和訳 PDFも配布されています。

スクラムそのものを解説しだすとそれだけで本が 1 冊書けてしまうので本投稿では詳細な説明は省きますが、猛烈に雑に説明すると以下のような感じです。

  • チーム全体で足並み揃えてガッとやる
  • 製品に必要な要素を書き出して順番に並べニヤニヤする
  • 固定された期間(スプリント)を切ってモリモリと開発する
  • スクラムガイドに設定されたイベントをペッとやる

スクラムは開発技法のフレームワーク的な立ち位置です。アプリケーション開発にフレームワークを使うときは、フレームワークに従う範囲内で自分で工夫して自分に合うようにカスタマイズしますが、スクラムもそれと同様、スクラムガイドで定義された範囲の中で自分たちの開発スタイルに合うよう様々な工夫をすることができます。

出会い

唐突ですが、僕は不必要な横文字が嫌いです。「コンセンサスを取る」とか「ショートノーティスで申し訳ないです」とかそういう文脈じゃないのに言ってくる人間とは友だちになれる気がしません。「意見を一致させる」「急なお知らせで申し訳ないです」と言えばいいじゃないか。何をカッコいい人ぶっているんだ。

そんなことを 365 日 24 時間思っている僕なので、「アジャイル」とか「スクラム」とかいう言葉に対しても「アジャイル(笑)」「スクラム(笑)」と斜に構えた態度を取っていました。

さて、ときは 2019 年 4 月。筑波大学情報科学類では、3 年生の 4 月に主専攻実験を決める必要があります。僕も例外ではなく、テーマ一覧とにらめっこしつつ何を履修するべきか考えました。するとテーマ一覧の中に燦然と輝くこのテーマが。

PBL 形式によるネットワークサービス開発(enPiT)

春 AB と春 C の期間前半は各自が自習ベースでシステム開発のための基礎技術を学びます。 その後、春 C の1週間に集中演習を実施し、アジャイルなチーム開発について学びます。

すごくムズムズする。「PBL」ってなんだよ。こんなゆるふわそうなテーマに実はあるのか?「アジャイル(笑)」君もいるじゃないか。よし、ここは一つ履修してバカにしてやろう。

こうして、僕はスクラム開発を学ぶ主専攻実験「enPiT」を履修したのでした。これが僕のスクラムとの出会いです。

enPiT 春〜夏 チーム開発

主専攻実験 enPiT ではチームを組んで実際に製品を開発します。初めに履修学生各々が持ち寄った「解決したい課題」を元に、気になる課題に集ってチームを構成します。選んだ課題を元に、どうすれば解決できるのかを考え、製品の設計・開発を行っていきます。

スクラムでは、「プロダクトバックログ」というものが非常に重要なものとして扱われます。「プロダクトバックログ」とは製品に必要な要素を洗い出し、製品にとって重要度が高い順番に羅列したものです。製品を開発する際は、羅列した要素の上から順番に実装を進めていきます。こうすることで、開発中の製品に常に最大の価値を与え続けることができます。

さて、僕が所属していたチームではある種の Web アプリケーションを開発することになりました。

ある程度の規模の Web アプリケーションを作るとなるとユーザの認証をしなければいけないことがほとんどです。僕が普段個人で開発するときは「どうせ後で必要になるなら」「割と基盤的な機能だし」と、ユーザのログイン周りをかなり初期から実装することが多いです。

ところがこの主専攻実験 enPiT はスクラム開発の実験。「ユーザのログインは必要だよね〜」と当然のように話していたところ、講師の一人に言われました。

「それは君たちの製品の最も味が濃い部分なのかい?」

と。たしかに、ユーザがログインできるからと言って課題は 1mm も解決されません。必要か不必要かより、課題の解決のためにどれだけ重要かを元に開発順序を決めることがスクラム開発では重要なのです。

freee 株式会社 インターン

夏休みは freee 株式会社にインターンに参加させてもらいました。2 週間のプログラムで、実際の開発現場に入って製品の開発に携わるという内容のものです。

これはおそらく偶然なのですが、僕が配属されたチームはかなりスクラムに忠実な開発スタイルを取っていました。僕のチームでは 2 週間を 1 スプリントとしており、運がよいことに僕が配属された 2 週間はスプリントにピッタリ合致していました。

インターン初日、簡単な入社説明会を終えるとチームメンバーは会議室でスプリント計画ミーティングをしていました。後半しか見られなかったのが残念ですが、ザックリとしたタスクの洗い出しをやっていたように思います。

enPiT での開発では、スプリント内での開発はほぼスケジュールどおりに進みました。まだ製品は開発途中なので運用中の製品からのバグはありませんし、社会と隔絶された大学内での実験なので波風が立つことはほぼ皆無です。しかし実社会での製品開発は面白いほどスケジュールどおりに進みません。表面化こそしないもののバグは大小含めて山のように見つかり、外部に頼んだ仕事は期日どおりに返ってきません。

スクラムではこういった事態に柔軟に対応するため、デイリースクラムというイベントが設定されています。デイリースクラムは毎日決められた時間・場所で 15 分間開くミーティングで、進捗報告や次のデイリースクラムまでにやることの報告、何か開発に関わる問題があるかの報告などの報告を行います。デイリースクラムのタイムリミットは 15 分ですが、デイリースクラム内で何か問題が報告された場合、デイリースクラム直後に問題を解消するための話し合いがもたれることもあります。

僕が所属していたチームではデイリースクラムが極めて効果的に機能しており、非常に感動しました。僕のチームは、何も知らない僕がインターンとして参加していることで非常にイレギュラーな状態になっていましたが、デイリースクラムで現況を報告することでスプリント全体としてスムーズに開発が流れていたように感じました。

スプリントレビューもスクラムガイドに忠実に行われていて感動しました。スプリントレビューとは、スプリントの最後に行われるスプリントの反省会のことで、そのスプリントでどんな開発が進み、製品に対して新たにどんな価値を付与できたのかを議論するミーティングです。このミーティングにはステークホルダーたるいわゆる「偉い人」や営業周りの人、他チームの人も参加して活発な議論が交わされていました。

Feedal

僕が開発に参加しているエンジニア向けの情報収集サービス「Feedal」でも、一時期スクラム開発を導入していたことがありました。

これは結論から言うとスクラム開発が失敗しました。

Feedal は学生のみのチームです。しかもメンバー全員がそれぞれかなり多忙で、Feedal に対して割ける時間はメンバーによってもタイミングによってもまちまちでした。スクラム開発では、一定の期間を区切りその中でタスク管理を行います。スプリント管理の前提は開発チームメンバーの参加度合いが予測可能なことです。メンバーがどれだけ Feedal に時間を使えるかが不透明な状態では、スプリントの計画を立てることはできません。Feedal では一応スプリント計画ミーティングの時間を持っていましたが、どう頑張っても計画どおりに開発することはできませんでした。

ただ、メンバーの予定をうまく調整するとか目標を引き下げるとか、スクラム開発を回す方法はいくつかあったはずです。それでも上手くいかなかった最大の理由は、スクラム開発への意識の低さがあると思います。これは偏にスクラムマスター(スクラムを上手く回すよう調整する役割の人)である僕が悪いと思っています。

多くの開発技法と異なり、スクラムはエネルギーを持ってスクラムを動かす必要があります。スプリント計画ミーティングやスプリントレビュー、レトロスペクティブ(チームとしてのスプリント反省会)などは時間をかけた重たいイベントです。スクラムを導入する以上はこれらのイベントを着実にこなしていく必要があり、これらをサボるとその瞬間スクラムは崩壊します。

企業などが責任を持ってスクラムを運用するならばまだ良いと思いますが、ごく少人数のゆるいチーム開発でスクラムを導入するのは少々覚悟が必要なのかなと感じました。

また、そもそも Feedal のような 4 人だけのチームでスクラム開発を用いるメリットはあまり大きくないのかもしれないなとも感じました。

Jsys に活かせるのか

少なくとも僕がいた代の Jsys にスクラムを導入するのは現実的に無理でしょう。メンバーの参加度合いはバラバラ、実行委員会の特性からしても仕様変更が多すぎてお話になりません。Jsys のメンバー全員が開発内容に対してコンスタントに積極的であればまだ可能性はありますが、そういうわけでもありません。メンバーもそれぞれ忙しいですし、スクラムイベントをこなせるようには思えません。

ただ、スクラム開発からいくつか活かせる部分はあるように思います。

例えばプロダクトバックログのようなものは定義しても良いでしょう。プロダクトバックログはタスクの羅列ではなく、製品に必要な要素の羅列です。羅列する粒度をタスクほど細かくしてしまうと管理が非常に面倒くさくなりいずれ破綻しますが、プロダクトバックログのレベルの粒度であればまだ管理はしやすいと思います。「あと何を作れば完成なのか」がメンバー間で共有できるのはモチベーション維持にも向いていると思います。

他にも、スプリントレビューは活かせる部分かもしれません。学園祭実行委員会には「総会」と呼ばれる委員会の会員全員が集う場がありますが、この場で「前回の総会から今までにどんな機能が追加されたのか」「次の総会までに何をやるつもりなのか」あたりは報告すると楽しいかもしれません。そのためには常に会員全員が製品を見られるようにする必要がありますが、そうすること自体にも意味があると思います。

最後に

4 月から今まで約 8 ヶ月の間スクラムに関してはそこそこ真面目に考えてきたつもりですが、まだまだ分からないこともあり、自分の中で何がベストプラクティスなのかはさっぱり分かっていません。

今後、スクラム開発の経験値をさらに積んだり他の開発技法の開発チームに携わったりしてスクラムに対する見方が変わったり進化したりすることは大いに考えられます。

来年のどこかの Advent Calendar でも開発技法に対する考えをポエムにできれば良いなと思っております。

ところで

久々にこんなにクソ長いつまらない文章を書いてしまい自分でもビックリしています。俺ってこんなにつまらない文章書けたんだ。まだうんこの話のほうが面白いぞこれ。マジで。

我々は何から手を付けるべきか

TL;DR

  • 須田の自慰ポエム
  • プロダクトやプロジェクトの意義を忘れないようにしたいよね
  • たとえコストが高くても、コア機能から実装していきたいよね

本文

最近、大学の主専攻実験のチームやプライベートで組んでいるチーム、バイト、あるいは個人で様々なプロダクトやプロジェクトに携わるようになってきた。それらの多くはまだこの世に存在しないものを自分たちで生み出していくようなプロダクトやプロジェクトである。そういった企画たちに携わっていく中で、「我々は何から手を付けるべきか」ということを考えるようになった。日記ついでに文章にまとめておく。

結論から言えば、何か企画を始めるにあたってまず手を付けるべきことは、「この企画はいったいどんな熱量を持っており、我々はこの企画の何に惹かれて集まったのか」をメンバー全員で確認するということである。自分たちが今まさに始めようとしている企画は自分たちや自分たちの周りをどう変えるのか、自分はこの企画が実現すれば何が嬉しいのかを確実に明確にし、忘れぬようにする必要がある。

企画が上手くいかず、志半ばで挫折せざるを得ない場面は多い。その原因は様々である。資金の不足、人員の不足、ライバル企画の存在……数多くの原因が考えられるが、僕が最も恐れる挫折の原因は「飽き」である。

人間は思いのほか飽きやすい。刺激が無くなれば一瞬で人間は飽きていく。ほとんどの企画は、飽きられた瞬間終了する。飽きるのは企画を提供される側だけではない。企画を提供する側、すなわちここで言う「我々」も、「人間は飽きる」という運命から簡単には逃れることはできない。

人間を飽きさせないためには刺激が必要である。企画における刺激とは、企画そのものが持つ熱量に他ならない。企画を提供する我々は、企画自身が持つ熱量を常に外部に提供し続けなければならない。刺激の供給が企画の被提供者を飽きさせないために必要であるのは言うまでもないが、刺激の供給は企画の提供者である我々を飽きさせないためにも必要である。企画の持つ熱量を適切に扱っている間は、我々は決して飽きることはない。

その形式は企画の種類によって様々であるが、企画にはリリースがある。リリースとは、我々が準備してきた企画を外部に公開することである。例えば企画がサービスの開発であればまさに言葉そのままの意味のリリースであり、イベントの企画であればイベントの開催がリリースに当たる。

我々はリリースに際し、その時点で我々が提供できる「企画の最も味の濃い部分」を提供しなければならない。我々がリリースに際して考えるべきことは「今回の我々のリリースは企画の持つ熱量を全力で伝えられているのだろうか」という一点に限る。「この部分は実現が簡単だからリリースしてしまおう」などといったことは考えてはいけない。そんなことをしてしまえば、人は一瞬で飽きる。飽きられた企画の再起は容易ではない。

例えば Twitter を開発することを考えてみよう。Twitter を完成させるためには、やらなければいけないことが山のようにある。ユーザの認証が必要である。クールで素敵な UI デザインも必要だろう。ダイレクトメッセージも欲しいところだ。さて、我々は何から手を付けるべきだろう?お察しのとおり、我々は今挙げたいずれの機能の実装も初めに手を付けるべきでは無い。Twitter のコアは「誰もが気軽に思ったことを投稿できる」という部分にある。これを実現するのは非常に簡単である。web ページを 1 枚作り、ど真ん中にテキストの入力欄を配置するだけで良い。これで「企画の最も味の濃い部分」の実装は完了した。さて、次に味の濃い部分はなんだろう?せっかく投稿したのだから、投稿された文章はぜひとも見たいところだ。では、投稿された文章を全てページ上に掲出するようにしよう。これもまた、その時点での「企画の最も味の濃い部分」の実装である。この時点ではクールな UI はおろか、ユーザの概念すらない。だが不思議なことに、 Twitter の面白さを最低限理解できる企画になっている。これは確実に Twitter のコア機能、「Twitter の持つ熱量」を実装できているからである。

我々は企画の被提供者を飽きさせないため、そして我々自身が飽きないために、刺激的なリリースを出し続ける必要がある。そのためには、企画の提供者である我々が企画が持つ熱量を決して忘れないことが必要である。そして、今我々が提供できる「企画の最も味の濃い部分は何なのか」を常に考え、実装し続ける必要がある。熱量の低い部分の実装はひとまず後にしとにかく熱量を追い求め続ける姿勢こそが企画を成功させるのではないかと、僕は思う。

うんこと僕

うんこ。

今日はうんこの話をしようと思う。

うんこの話と言っても、人前で漏らしたなどという強烈な話題は無く、さらに言えばこの投稿にはオチすら無いことを始めに断っておく。

うんこと僕の付き合いは長い。かれこれ21年半もの間、僕はうんこを生み出し続け、うんこは僕から生み出され続けてきた。

長い付き合いと言っても、21年半まったく同じようにうんこと付き合ってきたわけではない。僕の人生にはうんことの付き合い方を見直さざるを得ない時期があった。

高校を卒業するまでは、僕とうんこの付き合い方は一般人のそれと何ひとつ変わらなかった。朝登校する前に5分ほどトイレに籠もり、生産する。朝の生産が上手くいかない日もある。そんな日でも、夕食を食べた後ほどには下腹部から「脳よ、そろそろ生産を」という命令が飛んだ。男子高校生らしい、極めて健康的な生産生活である。僕の高校は生徒の人間レベルが比較的高く、休み時間にトイレの個室に入ったとしても変な目で見られるようなことは皆無だった。だが、高校のトイレの個室に入った記憶はほとんど無い。朝晩のどちらかに通常生産ができているので、入る必要が無かったのである。

そんな平和な生活が終わったのは、第一志望の大学に落ちてから数カ月後だった。浪人生という社会の底辺に落ちぶれた僕は、毎日電車で2駅、15分ほどかけて予備校に通うことになった。はじめの1, 2ヶ月は特に何の変化も無かった。しかし予備校生活にも慣れ始めた初夏の頃から、だんだんと僕とうんこの関係性は崩れていった。

関係性の変化はある事件から始まった。ある日の数学の講義の時間、僕は急にうんこをしたくなった。しかし講義は佳境であり、家で解けなかった問題の解説が今まさに始まろうとしているところである。うんこに行きたい。下腹部は既に悲鳴を上げている。だが解説は聞きたい。浪人して云十万円を親に支払わせておきながら、聞くべき解説を聞かずにうんこをしているのは何と遺憾なことであろうか。僕は我慢することにした。今から思えば異常な精神状態である。全力で括約筋に力を込め、シャープペンシルの芯も折れよと言わんばかりの筆圧で板書を取る。強すぎる空調が効いている教室で、ただ一人ダラダラと嫌な汗をかいている。何とか講義が終わった。友人よ、頼む、今は話しかけないでくれ。全力疾走でトイレにダイブしたいところだが、そんなことをすれば衝撃で内容物も全力疾走してしまう。皇族のようなにこやかな笑顔でトイレに向かう。風圧で死人が出るほどの勢いでトイレのドアを叩き閉め、どうにか事なきを得た。予備校が間借りしている、遠鉄百貨店9階のトイレがオアシスと化した瞬間である。

この事件は、僕にうんこの怖さを刷り込ませるのに十分すぎた。僕はこの事件を境に、トイレに行けない状況を極度に恐れるようになった。しかし僕は浪人生である。50分の授業が、1日最大10回訪れる。大教室のど真ん中の席に50分座り続けるのは、「トイレ行けない状況過敏症」の僕にとって過酷な状況である。休み時間にはもちろんトイレに行く。スッキリした、もう大丈夫だ。これ以上出るものは無い。教室に着席する。講義が始まる。脳の奥底でうんこの悪魔が「はい、今から50分あなたはトイレに行けません」と囁いてくる。うるさいうるさい、さっきトイレに行ったばかりだ。出るものは無いんだ。でもあれ、今トイレに行ったら出る気がする。というかトイレ行きたくなってきた気がする。なんか下腹部ムズムズしてきた。トイレ、トイレに行きたい。講義終了はまだか――。

講義のたびにトイレに行きたくなる症状は、しばらく続いた。うんこを我慢するツボを研究(手の甲の薬指と中指の間を強く押すと良い)したり、足の組み方によって状況を緩和できないか試行錯誤(左足を上にして深めに組むと良い)したりもした。根本的な解決を目指し、実家至近のかかりつけ医にも掛かった。診断は予想通り「過敏性腸炎」。医者からは「ストレス要因を取り除くことが必要ですね」と言われた。しかし浪人生からストレス要因を取り除けばただのニートである。結局、処方された薬を服用するのみで、根本的な解決には至らなかった。最も酷い時期には、通学のための2駅+出発駅の合計3駅すべてでトイレに入るという快挙を達成したりもした。電車という空間も講義教室と同様に「トイレ行けない状況」の最たるものだったのである。一緒に通学していた友人も、なぜこいつは出発前にしておかないのかと訝しんだことであろう。だがしかし、僕は出発前にもトイレを訪れ、対策には万全を喫しているのだ。もはや僕にできることは無いのである。

それでも、「数学うんこギリギリ事件」から日が経つにつれ、徐々に症状は鎮静化していった。と言っても元に戻るには程遠く、うんこ行きたい欲求をどうにか忘れる方法を身に着けた程度の改善である。

「数学うんこギリギリ事件」から3年以上が経ち、僕は大学生として生活している。しかし未だにトイレに行けない状況ではトイレに行きたくなる。大学から東京へと伸びるつくばエクスプレスは、区間快速の停車駅全てでうんこをしたことがある。友人とドライブに行くときは出発前に30分トイレで準備をする。大学でもあらゆる場所のトイレ事情を把握している。生活圏内では3C棟のトイレが最高である。できれば4階まで足を伸ばしたい。

僕とうんこの深い付き合いは今後も続いていくのだろう。僕が急にトイレに立ってなかなか帰ってこなくても気にしないでほしい。心の大腸を鎮めるためにお腹をさすっているだけであるはずだ。

「明日は多分北千住あたりでうんこだな」そんなことを考えながら今日も眠りに就く。

主専攻実験enPiTで少し幸せになれるTips #1

こんにちは。

このブログが授業の中で触れられた結果、Twitterの新規フォロワー2名と授業参加者からの白い目を獲得しました。

僕は元気です。皆様いかがお過ごしでしょうか。

まえがき

主専攻実験enPiTの1日目が終了しました。enPiTではRuby on Railsを用いてアプリケーション開発を行いますが、数十名で同時に開発となると様々なハマりポイントが出てきます。

僕はRails上級者では決して無いのですが、気になったものをいくつかピックアップして解説を試みます。

目次

PostgreSQLが上手く動かない

PostgreSQLはデータベースシステムです。enPiTでは、Herokuへのデプロイを想定してローカル環境でもPostreSQLを動作させることになっています。以下では、Homebrewを用いてPostgresQLをインストールした前提で話を進めていきます。

まず、PostgreSQLの状態を確認するためには psql コマンドを実行してみると良い です。

$ psql

出てきたエラーメッセージを読んでみましょう。

パターン0:rails newでコケる

以下のようなエラーが出ることがあります。

An error occurred while installing pg (1.1.4), and Bundler cannot continue.
Make sure that `gem install pg -v '1.1.4' --source 'https://rubygems.org/'` succeeds before
bundling.

これはPostgreSQLが正常にインストールされていないことに起因します。下記コマンドでPostgreSQLをインストールします。

$ brew install postgresql

先ほど rails new コマンドは途中で終了してしまっています。続きを再開するために以下のコマンドを入力しましょう。

$ bundle install

パターン1:PostgreSQLが起動していない

PostgreSQLを使う場合、バックグラウンドで起動されている状態にしなければなりません。

psqlコマンドを実行したときに以下のようなエラーが発生した場合、PostgreSQLが起動していない可能性が高いです。

psql: could not connect to server: No such file or directory
    Is the server running locally and accepting
    connections on Unix domain socket "/tmp/.s.PGSQL.5432"?

以下のコマンドでPostgreSQLを起動することができます。

$ brew services start postgresql

パターン2:データベースが存在しない

これはenPiTの資料でも説明されています。以下のような画面が出た場合、データベースが作成されていない可能性が高いです。

以下のコマンドを実行してデータベースを作成しましょう。

$ rails db:create

Railsが起動しない

$ rails s

がうまく動かない場合です。

パターン1:他の何かが起動している

rails sをしたときにエラーが大量に出るはずですが、その一番下に注目してください。

`initialize': Address already in use - bind(2) for "::1" port 3000 (Errno::EADDRINUSE)

というようなエラーが出ていた場合、他の何かが起動している可能性が高いです。Railslocalhost:3000というIP + ポートで起動しようと試みたのですが、他のwebアプリか何かが同じIP + ポートで起動しようとしているために起動できずエラーが返ってきます。

根本から対処するためには起動している他のアプリを停止する必要がありますが、その場しのぎ的には、以下のようにポートを変更してあげることで起動できるかもしれません。

$ rails s -p 3030

パターン2:Railsのゾンビが残っている

rails sした後、メッセージ最下部に以下のような文言が出る場合、Railsが死んでも死にきれていない可能性があります。

A server is already running. Check /<your project path>/tmp/pids/server.pid.
Exiting

エラーの本来の意味は「既に他のサーバが起動しているぞ」です。まずは既にRailsサーバを立ち上げていないか確認しましょう。

Railsが立ち上がっていないにも関わらずエラーが発生することも稀に起こります。本来、Railsはサーバを終了するときに /<your project path>/tmp/pids/server.pid を削除するはずなのですが、強制終了した際など、何らかの拍子にこれが残ってしまうことがあります。

この場合、手でこのファイル(/<your project path>/tmp/pids/server.pid)を削除すればOKです。

Railsでエラー画面が出る

rails sは問題なく実行できるものの、エラー画面が出る場合です。エラーには無数の種類があるので解説を省きますが、エラー画面の見方を説明します。

エラー画面は、上の図の番号順に見ていくと良いです。①で解決できれば儲けもの、④まで見ても解決しなければ厳しい戦いです。

①にはエラーのタイトルが書かれています。上記の例では ActiveRecord::NoDatabaseError となっていますね。どうやらデータベースが存在しないことがエラー原因だと分かります。パッと見て解決しない場合、タイトル文字列をそのままGoogleで検索してみましょう。かなりの確率で解決に繋がるはずです。

②にはエラーの概要が書かれています。タイトルを補足する程度の内容です。

③にはエラーを直接引き起こしたコードが示されます。どのソースコードかは、後ほど説明する④の最上行に示されています。注意するべきは、③に表示されるのはエラーを直接引き起こしたコードであり、エラーの原因となったコードではないということです。エラーの原因が掴めない場合、④に目を移します。

④にはエラーを引き起こしたコードから順に、「そのコードを呼出したコード」が列挙されます。エラーを直接引き起こしたコードには問題がなくても、そのコードを呼び出したコードに問題がありエラーが起こることは良くあります。

以上の①から④までを丁寧に見ればエラーは解決することになっています。エラーが解決しない場合、その場で座禅を組んで瞑想を始める他に手はありません。ご愁傷様です。

複数のGitHubのアカウントを使い分けたい

インターンやバイトでGitHubのアカウントを作って使っていたものの、今回新しく別のアカウントを作って開発したいという場合、アカウントを切り替える必要があります。

原則は基本通り、GitHubに指示されるまま下記のようなコマンドを実行すればOKなはずです(コマンド内のURLはサンプルなのでそのままコピペしても動きません)。

$ git remote add origin https://github.com/sample/sample.git
$ git push -u origin master

しかし、人によっては下記のようにエラーが返ってくることがあります。

error: The requested URL returned error: 403 Forbidden while accessing https://github.com/sudame/where2eat.git/info/refs

fatal: HTTP request failed

このエラーが出たら、GitHubの認証が通っていない可能性が高いです。

簡易的には、以下のようにすれば簡単に認証できます。your-github-usernameの部分は自分のGitHubアカウントのユーザ名にしてください。例えば僕なら sudame です。

$ git remote add origin https://your-github-username@github.com/sample/sample.git
$ git push -u origin master

これを実行すると、GitHubのパスワードを聞かれるはずなので、適切に入力してやりましょう。

しかし上記の方法ではGitHubにpushするたびにパスワードを聞かれて億劫です。余裕があればこちらの記事の通りに作業をすればOKです。

最後に

他に「ここみんな詰まってたよね」「死ねRails」などという情報がありましたら @dev_sudame までリプをください。書き足すかもしれません。