give IT a try

プログラミング、リモートワーク、田舎暮らし、音楽、etc.

学校の勉強とプログラミングの勉強は何が違うか(そして技術書をどう読むべきか)

これは何?

これは僕がメンターをやっているフィヨルドブートキャンプで受講生向けに書いた記事です。
ただ、内容の8割ぐらいは未経験からプログラマを目指している初心者のみなさんにも役立つと思うので、そのまま公開することにしました。
想定読者は「フィヨルドブートキャンプの受講生」なので、フィヨルドブートキャンプの関係者以外の人が読むと「???」となる部分があるかもしれませんが、その点は悪しからず🙏

Showa Women's University

それでは以下が本編です。

はじめに

みなさんはフィヨルドブートキャンプに入ってプログラミングの「勉強」をします。また、大半の受講生のみなさんは学校で「勉強」してきたと思います。どちらも「勉強」ですが、実は学校の勉強とプログラミングの勉強は異なる点が多いです。その違いを意識せずに、学校の勉強と同じ感覚でプログラミングの勉強をやると、非効率な勉強をしてしまう恐れがあります。

この記事ではプログラミングの勉強は学校の勉強と何がどう違うのか、という点をまとめます。そして、その内容を受けて、技術書をどう読み進めるべきか、という話を書きます。

(備考)

なお、ここに書く内容は資格試験には当てはまりません。資格試験はむしろ学校の勉強に近い面がありますが、ここでは資格試験は考慮しないものとします。

試験があるわけではない

プログラミングの勉強はいくらやっても試験があるわけではありません。フィヨルドブートキャンプでは課題提出のプラクティスがありますが、それは学校の試験とは大きく異なります。課題提出は同じ問題を、同じ場所で、同じ時間に、何も見ずに、全員が「よーい、どん」で解くような試験ではありません。

プログラミングは困ったらその都度調べればOKです。もちろん、いろんなことを暗記している方が早くコードが書けますが、暗記すること自体はMUSTではありません。「うーん、困ったな」とか「あれ、なんだっけ?忘れちゃった」と思ったら、その都度調べることが許されます。

高い点数を取ることが目的ではない

学校の試験は高い点を取るほど「偉い偉い」と褒められますが、プログラミングはいくら勉強しても得点が付けられるような試験があるわけではありません。そもそもプログラミングは学校の試験のように公平な点を付けられません。

よって本の内容を隅から隅まで完璧に理解して覚える方が高得点を取れるから偉い、ということにもなりません。もちろん、全部完璧に理解できればそれがベストですが、全部完璧に理解することは学校の勉強ほどプライオリティは高くありません。

本の内容を丸暗記したからといって必ず就職できるという保証はない

大学受験などでは教科書の内容を完璧に理解して覚えれば、ほぼ確実に志望校に合格することができます。
ですが、プログラマとして転職する際は何か技術知識を問われるようなペーパーテストがあって、それによって採用の合否が決まるわけではありません。

豊富な技術知識を身につけていることは目的の企業に採用されるために必要な一要素であるかもしれませんが、それがすべてではありません。

他人との競争ではない

プログラミングの勉強は他人と得点を競い合うものではありません。むしろ、業務では他の人と協力し合うことが大事になります。つまり、困ったら助け合う、教えてあげる&教えてもらう、の持ちつ持たれつの関係になるのが理想的です。

もちろん、他の人よりもすぐれた技術スキルを習得することは大事ですが、大学受験のように狭き門を目指して高得点を競い合い、点数が低い者が敗れ去る、といったルールはプログラミングの勉強には当てはまりません。

(備考)

就職活動では他人との競争が発生しますが、必ずしも技術力だけが採用・不採用に直結するとは限りません。たとえば、AさんとBさんではBさんの方が技術力が少し高いが、Aさんの方が会社のカルチャーにフィットしていたためAさんが採用される、ということもありえます。

