Agile Party 2023：Joe Justice氏の話しから学んだこと
Agile Party 2023
全然タイムリーではないのですが、アジャイルパーティー（略してアジャパーらしいです）にSCRUM MASTERの著者であるJoe Justice氏が登壇されていたので、こちらを視聴してアジャイル開発の当事者として学んだことをまとめてみました。
目次
- Agile Party 2023
- 目次
- ビル・ゲイツの仕事の進め方
- モジュール化とは
- Teslaの車作り
- 自分がアジャイル開発を進める当事者だったとしたら
- 名ばかりではなく、本質的にアジャイル開発をするには
- まとめ
ビル・ゲイツの仕事の進め方
全てのビジネス活動を、並列実行できるように多くの作業に分割し、全ての一連の作業を同時に、それぞれのチームで実行していくそうです。これをモジュール化と呼んでいるそうです。
- 一連の作業の例
- 要件
- 計画
- 分析
- 実行
- テスト
- 展開
モジュール化とは
分かりやすい例として、レゴが挙げられていました。大きな製品がレゴで作った車とするならば、一つ一つのブロックが小さい単位の機能となります。このように、小さな単位の機能を作っていくことで、大きな製品を作っていくことができるという話しでした。ここまでは自分もよく聞く話しでしたが、ここからが面白かったです。
Teslaの車作り
多くの自動車会社は車全体の設計をしてから製造をするという流れでリリースまで7〜8年かかることがあるそうですが、Teslaでは各部品に分けて、設計と製造を同時に行っているそうです。要するに作り始める段階では詳細は決まっていないということでした。なので、最終的に出来上がったもの、生み出されたものは誰も当初想像していなかった物ができるということになるそうです。Webの世界ではなくて自動車会社でもこの考えで開発を進めることができるんだなと驚きでした。ちなみに自動テストもあるそうです。要するにアジャイル開発の知識は業界を問わず応用できうる可能性を秘めているということが、ここでの最大の学びと驚きでした。
開発の概要
Teslaでは開発初期の段階ではモジュールこのぐらいかな、アウトプットこのぐらいかな？と推測して、その先はそれぞれの開発チーム（モジュール）に任せする。という方法で開発を進めているそうです。なんて大胆でスピーディーなんだろうとここでも驚きました。そしてそれぞれのチーム、例えばインターフェースを作るチーム、バッテリーを作るチームなど、それぞれのチームはまるで別会社のように独立して設計、テストを繰り返しているそうです。そして、お互いのモジュール化されたチームはお互いが干渉することは無いので待ちも発生せず高速に開発を進めることが出来る。結果として今のTeslaの成長に繋がったという説得力のあるお話でした。
自分がアジャイル開発を進める当事者だったとしたら
はじめに、ここではあくまで自分がアジャイル開発を新たに推進する立場だったらという前提で考えることで、今の自分に見えていないものが見えそうと考えて独り言のように書いています。なので、ここは読み飛ばして頂いた方が良いかもしれません。
当事者として考えようと思った背景
自動車に限らず物理の開発を手がけるビジネスモデルに関して言えば、人件費だけではなくて製造コストが毎スプリントないし、かなりの頻度で発生することが考えられると思います。ということは、新しい物を作る反面、製造コストを掛けてすぐに使わなくなる可能性がある物を生み出す勇気みたいなものがチームだけではなく、組織全体として必要ということになると思いました。それってアジャイル開発未経験の組織からしたら踏み出すのはかなり勇気がいることだと思い、自分ならどうするだろうと興味が湧いたので考えてみました。
シチュエーション
- 物理の開発を手がける組織に自分が所属している（人件費以外の製造コストが高い）
- 競合との差別化を図るために新しい物を作ることになった
- 開発手法の決定や推進に関して権限や裁量のある立場にいる
- アジャイル開発をしてこなかった組織で新たにアジャイル開発を導入する。または、したいと考えている。
そんな立場で、アジャイル開発を導入してリードすることが果たして自分に出来るだろうか？と考えた時に大枠何をするか考えてみると
- チームだけではなくて組織の合意を取らないといけない
- 相手を納得させるだけのエビデンスや実際の知見や経験に基づいた納得感のある説明をして相手の理解を得る
のようなタスクを進めることになると思いますが、今の自分では製造コストのリスクをメンタル的に過大評価してしまったり、リスクを正確に把握できるまで、アジャイル開発を提案することさえ出来ないのでは無いかと思いました。ここまでの独り言をNotionで書いてみて、再認識したのは自分は「アジャイル開発の思想っていいですよね！」とか思っていながら、何が大事なのかを全く理解していないということでした。
自分はどうしたいのか
ここで一旦想像の世界から戻ってきて、自分はアジャイル開発の型を理解したいのか、アジャイル開発を活用して何かしたいのか、自分に問いかけてみると、『将来エンジニアとして組織やビジネスをリードできる人材になりたいと思って、この世界に飛び込んだんじゃないの？』ってすぐにダメ出しが返ってきました。
名ばかりではなく、本質的にアジャイル開発をするには
それでは自分の場合、どうすればアジャイル開発をリードできるような人材になれるだろうと考えた時に、アジャイル開発を導入したであったり、アジャイルの文化を醸成してきたような方々のお話をイベントを通じてお聞きしたり実際に伺ったりしたりしながら、もちろん先人の書き残した記事など参考に自分自身が実際にアクションを起こして自身の体験にすること、そして自分自身も体験を発信すること。その繰り返しで、失敗と成功を豊富に積むことかなと思いました。その積み重ねで知見が増えることで自分の判断や方針、言葉に説得力が出てくると思うので、見た聞いた話しではなくて自身の体験を積むことが大事だと思いました。
まとめ
アジャイルとは1回で完璧な物を作ろうとせず、短いスパンで様々なコストを払ったとしても、改善を繰り返すことで開発スピード（時間）を買っているようなイメージというのが自分の理解で、このスピードが結果的に品質やコストダウンにも繋がるというメリットを再認識しました。また、アジャイル開発をリードするような人財になれるよう、Web業界に留まらず様々な方々との交流を通じて自分の経験や知見を増やしていきたいと思いました。その積み重ねの先にはエンジニアとしてビジネスの世界でも活躍できる楽しい世界が広がっているのではないかと思いましたので、長期的な目線で自分のキャリアを磨いていきたいと思いました。
というところで気持ちが高ぶってきたので、ここら辺で終わりにします。
最後までお読み頂きありがとうございました。
Kaigi on Rails 2023 オンライン参加で感じたこと
こんにちは、食欲の秋ですね。ご飯が美味しい季節なので冬に向けて食べ込んでいきたいと思っている今日この頃です。
ということで、先日オンラインではありますが初めてKaigi on Rails 2023に参加したので、エンジニア１年生の今の自分が感じたことをここに記録しようと思います。
はじめに
時間の制約もあって、自分が視聴したのは2日目のセッションだけになります。その中で事前に調べたり紹介頂いて視聴したセッション3つに絞って書かせて頂きます。尚、この記事は個人の所感ですので、正しくはリンクの資料などをご確認ください。また、純粋に感じたことを表現したいので生成AIは使わずに自分の言葉で書いていますので、表現のおかしい箇所が多々あるかもしれませんが、ご了承ください。
目次
- はじめに
- 目次
- 視聴したセッション
- いきなり感想
- 管理機能アーキテクチャパターンの考察と実践
- ペアプロしようぜ 〜3人で登壇!? 楽しくて速いペアプロ/モブプロ開発〜
- コードカバレッジ計測ツールを導入したらテストを書くのが楽しくなった話
- まとめ
視聴したセッション
視聴したのはこちらのセッションになります。
10/28(土)
- 13:30 〜 14:00 (Room B)
- 15:05 〜 15:35 (Room A)
- 16:10 〜 16:25 (Room A)
いきなり感想
語彙力崩壊してますが、結論どのセッションも最高でした。何が最高だったのか、それぞれのセッションごとに分けて書かせていただきます。
管理機能アーキテクチャパターンの考察と実践
第一印象
Ohbaさんは今年で3回連続3回目の登壇ということで、どんなお話しをされるんだろうと気になっていました。実際にセッションが始まって早々に感じたことは、言葉のチョイスと身振り手振りがとてもお上手でコミュニケーションスキルの高いエンジニアさんというのが第一印象でした。
当時の心境
aki on X: "話がとても上手くて聞き入ってしまう。 #kaigionrails #kaigionrailsB https://t.co/GSSOrQRwo7" / X
管理機能開発は「後追いでつくられがち」
自分が開発に携わっているサービスは歴史も長く、自分がジョインした時には全てを把握できないぐらい管理機能は豊富でしたので、「後追いで実装されがち」という実態を知れたこと自体が大きな収穫でした。
自分達で正解を作っていく
既存のシステムに新たに管理機能を実装していくことになった際に、アーキテクチャはモノリシックなのか、PDS順守なのか、モバイルだけに対応しているのか、Webに対応しているのか、はたまた両方対応しているのか、といったサービスごとに異なる独自のアーキテクチャになっている。 そういった様々なアーキテクチャごとの特性、ドメインを把握してトレードオフを明かにしながら、それぞれの正解を考えていくというプロセスを今回見せて頂いたのではないかと感じています。
まとめ
「正解は1つでは無い。むしろ自分達が正解を作るんだという気持ち」というような表現をされていたのが印象的で、エンジニアとしての考え方みたいなものを学ばせて頂いた最高のセッションでした。
ペアプロしようぜ 〜3人で登壇!? 楽しくて速いペアプロ/モブプロ開発〜
第一印象
あんすとさんという方が司会進行されていたのですが、非常に表現力豊かで芸人さんなのでは？と思うぐらい画面の前で終始笑いながら視聴させて頂きました。スライドのイラストも最高なので、個人的には殿堂入りしてほしいセッションです。
ほぼ全部ペアプロ開発
私は今の職場で初めてエンジニアになったのですが、正直ペア / モブプロをしたことがなくて、もしペアプロが必要と思えば自分から声を上げて適宜お願いするというのが今の環境かなと思っています。Tebikiさんの場合は組織的に開発はペア / モブプロというように方針として行なっている点が今の自分には新鮮で、どのように行なっているのか見るだけではくて、ライブコーディングの際に自分もタイピストになった気で視聴しようと思いました。
当時の心境
ペア / モブプロの概要
- 役割はドライバーではなくタイピストとナビと考えると良い
- 機能・要件の確認
- 全員で機能の説明を読み合わせる
- 全員で何故この機能が必要なのか認識を揃える
- 機能の必要性や問題、課題がないかディスカッションする
- 実装に入る前に実際の画面を見ながら完成形のイメージを共有
- 作業開始
まとめ
ソロプロ ツラかったランキング第1位の終わらないレビューは、今の自分がレビューできていない現実を考えると本当にそうだなと改めて実感しました。大事なことは実装の当事者になるというマインドが大事かなと今回のセッションを通じて学びましたので、ソロプロで実装を行う際はその点を意識してみようと思いました。自分の視野が大きく変わった最高のセッションでした。
コードカバレッジ計測ツールを導入したらテストを書くのが楽しくなった話
なぜこのセッションを視聴しようと思ったか
カバレッジ計測については、個人的なメンターから教えて頂いていて存在は知っていたのですが、実務でカバレッジを計測して自分のテストがどれぐらい網羅されているのか定量的に把握していなかったので、この機会に具体的にどうやって計測されているのか知りたいと考えていました。
個人メモ
- コードカバレッジとはソースコードがテストされた割合のことで、テストの品質を保つための指標として使う
- テストお願いします！と言われてもどこまでやんの？となるのでカバレッジを用いることで、例えば80%以上お願いします！という定量目標が定まる
- カバレッジ計測：SimpleCov
- GitHub Actionsに導入して自動で計測
- GitHub PagesにSimple Covの画面が表示されるようにした
- テストの優先度決定にもカバレッジが使える
当時の心境
まとめ
実際に個人開発でSimpleCovを導入してみて、実態を自分でも把握してから実務でも導入できそうか考えてみようと思いました。開発者体験が向上しそうだなとワクワクさせて頂けた最高のセッションでした。
まとめ
今回、オフラインで参加することが出来なくて会場の雰囲気を全身で感じれなかったことが残念でしたが、オンラインの良さとしてRoom A / B と2会場の様子を伺いながら落ち着いて視聴に集中できたのは良い点だったかなと思います。 また、Xでリアルタイムに発信したことで、登壇者の方と次回、オフラインイベントでお会いできるアポが取れたり充実した1日を過ごすことができました。
Kaigi on Rails 2023の運営に携わった全ての方へ感謝申し上げます。 本当にありがとうございました。
最後までお読み頂きありがとうございました。
中島聡『なぜ、あなたの仕事は終わらないのか』を読んで、エンジニアとしての仕事の向き合い方について考えてみた
こんにちは、最近日差しが強くなってきて、外出時に日に当たらないルートを考えながら歩く遊びをしているakiです。 今回は中島聡さんの著書『なぜ、あなたの仕事は終わらないのか』を読ませて頂いて、エンジニア1年生の自分にはまさに必要なエッセンスが凝縮された一冊だったので、自分の感じたことを書いてみたいと思います。
文字数：約2000文字
どんな内容か
この本の前半から後半ぐらいまでは仕事が終わらない理由とその解決策を記していて、後半では中島さんの仕事に対する考え方など重要なエッセンスが散りばめられています。特に後半の内容は社会人に限らず学生の方にもお勧めしたいと個人的に思っているので、まだ働きたい仕事が見つかっていない。分からない。という方がいたら個人的にお勧めしたい一冊かなと思います。 本書の内容を全て書きたいぐらい個人的に学びの多かった書籍ですが、その中でも特に記憶に残った内容を3つピックアップして書いてみたいと思います。
結局、なぜあなたの仕事は終わらないのか
ここでは、仕事が終わらない原因について3つ紹介されていて、自分の言葉で書くと、
- 人から頼まれたものなど、新しいタスクを受ける時にきちんとその内容を把握せずに「出来ます」「やります」と安請け負いをしてしまう
- 期限ギリギリになってから、タスクを終わらせようと残業や徹夜をする
- 計画の見積もり（スコープ）を曖昧な状態で進める
このようなことをするとタスクは期限までに終わらないということを繰り返し本書では伝えています。ここで個人的に『期限』を見積もることがとても重要だなと感じました。例えば厳密な期限が設定されていないが、なるべく早く進めてほしいタスクを依頼された時のことを想像してみましょう。スクラム開発であれば当然ですが今進めているタスクと優先順位を比べて、いつ頃までに出来る出来ないという情報を依頼元に共有すると思いますが、スクラムに関わらず自分で見積もってタスクが終わる期限を提示できるように習慣化しておくことで、終わらない仕事が無くなることをここで学びました。この見積もりの精度はこれからどんどん磨いていきたいと思います。
花さえ用意できれば、裏で昼寝してもいい
これはどういう意味かというと、極端な例ですが、あるパーティーで使う花を用意して欲しいと上司に言われたとします。あなたは花屋に予約して当日パーティー会場に花を届けて貰うように段取りしていたとしましょう。当日、雪のせいで配達が遅れてパーティーで用意するはずの花が遅れることになりました。この時、あなたはどうしますか？
花が遅れる旨を上司に伝えること。ではありません。上司があなたに依頼したのはパーティーに花を用意することであり、花屋に注文するために雇われたのではないということを本書では伝えていて、花を用意することが出来なかったのは100%あなたの怠慢だとも伝えています。この例でいえば、もし配達が遅れるなら車で近くの花屋まで行くとか、他の花屋に至急注文をするとか、そういった第二第三の案を直ちに遂行するということです。何を言いたいかというと花屋に注文をすることは任務の一部でしかなくて、あなたの仕事は花を用意することだということ。花さえ用意できれば、パーティー会場の裏で昼寝をしていてもいいのだというお話しでした。
もちろん現状を共有することは大事なので、花が遅れる可能性を上司に伝えること自体が問題では無いということはお分かりだと思いますが、ここを読んで、改めて自分の中で絶対にやらなければならないものとは何かを真剣に考えることは大事なことなんだと学びました。
崖を飛び降りながら飛行機を組み立てろ
これも確かにと思った話しで、結論から言うと何かの実践のために知識が必要な場合、知識はやりながら覚えていくべきだ。と本書は伝えています。何かの役に立つかもと勉強したり資格を取ることも大事なことかも知れませんが、本当に必要な知識は事前に身につけておく必要はなくやりながら覚えていくのが一番効率的で理解も早いと言うことを伝えているのだと思います。正直今は必要な知識ばかりで毎日勉強ばかりですが、何を優先して学ぶのか、考えることがあったので色々手広くやるのではなく今、本当に必要なものに絞って学んでいけばいいのだと学習の指針を決めることが出来たので、個人的にありがたい内容でした。
まとめ
ここでは詳細は紹介していませんが、生活リズム・仕事の進め方に関しても本書で具体例が書かれていたので、一部真似をしてここ数週間、夜型から朝方に変えてみたところ非常に効果があったので、このまま続けていこうと思います。他にもここでは伝えらきれないほど、沢山の学びがあったので気になる人は是非読んでみてくださいい。仕事に対する考え方が変わるかも知れません。
最後までお読み頂きありがとうございました。
RubyKaigi 2023に初参加して得た知見：オフラインでのコミュニケーションの大切さ
学びの場としてだけでなく、出会いの場でもある
RubyKaigi 2023に初参加して学びの場としてだけでなく、開発者や他の参加者との出会いの場としても大切なものであると感じました。そして、オフラインでのコミュニケーションの大切さを改めて実感しました。普段は、ネット上でのやりとりが主流となっていますが、実際に会ってお話することで、より深い理解やつながりを築くことができるのだということをRubykaigiで学びました。とくに各社サービス開発に携わる関係者の方々とお知り合いになれたことは、とても貴重な体験でした。皆さん自分たちが開発した製品に情熱を注いでいて、その情熱が世の中や日々の生活にも反映されていることを実感しました。こういった体験から、オンラインの世界だけではなく、オフラインの世界でも人とのつながりを大切にしていく必要があることを実感しましたので、そこで特に自分のようにRubykaigi初めてという方へ向けて、新しい出会い、人とどう繋がるかという点にスポットライトを当ててハック的な内容で自分なりにやって良かったことをまとめてみました。
自分に合ったRubyKaigiの楽しみ方
なぜこのような記事を書こうかと思ったかというと、RubyKaigi では様々なスピーカーのトークを聴かせて頂きましたが聞いてもついていけない部分が多く、自分自身の実力不足を痛感していました。そこで、無理に聞くのではなく会場をゆっくり回って、各ブースを訪れたり、サービス開発に携わる方々と直接お話することにしたのですが、これが想像以上に良かったので、そのことをブログに書いて、RubyKaigi初参加の人などに向けて何かためになることが書けるかもと思った次第です。
ハックRubyKaigi 初参戦で新しい人と繋がる方法
RubyKaigi 2023に参加したら、どうやって新しい人と繋がることができるのか気になりますよね。私は、ハックとしてネームプレートを利用する方法を実践しました。これは以前からもされている方がいて個人的にいいなと思っていたのですが思いの外、やってみて良かったので以下、その方法について紹介します。
ネームプレートにTwitterのQRコードを貼ろう
会場に入って一番最初に受付をして、ネームプレートなどをいただいて、それを首にかけて会場を回ることができます。この時、私は自分のTwitterアカウントのQRコードををネームプレートに追加することにしました。これをやったおかげで、話して仲良くなった方とスムーズ繋がることが出来て2日目からのRubyKaigi参加でしたが、30以上は新しいTwitterのフォロワーと繋がることができました。
Twitterのアイコン画像で認知してもらおう
QRコードと合わせて自分のTwitterのアイコン画像をネームプレートに貼っているだけで「見たことあるな」みたいなことを言っていただけたりとか、向こうから話しかけて下さることもあったりと話の種にもなるので、ネームプレートに極力大きいサイズで貼っておくことをおすすめします。この方法を利用して、RubyKaigiでたくさんの人と繋がってみましょう！
ハック以上に大事なこと
そのネームプレートを作っても、これだけは本当に大事だなって思ったのは、初めての人にも話しかけてみることが本当に大事だなって思っていて、自身の体験を例として、3日目最終日にRuby vs Kickboxer - the state of MRuby, JRuby and CRuby というタイトルでMichael Milewskiと、Selena Small のお二人の本当に素晴らしいプレゼンがあって、会場も大盛り上がりで自分もすごく楽しくて、技術の話っていうのも当然あったんですけど、Rubyでこんなに面白いことできるんだ、みたいな体験をこのお二人から頂いてすぐにマイケルさんとセレーナさんのファンになりました。そのプレゼンの後、会場を出てフラフラしていると、ちょうどお2人がいらっしゃったので、英語話せるわけではないんですけど、一緒に写真撮ってもらえないかなと思って勇気を出して、お二人に話しかけました。本当に会話は全然できていなくて、写真を撮ってもらっただけっていうような感じですが、それでもやっぱりこのオフラインで、せっかく目の前に、今まさに興味の湧いた人に対して何もできないみたいなことがもしあれば、それはすごくもったいないと個人的には思っていて、どんなにネームプレートの準備をしたとしても、声をかける勇気がなければ新しい出会いとかっていうのはないので、ぜひ、そのRubykaigiに限らずですが、そういうイベントに行った時には、もし自分の気になる人とか、話しかけてみたいなっていう人が目の前にいるならば積極的に話していけば、新しい世界が見えてくると思うので実践してみて下さい。
まとめ
RubyKaigi 2023に参加して、学びの場としてだけでなく、出会いの場でもあることを実感しました。会場での出会いは、新たなアイデアやビジネスチャンスを生むことがあるかもしれません。今回ご紹介した方法以外にも、スムーズに繋がれるような仕組みを用意しておくことができるのであれば、ぜひ作ってみることをおすすめします。RubyKaigi で、積極的に話しかけて新しい出会いを作ってみましょう！
最後までお読みいただきありがとうございます。 それでは、次のRubykaigi 沖縄でお会いしましょう！
Webエンジニアになって最初の42日間で学んだこと
はじめに
この記事はエンジニアになって研修期間中にFBCというプログラミングスクルーで学んだことを書いています。実務や職場のことについては特に触れていませんので、その点ご了承下さい。
どんな人に向けて書いているか
エンジニアを目指している方や、エンジニアになったばかりでこれから体型的に基礎を固めていきたいけど、独学でやると知識が偏りそう。プログラミングスクールに入って学習してみたいけど、沢山あるしプログラミングスクールはなんか怪しいと思って一歩前に進めない人に向けて書いています。
なぜエンジニアを目指している方に向けて書こうと思ったのか
私はもともとスクールは怪しいと思って、1年以上(1800時間程度)独学で学習してWebエンジニアになったのですが、入社して約2ヶ月の研修期間中にフィヨルドブートキャンプ(FBC)というプログラミングスクールのカリキュラムを受けさせて頂きました。このカリキュラムの内容がとても良くて、しかもRubyで開発している人なら誰もが知っているあの有名な人に直に教えて頂いたりと、独学時代に知っていれば絶対入っていたなと実感しているので、同じようにエンジニアを目指している人に向けて書きたいと思いました。
どんな内容になっているか
私が学んでことをFBCのカリキュラムを各タイトルとして300字程度で簡単にまとめてお伝えしたいと思います。ブログなので、技術的な内容にはあまり触れていいませんが、気になるタイトルがあれば学習やスクール選びの参考にしていただければと思います。またここに記載のタイトルは私が行ったカリキュラムだけで、FBCのカリキュラムのごく一部になります。
私の学習スタイル
初めに私の学習スタイルについて簡単に触れておきたいと思います。同じようなスタイルの方は相性がいいかもしれませんので参考までに。例えば新しく触れる技術については、心理的に開き直った状態でとりあえず分かるものから手を動かしてみる。そして、分からないことはググったり本で調べて、まずはざっくりと雰囲気や全体像を掴んでから、まとまったドキュメントを読んで理解する。でも分からない時はサッと誰かに聞きたい。ということをやっていました。自分主導で考えてあれこれやるのが好きなタイプなので、このような学習スタイルなんだと思います。FBCでは気軽に質問できる環境もありますし、提出した課題に対して驚くほど手厚くレビューが返ってきますので、一人で悩み込んで前に進めないという不安はありませんでした。
42日間で学んだこと
それでは42日間の記録について、つらつらと書いていきます。
【day1~2】 HTMLの基本を理解する
ここでは<h1>などのタグの重要性について理解が深まりました。ブラウザは目で見るだけではなくて耳で聞く人もいて、そういう時に文章の中の「この部分は見出しである」、「この部分はリストである」という印を付ける作業をしていないと長い文章をダラダラと聞かされることになるのでウェブアクセシビリティはとても悪い。 だからタグは文字を大きくとかそういう「見た目」だけの話しではなくて、むしろ耳で聞くユーザーのことを意識しながら様々なタグを使い分けることが大事だということを学びました。
【day3】 Markdown を使って HTML を書く
Markdownは、HTMLタグとは異なり、HTMLで可能な表現の一部を実現するために開発されたものであることを学びました。Markdownで作成したテキストは、HTMLに変換されてWebページ上に表示されます。Markdown記法は、シンプルで覚えやすく、見やすいテキストを簡単に作成することができます。デベロッパーツールを使用して、Markdownで記述されたテキストがどのようにHTMLとして認識されているかを比較することで、より理解を深めることができました。
【day4~5】ssh の基本を理解する
SSH（Secure Shell）は、ネットワーク内のコンピューター間で安全なデータのやり取りを行うためのプロトコルという概念は知っていましたが、どうやって接続先のコンピューターの認証を行っているのか知りませんでした。他にもウェルノウンポートなどネットワークの知識を学ぶことができました。今までコードを書くことに目が向きがちでしたが、ネットワークの知識もsshの学習を通じて学ぶことができ、インフラ方面の興味がより湧いてきました。
【day6】SSL/TLS の基本を理解する
通信をセキュアに行うために「共通鍵暗号」と「公開鍵暗号」を使用していることを知り、更に証明証には「ルート認証局」の署名をチェックしていることも分かりました。ルート認証局は、証明書の発行元の機関で、信頼できる機関が署名したものであることを確認するために重要ということを学びました。
【day7】GitHub の基本を理解する
Gitコマンドが何をしているのか分からなかった私でも、Gitコマンドが何をしているのかイメージできるようになりました。ローカルリポジトリについても理解が深まり、.gitファイルがローカルリポジトリであること、そしてこのファイル内にはリポジトリ、圧縮ファイル、ツリーファイル、コミットファイル、インデックスファイル、そして設定ファイルなどが含まれることが分かりました。
【day8】Ruby初級
TryRubyは、Ruby初心者にとって最高の教材だと思います。インプットとアウトプットが同時にできるため、自分でコードを書いて実行することで理解が深まると感じました。そして、ゼロからわかるRuby超入門の読み方も、公式リファレンスの読み方を優しく解説してくれたため、今後他のドキュメントを読む際にも役立つと思います。
【day9】FizzBuzz問題（ruby）
有名な課題だと思いますが、この課題から実際にコードを書き始めました。初めは実装の内容をコメントで記していましたが、コード自体に意味を持たせるという方向で実装しましょうというアドバイスを頂いたことでその後の実装でも意識するようになり、大きな学びとなりました。
【day10~11】カレンダーのプログラム(ruby)
calコマンドをRubyで作るということをやりました。-mで月を、-yで年を指定できるというオプションも実装しました。ここではメソッドの命名やrequire関数を使用して、標準ライブラリやインストールしたライブラリを渡すことができることを学びました。また、shebang（シバン）やPATHについて学ぶことができました。
【day12】rubocop の使い方を知る
rubocopを使うことで、人の目では見落としがちな細かい部分を指摘してくれるので、rubocopに限らずこういった仕組みを活用して、人力に頼らない仕組みについて学ぶことができました。
【day13~24】lsコマンドを作る1~5
研修期間の中で一番印象深かったカリキュラムで、この課題はlsコマンドの仕様を読み解いて、どうやって実装するか考えて実装するという流れを自分一人で行います。そのため実装まで時間のかかるカリキュラムでした。やっと実装が終わったと思って課題を提出してもそもそも仕様を見直しが必要ということもありますので、当初は精神的にも辛いところがありました。ただ、この課題のおかげで自分で調査して仕様を考えることができたのは自分にとって大きな成長に繋がったと思います。この目的には、環境の変化が目まぐるしいこのWeb業界で、今まで実装したことが無いような機能を開発することになる。その中で仕組みを変えることも大事だが、「今の仕組みや環境の中でどう進めていくか」という柔軟でスピード感のある働き方も重要だという意図が込められていると個人的には感じています。考え方のバリエーションが増えたことは自分にとって財産です。
【day25~26】nginxの基本を理解する
自分でレンタルサーバーを借りて、指定されたOSで環境構築するという課題でした。環境構築中にでたエラーの切り分けも大事で一つずつ読み解きながら進めることが大切だと感じました。この経験は後に実務の環境構築でも役に立ちました。また、nginxを学ぶ中でWebサーバーの基本的な仕組みについて理解を深めることができました。
【day27~28】nginx で VirtualHost を使って複数のドメインのサイトを立ち上げる
自分で購入したドメインを使ってサーバに接続するということを実装しました。ログも別々のディレクトリのlogファイルに吐かれる設定しました。Nginxがリバースプロキシであるということや、ロードバランシングも行っているなど、まだまだ覚えることは多いですが、手を動かしながら学べたことでネットワークの知識を広げることが出来ました。
【day29】nginx で SSL 対応サイトを作る
オレオレ認証を使って、nginxでSSL対応のページを立ち上げることを実装しました。SSL対応の設定は、Webサイトのセキュリティを向上させるために必要不可欠なものです。今回、nginxを使ってSSL対応のページを立ち上げることができたことは、自分にとって大きな成果となりました。
【day30】PostgreSQLの基本を理解する
PostgreSQLの設定をするときに出たエラーの対処が印象的で、ネット上の記事を見ながら原因の切り分けをしましたが、書いてあることが嘘だと見抜くことが少しずつ出来るようになってきたことで成長を感じましたし、公式ドキュメントを見る癖もついてきたと思います。また、OSやPostgreSQLのバージョンを確認することが出戻りを減らし、エラー特定にもつながることも学びました。
【day31】データベース設計の基本を理解する
ここでは、Tweeterの機能を読み解いて自分でER図を作成するということをしました。Tweeterの機能でツイート、リツイート、引用リツイートの関係性やどんな機能になっているか整理するだけでかなり勉強になりました。詳細はネタバレにもなるので、割愛します。
【day32~35】SinatraでシンプルなWebアプリを作ろう
独学の時はRailsというフレームワークを使用していましたが、Railsのありがたさを理解するためにも別のフレームワークのSinatraでWebアプリを作るということ実装しました。XSS(クロスサイトスクリプティング)対策も実際に自分のサービスにXSSを仕掛けてどういう悪さをするのか試しながら対策をすることができました。
【day36~38】テスト技法
テストの考え方は奥が深く、短期間で全てを理解することは難しそうですが、実際に課題を通じて技法を学ぶことは今後のエンジニア人生において重要だということが分かりました。テストは破壊的な作業で、「正しく動作しないこと（エラー）」を発見しようとするものです。それに対してプログラミングは、創造的で「正しく動作させることを目標」とした作業です。新しいことを学んで、自分の考え方がアップデートされていくのが実感できた課題でした。
【day39】TDD の基本を理解する
テスト駆動開発は以下のRED、GREEN、REFACTORという3つの作業サイクルを細かく繰り返してプログラミングを進めていくということを学びました。
【day40~41】オブジェクト指向プログラミング
オブジェクト指向を学ぶために、カリキュラムではありませんが砂糖水を作るというデザインパターンを参考に実際に手を動かしながら学んだり、全体をイメージするのにノートに手書きで図を書いて頭を整理しながら学習を進めました。また、書籍の「プロを目指す人のためのRuby入門」の7章の中で紹介されているコードを実際に手元で書いて動かしながら良く分かっていない部分を一つ一つ理解しながら学習を進めました。その結果、自分に足りていないものは 『オブジェクト指向に向き合うための思考力』 ということが痛いほど良く分かりました。
【day42】Railsでテストを書く
ここでようやくRailsを触ることが出来ました。ここでは、同じsystemテストを実行しているのに、成功する場合と失敗する場合があることに気づきlogをひたすら追って調べるということをしました。調べていくと、JSを使って画面を書き換えるWebアプリはCapybaraがJSの処理を待たずに次へ進もうとすると部分一致するワードがそこにあれば想定とは違う挙動になって、テストが落ちやすいということが分かりました。Turbolinksと呼ばれるRails標準の画面描画ライブラリが裏でこっそり動いていたことが原因でしたので、CapybaraにTurbolinksの完了を待って次の操作を実行する方向で実装しました。
まとめ
今まで個人開発で得た知識が、点から面になっていくことを実感しています。FBCのカリキュラムを進めたことで、自分は「どんな技術を知らないのか」、「どれぐらい理解しているのか」、「今後何を学んでいくと良いのか」客観的に把握することが出来ました。また、カリキュラムを進めていく中で、分かった気にならずに一つずつ理解して学習していくことの大切さを身を持って学びました。興味のある方はFBCのお試し期間で実際に体験してみて下さい。
感謝
FBCのメンターを運営されている全ての関係者の皆様と、このような貴重な時間を下さったGMOペパボに心から感謝します。何か話しを聞いてみたいという方がいれば、気軽にTwitterでDM下さい。
最後までお読み頂きありがとうございました。
Gentle dictatorship ”優しい独裁者”
初めに
ここでは政治の話は一切出てきません。 あくまでWeb業界にまつわるお話しですので、ご了承ください。
どんな話？
Web業界に限った話しではないかも知れませんが、物の例えとして ”優しい独裁者” という言葉を最近知ったので、ここで紹介したいと思います。
優しい独裁者とは
民主的な議論ではまとまらない話しを立場や技術力もあって発言力のある人が一つの指針や決定を下して話しをまとめる様子のことを言うそうです。 Web業界に限った話ではありませんが、 ”これといった答えはないが何か一つ決めなくてはいけない” といったシーンがあると思います。そういう時に ”優しい独裁者” が一人いると並行線だった議論に終止符を打つことができて組織の生産性を考えた時にハッピーになるというのがお分かり頂けるかと思います。 逆を考えてみると、みんな同じぐらい分かる人がいて、それぞれが思うベストを言い合うと話がいつまでも纏まらなくて組織の生産性の観点が悪くなることも想像できそうですね。
民主主義が必ずしもいいとは限らないという話し
みんな同じぐらい分かる人がいて、それぞれが思うベストを言い合うと話がいつまでも纏まらなくて・・・
この一例として、RuboCopの設定は議論が始まると終わらない。ということが良くあるそうです。確かにそれぞれいろんな宗派があって言い始めるとキリがないですよね。個人開発なら自分好みにすればいいですが、組織の生産性で考えた時にいつまでもその議論をすることは最善とはならないでしょう。こういった場面で立場や技術・発言力のある人が ”優しい独裁者” となって「基本はデフォルトのまま運用」とスパッと決めてしまうことが組織の生産性を考えたときに必要になってくる考えと言えると個人的には思います。要するに、ビジネスの世界では民主主義が必ずしもいいとは限らないということが言えるでしょう。
まとめ
独裁者と聞いて嫌悪感を抱くかも知れませんが、あくまで言葉遊びと捉えて下さい。 その言葉の向こう側には組織のために人肌脱いでくれる素敵な独裁者の姿が見えてくるでしょう。 いつか自分もそんな人になれたらと思いながら、Webの奥地へと進んでいくのであった。
最後まで読んで頂きありがとうございました。
Sunbathing sheep
自己紹介
はじめまして私、aki（あき）といいます。
今月からGMOペパボ株式会社に研修生枠のペパボカレッジで入社した ”駆け出しエンジニア” です。どうぞよろしくお願いします。
経歴
興味のある方はこちらのリンクからどうぞ。
気軽にお友達になって頂けると嬉しいです。
お気持ち
Twitterで好き勝手つぶやいているので、気になる方はこちらのリンクからどうぞ。
こちらも気軽にお友達になって頂けると嬉しいです。
どんな記事を書いているか
ここでは技術以外のエンジニアとして学んだことを気ままに書いていこうと思います。ブログのタイトル ”Sunbathing sheep” は自分の名前から取っているというだけで、特に意味はありません。
