「シブヤクハック」で渋谷区のゴミ問題をハックしてきました!(後編)
Microsoft主催のハッカソンイベント「シブヤクハック」に参加してきました!
シブヤクハックは、渋谷区が抱えるいくつかの課題に対し、MicrosoftのAzureを中心とした各種技術を使って2日間でアイデアを検討・実現しよう、というイベントです。
このエントリは、そんなシブヤクハックの2日目を僕の目線から振り返ります。
1日目はコチラです。
2日目は朝10:00に各グループで集合してのスタートで、前の日に考えたアイデアを元に設計→実装→成果発表→投票→懇親会というスケジュールでした。
アイデアを形にするまで
まずは、スタートから実装終了までを振り返ってみたいと思います。
設計
僕の所属する通称「ゴミチーム」は、1日目でだいたいのアイデアはまとまっていたこともあり、2日目はそれを元に技術的な設計を検討するところからのスタートでした。
最初はAzureにどのようなプロダクトがあるかもあまり分からず、瀬尾さんにいろいろと教わりながら30分ほど検討し、最終的に以下のようなシステム構成でまとまりました。
細かい技術的な話は他の技術者向けの記事でまとめる予定ですが、全体としてMicrosoftのAzureで提供される各プロダクトを上手く使い分け、以下の工程を実現しています。
- 渋谷区内のゴミ画像をSNSから取得(Logic Apps)
- 取得した画像から、各地点・時間ごとのゴミの量を解析(Custom Vision Service)
- 区の職員向けに、蓄積したデータを可視化(Power BI)
各工程で生成したデータはBlob StorageとCosmos DBに保存し、各プロダクトの連携にはFunctionsを利用する、という設計です。
いざ、実装
次に実装に映ります。
ここで面白かったのが、実装と言っても午前中の残り時間(10:30~12:00)はひたすらAzureの各プロダクトをWebブラウザから操作するのみだったことです。
コードは一行も書かず、ブラウザ上でCustom Vision Serviceに学習用の画像をひたすらアップロードして学習させたり、CosmosDBの設定をしたり、それをチームメンバーのアカウントと共有したり、とった具合で、上記の1, 2, 3でやろうとしていたことが単体で動くようになってしまったのは、ただただ便利の一言でした。
この時間に、渋谷区役所職員の宮島さんに、実際に渋谷区を歩き回ってゴミ画像を収集していただきました。ありがとうございます!
実際に撮っていただいた写真はコチラ。
やっぱり実際のデータがあると開発も調子が出ますね。
試しに撮っていただいた写真をCustom Vision Serviceに投げてみたところ、それなりに見た目から受けたイメージと近い数値(ゴミ捨て度)が返却されたのも、さすがMicrosoftの技術でした。
お弁当
12:00ごろになるとお弁当が支給されました(ごちそうさまです!)。
「ハッカソン」というとご飯を食べる暇もなくひたすらパソコンに向かってコーディングするイメージがあったのですが、今回はそんなこともなく、チームメンバーや同じ部屋にいる別のチームの方々とも話をする余裕もあり、とても楽しい時間でした。
ちゃんとしたアイデアと設計、そしてAzureがあったからこその余裕だったのではないかと思います。
実装再開
お昼を食べてリフレッシュしたところで実装再開です。
午前中でCustom Vision Serviceである程度画像からゴミの有り・無しが判別できるようになったため、ここからはFunctionsでコードを書いて
- 画像データを取得
- 取得した画像データをCustom Vision ServiceのAPIを使って解析
- 解析結果をCosmos DBに保存
という処理を書いていきます。ここでようやくコーディング開始です。
難しいところはAzure任せのため、処理の内容は各Azureプロダクトを連携させる、とてもシンプルなものの想定でした。
のですが、実際に書いてみると予想外にハマるポイントが多くあり、FunctionsからCustom Vision ServiceのAPIを叩いてもなぜかエラーが返ってくる、FunctionsからCosmosDBのデータが取得できない、などなど、ここから実装終了時間まではハッカソンらしい試行錯誤の時間でした。
結局、チームメンバーの瀬尾さんやnoriさんにいろいろ助けてもらいながらも17:00の実装終了時間までに問題が解決せず、「うまく動いたらこんなデータが出るはず」のサンプルデータをPower BIで可視化した画面で成果発表をする作戦に変更となりました。
ちゃんと動くところまで作れそうだった&作りたかったためこの結果はとても悔しいですが、重要なのは成果発表でチームのアイデアがどこまで区の方々へ伝わるか、ということで気持ちを切り替えて成果発表に向かいます。
なお、問題の技術的な詳細については別の記事かQiitaにでもまとめて投稿しようと思います。このエントリは技術者でない方も読むため割愛です。(しかもまだ解決してないです、、、)
発表する
ここからは参加者全員で集まって、各チームの成果発表です。
発表の後には投票があり、投票があるということは順位が決まり、さらにはニコ生で何千人もの人が見ていることもあり、とても緊張する瞬間でした。
成果発表
ゴミチームは最後の発表でした。
実際の成果発表の様子はニコ生で(有料会員限定ですが)見返せますので、もし興味があれば見てみてください。
こちらの8:23:00 あたりからです。
最初に企画の全体像とそこに至るまでに議論したことを振り返り、実際にハッカソンでやったこと、成果として見せられるものの紹介、という流れでの発表でした。
発表資料は瀬尾さんに(僕がAzureにハマっている間に)作っていただき、僕はそれを他チームの発表の合間のちょっとした時間でチラ見する、というだいぶギリギリな準備だったのですが、作っていただいた資料が上記の流れでとても話しやすかったためなんとか制限時間内におさめつつ話すことができました。瀬尾さんありがとうございました!
タッチ&トライ
発表の後はタッチ&トライの時間で、各チームのデモを見て回っていました。
実装が思ったところまで完了しなかったのは自分のチームだけかと思いきや、実際はどのチームもアイデアと実現できたことにギャップがあったようで、ちょっと安心してしまいました。
とはいえ、どのチームもアイデアを直接聞きながらデモを見ると、どれも挙げられていた課題を効果的に解決できそうなものばかりで、とても見ていて楽しい時間でした。
と同時に、自分たちのゴミチームにどれだけ票が入るか心配で、落ち着いてデモを見て回れなかったのも正直なところでした。
結果発表
さて、タッチ&トライも終わって最後の結果発表、今回は各チームのリーダー(つまり僕も)が投票箱を持って、玉入れのカウント方式で一枚ずつ取り出しながらの集計でした。
ぱっと見とても少なく見えたので「やっぱりダメだったか、、、」という気分だったのですが、いざカウントアップしてみると意外と多い方だったようで、結果は2位。1位のチームとは2, 3枚差でした。おしい!
澤田副区長の総評によると、ゴミチームはプレゼンやアイデアはよかったものの、今回の企画を実現した後のビジョンについての言及が足りなかったそうで、1位のチームにはそれがあったから投票用紙を10枚全部入れたとのこと。10枚全部って、、、それ少しでもばらけて入れてたらゴミチーム1位だったじゃないですか、、、
ご自身でも言っていた通り、副区長はメリハリのある方でした。
まあ言っても結果は変わらないですし、アイデアを評価されたのは確かですし、1位のチームのアイデアが良かったのも事実なので、総じて納得して結果発表終了しました。これでハッカソンは終わり。あとは飲むだけです!
懇親会
懇親会では、2日間同じチームでお世話になった方々の他にも、他のチームのエンジニアの方、渋谷区役所の職員の方、マイクロソフトの方など、いろいろな方とお話させていただくことができ、1時間とは思えないほど良い交流ができました。
特に瀬尾さんが「You MicrosoftのMVPになっちゃいなYo!」としきりにおっしゃっていたので、今年はMVPを目指していろいろ情報収集と発信をしてみる年にしようと思います。なれなかったとしても、それで得た知識はきっとフリーランスの仕事のプラスになるはず!
ちなみにMicrosoft MVPについてはこちら。
マイクロソフトの製品やテクノロジに関しオンライン、オフラインで顕著な活動をされている個人を表彰するプログラム
だそうです。過去1年に遡って成果を見るそうで、現在僕は成果ナシのため、道のりは険しそうです、、、
まとめ
以上、シブヤクハックの2日間の振り返りをしてみました。
ハッカソン、ニコ生中継、Azureでのプロダクト開発などなど、初めてのことだらけで参加する前はとてもドキドキだったのですが、結果として開発やプレゼンなど、それなりに前向きに参加できてとても満足の2日間でした!
特にAzureを使ってちゃんとプロダクトを作ろうとしたのは今回が初めてでしたので、趣味ではなく実際の開発現場でAzureを使うイメージを少しでも持つことができたのはとても大きな成果でした。
ハッカソンの中では時間の関係で実装できなかった部分もありましたので、また落ち着いて実装を進めてみようと思います。(が、1週間放置してたらサブスクリプションの残額が切れてしまいました、、、どうしたものか)
「シブヤクハック」で渋谷区のゴミ問題をハックしてきました!(前編)
Microsoft主催のハッカソンイベント「シブヤクハック」に参加してきました!
このハッカソンは、渋谷区が抱えるいくつかの課題に対し、MicrosoftのAzureを中心とした各種技術を使ってアイデアを検討・実現しよう、というイベントです。
このハッカソンには一般の開発者だけでなく、なんと渋谷区役所の職員の方やMicrosoft MVPの方、そしてもちろんMicrosoftの技術者の方も一緒になってグループでハックする、というのがとてもユニークで面白いイベントでした。
僕はといえばハッカソン初参加だということも忘れて勢いで通称「ゴミチーム」のリーダーをさせていただき、初日と最後の成果発表でしゃべらせていただいてしまいました。
緊張しましたが、最終的には投票2位に入れたこと、最後の澤田副区長の総評でアイデアに対して好評をいただけたことなどもあり、とても楽しいハッカソンでした!
また今回、Azureをちゃんと目的を持って使うことができたことも、技術的にもとても勉強になりました。
さて、このエントリではそんな「シブヤクハック」を、僕の目線から時系列で振り返ってみたいと思います。
概要
シブヤクハックの公式ページはこちらです。
このページの下の方に渋谷区役所の職員の方々が事前にブレストした(「ブレスト」自体があまりない体験だったとか、、、!)結果挙げられた課題23個が掲載されているのですが、僕たちゴミチームはこの中の10番目「街でゴミを捨てる場所、設置状況を皆知らない。結果としてポイ捨てが減らない」をターゲットにハッカソンを開始しました。
その結果生まれたアイデアはHacklogにアップしてあります。
1日目
初日(3/23 18:00〜22:00)は参加者が渋谷区の課題を理解し、グループに分かれてそれを解決するアイデアを考える、いわゆる「アイデアソン」の時間でした。
僕たち「ゴミチーム」は、一般の開発者として僕と noriさん、技術サポートにMVP for Windows Developmentの瀬尾さん、そして渋谷区職員の宮島さんの4人チームで、渋谷区のポイ捨て問題をターゲットにしました。
課題を深堀する
話をしているうちに、以下の3つの問題が重要なポイントだということが見えてきました。
ゴミのポイ捨てはソフトウェアで解決できる課題なのか?問題
ゴミのポイ捨て問題は言うまでもなく物理的な問題です。 そのためこれを解決するためには最終的にゴミ箱の設置場所、設置時期を工夫する等物理的な対策が必要になります。
つまり我々エンジニアがWebアプリやスマートフォンアプリを作っただけではゴミ問題の解決は難しいことが予想されます。 ハッカソンとして、技術「だけ」で渋谷区から路上のゴミを一掃することは現実的ではなく、この問題を解決するための別の観点でのアイデアの検討が必要でした。
ゴミのポイ捨ては本当に課題なのか?問題
この問題は区役所の職員の方が会議室で話している中で出てきた課題です。つまりネガティブな言い方をすると「イメージだけで話している」可能性がある、と言えます。
特に渋谷区は渋谷駅を抱えており、渋谷駅周辺はハロウィンなどのイベントがあると人が殺到してゴミ箱があふれ、ゴミのポイ捨てが問題になる、という事情がある区です。
ハロウィンの後のゴミのイメージはたしかに強烈ですが、冷静に考えるとそんな規模のイベントは年に数回もなく、それ以外の日にゴミのポイ捨てが本当に問題になっているのか、また駅から少し離れた地区でも同じ問題が発生しているのか、などがまだイメージの域を出ない状態で、現状の正確な把握が必要である状況が見えてきました。
ゴミ箱はそんなに簡単に設置できない問題
実際にゴミ箱を増設することを考えた場合、渋谷区が設置できるゴミ箱の数には限界があります。 国道・都道は国や都の持ち物であり、そこに区が新しくゴミ箱を設置するにはそれなりの交渉や時間が必要になるためです。
もちろん区が管理する土地であればゴミ箱は比較的楽に設置できるのですが、現状ではそれは公園など街の一部に限られているようでした。 ゴミを捨てたいためだけに公園に向かう、という人はそう多くないでしょう。
スコープを定義する
以上のことから、僕たちゴミチームは今回のハッカソンで「ゴミをなくす」ではなく、「ゴミ問題の現状を正確に把握する」ことを今回のスコープとして定めました。
先ほど書いたとおり、ソフトウェアは物理的な問題を解決するには力不足な一方で、「情報」を整理してユーザーに提供することに関しては最適な手段です。今回のハッカソンではゴミ問題の現状を正確に把握できるソフトウェアを開発し、そこで得られた情報を元に次のフェーズで区の職員の方々が物理的な施策を検討する、という流れでアイデアをブラッシュアップすることになりました。
その結果まとまったのが、先ほどのHacklogです。
街ゆく人がTwitter等のSNSに渋谷区の路上を撮影したくなる仕組みを作り(今回は「キャッチーなハッシュタグ」を検討しました)、その投稿データや写真から「いつ」「どこで」「どのくらい」ゴミが捨てられているのかを解析します。
解析したデータを地図やグラフにプロットして可視化することで、区の職員が手軽にデータを閲覧し、それを見ながら次の具体的・物理的なアクションを検討できるようにしよう、というものです。
発表する
以上のアイデアがまとめられ、ちょっとした技術的な検討を始めたところで時間終了。中間発表の時間になりました。
僕がしゃべらせてもらった発表は可もなく不可もなく(どちらかというと言い忘れた部分がいくつもあった記憶でしたが)、それよりも発表がニコ生で中継されていることで頭がいっぱいでした。
ちょまどさん効果もあってか、その日の視聴者数はなんと3, 4時間ほどで1万人超えだったとか!
会場は2, 30人そこらの小さな部屋だったのですが、仰々しいカメラとその先で見ている視聴者の方々のことを考えると、今までにないくらいの大舞台で発表した気分でした。
まあ言い忘れなどはありましたが、そこは明日の実装と成果発表で挽回ということで、残りの時間をもう少し実装方法の検討に使って1日目は終了でした。
ここまで、Microsoft主催のハッカソン「シブヤクハック」の僕の1日目について振り返りました。
ハッカソンもニコ生も行政の課題も、どれも初めての体験だらけではありましたが、とても良い議論と良いアイデアを出せたことは大きな成果だったと思います。チームメンバーの方もとても話がしやすく、どんどんアイデアをより良いものにすることができました。
ここから2日目、怒涛の実装に入るのですが、長くなってしまったので続きは後編で書きたいと思います。
後編ではAzureの各プロダクトを使ったアイデアの実装とその成果発表、投票の様子などを書きたいと思います。
(宣伝)
プロフィール欄にも書いていますが、僕はフリーランスエンジニアとしてWebサービスの開発を仕事にしています。
渋谷区生まれ渋谷区育ち、両親祖父母が現在も渋谷区在住の身として、今回のハッカソンで検討した課題はどれも他人事ではない問題ですので、今回のアイデアを形にする際はぜひお仕事のご連絡をいただければ嬉しく思います。
ペライチ主催のイベント「クラフトビールを飲みながらエンジニアと交流しよう 」でLTしてきました
だいぶ時間が経ってしまいましたが、1/25(木)に、ペライチ主催のイベント「クラフトビールを飲みながらエンジニアと交流しよう 」でLTしてきました。
発表内容はこちら
www.slideshare.net
なんと発表の音声を橋田さんのVoicyにもアップしていただけました!
ちょっと声が遠くて聞き取りづらいのですが、BGMを消して音量を上げればなんとか聞こえるのではないかと思います。
LTの内容はGitHub上でのコードレビューを通してRubyを学習できるCodeYourRubyというリポジトリの紹介でした。 この内容はそれまでにも何度か別の勉強会でLTしてはいたのですが、今回はLT後のフィードバックや議論が特に盛り上がりましたので、それについて書いてみたいと思います。
CodeYourRubyを事業化する
議論の主な内容は、「どうしたらレビュワーが集まるか」から発展して、「どうやったら事業化できるか」という視点でした。
ちなみにCodeYourRubyは僕の思いつきと勢いだけで作ったリポジトリで、これを事業にするという発想は全くなかったのですが、LTを聞いてすぐに「もしこの取り組みを事業にするなら?」という視点で議論が盛り上がったところは、さすがベンチャーの世界に生きている方々だと感じました。
レビュワーを集める
さて、一旦事業化は置いておいたとしても、CodeYourRubyはその性質上、「レビュワー」にとっての参加するメリットがとても弱く、プルリクは溜まるけれどそれをレビューする人がいない、という問題を抱えています。
それに対する解決策として、LTの場では以下のようなアイデアが出ました。
- 良いレビュワーにポイントを付与する
- レビュー内容を採用活動に利用する
前者は質問サイトのように良いレビューをしたユーザーにリアルな買い物で使えるポイントを付与することで、レビュワーのモチベーションを上げよう、というものです。
後者は、企業が採用活動をする上で応募者にCodeYourRuby上でのレビューを必須にすることで、そのレビュー内容を応募者の特性の判断材料として活用する、というものです。
この記事では、後者のCodeYourRubyを採用現場で活用するアイデアについてさらに考えてみたいと思います。
採用の判断材料としてのレビュー
やってみると分かるのですが、「レビューする」というのは自分の知識や経験、調査力とそれを伝える力をとても必要とする行為です。
自分の知っている領域だからと言っても、他の人が書いたコードをよりよくするための案を説得力を持って伝えるためには、それ相応の根拠となるリソースの引用や、分かりやすく伝えるためのコミュニケーション的な工夫が必要になるためです。
同じチーム内の顔見知りに対してのレビューならまだしも、CodeYourRubyはオープンな場での、全く知らない人に対するレビューで成り立つため、さらにこの点に気を遣ってコメントする必要があります。
つまり、コメントが曖昧でないか、経験や根拠を明らかにして説得力のあるコメントができているか、伝わりやすい言葉選びができているか、など、コードレビューを見ることでその応募者の技術力や調査力、コミュニケーション力を計れると期待できます。
まとめると、レビューをすること(そして自分の能力を示すこと)が採用につながるためレビュワーが真剣にレビューをし、初心者はそのレビューを求めてプルリクを送り、採用担当者はそのやりとりを見て良い人材を発見できる、そんな場をCodeYourRubyで実現できるのではないか、というのが当日盛り上がった議論(と、後日僕が考えた内容)でした。
収益をどうするか
しかし一方で、「どう収益化するか」という点が課題です。
例えばこれで採用活動を効率的に進められるようになる企業側からお金をもらうことを考えたとしても、CodeYourRubyはオープンなGitHubリポジトリのため、レビューの内容を閲覧することに対する課金を強制することはできません。
ではリポジトリをPrivateにして、契約した企業だけ見られるようにするか?というとそれもできません。CodeYourRubyにはまずRubyを学習するエンジニアが自由にアクセスし、自由にプルリクを送れる必要があるからです。
マネタイズするには、今のようなGitHub上で全て完結するような考え方ではなく、そこから発展した何らかのサービスの開発が必要になりそうです。が、そのあたりは全くのノーアイデアです。
まとめ
というワケで、CodeYourRubyを事業として成長させることについてあれこれ考えてみました。
今の段階での考えとしては、事業として収益を上げるのではなく、まずは純粋にレビュワーも惹きつける仕組みづくりをするのが現実的かなあ、という状態です。
マネタイズを考えなければ、採用担当者はCodeYourRubyに投稿されているプルリクをひとつ選んで応募者に課題として伝え、そのプルリクの流れを見ることでこの記事に書いたように活用できます。もしかしたら、社内の新人が勉強を兼ねてレビュー対象となるコードをコミットしても良いかもしれません。
まだまだCodeYourRubyの活かし方については試行錯誤中ですが、もしこの記事に記載したアイデアに興味を持った方がいらっしゃいましたら、ぜひご連絡ください!
最後に、こんな有意義な意見交換ができる場を開催していただいたペライチのみなさま、ありがとうございました!ビールもとてもおいしかったです。
「プロを目指す人のためのRuby入門」から学ぶ「分かりやすい入門書」
@JunichiItoさんの「プロを目指す人のためのRuby入門」をとりあえず1周読みました。 まだ全部写経できた訳でも理解できた訳でもないですが、ひとまず読み終わりましたということで、考えたことを一度まとめてみようと思います。
「Rubyは初心者」にオススメ!
先にオススメしておきます。この本は僕のような他の言語で開発の経験があったり、すでにある程度Rubyプログラミングを進めていたりする人には強くオススメです!
言語に依らない基本的なプログラムの書き方(forやif、変数など)は理解していることを前提に、「Rubyらしさ」が重点的に書かれているため、新しい言語としてRubyを学ぶ時に知りたいことがとてもよく分かる内容になっています。
その辺りはまさに @JunichiItoさんがブログに書いている通りでした。
というところで、Rubyの学習にとても良い本であるということは上の記事や他の方のブログなどに書かれている通りですので、この記事では詳しく書きません。代わりにこの記事では、どうやったらこんな分かりやすい内容の入門書が書けるのかという点に着目して考えてみたいと思います。
この記事の対象読者
先述した通り、この記事では「ここがよかった!」などの読む側の視点ではなく、「こう書くと分かりやすい!」という書く側としての視点から本書の良いところを探してみたいと思います。
現在僕はDjangoを利用したWebアプリケーション入門研修のテキストを作成しています。しかし自分の書いた内容がどうしても「分かりやすい」とは思えず悩んでいたところ、ちょうど本書が発売され、なぜこの本が「分かりやすい」のかを考えてみることが自分のテキスト作りにもプラスになるのではないかと感じました。
この記事は僕のような初心者に対して「分かりやすい」文章を書きたいと思っている方に役に立つような記事になれば良いと思います。
なお、この記事に書かれていることは引用部分を除いて全て僕の推測ですので、@JunichiItoさんや編集者さんの意図したことだとは限らないことにご了承ください。
50点の内容を100%理解できる本
まず、この本の一番の特徴は50点の内容を100%理解できるように書かれた本であるということだと思います。
多くの技術的な入門書やWebの記事は、なるべく誤解を与えないためか「100点の内容を書く」ことに注力する傾向があります。APIドキュメントのようにメソッドとその説明を列挙したり、文法を余すところなく説明したり、という具合です。
そのような内容はリファレンスとして有用ですし、それをきちんと理解できれば実際の開発で役に立つことは間違いありません。しかし「入門書」となると話は別です。
その分野の初心者としては、隅々まで説明されても実際の開発現場ではその中のどこが特に重要になるのかが判別できません。その結果、100点の内容のうち10%しか理解できない結果になってしまいます。
一方で、要点を絞り、主観を交えて大事な部分を強調することによって厳選された50点の内容を100%理解できれば、結果として5倍の内容を身につけられるというのが本書を読んで考えたことでした。
ここからは、厳選した50点の内容を100%理解できる文章にするための本書の具体的な工夫について考えてみたいと思います。
「分かりづらい」書き方
「分かりやすい」書き方を考える前に、ここでは先に「分かりづらい」書き方について考えてみようと思います。あらかじめ書いておくと、本書はここで説明する「分かりづらい」書き方を避ける工夫がいろいろと凝らされています。
今までの経験上、僕が本を読んでいて「分かりづらい」と感じてしまう瞬間は以下の通りです。
- 何が便利でどう使われるのかが説明されないまま淡々と話が進む
- 新しい話題が突然出てくる
- 自分の前提知識や目的に沿っていない
それぞれについて、詳しく考えてみたいと思います。
何が便利でどう使われるのかが説明されないまま淡々と話が進む
たとえ素晴らしい技術や仕組みだったとしても、その素晴らしさが伝わらなければ読んでも頭に残りません。自分がそれを使う具体的なイメージがないままだと、その内容をとりあえず「暗記」しなければならない気になってしまい、結果的に「分かりづらい」説明になってしまいます。
新しい話題が突然出てくる
ひとつの技術について説明していると、周辺知識として別の技術の説明が必要になることがあります。そんなとき、「100点の説明」をしようとするとどうしてもその周辺知識の説明が長くなってしまい、読んでいて「あれ、今なんでこの技術を勉強してるんだっけ?」という気分になってしまい、結果としてその内容が頭に残らなくなってしまいます。
自分の前提知識や目的に沿っていない
基本的に入門書を読むときは、「これができるようになりたい」という目的や「今はここまで理解している」という前提知識があります。
そんな中、自分の目的に沿っていない内容にページを割かれたり、すでに知っている内容を改めて説明されてしまう(もしくはまだ知らない内容を既に知っている前提で説明が進んでしまう)と、「この本は自分に合っていないのではないか?読み進めても意味がないのではないか?」と考え始めてしまい、とりあえずページを進めることが目的になってしまいます。
以上、「分かりづらい」文章の特徴をざっと挙げてみました。
ここから考えてみると、自分にとって程よく新しい内容が書かれていて、さらに読み終わった後に自分がそれを活用できている姿が想像できると「分かりやすい」と感じられるのではないかと思います。逆にその状態から外れてしまうと、だんだんと集中力がなくなって「分かりづらい」と感じるようになるのではないでしょうか。
「プロを目指す人のためのRuby入門」はそれをどう解決しているか?
では、このような問題を本書はどのように解決しているのかについて考えてみます。
念のためもう一度書きますが、ここで書く内容はあくまで僕の推測や感想であり、@JunichiItoさんが意図した工夫だとは限りませんので、ご了承ください。
「何が便利でどう使われるのかが分からない」問題
これは「第3章 テストを自動化する」や「第6章 正規表現を理解する」が良い例だと思います。
本書では、その技術を「使わなかった場合」について説明した上で、「使った場合」に同じ要件をどれだけ楽に解決できるか、という順序で説明しています。
これについては@JunichiItoさんご本人も以下のようにツイートしています。
他の言語で長年やってる人はともかく、「プログラミング歴=Ruby歴=半年か1年」みたいな人は「/ab+c/は"abbbc"にマッチします」みたいな説明しか読んだことないのでは?と思ってます(僕の想像)。なので、まずは実際のユースケースがイメージできるような説明を最優先にしています。 https://t.co/5DQ50495B8
— Junichi Ito (伊藤淳一) (@jnchito) 2017年11月22日
また、本書は各章の構成が「例題の要件定義」→「基礎的な説明」→「例題」→「さらに発展的な説明」となっており、中でも「基礎的な説明」は例題を解決するためいの必要最低限な内容に絞られているため、そのどれもが例題として挙げた要件を解決するために実際に使えるものであることを意識しながら読むことができます。
また、細かく文章を見てみると、「実際に使うことはありませんが知識として」とか、「Rubyの開発では~がよく使われます」などのように、どの程度の温度感で説明を読めばよいのかが分かる前置きがされていて、メリハリをつけて読めるよう工夫されています。
「新しい話題が突然出てくる」問題
先述の通り、本書は「例題の要件定義」→「基礎的な説明」→「例題」→「さらに発展的な説明」という構成になっています。
そして、個別のAPI仕様などの細かな要素は例題の要件を実現するために必要なものだけに厳選されていて、それ以外の周辺知識についてはWeb上の記事や公式ドキュメントへのリンクを示すのみにしてバッサリと切り捨てる、という工夫がされています。
これによって、書く側としても今書くべき内容が何かを迷う必要なく、また読む方としても話題があちこち逸れる感覚がなく読み進められるようになっています。
書籍によってはバッサリ切ることも詳しく説明することもないままに「とりあえずこれはおまじないとして、~のようなものだと思っていてください」のような曖昧で混乱を招くだけの説明をされることもあることを考えると、この進め方はとても読者に親切だと感じました。
このあたりの既存の記事へのリンクの活用方法は、普段QiitaやブログなどWebで記事を書き慣れている@JunichiItoさんならではの感覚だなー、と思います。
「自分の前提知識や目的に沿っていない」問題
前提知識や目的は、読者一人ひとりによってさまざまですので、この問題を100%解決するのは難しいように思います。しかしだからと言って内容を網羅的にしてしまって「読者一人ひとりが自分に合った読み方をしてくれればよい」というアプローチは、この問題をさらに深刻にする結果にしかなりません。
本書はまえがきを以下のような質問から始めることによって、この問題を解決しようとしています。
Q1.すでにほかのプログラミング言語で3年以上の開発経験がある。もしくは「プログラミング歴=Ruby歴」で、 Rubyを始めてから半年以上経っている。 (Yes/No)
Q2.Rubyを学習する動機はRailsアプリケーションの開発に役立てるためだ。 (Yes/No)
Q3.すでに仕事でRubyを使っている。もしくはこれからRubyを使った仕事に就こうとしている。 (Yes/No)
みなさんはいくつYesになりましたか? 3つともYesになった方は、本書がみなさんのニーズを満たしている可能性が高いです! 反対に、3つともNoだった方は残念ながら本書がお役に立つ部分は少ないかもしれません。Yesが1つ、または2つだった方は、もしかするとみなさんのニーズにマッチする部分があるかもしれないので、もう少しじっくり本書の内容を吟味してください。
これからRubyを勉強しようという人の中で、これが3つともYesになる人の割合はそれほど高くないのではないかと思います。このような質問によって「読者を減らす」ことで、読者の前提知識や目的をある程度そろえることができるのです。
あとは、その絞られた読者に対してのみマッチする内容や文章を書くことによって、より多くの読者にとって前提知識や目的に沿った説明ができる、という訳です。
また、少し小道に逸れた説明に入る際は必ず「ちょっと難しい内容で混乱するかもしれませんが」のような注釈がついて、ここから説明する内容が前提知識や目的に沿っていない可能性があることを教えてくれるのも、本書の親切なところです。
「ターゲットを絞る」というのはマーケティングの基本だと言われたりもしますが、いわゆる入門本でここまで具体的に、バッサリと読者を選ぶ本というのも珍しいのではないかと思います。(たぶん「初級者でも中級者でも楽しめます!」と書いておいた方が売り上げが良いとかそんな事情があるんじゃないかと邪推しています)
しかし、そうすることによって読者にとってピッタリの内容を狙って書くことができるというのは、読者目線に立った工夫なのではないかと思います。
まとめ
以上、「プロを目指す人のためのRuby入門」から学ぶ「分かりやすい入門書」の書き方の考察でした。
テキスト作成であれ、Qiitaへ投稿する記事であれ、ある内容を誰かに説明する機会は少なからずあると思います。そんなとき、本書でされている(と思う)工夫を活用してみることで、もう一歩「分かりやすい」説明ができるようになるのではないかと思います。
少し話題は逸れますが、この本を読んでいてもうひとつ、@JunichiItoさんはとてもよく勉強されている方なんだなー、とも感じました。
このテキストは写経しやすいような閉じない紙質であったり、議論が発生することを前提にした主観的な説明であったり、すべての説明に付属されているサンプルソースであったりと、「読んでわかった気になって終わり」ではなく実際に仕事で使えるようになるための道案内がとても親切にされています。
これはきっと、実際に@JunichiItoさん自身がRubyやRailsを1から勉強して仕事で使う中で、実践で使えるようになるために必要な道筋をその身をもって体感したした結果なのではないかと思います。
「本書の刊行に寄せて」に書かれているまつもとゆきひろさんの
「ああ、人の気持ちがわかるとはこういうことなんだなあ」と何度も感じました
という表現は、本書の読者と同じように@JunichiItoさんもRubyを勉強してきた経験が、本書に強く反映されているということなのかな、と勝手に解釈しています。
長くなってしまいましたが、このような良書を先行販売で読めてよかったです!
まだ仕事でRubyを使うのは少し先になりそうですが、それ時が来るまでに本書をもう一度写経し直し、それをベースにAPIリファレンス等を読み、実際にプログラムを書きながらRubyの腕を磨いておこうと思います。
ノンエンジニアのためのプログラミング入門 第1回:Hello World!
こんにちは。フリーランスでWebシステムの開発や新人研修などをしている @chooyan です。
先日、coconalaというサービスで「文系の方向け!プログラミングのプの字を教えます」というサービスを出品してみました。
このサービスは プログラミングのプの字も知らずにエンジニアになった @chooyan がチャット形式でプログラミングの基礎を教えます!というものなのですが、同じ内容を読み物として体験できる版として、この「ノンエンジニアのためのプログラミング入門」シリーズを書き初めてみました。
プログラミングなんてしたことないけどちょっとやってみたい、あわよくば仕事にしたい、という思っている方は是非読んでみていただければと思います。
想定している読者
このシリーズは、プログラミングは初めてだけれどもここで得た知識を仕事でなんらかの形で活かしたい、という方を想定して書いています。
そのため、他の入門サイト等では説明を曖昧にしたり割愛しているような、少し難しめな内容も必要に応じて突っ込んで説明している部分があります。
最初は理解が止まってしまう部分もあるかもしれませんが、実際に仕事で使う場合(自分で開発する場合だけでなく、エンジニアと技術的な話をする場合など)には必要な知識ですので、少しの頑張りとご協力をいただければと思います。
プログラミングを始めてみよう
さて、記念すべき第1回は、「プログラミングとは何か」ということを少し考えつつ、自分で書いたプログラムを動かしてみるところまでをやってみます。
プログラムとは
プログラミングとは、プログラムを書いて動かすことです。 では、プログラムとは何でしょうか。
と自分で書いておいてなんですが、「プログラムとは何か」と言われてもちょっと質問が漠然としすぎていてうまく説明できません。
そこで、ここではエンジニアの思考回路を理解するための説明として、「インプット」と「アウトプット」という言葉の説明から始めてみたいと思います。少し遠回りになりますが、理解を深めるために少しおつきあいください。
一般的な「インプット」と「アウトプット」
「インプット」と「アウトプット」という言葉自体はプログラミングでなくてもビジネスではよく使われる言葉なのではないかと思います。
例えば仕事におけるスキルアップの会話では、「本を読む、ネットで調べる、講座を受けるなどの『インプット』だけでなく、人に話す、ブログに書く、資料にまとめる、などの『アウトプット』が大事だよね」といった話が出たりしますが、この場合の「インプット」と「アウトプット」とイメージは一緒です。
つまり、インプットは受動的に「受け取るもの」で、アウトプットは能動的に「生み出すもの」と言えるかと思います。
コンピューターの世界の「インプット」と「アウトプット」
では、コンピュータの世界でのインプットとアウトプットにはどのようなものがあるでしょうか。
たとえばインプットには、キーボードやマウスによる操作、温度センサーや照度センサ―などのセンサーから受け取るデータなど、様々なものがあります。一方でアウトプットは画面への表示やスピーカーからの音声、プリンタから印刷された紙などがあります。
我々ユーザーの操作によって発生する情報(キーが押された、画面が触られた、など)や、別の機械を通して受けとった情報がインプットで、その結果コンピューターによって作られたもの、表示されたもの、発生したものがアウトプット、というイメージです。
プログラムとは
さて、ここで「プログラムとは」に戻ります。
先ほどのインプットとアウトプットの話を踏まえると、「プログラム」とは「インプットを基に、ユーザーが必要としている情報を適切にアウトプットするための処理」であり、「プログラミング」とは、そのような処理を書くこと、と説明できるのではないかと思います。
「キーボードの"Aち"というキーがタイプされた」というインプットを検知して「PCの画面上に"a"、もしくは『あ』(もしくは『ち』)という文字を表示する」というアウトプットをしているのもプログラムですし、もう少し身近なところだと、スマートフォンの地図アプリで「住所を入力して検索ボタンを押した」というインプットに対して「その住所の地図が表示される」というのもそのように書かれたプログラムが中で動いているからです。
そしてこの記事を読んでいるみなさんは、そのようなプログラムを今まさに書こうとしている、ということになります。
始めてのプログラミング
さて、プログラムが何かについて考えてみたところで、カンタンなプログラムを書いてみましょう。
その「カンタンなプログラム」とは、「画面に"Hello World!"と表示する」というものです。
「"Hello World"ってなんだよ!」って思われた方、その通りです。僕もなんで"Hello World"なのかはよく分かりません。が、そういうものなのでそうなのです。
どの国でも、どのレベルのエンジニアでも新しい技術を学び始めるとき最初にやるのは"Hello World"です。ググってみると分かりますが、「PythonでHello Worldしてみる」みたいなタイトルのブログ記事は無数にあります。英語圏であれば "Hello World in Python" とかでしょうか。それくらい、「"Hello World"と表示する」プログラムは定番中の定番なのです。
というワケで、この記事でもその定番に倣います。
なお、このシリーズではプログラミング言語としてPythonを使います。
理由は「始めてでも書きやすいから」に尽きるのですが、あまりPython特有の話は出さないようにしますので、他の言語の勉強を検討中の方でも読んで時間の無駄にはならないかと思います。ひとまずこの記事ではPythonを使うということをご了承いただければと思います。
Hello Worldのイメージ
まずは今から作ろうとしているプログラムの実行イメージです。
いきなりスマートフォンのアプリ上に"Hello World!"と表示したりするのはちょっと難しいので、まずはコマンドプロンプト上に"Hello World!"を表示してみるところから始めます。
まずは下の図1を見てください。
図1:コマンドプロンプトでHello Worldが表示される
この黒い画面がコマンドプロンプトです。Windowsには必ず入っています。
このコマンドプロンプトを開き、python helloworld.py
とタイプしてEnterキーを押すと、次の行に"Hello World!"が表示される、これが今回のゴールです。
なお、この記事では基本的にWindowsを前提に書いていますが、基本的にはMacでも同様です。「コマンドプロンプト」ではなく「ターミナル」を、「エクスプローラー」ではなく「Finder」を使って読み替えてみてください。
それではやってみましょう。
プログラミングを始めるその前に
さっそくプログラムを書いて実行、といきたいところなのですが、新しくプログラミングを始める場合、多くの場合は「環境構築」が必要です。つまり、Pythonプログラムを動かすためのプログラムが必要になります。
ちょっとなにを言っているのか良くわからないと思われたかもしれませんが、とりあえず「最初にPython
をインストールしなければならない」ということだけ把握していただければ良いかと思います。詳しくは別の回で説明する予定です。
まず、Pythonがインストールされていない状態であることを確認しましょう。*1
コマンドプロンプトを開きます。
"Win"キーと"r"キーを同時押し > "cmd" と入力 > Enterキーをタイプ
これで開くはずです。Macの場合は"Command"キーとスペースキーを同時押し > 「ターミナル」と入力 > Enterキーを入力
でターミナルが開きます。
図2:コマンドプロンプトを開く
コマンドプロンプトが開けたら、python --version
と打ち込んでEnterキーをタイプします。
図3:Pythonがインストールされていないことを確認
'python' は、内部コマンドまたは外部コマンド、 操作可能なプログラムまたはバッチ ファイルとして認識されていません。
と表示されたかと思います。確かPythonはまだインストールされていませんので、このエラーは想定通りです。
逆に、エラーにならずに
Python 3.6.2
と表示された場合は、すでにお使いのパソコンにPythonがインストールされていることを表します。おそらくMacの方はこちらになるのではないかと思います。(MacやLinuxではPythonはプリインストールされているためです)
図4:すでにPythonがインストールされている場合はバージョンが表示される
もしインストール済みだけれども表示されたPythonのバージョン(3.6.2
の部分)が3.6.2より低い、という場合は、このあと説明するインストール手順と同じ手順でバージョンをアップデートしてみてください。*2
では、エラーになることが確認できたところでインストールを始めてみましょう。
Python のインストール
Pythonの公式サイトを開きます。
ここが、Pythonというプログラミング言語の公式サイトです。ここから、Pythonの文法やアップデート情報などの資料へのアクセスやダウンロードができるようになっています。
ここからダウンロードページを開きます。ページ上部のメニューバーの"Downloads"をクリックしてください。
ダウンロードページを開くと "Download Python 3.6.2" というボタンがあると思いますので、クリックしてください。python-3.6.2.exe
というファイルのダウンロードが開始されますので、ダウンロードが完了したらこのファイルを開きます。
表示される案内に従ってインストールを進めます。
図5:"Install Now"をクリック
図6:Pythonのインストール中
インストールが完了したら、ダイアログを閉じてインストール完了です。
図6:Pythonのインストールが完了
インストールの確認
では、インストールが無事完了していることを確かめるために、再度コマンドプロンプトを開き直します。
※ 先ほど使ったコマンドプロンプトのウィンドウはまだインストールが反映されていないため、閉じてしまってください。
新しく開いたコマンドプロンプトで、先ほどと同じようにpython --version
と打ち込んで、Enterキーをタイプします。
図7:再度コマンドを打ち込んでPythonがインストールされていることを確認
今度はエラーではなく、Python 3.6.2
が表示されました。Pythonが正常にインストールされていて、バージョンは"3.6.2"であることが確認できましたね。これでPythonのインストールは無事完了です。
いざ、プログラミング
これでようやくプログラムを書く環境が整いました。
それでは、先ほどの "Hello World!" のプログラムを書いてみましょう。
まず、「メモ帳」を開きます。
実際の開発現場ではここでメモ帳ではなくもっと高機能でオシャレなテキストエディタを開くのですが、そのエディタ自体の使い方を知る必要があるなど余計な手間が増えてしまうため、ここではなんの機能もないシンプルな「メモ帳」を使います。
メモ帳が開けたら、以下の一文をタイプします。コピペはダメです。勉強のためにも一文字ずつ書き取りましょう。エンジニアの世界ではこの作業を「写経」と呼んでいます。
print('Hello World!')
さあ、これだけです。
これだけ書けたらファイルを保存します。名前はわかりやすいよう、helloworold.py
としておきます。ファイルの末尾についている ".py" が、Pythonプログラムが書かれたファイルであることを示す拡張子になります。*3
保存場所はどこでも良いのですが、あとで整理しやすいよう、Cドライブの下(C直下と言ったりします)に programming
というフォルダを作り、その中に保存すると良いでしょう。
図8:helloworld.pyをprogrammingフォルダに保存
保存できましたでしょうか?
それではこのプログラムを実行します。
実行するのですが、ファイルをダブルクリックするわけではありません。プログラムの実行は、先ほど少しお見せしたようにコマンドプロンプトからするのが基本です。以下の手順でコマンドプロンプトを開きましょう。
まず、保存したフォルダをエクスプローラーで表示します。表示したら、エクスプローラー上部にあるアドレスバーに、"cmd" とだけ打ち込んでEnterを押してください。これでコマンドプロンプトが表示されるはずです。*4
図8:programmingフォルダからコマンドプロンプトを開く
最後に、表示されたコマンドプロンプトにpython helloworld.py
とタイプし、Enterキーを押してみてください。
先ほど示した実行イメージの通り、次の行に"Hello World!"が表示されたのではないでしょうか。
図9:Hello World!
まとめ
お疲れ様です!
初めてのプログラミングはいかがだったでしょうか?
もしかしたら「Hello Worldなんてできて何になるんだ」と思われたかもしれません。確かにこれだけではまだ何ができたわけでもありません。しかし、「プログラムを書く環境ができた」ことは、実はとても大きな一歩です。次回からは、一度動いたこのプログラムに処理をどんどん追加する形でプログラミングを学んでいきます。*5
この記事を読みながら"Hello World"をする中で、様々な疑問やうまくいかなかった点が出てきたかもしれません。その場合はどんどん調べたり、コメント欄へコメントしていただければと思います。プログラミングを学ぶ上で一番大事なのは疑問や不明点はどんどん自分で調べて試して体験してみることです。この記事に書いてあることが全てではありませんので、ぜひ色々なサイトや書籍をみてみてください。
次回は「第2回:引数を使ってインプットしてみる」です。
それでは、楽しいプログラミングライフを!
*1:この「作業前の(エラーになる)状態を確認しておく」というのはとても重要です。作業後にBeforeとAfterを比較することで、自分の成果を明確にすることができます。
*2:特に、Pythonはバージョン2.x.xと3.x.xでは入門の説明から変えなければならないほど違ったりするため、ここでPython "2.x.x"と表示された方は必ずアップデートしてください
*3:「拡張子って何?」という方はググってみてください。簡単にいうと、ファイルの種類をWindowsに教えてあげるためにファイル名の末尾につける文字のことです。
*4:ここでコマンドプロンプトを開く手順を先ほどと変えているのには理由があります。詳しくは別途説明しますが、コマンドプロンプトは「どのフォルダで開いたか」によってできることが変わるためです。
*5:もしプログラムを書く前の環境構築が難しい、面倒だと感じた方、それもとてもまっとうな感想です。環境構築は得てして面倒でつまづきやすく、現場のエンジニアでもこの作業に想定外の時間をとられてしまうことが珍しくありません。この問題を解決するため、環境構築を誰でも簡単に、ミスなくできるようにする工夫は様々なアプローチで今も行われています。
フリーランスエンジニアになってからの2か月を振り返る
会社を辞めてフリーランスになってから約2か月が経ちました。
キリの良いタイミングというわけではないのですが、なんとなく今の生活にも慣れてきたような気がしますので一度ここまでを振り返ってみたいと思います。
これからフリーランスをやってみたいけどなんとなくイメージがつかないなー、という方(つまり3か月前の僕)へ、何かのお役にたてれば。
フリーランスになるまで
はじめに、僕がフリーランスになろうと思ってから実際になるまでを振り返ってみようと思います。
がんばっていろいろアウトプットしてみた
僕がフリーランスになろうと考え始めたのは去年の夏くらいでした。言い方を変えると、フリーランスになると決めてから1年近くを準備期間として使っていた、ということになります。
その1年間は、とにかく外に向けて「これをやったよ!」が言えるようにアウトプットすることを意識していました。具体的には、Qiitaに記事を書いてみたり、Twitterしてみたり、自分で書いたちょっとしたソースコードをGithubに上げてみたり、といった具合です。
それをすればフリーランスでもやっていける、というよりは、それができてやっとフリーランスのスタート地点に立てる、という感覚でした。
フリーランスになると、多くの場合仕事を得るために自分のことを全く知らない人に対して自分に価値を見出してもらう必要が出てきます。 つまり、自分が前の会社でどれだけ頑張ったとか、どんな製品を作ったとか、どんな人脈があったとか、そんなことは全く関係のない人に対し、「自分のスキルにはこれだけの価値があります」と言えなければなりません。そんな時に最低限の説明材料として必要になるのが、所属する会社に関係なく価値のある情報を、インターネットを通して誰でも見ることができる場所に公開されていることだと考えました。
いろいろやってみた結果、たとえばQiitaでは37記事を投稿して1294コントリビューションを得ることができ、フォロワーも49人まで増やすことができました。(2017/7/25現在) 周りを見渡すと決して多い数字ではありませんが、1年前に全くのゼロからスタートしたことを振り返ると、自分としては珍しくコツコツと積み重ねられたものだなと思います。(もともと飽きっぽい性格です)
詳しくは後述しますが、結果としてこれをすることで得ることができた知識や実績、自信などが役に立ち(かどうかはわかりませんが)、フリーランスになった後もすんなりと当面の仕事を確保することができました。
フリーランスについて調べてみた
また同時に、この期間にフリーランスの情報をネットで調べてみたりしました。 が、こちらは今振り返ってみるとあまり役に立たなかった印象です。
そもそもフリーランスエンジニアといってもスキルの低い人から高い人、仲介サイト経由で仕事を請ける人から自分で仕事を探したり創ったりする人などとても多様なワケですし、それぞれにメリットデメリット、楽しいことやつらいことがあるワケで、「フリーランスはこうだ!」と言える人はどこにもいないのです。
結局、自分はどう働きたいのか、そのために何を準備して、どんなスキルを身に着けて、誰にどうアピールしていけばよいのか、といったことを自分で考えて実行するのが大切で、同時にその自由さがフリーランスの一番楽しいところの1つなのだと今は考えています。
フリーランスになってから
フリーランスになって最初の仕事は、とある研修ベンダーの外部講師として新人研修のサポートをする、というものでした。
これは完全に前職のツテで決まった仕事で、その研修ベンダーの方々も僕のことをそれなりに知ってくださっていたため、とてもすんなりと話が決まった印象です。コネって大事だなー、と思った瞬間でした。
あまり詳しくは書けないのですが、この研修では技術以外にも企画の立て方を同じくらい叩き込まれる内容で、後ろで聞いている僕の方が勉強になるくらいでした。新人たちもとても前のめりでいろんなことにチャレンジしていて、とても楽しい仕事だったことを覚えています。
これともう一か所の研修の講師補佐を合わせて1か月ほどしていました。これが6月です。
7月から、つまり現在はとあるメーカー会社でAndroidアプリの開発をしています。 この仕事はとある仲介会社を経由して見つけることができた仕事で、今までのWebサービス開発とはまた違った経験のできる仕事です。
海外にも支社があるおかげでそこから来ている外国人も多く、雑談などを通してWebサービスの多言語化のヒントが多く得られる職場です。
3か月ごとの自動更新で、週5で会社に常駐のためあまり生活スタイルとしては会社勤めと変わらない働き方ではあるのですが、とりあえず安定した収入源は確保できた形です。
今の仕事が決まった経緯
前提として、僕は自分で仕事を探したり創ったりしたい派です。ただ、フリーランスになっていきなりそれで生活に十分なお金を稼げるほど簡単なことだとも思っていません。僕は家のローンもあれば子供2人の育児中でもあるので、まずは「食いっぱぐれない」ことがフリーランスとしての最初の目標でした。
そのため、ひとまず食いっぱぐれないために、前職のツテで知ることができた仲介会社へ相談して仕事を探してもらうことにしました。
驚いたのは、「7月以降の仕事のご提案をお願いします」とメールしたその直後から次々と仕事の提案が来たことでした。合計10件くらい提案をいただき、概要から判断して面談の日程調整を5件くらいお願いし、結局最初に調整のついた2件の面談をする、という流れだったのを覚えています。
1件は前職と同じような環境のWebサービスの提供会社で、もう1件は今のメーカー企業でした。
面談の結果はどちらもその場で「7月から開発に参加してください」で、当然両方の現場に参加することはできないため、今後の多言語化の仕事のプラスになりそう(海外に支社があって、同じチームに外国人がいることは面談の際に伝えられていた)という理由と、なんとなく前職と違う環境で違う経験も積んでみたいという漠然とした理由で今のメーカーの方を請けることにしてみました。
面談ではやはり先述したQiitaなどのアウトプットの部分から話が広がったり興味関心を理解していただけた場面が多く、そのあたりもすんなりと話が決まった一因になったのかな、と思っています。
仕事が決まる過程を振り返ってみると、仲介会社にあれこれ相談すればフリーランスでも食いっぱぐれることはないのだな、という感想です。 また、案件の紹介される勢いから見ても、エンジニアという職業はどこも人が足りていない様子がうかがえ、そこに対して適切にアピールできれば「仕事がない期間」ができてしまうなんて想像できない、というのが正直なところです。(当然、「適切に」アピールするためには日ごろのスキルアップとアウトプットが必要ですが) 報酬も、経費分を差し引いても前職の稼ぎより少し余裕が出るかな、という額なのでこちらも問題ナシでした。
面談をしていて印象的だったのは、今の案件の面談の中で、部長の方に「開発スピードに自信はありますか?」と聞かれ、とっさに「あります!」と答えると、「自信があるのはとても大事」とおっしゃっていたことでした。 その理由については特に何も伝えられませんでしたが、結局スキルなんて実際に一緒に仕事してみないとわからないものだから、自信の有無が今までどれだけ頑張ってきて、どれだけ役に立ちそうかの良い判断材料になる、ということなのかなと勝手に想像しています。
結果的に、1年間アウトプットを続けて得られた自信はここでも役に立てることができました。
これから
とりあえずフリーランスとして仕事をスタートできた段階ではありますが、今後はもっと自由な働き方で、もっと高い報酬で働けるようになることが当面の目標です。
といのも、フリーランスになった目的のひとつは、家事、育児や自分の趣味などの時間をもっと柔軟にとれるようになりたい、というものでした。特に育児については、子供がいつ病気にかかって仕事している場合でなくなるかもしれませんし、世間一般と休みをずらすことでより外出を楽しむことができたりします。これが、今まで通りの平日週5で会社に通うスタイルでは状況は変わりません。
さらに、子育て&週5の通勤だとスキルアップの時間が圧倒的に不足します。平日の日中はオフィスで仕事をしなければならず、休日は1日子供の相手をしなければならず、結局集中できるのは通勤電車の中と夜子供を寝かしつけたあとの合計1日3時間程度だけだったりします。
そのあたりを改善するためにも、1か月あたりの稼ぎをもっと多くして、仕事をしない期間があっても大丈夫な状況を作り出し、自分の都合に合わせて仕事とそれ以外の時間を調節できるようになりたいところです。
そして何より、Webサービスの多言語化という内容で自分で仕事を見つけ、自分で稼げるようになることを引き続き目指したいと考えています。今はとにかく仕事の内容を選ばずに稼いでいますが、やはり名刺にも書いた通り「Webサービスの多言語化」を自分の一番の価値として売り出せる仕事が僕の実現したいところです。
というわけで、Webサービスの多言語化はぜひ chooyan.engineer@gmail.com までご連絡ください!
その他
各種事務手続きについて
フリーランスになるための開業手続等ですが、思ったより簡単でした。 だいたいの場合、ネット上で軽く前提知識を得た上で窓口へ相談すれば効率よく必要な手続きについて教えてくれますし、その場で実際の書類を一緒に書いて提出までしてしまえば手戻りもなく手続きを済ませることができます。ついでに必要な手続きが他にあればその場で教えてくれたりもします。
小難しい手続きはネットで済まそうとするのではなく、最後は専門家を直接頼るスタンスで進めれば特に苦労することはないのだと知りました。
金銭感覚について
金銭感覚もだいぶ変わりました。 フリーランスは、正社員以上に収入が増減しやすいです。つまり、投資した分のリターンも見込みやすい、と考えることができます。
最近は、たとえば通勤の際の30分間の電車移動に片道400円の特急を使うようになったり、空き時間の作業場所をカフェではなくコワーキングスペースにしてみたり、といったことを意識してやってみています。多少お金がかかっても集中して何かをできる環境を確保することで、そこでの成果によって今後もっと良い条件の仕事を見つけられたり、副収入を確保できるのではないかと思っています。
また、同じような理由で自分や家族の健康やストレス解消に必要だと思ったものは、値段は見て見ぬふりをして買ってみるようにしています。フリーランスにとって病気(家族も含め)で仕事する時間が減ることはそのまま収入減につながりますので、多少の節約よりも健康への配慮を優先するようになりました。
業務内容について
正社員でなくなったことで、自分の仕事は「開発」のみになり、上司との面談や研修などの「組織のためのタスク」がなくなったことも大きな変化でした。
オフィスの椅子に座っている間は打ち合わせもなく、横から入るタスクもなく、ひたすら今自分に求められているアプリの完成に集中できるため、1日に使える時間が前職の5倍くらいに増えた感覚です。それだけ、横槍が全く入らないという状態は開発がはかどるものだと知ることができました。
もともと僕は会社から面倒を見られることにそれほど必要性を感じないタイプで、さらにはちょっとしたことで集中力が切れやすい人間だったため、この変化はとてもプラスでした。
まとめ
総じて、フリーランスに転向したことはとても自分にとってプラスになったと感じています。毎月のように新しい人たちと新しい場所で新しい仕事をすることができ、とはいえ収入が不安定になることもなく、今のところ仕事を楽しむことができています。 よくネット上で「フリーランスはやめた方が良い」という内容を目にすることは多いのですが、今のところそんな実感はなく、むしろこの働き方をもっといろんな人に体験してほしいと思ったりしているくらいです。(あまり無責任に勧めたりはできませんが)
とは言え僕もフリーランスになってまだまだ2か月そこらの駆け出しですので、1年くらい経った時にどうなっているのかは全く予想できていません。そのあたりはまた来年このブログにかければと思います。
最後に、フリーランスをやっていると「10年後どうするの?」とよく聞かれたりしますが、最近そんな先のことはあまりこと細かに考えなくなってきています。
前職では同じ会社に7年間勤めていましたが、1年前に予想していたことが次の年にあっさり覆っている、という経験を何度も体験しました。同じ会社に所属していても数年先はわからないのだから、先が見えないという点では正社員もフリーランスも変わらないような気がしています。
それよりも1年先にどうなっていたいかを考え、それを実現するためにどう行動すればよいかを考え、ちょっとずつ目標に近づいていく、というのを毎年重ねていけば、そのうちなるようになるんじゃないかな、というのが最近よく考えることです。 10年後については、「最低限子供たちの学費は無理なく払えるくらい稼ぎたいなー」ぐらいなものです。
長々と書いてしまいましたが、とりあえず僕は今楽しくフリーランスの仕事をしています、ということが今回書きたかったことです。 世間では祝日がないと騒がれる6月も、僕は合計6日ほど平日にオフがありました。
またなにか変化があればこのブログに書きたいと思います。
新卒から7年間働いた会社を退職してフリーランスエンジニアになりました
先週、新卒で入社して7年間働いた会社を退職し、フリーランスエンジニアとしての生活をスタートしました。
大学の専攻ががっつり文系だった僕でもエンジニアとして採用してくれ、3ヶ月の研修とさらに3ヶ月ものOJT期間を提供してくれて、徐々にエンジニアとしてのスキルを伸ばしながらWebサービスの開発の仕事をさせてくれる、とても良い環境の会社だったと思います。
この記事では、そんな会社を辞めてフリーランスに転向した経緯を振り返りつつ、今後フリーランスとしてどう仕事していこうとしているのかをまとめてみます。
どんなことをやっていたのか
前職では、主に自社開発のWebサービスをB to Cで提供する会社で、AndroidアプリやServletによるWebアプリケーションの開発をしていました。 言語はJavaが一番多く、次いでJavaScript、Python、という感じでした。
僕は落ち着かない性格で、1年前後のスパンでプロジェクトを転々とし、時には人事としても働いてみたりしながら、データのクローリングや整形、ServletやJSP, JavaScriptによるWebアプリケーション開発、Androidアプリ開発、さらには新卒採用や教育研修まで幅広く経験しました。
そんな7年を経て、現在ではLinuxの文字だけの世界がとても居心地よく思えるようになったり、Qiitaに記事を投稿するようになったり、といったことは当時からすると考えられない変化ではないかと思います。
プライベートでもNode.jsやRailsを書いてみたり、EC2でマインクラフトサーバー立ててみたり、Raspberry Piで電子工作してみたり、だいぶエンジニアを満喫している現在です。
フリーランスへの転向の理由
そんな至れり尽せりの環境ではあったのですが、いつからだったか、「自分の技術に世間一般ではいくらの値段がつくのか」というのに興味が出てきました。 また、入社以来社内のエンジニアとばかり仕事をしていたので、勉強会やWeb上で見かけるような、外のエンジニアと仕事をしてみたいと思うようにもなりました。
自分の意思決定で、自分の責任において自分の好きな環境・条件で好きな開発ができ、好きにお金を稼げる、という状況にとても憧れがあり、最終的にフリーランスでやっていこうと決断して今に至っています。
今後
今後は「多言語対応フリーランスエンジニア」という肩書きで、Webサービスの多言語化を専門とするエンジニアとして仕事しようと思っています。 多言語対応はシステムの根本的な設計に関わるために一度進めてしまうと後戻りしづらく、とはいえ自社にノウハウを持っている会社もそれほど多くないと踏んで、この分野のプロフェッショナルになれば一定の需要があるのではないか、と予測しています。
多言語対応のライブラリは “i18n” とつくライブラリがどの言語にもありますが、それらのライブラリの使い方だけでなく、技術以前の言語や文化、宗教、政治などの文系的な知識も提供できるエンジニアとして、文系のメリットを最大限に活かしながら仕事ができればと考えています。実際調べていると多言語対応はシステム的にもテキストを翻訳すれば良いだけではないことがわかるのですが、そのあたりはこのブログに一つずつまとめられればと思っています。
多言語対応と言ったら @chooyan_i18n!と言われるよう、セルフブランディンク的なことをしていく所存です。(このあたりも文系的な知識が役に立つ、はず、、、!)
というわけで、多言語対応は @chooyan_i18n へ!