よって、技術書の内容を隅から隅まで理解する必要はない

上記のような理由により、技術書を読むのと、教科書や参考書を読むのとは考え方が大きく異なります。つまり、技術書の場合は隅から隅まで完璧に理解して暗記する必要はありません。

ゆえに、学校での勉強と同じ感覚で技術書を読もうとしている人は、考え方を改める必要があります。

じゃあ、技術書はどんなふうに読めばいいの?

技術書の理想的な読み方ですが、僕個人としては以下のように考えます。

頭の中にインデックスを作れば良しとする

技術書のオススメの読み方は以前こちらのブログに書きました。

blog.jnito.com

上のブログでも書いたように、わからないところが出てきたら、あとで読み直せるように頭の中にインデックスを作ればそれでOKです。わからない内容はその知識が必要になったときに読み直せば良いのです。

恥ずかしがらずに誰かに聞く

また、フィヨルドブートキャンプでは「わからないところを誰かに聞く」ということもしやすいはずです。DiscordやQ&A掲示板、質問・雑談タイムなどを活用すれば、メンターや他の受講生がきっといろいろ教えてくれます。

重要なポイントとそうでもないポイントを押さえる

さらに、フィヨルドブートキャンプの「技術書を読む系」のプラクティスでは、「本の読み方」が紹介されていることがあります。

例:「UNIX・Linux について知る」のプラクティスと、新しいLinuxの教科書の読み方

こういった「読み方」ページを参照して、重要なポイントとそうでないポイントを事前に把握しましょう。重要でないポイントは今すぐ理解できなくても大丈夫です。

何度か読み直して「ちょっとわからんな、今の自分には難しすぎるな」と思ったら、いったんそこはスキップしてどんどん読み進めていきましょう!

重要なポイントでなくても、自分にとって面白そうなら深掘りOK!

重要なポイントでなければ理解できなくても良いと書きましたが、そのポイントが自分にとって面白そうな内容であれば、深掘りするのは全然構いません。たとえば、「Linuxの教科書を読んでいたら、sed/awkがとても面白そうだったので、sed/awkを極めたいと思いました!」というのであれば、ぜひsed/awkを極めてください。「重要でないポイントは絶対に立ち止まるな」という主張ではないのでお間違えのないように。

まとめ

というわけで、このエントリでは学校の勉強とプログラミングの勉強は何が違うか、そして技術書をどう読むべきか、という話を書いてみました。

多くの日本人にとって、人生で「勉強する場所」と言えば「学校」ぐらいしかないので、プログラミングの勉強もつい、学校の勉強と同じスタイルになってしまうのは仕方ない面もあります。ですが、よくよく考えるとそれだけが全てではないはずです。なので、プログラミングの勉強をするときはちょっと視点を変えてみましょう😉

bootcamp.fjord.jp

新しいLinuxの教科書

新しいLinuxの教科書

自宅のリフォームとソニックガーデンの「納品のない受託開発」

伊藤さんの近況報告

1ヶ月ぐらいブログの更新が空いてしまいました。
子どもの卒業式・入学式や町内会の役員仕事やら、あれこれ用事が重なってゆっくりブログを書く時間がない今日この頃です。

ブログを書く時間がない理由のひとつに、家のリフォームがあります。
ふと思い立って、伊藤さんちでは現在、自宅の風呂、洗面所、トイレ、キッチンと、水回りを一通りリフォームしてしまおう!という計画が進んでいます。

今住んでいる自宅は築13年ですが、現状、特にどこか具合が悪くなった部分があるわけではありません。
じゃあなんでリフォームするのか?というと、理由は大きく分けて3つあって、

  • 新築当時は予算がなくて、水回りは平凡な風呂やトイレしか選べなかった
  • 家の設計をしていた当時は妻が長女を妊娠していた時期に重なっていて、つわりのせいで打ち合わせにあまり参加できず、妻のこだわりを十分反映できなかった
  • 長男が高校生になり、あと3年ぐらいしたら大学進学で家を出て行く可能性があるので、子どもたちが家にいる間にリフォームをしておきたい

