エンジニア経験無い人を教える＆働き先を紹介するまでの話
タイトルで全て言い尽くしましたが、自分がやりたかった
教える（正確にはコーチング）⇔開発する
の両方が相互に作用するような自分がイメージしてたことがようやく実を結びました！
Connecting the dots
@ukedchat @gapingvoid There's one more image to this that you're missing... creativity. :-) @ElsiumEd pic.twitter.com/T283tvkX30
— Elsium (@DavidKirtlan) February 8, 2014これ知ったのは増井さんの講演を紹介されてる記事なのですがそこで
そして大事なのが、点と点を最短距離でつなげるだけでなく、異なる組み合わせをすることで、新しい全く考えもしなかった物が作れる。それがクリエイティビィティなんです
と書かれました。
当初は、人に教えるという2者間の関係だけだったのですが、そこから、色々な組み合わせができないか模索したことで、今後の予定も含めてちょっと絵↓を描いてみたのですが、ここからさらに世界が広がりそうな気がしてきました
以下、エンジニア経験無い人を教える＆働き先を紹介するまでの少し長い話です
エンジニア志望の人との出会い
昨年11月頃にお手伝いしていたスタートアップの会社で私はエンジニアとしてRailsの開発をごくわずかですがやってました。私含めリモートで働いてる方が結構いたので、顔合わせ的な感じで飲み会があったのですが、そのスタートアップの事務方の仕事をしてるエンジニア志望の人と会いました。
その人、当時は日中は日雇いの土方（IT土方ではなく、ガチの土方）の仕事をしつつ、夜はそっちのスタートアップの仕事の事務方の仕事をして空き時間にプログラミングの勉強をしてるというかなりハードな生活をしており、見た感じは温厚そうなどちらかというと草食系な感じなのに、やってることはスゴイなぁと思って、何か役に立てることがあればと思ってひとまずボランティア的に、プログラミングを教えてました。
しばらくはRailsではなくRuby自体について教えていた
本人はRailsチュートリアルを勉強し終えたという段階だったので、本人的にはそのままRailsをもっと学びたいという感じだったのですがプログラミング自体の経験がそれほどない状況の中で、そのまま突き進んでいったとしても少し表面的な理解になりそうな気もしたので、一旦Railsからは外れることにしました
とはいえ、Railsから全然関連性がないものとなると、本人のモチベーションも落ちそう＋たまたまその時に自分が関わっていた仕事のからみもあって、ActiveRecordの機能を活用しつつ、クローラー開発について学んでもらうことにしました。
ちょうどその時にRubyによるクローラー開発技法 巡回・解析機能の実装と21の運用例が出て間もなかったことも有り、少し読んだ感じでは参考書籍になりそうな気がしたので、購入して貸し与えてこれを見ながら、クローラー自体について理解してもらいながら、ちょっとづつActiveRecordの機能を取り入れてカスタマイズしてもらうような感じで教えていきました。
クローラー開発でデータ処理というか配列やハッシュ操作についてそれなりに勉強してもらえたのかなと思いつつも、Ruby自体の理解がどこまで深まったのかはちょっと謎ですが(^_^;)まぁそれなりに成果はあったのかなと。
より実践的な学びを得てもらいたいと思い色々画策した時期
そんなことをしばらくやっていて、より実践的な学びを得てもらいたくって、仕事に近い課題をどうにかして与えたいと思いました。
クラウドソーシングを使ったやり方をまずは画策
自分の仕事がちょっと切れていたこともあって、クラウドソーシングの情報をチェックしてたら、クローラー開発の仕事が、数は少ないながらも意外とあって、しかもエントリーしてる側のエンジニアの数も、別のカテゴリ（一般的なWebアプリとかのやつ）に比較するとそこまで多く無さそうで需給バランス良い印象を受けました。
そっちの案件を受注して、自分がメインで作りつつ、その人にサブ的に開発してももらってその分の謝礼を支払うみたいなことを考えていくつかエントリーしたのですが、自分の実績のなさもあって、受注に至らなかったのと、自分が別の案件関わりだしたこともあってクラウドソーシング使って実践的な開発を経験してもらうのは一旦断念
自分の人脈を通じたやり方にシフト
年末に、自分の案件獲得のために割りと色々な人に会っていたのですが、そのうちの1人の人手、Facebook上では互いに面識あるけど、そんなにじっくりと喋ったことがないっていう人と一度お会いすることになりました。
その人は、開発もしてるけど、プログラミングをマンツーマンで割りと濃く教えてる商売もされていたので、何となくですが、自分が教えてる人も引きあわせてもいいかなとおもって3人で飲む機会を作り、話の流れで、その人からスポット的にRailsでの開発の仕事を紹介してもらえることになりました。※ついでに自分もその人の仕事を違う形でお手伝いすることになるんですけどね(^^)v
ただ上記はスポット的な仕事でフルタイムではないので、折角なので、フルタイムで開発の仕事、出来ればRailsの開発の仕事の可能性がないかなぁ〜と思って自分の人脈通じて可能性を探ろう・・とずっと考えていたのですが、自分が常駐してる先で人手が足りないのでみたいな話をされていたのでエンジニアとしての経験はまだないけど自分がずっと教えてる人がいて、しばらくは自分も出来る範囲でフォローするのでアルバイトで採用とかどうでしょうと打診し、双方OKということで、明日から、アルバイトだけど、Railsでの開発についてもらえるようになりました！
※ツッコミはいりそうな気もするので一応書いておくと、有料職業紹介事業の免許持ってないしそっちの方で稼ぐという意識が無いので、今回、人を紹介しても紹介料は一切もらってない
最後にもう一回最初に出した絵の解説
当初は自分と、教える相手の2者間の関係でした。それが、年末に飲み会セッティングしたことで右隣の水色の人との3者の世界が出来上がりました
一方で、自分が常駐してる所で自分はそこで開発の仕事をしてるのですが、一方で人手が足りないということで今回アルバイトとして人を紹介したことで、そこでまた関係が作れました
さらに、そこの常駐してる所の人はどういう風に採用活動をしていいのかという現場視点での苦労だったり、本人は口にしてないけど、チームビルディングとかでも今後苦労するのかなと思っており、その辺りの経験をここ最近ずっとされていて、少し前にこんなことを喋っていた人との場をセッティングしてあげる（ちなみに今日の夜）ことでまた違う世界が描けるのかなーと思ってます。
1人でやれる仕事に限界があるので今後どうするか考えてみた
30歳からのスタートアップを書いてるハッシーこと橋田さんに声をかけられて、先日の水曜日に、エンジニア必見！『エンジニアのキャリアを考える』勉強会 第六弾というトークイベントで、登壇してきました。
こういうのは、自分は運営とか進行で関わることは多々あったのですが登壇するとなるとずいぶん久しぶりな感じでとても新鮮でした。
登壇後に
「ちょっといいですか？」
といって参加された方から多数声をかけてもらって、ちょっとした有名人のような気分が味わえ、普段は運営者側でこういう光景を見ることがよくあったのですが、自分がそういう立場になるとは全く想像してなかったので何か不思議なものですね(^_^;)
内容の方は？
内容的にその場の会場にいた方限定の話題とかがあったので、橋田さんと後日会った時に、記事を書き起こしてるということも聞いたので細かいことは控えますが、現在の自分の心境というか状況で印象に残る話題があったのでそのあたりをちょっと書いておこうと思います
1人でやれる仕事には限界がある
本編の中でも話題にでたのですが、懇親会でお話しされた方とでもこの話題になりフリーランス等で1人で仕事をしていて、1人でやれることに限界があるっていうのは、話には聞いていたのですが実際に自分が今そういう立場になってつくづく実感してるので今回改めてブログに書いておこうと思ってます。
参考までに自分の現在の状況
仕事を入れ過ぎてしまって期待された成果が出せるかわからないし、かといってあまり入れ過ぎないようにしてしまうと今度は予想する売り上げが立たずに・・ということで中々この辺りのコントロールが難しいなぁとこれはずいぶん前から考えてました。
現在はどうかというとこんな感じ
2つ仕事をしてる
- 1つは週3日（うち2日常駐）でもう１つは週2日（こっちは2日とも常駐）
- 幸いに両方共、Rails4＋AngularJSという構成
- 2社とも出来れば稼働時間を増やしてほしいと頼まれてる
- 両方共、業務内容、支払い条件、職場環境は申し分ないのでそれぞれの要望に応えたい
上記と並行して空き時間にプログラミングを教えてる
- 今後も教える予定の候補者がいたりする
上記に加えて、自分でやりたい商売があってそのためのプロトタイプを作りたい
- OpenCV、機械学習、平滑度みたいな所がキーワードに含まれそう
- 機械学習の概念は以前ちょっと勉強してとってもショボイけど実際に手を動かして作ったことがあるけどそれ以外は概念知ってるけど手を動かしてないから色々やりながらという感じ
- WebアプリケーションエンジニアのためのJavaScript中級者講座
- 非同期処理とかJavaScript固有の変数スコープの概念をしっかり抑える内容
- Qiitaにちょっと前にポストした手続き的に書いたjQueryのコードをどのようにリファクタリングするか考えてみましたのストック状況とか、自分の周囲の人でJavaScriptに苦手意識あるWebエンジニアな人が一定数いるのでそこの課題解決をしたい
- GemJamの定期開催
どう考えても1人でやるには限界ありますね(^_^;)
1人でやれる限界を超えるためにどうやって解決するか
自分の中では家族との時間を確保したいというのがあるので1週間に7日働いて・・・とかは全く考えてないです。
でどうやって解決するかというと1人プログラミングを教えてる人でその人にアルバイト的に仕事をお願いしようと思ってます。
守秘義務の問題あるので、2つ行ってる実案件のコードは見せることは出来ないから、その開発の仕事を直接依頼するのは無理。
でも今後仕事で必要になりそうな機能についてのサンプルアプリ作ってみるとか、自分がちょっと苦手としてる領域（例えばRailsアプリの設計をMVCごとに見直しリファクタリングして連載総まとめ (1/2)の外部構造の見直しのconfig/routes.rbをどう書き換えるかというような話）について、事前に下調べしておくとかは、こちらの依頼内容がしっかりしていれば、仕事として依頼しやすいかと思ってます。
冷静に考えると、これって自分が昔やりたかった新規事業のアイデアに限りなく近いなぁと思ってます
このスライド作ったのがちょうど2年前なのですが、この絵でいうと、自分が教える役とコードレビュー＆アドバイザー役としてやるということは当時は全く想像してなかっただけにちょっとビックリもしてますが、割りとこういうのをやりたいとずっと思っていたし、テーマ的に響きそうな人に出会ったら、そういう人には自分の考えを伝えてきてるので、そういう地味な活動が今に繋がってきてるのかなと思ってます
今後に向けて
教えるだけとか、開発するだけっていうのでは、それぞれ専門的な人とか会社がたくさんあるし、そこで勝負するつもりは元々無かったのですが、どうやってやるのかという所でイマイチしっくり来てませんでした
教える（正確にはコーチング）⇔開発する
の両方が相互に作用するような自分がイメージしてたようなビジネスがようやく出来てきそうな気がしてきました！
今更ですが2014年を振り返る＆今年の目標
昨年も年が明けてから振り返りをしてましたが、今年も、大分遅れての2014年の振り返りをしつつ、今年の目標に向けて書いておきます
簡単な振り返り
まだ会社員だった頃にこれまでの１万円のビジネスから脱却して10万円のビジネスを目指すために出来そうなことを考えていたし、本厄の今年の目標は「稼ぐチカラ」と「生きるチカラ」を意識すると書いていたりと、振り返ると、フリーランスになる前からこういう意識を持っていたっていうことに改めて気づきました。
- 本業に関連すること
- キャリアトークイベント
- 気づいたら9本やってた
- このイベント経由で知り合いになった方がわずかですが数名いた
- 普通に転職媒体とかではきっと出会えなかったと思うのでイベントやっていた効果を感じた
- キャリアトークイベント
- 趣味と実益兼ねての技術的な勉強
- Titaniumの開発はAlloyを取り入れはじめた
- CraftBeerFanも当初はClassic環境だったけどAlloy使って全面的に書き換えたりしました。
- ただBackbone.js由来の機能をほとんど使いこなしてないのが大きな反省
- 技術系のネタは最近Qiitaへの投稿をメインにしつつある
- 技術面の自分のアピールとしてはQiitaの方がわかりやすい
- Titaniumの情報もQiitaに集約するトレンドが生まれつつあったのでそれに乗った
フリーランスになってからは定期的に振り返りしていたので割愛
今年の目標
フリーランスになって当初から比べると、状況が大分変わったり、考え方も少し変わったので、今年の目標についてまとめておこうと思います。
エンジニア的な開発に関連する仕事
ベースとなる生活費を稼ぐという意味では、エンジニア的な開発に関連する仕事は当面必要なのでこれは今季も継続してやってきます。
フリーランスを始めた時は、知ってる人の所の仕事が大半だったので、リモートワークを割と必須にしてたのですが、それだとかなり可能性を狭めてしまうので、週2,3日の常駐ならOKというスタンスに変えました。
おかげさまで、フリーランスになる前から面識はあったシェアゼロの中川さんの所で自分の条件にマッチする所をご紹介いただけて、それ以外に、こちらも以前からトークイベントで利用させてもらっていたコワーキングスペースCo-Edoの所で、案件ご紹介いただきました。
※稼働時間がちょっと大変なことになりそうですけどね(^_^;)
上記以外にも登録だけしておいた所もあって、週2,3日程度の常駐OKというスタンスでなら、割と案件獲得をしやすい市況なのかなと思ってます。
譲らない条件面
自分の場合には時間の自由度が高い条件を極力再優先に考えていて、金銭的な部分はその次っていうスタンスで考えてるので、週5日常駐というのはやっぱり抵抗を感じてしまいます。
なぜならば、今すぐではないにしても、将来的に介護の問題が出てくるので、そうなった時に、週5日常駐の仕事しか経験が無かったりすると、どこかの場所に物理的に週5日通うというのがキツい状況になってしまうと思ってるからです。
ひとまず仕事をある程度選べる状況ならば
- 全日常駐とかは出来れば避けたい。
- AM6:00頃から仕事をしてる自分のライフスタイルに合わないので出来ればそれを今後も維持したい
- 週2日＋残りはリモートとか、週3日常駐するとしても、午後3時ごろまでとかだとすごく理想だけどこの辺りは互いの話し合いで決められるならそうさせてもらえると良い
みたいなスタンスでいこうと思ってます。
リモートワークについて研究する
前述した通り、将来的に介護の問題っていうのは、色々な人に降り掛かってくると思ってます。そういう状況になった時でも、いつでもどこでも働けるという状況を今のうちから作っておく必要があるかと思ってるので、リモートでのワークスタイルについては自分なりに意識を持って取り組んでみようと思ってます。
私がイメージするリモートでのワークスタイルというのは全部在宅っていう意味合いでは考えていません。その時々の状況に応じて、会社以外の場所でも働ける体制だったり、そういうのを実践するのに必要な考え方というのを言葉の定義としています。
ちなみに、年初からの仕事は両方共リモートワークについての理解がある所なので、働く中でまた違った発見を得られそうな気がしてます。
本業の一環として取り組むこと
すでに実践してることもあるのですが、年末年始に色々活動して種を巻いておいたことが、ここにきてちょっとづつ芽を出しつつある感じです。
非エンジニアな人にプログラミングを教える
これは昨年後半くらいからshiro615さんを教えてるのですが、それとは別件でもう１名教えてます。
shiro615さんは割りと近所なので、互いの予定をふまえて気軽に会いやすいのですが、別件の方はどう考えても物理的に遠すぎるので、リモートで教えてます。
その方はスマフォアプリをベースに自分でサービスを作りたいという方で、今後エンジニアの方を採用するにあたって、技術的なベースをしっかり作っておきたいというのが目標にあったので内容とか進め方は以下のようにやってます
- 自分が使い慣れててる＆オンラインの教材として自分が作ってるものがあったのでTitanium＋ACS＋Alloyでの開発がメイン講座
- 作りたいイメージが明確だったので、それを作る過程を全てコード書いてもらうことで、理解を深めてもらう
- GitHubのIssuesにその週の課題を提示。
- 最初のうちは写経中心だったけど、途中から応用編的なものを考えてもらう感じにしてあまり簡単すぎず適度なカベを設けて学習に取り組んでもらうことでモチベーションを低下させないようにしてる
- Issuesは１つ１つの課題別に登録をして、その週に取り組むべき課題一覧専用のIssueを登録して・・・という感じでこっちの作業コストはかなりかかるけど、このやり方自体は結構使い回しが効きそうなので、その辺りの検証も兼ねてやっています
- Skyepで週１日程度のミーティングを行い、振り返りをしてもらって理解度とか、意識の変化とかを出来る範囲でこっちが掴むように心がける
フリーのカメラマンさんの日頃の課題を解決するサービスを作る
七五三などの行事の時などに、家族写真を撮影してもらうために、出張撮影をお願いしたことがあるフリーのカメラマンさんの知り合いがいます。
ふとしたことがきっかけで、そういう人たちの仕事上の共通の課題というか大きな悩み事があるかなと思ってメールで質問したら、自分の予想通りの課題でした！
しかも1人の方と直接お会いして実際にお話を聞いていたら、もっと大きな課題が見つかり、そっちの課題解決のためには、技術的にちょっとチャレンジする要素があるのですが、しっかりと収益の見込みが立てられそうな気がしてるので、フリーのカメラマンさんの日頃の課題を解決するサービスを作ります。
最初は日頃の課題を解決するサービスを作りたいって書いていたけど、ここは言い切ることで自分に言い聞かせることにします(^_^)
大分長くなったけどこんな感じで今季というか今年取り組んでいきます
フリーになって半年経過したのでふりかえり
半年フリーランスをやってみて、ある程度自分の予想通りにコトが運んだなぁと思ってます。
目先の金額を取らずに実績作りだったり面白そうな仕事を選んでやってみたのですが、それはそれでいいのですが、理想だけを追い求めても、日々生きていく上での生活費もしっかり稼がないとダメだしそのあたりのバランスをうまく取らないといけないっていうのを実感した半年ですね。
実はこのエントリを今月前半に半分ほど書いていて寝かせていて結果として長文になったのでざっくりまとめるとこんな感じ
- これまで手伝っていた所が予算的な都合で終了。
- 自分のミスで他の仕事を入れてなかったので割りと焦った
- 消費を減らすのはダメだけど、人に合うような次の仕事に繋がる投資を減らすところまでやっちゃダメっていう大きな反省＆教訓を得た
- （契約取り交わしてないのでまだ安心してないけど）年明けから2つ仕事が決まる
- 開発っぽいのとは別に本来やりたかった人材育成っぽい所でビジネスの下地ができそう
- 未経験でWebエンジニアになりたい人にずっと教えてたけど、自分のツテを通じてアルバイト的にエンジニアとしての仕事が出来そう。
- Webデザイナー・エンジニアな人向けのパーソナルコーチっぽいことが出来そう
- 自分で稼ぐ仕組みがやっぱり1つは欲しい
これまで手伝っていた所が予算的な都合で終了。
その仕事がエンジニア的な仕事以外の要素も増えつつあって、それはそれで勉強になる部分があったので、ひとまずそちらに専念できるように、他のお仕事を基本的には一旦全てストップさせました。
しばらくそちらに専念していたのですが、予算的な都合で終了してしまいました。
自分のミスで他の仕事を入れてなかったので割りと焦った
自分が会社をやめた時に、1つの所に収入を頼るのが不安って書いていたのに、その状況に自ら追い込んでしまったというなんとも情けないことに・・(T_T)
今月上旬位にそんな状況になって、まぁ次の仕事もある程度可能性あるかなと思ったのですが、思っていたほどなくって凄く焦りました。
ただ、前職の経験上、一年の中で11月後半から12月の中旬位までの時期って一番人も求人も動かない時期なので、その時期に仕事がないのはある意味当然なんですけど、その時はちょっと冷静な判断ができなかったこともあり焦りました。
消費は減らすけど投資まで削ってはダメ
次の案件が見つかるかどうかちょっと目処が立たないのかなぁという気持ちになったので、ひとまず余計な消費はしないようにと心に誓い無駄な外出とかもしないように決めました。
ただ、外出控えるというのは、人と会うことも控えがちになってしまい、結果として、自分の世界が広がりづらい状況になってるなあというのをどこかで気づきました。
会社を辞めた時にかいたエントリで、個人的には金銭的なことよりも、社会的に孤立するということのほうが怖いって書いたけど、あの状態に陥ってしまいそうで、これじゃイカンなぁと思ったので、まずは
- エージェント的なことをやってる人とか会社の人と会う
- ずっと家にいても午後には子供が戻ってきて落ち着いて仕事ができないこともあり不定期だけどコワーキングスペースに行く
- しばらく手が空いてしまうので、金銭的なことは一旦脇において、知り合いの所の開発をお手伝いするというのを２つほど投げかける
- なんとなく自分でやってみたいサービスがあったのでそのヒアリング兼ねて人と会うアポを入れる
ということをやりました。
金額的には微々たるものかもしれないけど、当初こういう活動にかかるお金も節約しようという気持ちになったのですが、今考えると、それはまぁ正しい判断じゃなかったですね
とりあえず次の案件は決まる
半年ほどお手伝いしてた所は、単純に開発するだけではなく、運用体制整備したり、仕事で利用していたツールがイマイチ連携とれてない状況だったので、色々な事例を参考にしつつ、GitHubを中心としたワークフローをどうにか整備したり・・・と色々提案しながら仕事を進めていたので、そういうのはは実績として記載しやすかったかなぁと
単純なエンジニアとしてのスキルだと世の中すごい人がいるのは知ってるので、自分にはそういう部分でかなわないと思ってるので、そうじゃない所（現状の課題とか問題を見つけ出して、そこについて、現実的にどういうアプローチならみんなが納得しそうかというのを考えたり行動する）の部分をうまくアピールしながら、ここ半年ほど経験した色々なことをスキルシートに記載していくつか巡ったら、次の案件が決まった感じです
やっぱり実績は大事ですね(^_^;)
開発っぽいのとは別に本来やりたかった人材育成っぽい所でビジネスの下地ができそう
これがここ1,2週間くらいの動きで急に動いた感じなのですが、このエントリでも触れていて、以前からやりたかった何か作る（開発する） ⇔ 教える や、何か作る（開発する） ⇔ 場作り みたいな所に繋がる下地ができそうな気がしてきました。
未経験でWebエンジニアになりたい人にずっと教えてたけど、自分のツテを通じてアルバイト的にエンジニアとしての仕事が出来そう。
少し前に開発の仕事を手伝っていた所で、エンジニア経験はないが、今後Webエンジニアとしてやっていきたいという20代半ばの人と知り合いました。
その後、不定期に彼に自分がもってる知識で色々教えてるのですが、基礎的なことはある程度は教えられても、期待される成果物があって、それに対応するアウトプットが出せるようなスキルをどこかのタイミングで得ておかないと今後エンジニアとしてやっていくには厳しいのかなと思ってます。
前職で、こういうエンジニアの育成的なことは事業としてやっていたし、競合他社含めて、何らかそういうことは行ってると思うのですが、中々そういう事業が定着しない理由の1つに、相手が期待する成果物をしっかりと提供できるという経験を得ることが出来ないからかなと思ってます。
「そういうスキルを仕事に就く前に期待するのは、そもそも間違ってるんじゃないの？」
という意見もありそうですが、自分の考えとしてはまぁそうではないと思っていて、そのために最大限のフォローをしようと思ってて、教えるというスタンスよりも、まく導くという感じですね。
アウトプットの重要性についてようやくその人なりの気づきがあったようで、少しづついろいろな形で出てきたので、これをちょっとづつ積み重ねていき、その人が興味ある分野の内容を扱うRailsアプリをGitHub通じてコミュニケーションとりながら一緒に開発を進めていく予定です。
それが出来上がったタイミングの前後くらいで、自分のツテ通じてアルバイト先が紹介できそうな目処もたったので、
場作り ⇔ 何か作る（開発する） ⇔ 教えるみたいな関係性の中でビジネスとして行う最初の事例になりそうです。
Webデザイナー・エンジニアな人向けのパーソナルコーチっぽいことが出来そう
前に書いたこれが出来そうな目処がたちました。
実際やるとすると
- その人がなんとなく考えてる方向性についてキャリアカウンセリングする（これは前職でずっとやっていたこと）
- 話を踏まえて当面の課題を設定する
- 課題をオンライン中心で教える（SkypeかGoogleHangoutとか）
- 現状躓いてるポイントをヒアリングするために物理的に可能なら可能なら直接会う（無理ならSkypeミーティング）
- 以下繰り返す
という流れかなと。
自分で稼ぐ仕組みがやっぱり1つは欲しい
来月からの仕事が決まったし、上記のパーソナルコーチっぽいこともあるとはいえ、これとは別に自分自身で、自分の分身的に稼いでくれるWebサービスがやっぱり１つ欲しいなぁと実感してます。
具体的には、小さい会社とか個人で活躍してる人が仕事をする上で困ってることを解消するサービスで具体的にはフリーのカメラマンさん。
撮影前後の事務作業が結構煩雑な所があるんじゃないかと思って、家族写真の撮影をお願いしたことがあるフリーのカメラマンさんにメールをしてみた所、そこから得られたフィードバックを見る限り、すっごい大変なことをされていました。
そこの手間を少しでも解消できるようにその人が普段使ってるツールをうまく連携させられるものを作りそのフィードバックを元にして、別の似た人を見つけて、まずは使ってもらえる人とか会社を一定数見つける。基本無料だけどプラスαのサービスで料金をいただくようなことが出来ればと思ってますが、自分の理想としては倉貫さんがブログに書かれてる顧問プログラマーで触れられてるようなプロフェッショナルサービスのようなスタンスで関われる所をどうにかして見つけていきたいなぁと思ってます。
あとは地域の課題を解決するような何か
「こんなことをやりたく、自分は開発側ができるから、パートナーになりそうな人がいたら」と思って以下のようなプランをとある会社に打診したのですが特に返事がないんだけど、折角まとめたアイデアなんでブログに書いておきます
仮）まちの学食
概要
- 飲食店さんが抱えてるであろう課題：
- 予約されていたお客様の急なキャンセルで確保していた食材をさばききれず、まかないとして調理しても結局は消費しきれずに、食材ロスにつながってしまう。
- 塾に子供を通わせてる親御さんが抱えてるであろう課題：
- 夕食のお弁当まで作るほど時間的・体力的余裕がなく、結果として塾周辺でコンビニやファーストフードで済ませてる。ただ育ち盛りの子供に出来ればしっかりとした食事を提供したい
上記２つの課題に対して、以下のようなサービスを提供
- 飲食店の店員さん向けに、リアルタイムクーポンのような仕組みを備えたアプリを提供する。
- そのアプリを通じて、「その日限定」ｘ「まかない」として作った分の料理を格安で食べられる（あるいは持ち帰ることが出来る）クーポンを配信
- クーポンを受け取る塾に通わせてる親御さんは、飲食店さんが作ったまかないの食事を格安で子供に食べさせることが出来る
PoC実施時の最初のエリア
以下理由で、練馬駅を最初のエリアとして想定してます。
- 駅前に日能研練馬校、SAPIX小学部・・と子供向けの塾が一定数ある
- 飲食店さん（含むバー・スナック）も練馬駅に一定数ある
- 練馬駅から3駅の光が丘の駅前のマンション＋その周辺のファミリー向け物件は意外と家賃高く、実際、田柄という地域の地価は杉並区の上高井戸（八幡山駅周辺の住所）や千川町（仙川駅周辺住所）と較べても遜色なく世帯所得がそれなりにある家族が一定数あるので、サービス自体が受け入れてもらえた場合にしっかりとお金を払ってくれる可能性がある
実施におけるリスク要因
- 「まかない料理を提供する」という作業自体は、飲食店さんからすると通常の業務の延長線上なので業務負荷はあがらないと思うが、一般的に飲食店さんは新しいことをやりたがらないというのは、事前のヒアリング内容からおおまかに把握しており、こういうコンセプトを受け入れてもらえない可能性が高い
- 実際に店舗に子供を向かわせることに対することが、親としてすごく抵抗がありそう。
GemJamという勉強会を行いました
昨日ですが、日頃お世話になってるコワーキングスペースCo-Edoにて、GemJamという勉強会を行いました。
この勉強会を企画した背景
2つほど理由があって
- 何気なく使ってるgemについて定期的に勉強してみたくなった
- アウトプットの習慣を得るきっかけ作り
という所から企画＆実施しました。
何気なく使ってるgemについて定期的に勉強してみたくなった
だいぶ前ですが、WEB＋DB PRESS Vol.70で あなたの知らないActiveSupport事例で深くわかる使い方という特集記事があり、本文中で
Ruby on Rails（以下Rails）の縁の下の力持ち」とも言えるActiveSupport gemについて取り上げます
という出だしの文章がありました。
こういう感じでRailsのコアモジュールですごく恩恵をこうむってるけど実は内部のことをよくわからずに使ってるようなgemって結構あるのかなと思ってます。
そういう恩恵をこうむってるものを深く掘り下げて1人で勉強するのは特に経験がまだそれほどない段階では、モチベーションをあげづらいかなと思い、同じような気持ちを持った人同士集まって、各自のスキルに応じた勉強をしてもらいつつ最後にアウトプットをしてもらうことで勉強した成果を確認しやすいかなとふと思ったので企画してみました。
アウトプットの習慣を得るきっかけ作り
ちょっとした縁で酒と泪とRubyとRailsとのモリジュンさんと知り合いになったのですが、少し前に「3分 Gem クッキング」というタイトルでLT発表しました！ということを書かれてました。
最後の方の反省点の所を読んでて、LTみたいなものって、ちょっとづつ経験を積んでいくことで、だんだんと話しやすくなっていくのかと以前から思っているけど、なかなかそういう練習を気軽に詰める場って無いなぁと思ったので、モリジュンさんみたいな経験がある人が、学んだこととかを気軽に発表できる場づくりという意味でもこういう勉強会があってもいいのかなと思いました
ネーミングの由来
音楽のジャムセッションっぽく、あまり事前にこまかい打ち合わせとか約束事を決めず、その時の参加者の属性とか雰囲気に合わせたスタイルにしたいと思って、Gemのジャムセッションっぽいものということで、GemJamにしました。
さっきDoorkeeperにコミュニティページを作ったので興味有る方は登録だけでもいただければと思ってます。（次回開催日はまだ決めてないですが来月にPryをとりあげたいなぁと思ってます）
自分の勉強内容の振り返り
以下、長文ですが、自分の振り返りをしておこうかなと。
ActiveSupportは多機能すぎてどんなことができるのか全体像がつかめてない状態だったのですが、まずは適当にいじることにしました。
利用する時に最初ハマったこと
require 'active_support'
として
4.hours.ago
としても、エラーになる。
active_supportだけをrquireしてもIntegerクラスに対する時刻関連の機能拡張が読み込まれるわけではないとのことで、そのため、時刻関連のようなものを利用する場合には
require 'active_support/time'
とするか、面倒な場合には
require 'active_support/all'
とすればOK。ただallとすると当然読み込みが重くなるみたい
文字列処理
class AdminUser end "AdminUser".underscore => "admin_user"
という感じで、キャメルケースな名前をスネークケースに変換してくれてるのは、ActiveSupportさんのおかげっぽいことを知れて、地味に感動しました。
日付処理
文字列処理についてそれい以上何かしらべようという気分にならなかったので、日付処理についてちょっと試行錯誤してみました。
Date.new(2014, 12, 27).tomorrow => Sun, 28 Dec 2014 Time.now.beginning_of_day => 2014-12-27 00:00:00 +0900 Time.now.end_of_day => 2014-12-27 23:59:59 +0900 Time.now.change(hour: 4, min: 30) => 2014-12-27 04:30:00 +0900
Time.currentとかはRuby標準っぽいなぁと思っていたら、ActiveSupportの機能だった
ActiveSupportをrequireしてると
Time.current => 2014-12-27 14:52:53 +0900
となるけど、requireしないと
irb irb(main):001:0> Time.current NoMethodError: undefined method `current' for Time:Class
とかなるのを知った
JavaScript/Node.js界隈でよく利用されるMoment.jsと日付処理が似てることに気づく
beginning_of_dayとか見ててどっかで見覚えあるなぁと思ったら、Moment.jsの使い方とすごく似てると思ったので対比させてみました。
現在時刻を取得
moment = require('moment'); moment().format() // '2014-12-27T14:10:14+09:00'
明日を取得
moment().add(1, 'days').format() //'2014-12-28T14:15:19+09:00' moment().add(1, 'days').format('YYYY/MM/DD') // '2014/12/28'
当日の午前4時30分
状況としては、毎日稼働してるバッチ処理の中でその日の午前4時30分というのを指定したいようなケース
moment().hours(4).minute(30).second(00).format() // '2014-12-27T04:30:00+09:00'
気になったので、日付処理のソースをちょっと読んだ
上記のような試行錯誤をしてる段階で
Time.now.change(hour: 4, min: 30)
みたいなやつのchange（）の処理がどうなってるのか気になったので該当するソースがどこか調べてみた
active_support/core_ext/time/calculations.rbを見ると
def change(options) new_year = options.fetch(:year, year) new_month = options.fetch(:month, month) new_day = options.fetch(:day, day) new_hour = options.fetch(:hour, hour) new_min = options.fetch(:min, options[:hour] ? 0 : min) new_sec = options.fetch(:sec, (options[:hour] || options[:min]) ? 0 : sec) if new_nsec = options[:nsec] raise ArgumentError, "Can't change both :nsec and :usec at the same time: #{options.inspect}" if options[:usec] new_usec = Rational(new_nsec, 1000) else new_usec = options.fetch(:usec, (options[:hour] || options[:min] || options[:sec]) ? 0 : Rational(nsec, 1000)) end if utc? ::Time.utc(new_year, new_month, new_day, new_hour, new_min, new_sec, new_usec) elsif zone ::Time.local(new_year, new_month, new_day, new_hour, new_min, new_sec, new_usec) else raise ArgumentError, 'argument out of range' if new_usec > 999999 ::Time.new(new_year, new_month, new_day, new_hour, new_min, new_sec + (new_usec.to_r / 1000000), utc_offset) end end
最初の方のoptions.fetchっていうのがどの辺で行われてる処理なのか気になったので、ターミナル上で
find . -type f -name "*.rb" | xargs grep "options"|more
という感じで検索してでactive_support/cache.rbあたりがそれっぽい処理をしてるようにみえたのでちょっと読んで見ました
def fetch(name, options = nil) if block_given? options = merged_options(options) key = namespaced_key(name, options) cached_entry = find_cached_entry(key, name, options) unless options[:force] entry = handle_expired_entry(cached_entry, key, options) if entry get_entry_value(entry, name, options) else save_block_result_to_cache(name, options) { |_name| yield _name } end else read(name, options) end end
何気なく読んでて、ふと引数に渡す時、分、秒がありえないケースの場合にどういう処理をしてるのかというのが気になったので
Time.now.change(hour: 23, min: 60)
とかやると、ArgumentError: argument out of range というメッセージをactivesupport-4.2.0/lib/active_support/core_ext/time/calculations.rb:95行あたりでエラーを吐き出すようになってる。
この辺りを読んでくと
- new_usec > 999999という謎の処理がある
- 前後のソースを読んでいたら、Rational(nsec, 1000))みたいなものが関連しそう
- Rationalっていうのが気になってこれはActiveSupport固有の処理かと思ったら、Ruby標準のものらしく、有理数というのがあるらしい。有理数の解説はこちら
という結論になったけど、これ以上深追いしても、結局何のためにこれ読んでるんだっけ？っていう状態になりそうだったのでソースコードリーディングは一旦切り上げました。
結局作ったもの
全くエンジニア経験のないshiro615さんに、現在プログラミングを教えていて、彼に、クローラー開発について教えていたこともあり、何かそっちに関連するようなものを作ろうと決めました。
デーモン化したRubyのスクリプトから毎日決まった時間、例えば、午前4時30分にクローラーを実行するというのを、cron使わずに、呼び出すようなサンプルアプリだったらActiveSupportの機能を使えそうかなと思って、クローラーは別に開発していたので、デーモン化したやつで、毎日決まった時間に実行するっていうベースになりそうなところだけ作ってみました。
Titanium用のモジュール書くためにObjective-Cについて腰を据えて学んでみた
仕事のからみで、Titanium用のGoogle Analytics for iOSが今後必要になりそうだったのでモジュール作りはじめてGitHubに公開しつつ折角なのでTitanium用のモジュール作りのはじめの一歩的な内容をQiitaに投稿しました
とりあえず、起動時にトラッキング出来るようにはなったのですが、イベントのトラッキング処理の所がうまくいかず、Objective-Cについて体系だって学んでなかったので腰を据えて取り組むことにしました。
想定してる人
- Titaniumでアプリをひと通り開発したことがある。
- 理想は自分のアプリを作ったことがある人のほうがよりしっくり来る内容だと思います
- Titaniumで利用できるAPIについてはおおまかに把握してる
- 具体的には標準のAPIでどんなことが実現できるのか全体を把握してるという意味
- 細かい使い方は調べながら利用できる
- C言語、C++、Javaなどの静的型付け言語の経験がほとんど無い
- 自分の場合にはRuby/JavaScriptメインに、VBScriptあたりが経験ある領域
やってみたこと
最初はクラスメソッドさんのStoryboardでUITableViewを実装し理解するを見ながら写経してました。
写経してたら途中途中でわからないことが意外と多かった・・
例えば
@property (nonatomic, strong) NSArray *dataSourceiPhone; @property (nonatomic, strong) NSArray *dataSourceAndroid;
というのが出た場合に
- nonatomicとかstrongとかってどういうことなんだろ？？
- *dataSourceAndroidの先頭のアスタリスクつけるのは何故？
と割と細かい所で立ち止まってしまうことが結構ありました。
UITableView使って、動作するものは出来たのですがこの程度の理解だと今後考えるとちょっとダメだなと考えて、実装を進めるのは一旦保留してまずはObjective-C自体についてもう少し理解を深めることを優先することにしました。
理解を深めるのに実践したこと
＠ITのiOS SDKで始めるObjective-C入門はボリュームがちょうど良かったのでこれを見ながら写経しました。
特に
- Objective-Cのクラスやプロパティ、特徴的なメソッドの使い方のやつのSetter/Getterの所の解説→インスタンス変数とアクセサーをまとめて自動生成する機能がある→プロパティ（@property）の説明
- Objective-Cのクラスやプロパティ、特徴的なメソッドの使い方（3/3）のメソッドの説明で、他の言語やっていた人に違和感をもたれるところかもしれませんという話
の所はすごく腹落ちした所があり、自分としてはすごくわかりやすい解説でした。
実践した後の気付き
メソッド名の書き方がわかりづらいと思っていたけど、上記@ITの記事見てたらこれは自分だけではなさそうっていう気付きを得られました。また、nonatomicの対比として、atomicがあることを知ったことで、
「あー、nonatomicって、 nonatomicってことだったのか」
という気付きも得られました。
プロパティのstrong/weakの使い分け
はるか昔にWSH/VBScriptでゴリゴリコード書いていた時に値渡し/参照渡しみたいな概念がある程度頭にあったので、copyが文字とおりコピーするっていうのはすぐに理解出来たのですが、strong/weakがそれぞれ強い参照と弱い参照っていったいどういうことって正直最初しっくり来ませんでした(T_T)
Objctive-Cにおけるプロパティ属性まとめ。正直、weakとかって使いどころが分かりづらいですよねーという記事を読んでて途中のメモリリークあたりを読んでるうちにようやくそれぞれの存在意義が理解出来てきました。
まとめ
- TitaniumでiOSアプリ開発やっていたし、Objective-Cの基礎的なことはわかってるから・・という傲慢な姿勢は良くなかった。
- 何事にもまずは謙虚にやるべきと反省。
- とはいえベースの知識はあるので、変数の概念とか制御文の基礎的な所はある程度読み飛ばしつつ、Objective-C固有の概念の所は難しく感じそうになってもめげずに理解を深めるように意識するのが大事
- 1つの情報源にあたっていて、理解が進まないようなら他のサイト（状況によっては書籍など）を参考にしながら学習をする
- 個人的には＠ITのiOS SDKで始めるObjective-C入門はボリュームがちょうど良かった。特に最後のObjective-Cのクラスやプロパティ、特徴的なメソッドの使い方のやつは
- 学習していたつまづいた所は面倒でもこうやってブログにまとめることで理解の甘い所について改めて理解できる
- こうやって書いててもアスタリスク付く所のやつはまだしっかり勉強してないからよくわかってない(^_^;)
プロダクト思考とサービス思考
最近お手伝いしている所のサービスについて色々ディスカッションする機会が増えて、時折議論が噛み合わないなぁと感じることがあったり、別件で、違う会社の人の話を聞いてても、些細な所でちょっとした違和感を感じるケースがあったりしました。
なんでそういう違和感を感じるのかイマイチ掴めてなかったのですが、自分は、常にサービスという言葉を常に意識して言葉に出してるのに対して、相手の方はプロダクトという言葉をおそらく無意識に使ってるからなのかなとなんとなく感じました。
ここでいうサービスとプロダクトの言葉の意味合い
言葉の定義としては、自分の中ではこんな意味で考えてます。
プロダクト思考
- どういう機能がいいのかをまず考える
サービス思考
- 誰が使うものなかを考える
- アプリとかサービスを出したらおしまいではないのでその後どうやったら使い続けてもらうのかを考える
- 使い続けてもらうからには当然売上も立たないといけないし、そのサービスを維持するのにコストがかかりすぎるのもいけないのでそこも考える。
- プロダクトはサービスの中の要素であるので、プロダクト単体で技術的に難しいことがあっても、実際のオペレーションで対応したほうがコスト的に割に合うならそちらを優先することを意識
あと、ここでの話は小さい会社（ベンチャーとかスタートアップという言い方がされる領域かな？？）でのことを想定してます。他の状況だと少し捉え方がかわりそうな気がしたので一応この点についても触れておきました
自分は元はプロダクト思考だった
自分は元はプロダクト思考でした。プロダクト思考からサービス思考になったきっかけはたぶん2000年の電子年賀状システムを社内向けにリリースした頃だったと思います。ちょっと昔話をしながらもう少し掘り下げて書いていきます
当初は電子年賀状システムを「作る」という発想しかなかった
流石に15年近く前のことなので、当時の細かい背景は正確に覚えてないのですが、当時の上司（上昇志向がとても強い外国の方）が自分たちの所属していた部署のプレゼンス（存在意義的な意味合いで使っていた気がする）を高めたいという気持ち＋αから、何か社内向けにサービスを提供したいというのがあって、電子年賀状システムという構想を出してそれをやることになりました
話を聞いた時に、Windows＋WSH/ASP+VBScriptみたいな構成を得意としていた自分としては、BASP21というCOMコンポーネントを使いつつ、HTMLメール送信すればイケそうという考えがすぐに浮かび、作るということしか考えてませんでした。
作るのが必ずしも正解とは限らない
自分たちで機能面について考えて、それについて実際に利用しそうな人からフィードバックもらってという感じのアプローチをたぶんとった気がします。※あまりに昔のことなので当時こんなことを考えていたかどうか微妙ですが(^_^;)
フィードバックもらう中で、
みたいな意見が出て、自分の当時のスキルではBASP21でHTMLメールの送信は出来てもそれ以外の機能で、特にテンプレートを任意に選ぶというのが技術的に難しい印象を受けました。
ただ、当時の上司の頭のなかでは、作る前提では考えておらず、むしろ外部に使えそうなパッケージ製品があればそれを積極的に使って欲しいというスタンスでした。
自分としては作りたい気持ちがとても強かったので、正直おもしろくないという気持ちが全面に出てたのですが、しぶしぶ、外部のものを探したら、今回のやつにとてもフィットするのがあったのでそれを採用しました。（結果的にそれを選んで正解でした）
大事なのは「誰に」「どのように」使ってもらうのかを考えることが大事だと知った
当時いた会社は、まぁみなさん凄腕なエンジニアの方が多くいらっしゃるような環境だったし、営業やマーケティングの人たちも、会社自体がIT系だったからみなさんITリテラシーは高い方が多くいらしていました。
取引先に対して、本文に自分が選んだテンプレートで年賀状がメールで送られる、しかもFlashとかでもなく、ファイルが添付されるものでもないというのはみなさんすぐに理解してくれたとおもってます。
紙の場合には、決まった日までに書かないと届かないという問題があったけど、メールベースのものだったので、12月31日までに書けばOKだし、メール送信予約機能も当然あったので
- Aという顧客には元旦に届くように設定する
- Bという顧客は、年明けに会社で見るだろうから元旦ではない日付で設定
みたいなことも出来るような仕組みを整えていました
開発元の方（たしかカナダの方）の協力を得ながら、割りと細かい使い勝手まで気を配ったり、元旦に出社して、メールの不具合がないかどうかサポートもして、年明けしばらくしてから、部署を横断して社内の問題点について議論するような会議が定期的に開かれていたので、そこで結果報告＆フィードバックもらったのですが、そこそこの評価をいただきました。※同じくらい、来年度に向けての改善（連名機能ないのがおかしいとか）もガンガンもらった
こういうフィードバックもらってからは、「誰に」「どのように」使ってもらうのかを考えないとダメでプロダクト単体でモノゴトを捉えていた自分がいるなぁとなんとなく反省した気がします。
サービス思考に切り替わってからの変化
この電子年賀状と並行して、社内のユーザさんが利用していたノートPCを大量に環境移行しないといけなかったので、データ＆PC環境の一部をPC間で移行するVBScriptを自分たちで書いてました。
ツールの完成度はユーザさんには直接のメリットは無い
ベースとなるものを自分ともう1人の人とで「このRegistryKeyの値を読み出すとxxのアプリのプロファイル情報参照できそうだから移行時のパスとして使えるんじゃねー」みたいなことを話しながら一緒に書いてて、それをやっていた頃は、そのツール自体の出来というか完成度を高めることを強く意識しすぎていました。
ただそのツール自体の完成度というのはユーザさんにとっては別にどうでもよくって、「仕事に支障が出るから、なるべく短時間で環境移行が終わってほしい」というのが本来求められてる所でした。
電子年賀状に関わった後、ちょっとづつですが自分の中ではユーザさんにとってのメリットが何かをまず先に考えるようになりPC環境移行についてもどうやったらユーザさんがPC使えなくなるダウンタイムを減らせるのか？ ということをまず先に考えるようになったかなと思います。
サービスという視点で全体を捉えるようになった結果として
環境移行のオペレーション全体で最適化することでダウンタイム減らせるかもという仮説の元で
- ユーザさんが好きな日程で環境移行の日程を調整出来る
- そこの作業の日程調整はメールでやると互いに煩雑なので社内上にWebアプリを作った。
- このWebアプリはカレンダーっぽいUIをなんとか実現して空き日程＆時間帯がすぐにわかり、空き日程をクリックすれば予約受け付け終了＆確認メール送信されて、実際のオペレーションする人もいつ、誰のPCを設定すればいいのか別の画面から確認できて割りとイケてたモノだった気がする
- 日中に環境移行出来る人の枠は当然のことながら、忙しい人向けに夕方預かり→翌朝引き渡しの枠も設定
- PC環境移行の作業自体はほぼ自動化されていたので、最後PCを預かって、最低限の作業だけすると、夜間に、PC→PCへの環境移行が終わるように前述のスクリプトなどを組み合わせて実現していた。最悪環境移行が完了しなくてもPC自体はあるのでそこから足りないデータをコピーする手はずを整えていたのでそれで全然OKだった。
というようなことをやってました。
このオペレーションが確立されたことで、この環境移行のために適宜人員を増やして対応していたものが、通常の業務の1つとして組み込めるようになったことで、余力ができるので、費用対効果を意識しつつ、ユーザさんにとって利便性があるサービスがどんなものがありそうかを考えて・・ということが出来るような体制になっていきました。
残念ながらその後は、大掛かりな組織変更があったことでずっとこういうことが出来たわけではないのですが、
- ユーザさんにとってのメリットは何か？
- そのサービスを回すためのオペレーションをする人が無理なくこなせる仕組みがどのようなものか？
- 効率化や作業ミスなどを回避するために、積極的に技術的な所は活用するけど、その技術が何を解決するものかを忘れないようにする。
みたいな発想が2000年〜2002年頃の間に養えたのは、今振り返るととてもよかったなぁと思います。
まとめ
プロダクト思考とサービス思考のどっちが良い・悪いという決め付けをするつもりは全くありません。ただ何か議論してるような時に、話が噛み合わないなぁと思った時に、互いにどういうスタンスで話をしてるのかを明確にするだけでも、噛み合わない状態からちょっと先に進めるのかなと思ったので、まとめてみました