・・・といった理由で、「家族全員が楽しめる間に、こだわりのリフォームを!」という運びになりました。

というわけで、2月ぐらいから急ピッチでキッチンメーカーのショールームを訪れたり、ハウスメーカーさんに図面を書いてもらったりしています。
で、僕の方はできあがった図面や見積もりを細かくチェックしたり、カタログを穴が空くぐらい眺めて、今回のリフォームに取り入れるべきオプションがないか、等々の確認をしています。
何か気になる点が見つかると担当者さんにメールを送ったりする必要もあり、なんだかんだであっという間に時間が溶けていきます・・・。

現時点では図面や見積もりが9割方固まった段階で、これから5月から6月にかけて順次工事を進めていく予定です。

f:id:JunichiIto:20210423111214j:plain
現在の我が家のキッチン。ここからさらにこだわりのキッチンにリフォームします

家のリフォームはウォーターフォール開発

で、当たり前といえば当たり前なんですが、家のリフォームは「THE☆ウォーターフォール開発」で進むんですよねー。
つまり、最初に全部仕様をかっちり決めて、見積もりと納期を出してもらって、互いに合意が取れたら契約して着工、というスタイルなわけです。

しかし、システム開発も家のリフォームも、ウォーターフォール開発はあまり嬉しくないです。
いかんともしがたいのはわかっているものの、どうリフォームするかを考えていると「実際に使ってみないとわからない」というポイントがたくさん出てきます。
カタログを見たり、ショールームに行ったりすることである程度想像しやすくなる部分はありますが、それでも限界があります。

たとえば「次回の打ち合わせまでにトイレや洗面所のクロスの色や柄を選んでください」とお願いされても、クロスのサンプルを眺めるだけじゃどういう組み合わせでどういうふうに見えるのか、正直よくわからないんですよねえ。

しかも、ウン百万もする大きな買い物なので、絶対失敗したくない。
でも、やってみないとわからない部分がたくさんあるので失敗しそう。
というジレンマ。

失敗はしたくないけど、かといって「試しにやってみて、ダメだったら作り直す」というオプションの選択はまず不可能なので、仕方なく図面やカタログとにらめっこしながら、脳内イマジネーションをフル稼働させる作業をずっと続けております。

システム開発もウォーターフォール開発はつらい

で、ここからシステム開発の話に移ります。
システム開発もウォーターフォール開発になるとこれとほぼ同じ問題が出てきますよね。
ウォーターフォール開発は仕様書を書いて、見積もりと納期を出して、合意を取れたら開発開始、というスタイルなので。
でも、システムだって使ってみなきゃわからない部分がたくさんあるわけです。
というか、システムには形がないので、家のリフォーム以上に「実際に使ったらどうなるか」を想像しにくいと思います。

僕はシステムを作る側の人間ですが、今回のリフォームでお客さんの立場に立つことで、あらためて「やっぱりウォーターフォール開発はあかんなー。絶対お客さんもつらいと思うわ」と強く思いました。

ハードの開発スタイルにソフトの開発スタイルを合わせる必要はない

ただ、システムは「形がないので想像しにくい」という弱点がある一方で、「建築物に比べるとはるかに作り直しやすい」という強みがあります。
「画面の色はどうしよう」とか「文字の大きさはどれくらいがいいかな」みたいな話であれば、その場でぱっぱっと変更することができます。
それだけでなく、もっと大きなレベルで「あとからCSVエクスポート機能を付ける」なんてことも、ソフトウェアであれば比較的簡単に実現可能です。

であれば、ウォーターフォール開発をやめたらいいんですよね。
ある程度大まかな要件を決めたら、実際に開発してみる。
そして、「実際に使ってみて、しっくりこない部分があれば作り直す」というスタイルにしちゃえばいいんです。
建築物はハードですが、システムはソフトなので、そもそものモノが違います。
なのでハードの開発スタイルに合わせてソフトを開発する必要はないわけです。
(何十年も前のソフトウェア開発だとコンピュータ資源の制約があってハードウェアと同じぐらい作り直しにくかったと思いますが、それは昔の話です)

システム開発をサブスクとして提供する「納品のない受託開発」

しかし、「何度でも作り直せばいいやん!」と思ってもその次に問題になるのが、「そのスタイルでどうやって商売するか」というビジネスモデルの問題です。
「事前に見積もりや納期を出す方式」で商売をすると、「何度でも作り直す方式」と相性の悪い部分がたくさん出てきます。

この問題を解決するために、僕が勤めている株式会社ソニックガーデンでは「納品のない受託開発」というビジネスモデルを採用しています。
これは文字通り、納品をなくして継続的に開発を続けるというビジネスモデルです。
今どきの言葉で雑にまとめると「システム開発のサブスク」ですね。
毎月定額料金で開発をし続ける、定額料金を払っている間はいくらでも作り直し可能、というスタイルで開発を進めます。(めちゃくちゃ雑なまとめですが)

「納品のない受託開発」は楽しい

僕はかれこれ10年近くこの「納品のない受託開発」でシステム開発を続けていますが、とても良い開発スタイル&ビジネスモデルだと思っています。
特にお客さんが新規事業を始める場合は「システムがどう出来上がるか想像しづらい」という問題以上に「お客さん自身のビジネスがどう転ぶかわからない」という問題の方が大きいです。
「納品のない受託開発」であれば、お客さんのビジネスの進化に合わせて継続的かつ柔軟にシステムを変更していく、ということが可能です。

なので、システムを作る側も、開発をお願いする側も、ウォーターフォール開発に比べると圧倒的にストレスが少ない開発スタイルだと思います。
まさに「win-winの関係」ってやつですね。

それにウォーターフォール開発だと、使うかどうかわからない機能も事前に作るかどうか決定しなければなりませんが、「納品のない受託開発」であれば「最初はその機能無しでリリースする。本当に必要になったらそのタイミングで機能追加する」という選択肢が採れるので、開発コストの節約にもなります。

今回、自宅のリフォームで「THE☆ウォーターフォール開発」に巻き込まれながら、「あ〜、家のリフォームも『納品のない受託開発』スタイルでできたらいいのにな〜」と何度も思った次第です。

まとめ(と、We're hiring!)

前述の通り、「納品のない受託開発」は発注者側だけでなく、開発者にとってもメリットがあります。
お客さんと直接やりとりをしながら、二人三脚でシステムを開発していくのはとても楽しい作業です。
バリバリコードを書きたいけど、ウォーターフォール開発だとなんかすごくストレスが溜まる……と考えている開発者のみなさんは、「納品のない受託開発」プログラマになると幸せな開発者体験が待っているかもしれません。

興味がある方はぜひソニックガーデンのホームページを覗いてみてください😘
www.sonicgarden.jp

あわせて読みたい

「納品のない受託開発」について詳しく知りたい方は社長の倉貫さんが書いたこちらの書籍もどうぞ。
現在では変わった点もいろいろありますが、基本的な考えは大きく変わっていません。

「納品」をなくせばうまくいく

「納品」をなくせばうまくいく

  • 作者:倉貫義人
  • 発売日: 2014/07/18
  • メディア: Kindle版

Chromeの画面通知が出ないときの確認ポイント & M1 Macを仕事で使ってみた感想

最近M1 Macを買いました。というか会社に買ってもらいました。(感謝🙏)

開発環境を旧マシンから移行していってるんですが、会社で使っているチャットツール(Remotty)のChrome通知の動きがおかしかったので、確認ポイントと解決策をメモしておきます。

発生していた問題

チャットツールで新しいコメントやメンションがあったときのChromeのブラウザ通知が、音だけ聞こえて画面上の通知(下記画像)が出ない。

f:id:JunichiIto:20210323192925p:plain:w300

確認したポイント

サイト設定(問題なし)

URL入力欄の鍵マークをクリック→Site settingsを開く→Permissions > NotificationsがAllowになっているか?(なっていた)

f:id:JunichiIto:20210323173458p:plain:w300

あ、ちなみに僕は英語モードでMacを使っています。

Do Not Disturb設定(問題なし)

System Preferences > Notifications > Do Not Disturbで、通知を出さないような設定になっていないか?(なってないので問題なかった)
f:id:JunichiIto:20210323185858p:plain

今回の解決策 = System Preferences上のChromeの通知許可を許可する

System Preferences > Notifications > Google Chromeで、通知が不許可になっていないか?→なっていたので通知を許可した(解決!)
f:id:JunichiIto:20210323190133p:plain

これでめでたく通知が表示されるようになりました🎉

Special thanks

このエラーの解決策を一緒に探してくれた弊社ソニックガーデンのメンバーに感謝!🙏

おまけ:M1 Mac、どう?

速くて熱くならない=期待どおりのパフォーマンス

まだ使い始めて数日なので最終的な結論は出せないですが、おおむね良いです。
今まで使ってたMacBook Pro(Intel Mac)は2コアでM1 Macは8コアなので、コア数が多いぶん全体的に処理に余裕を感じます。
動きもIntel Macに比べるとキビキビ動きます。
キーボードの入力も反応が速くなったように思います。
(というか、Intel 2コアが遅すぎた)

今まではちょっと大きなRailsプロジェクトをRubyMineで開いたり、ビデオ会議で画面共有したりするとすぐにMacが熱くなってファンがうなりを上げていましたが、M1 Macでは今のところそういう現象が起きていません。
本体を触ってもほんのりぬくもりを感じる程度です。

そもそもなぜ僕がM1 Macに買い換えようと思ったのかというと、「これからだんだん暑くなってくる季節に、このIntel Macじゃもう乗り切れん!」と思ったからです。
RubyMineの動きもだんだん重くなってきたので、Intel Macじゃ開発効率が悪い、というか今のご時世に2コアじゃ全然足りない!と思いました。

というわけで、今のところ重たい処理も涼しい顔でこなしてくれるし、8コアでマルチタスクも効率良く処理してくれるので、M1 Macはとっても快適!という感想です。

開発環境としてはやや不安あり(でも現状はなんとかなってる)

その一方で、RubyやRailsの開発環境としてはまだちょっと不安が残る感じです。
Intel Macでは遭遇しなかったようなエラーがたまに発生するので、「えっ、もしかしてこのライブラリはM1 Macにはインストールできない?」とか思って焦ります💦

変なエラーが起きたときは、

  • ググって解決策を見つける(8割ぐらいは解決策や回避策が見つかる印象)
  • ググっても解決策がない(Issueは報告されているが誰も解決していない)ときは、そのツールを捨てる方向で動く

という対処方法でなんとか乗り切っています。
でもそのうちどうしても乗り越えられないエラーが出てくるんじゃないか?と少しビクビクしています。。

あ、ちなみに僕は開発環境構築にDockerは使っていません。
あと、Virtual BoxみたいにM1 Macに対応していないミドルウェアは最初からM1 Macに移行するのを諦めています。

自分が使っているアプリやツールがM1 Macに対応しているかどうかは、下のサイトでチェックすると便利です。
isapplesiliconready.com

すべてのツールがM1対応するまで、もうしばらくIntel Macは手放せないですね。

あわせて読みたい

前回、Intel Macを買ったときのブログ記事です。
買ったときから「あんまり速くないな〜、このマシン・・・」という印象だったんですよねえ😑
blog.jnito.com