子育てのゴールデンタイムの今を大事にする
うちの奥さんがしばらくの間、日曜日に学校に通うことになったという事情も合ってしばらくの間、毎週日曜日に娘と2人で過ごしてます。
最初は、近所の公園でいつものように遊んで・・・と思ったけど毎週日曜日がそんな感じだと、まぁツマンナイだろうし、車のCMにあったモノより思い出じゃないけど、折角のこういう機会なんで、娘が行きたいと思うような場所をピックアップして、遊びに行くようにしてます。
最近の活動を振り返ると後厄のオジサンな自分からすると頑張ってると思う
ここ最近を振り返ると
- GWまっただ中に渋谷のNHKスタジオに行く
- 井の頭公園に動物を見に行く→隣駅に移動してローラー滑り台などの遊具がたくさんある公園で遊ぶ
- （電動アシスト付き自転車ですが）娘を乗せて自転車を30分ほど漕いで交通公園で遊び、その帰りに都内で唯一の牧場見学に行く
- 別の日に、自転車を30分ほど漕いで植物園＆小さい動物公園で遊ぶ
という感じでした
今後の予定としては
- 大潮周りの日をチェックしながら、大学時代〜20代なかばまでウィンドサーフィン＆サーフィンのためによく通っていた鎌倉の一角の和賀江島で磯遊び出来るっぽいのでそこで遊ぶ
- 大森エリアで遊ぶ（しながわ水族館、平和の森公園フィールドアスレチック、城南島海浜公園）
みたいなプランを立てます
後厄のオジサンな自分からすると、年長さんになったうちの娘と1日遊んで過ごすにはそれなりの体力が必要だというのをすごく実感してて、ここ最近の毎週月曜日はだいたいどこかが筋肉痛になってる確率がとても高かったりします^^;
なぜそこまで頑張るのか
ちょっと長い前置きでしたが、なぜそこまで頑張るのかという理由として、このエントリのタイトルに繋がるのかと。
子育てのゴールデンタイムっていう言葉は自分が考えたフレーズじゃなくって子育てでヘトヘトなパパママへ！実は短い「子育てゴールデンタイム」という記事にかかれていたものなので、そこから引用しました。
でも、そうした大変な時期って、本当に、あと数年なんですよね。大変なことほど、後から振り返ると楽しいというか…。
ということが書かれてたのですが、冷静に考えると、来年小学校だし、小学校に入って、数年もすると、親と一緒に遊ぶっていう機会はたぶん無くなるだろうからそう考えると、本当にあっという間ですね。
まぁ、ゴールデンタイムっていうのがあっという間っていうのはわかったのですが、それでも何故頑張れるのかちょっと振り返ってみました。
成長を感じることが出来るから頑張る
生まれて病院を退院した後に、すぐに家族３人で過ごしてきて、今に至るのですが、例えば月齢半年〜２歳位までの頃のことは、あまり記憶に無かったりします。
でも写真を見ると「あーそういえばこんなことがあったなぁ」っていうのは思いだせるし、そういう過去と比べると、今はずいぶん成長したなぁという実感を得られるのは、父親として出来る範囲で育児と家事に関わってきたからこそなんだと思ってます。
そういう過去の蓄積があるから、子どもの成長とか変化に気づけるわけだからそう考えると頑張れるのかなと。
一人っ子の娘の切なさそうな顔を見て
いつだったか記憶が曖昧なのですが、公園に娘を連れて遊びに行っていつものように（自分も一緒になって）遊具で遊んでいました。
世の中では少子化と言われるけど、意外とうちの近所では2人とか3人兄弟・姉妹みたいな家族が結構多いみたいで、周囲の子どもたちは兄弟・姉妹で仲良く遊んでおり、その姿を眺めていた娘が、なんとなく羨ましいという感じのちょっと切なさそうな表情をしていたように見えました。
私自身は、姉が2人いるのですが、末っ子長男で男1人なんで、なんとなく気持ち的に一人っ子の気持ちがちょっとだけわかる面があり、そういう自分の心境で勘違いしてるだけっちう気もしますけどね^^;
1人よりも2人。2人よりもそれ以上で遊ぶ
いづれにしても、1人で遊ぶよりは、2人で遊んだほうが楽しいし、実際自分も子供と一緒に遊んでると、小難しいことを考える暇もないし、日頃使わないような脳神経が刺激されるような感覚もあってとてもリフレッシュされます。
こっちから知らない子どもに話しかけると最近だと怪しい人扱いされそうだし、そもそも自分からそういうのが積極的に出来るタイプではないのでやらないのですが、 幸いなことに、娘と一緒に遊んでると、かなりの確率で、男女問わず知らない子どもに自分は話しかけられます。
そういうタイミングをうまく掴んで、そういう子をうまく巻き込みつつ、一緒に娘を遊ばせるようにすることで、わずかな時間かもしれないけど、2人ではなく3人とか4人とかの大勢で一緒になって遊べることもできるので、そこは親として自分次第でどうにか出来る事なので、頑張ってやってます！
最後に
なんでこんなことを書こうと思ったのかというと、ちょっと前に、こちらの団体の方から、我が家の家事事情についてのインタビューを受けたのですが、話の流れで育児についてちょっと考えるというか振り返ったので、それをちょっと深堀しておきたくなって書きました。
あとは、仕事でRails2系→４系というちょっとチャレンジングなことをやってて、ちょっと煮詰まり気味なので、書いたというのもあったりします^^;
自分のエピソードを引き出すためのプロダクト/ポートフォリオを作る
お客さんとなる方との打ち合わせで
「xxxはどの程度できますか？」
という質問をされることが多々あるかと思いますし、実際自分もここ1年弱の間にこういう打ち合わせを何度か経験しました。
この辺りでちょっと思う所があるので少しまとめておこうと思います。
出来る・出来ないの質問ではそもそも相手の技術レベルが把握しづらい
前職ではWeb系な人を対象としたキャリアカウンセリング（キャリアコンサルタント）をしてたのですが、経歴、希望を踏まえてお仕事の紹介をするために、相手の技術的なことを把握する必要があったのですが、
- 「○○の構築は出来ますか？」
- 「xxの言語は出来ますか？」
- 「○○の設計経験はありますか？」
というYES/NOの二択になりがちな問いかけは避けてました。
何故かと言うと、双方にとっての出来る・出来ないのレベル感だったり期待値が異なり、こういうのを鵜呑みにしてしまうことで後々互いに不幸になると思ってるからです。 ※これは前々職でのエンジニア時代の自分自身の苦い経験から得た教訓だったりします(^_^;)
YES/NOではなくエピソードを語らせる
ではどうしていたのかというと、仕事でのエピソードを語ってもらうようにしてました。エピソードを語らせるというと何かすごく大げさな印象になりそうですが、質問自体はシンプルで、経歴書の中で気になった箇所とか、個人的な興味とかで、
「○○されていたみたいで、これってxxが大変だったと思うのですがその辺りでどんな苦労されましたか？」 「△△という立場ならではの苦労ってどんなことがあるんでしょうか？」
という感じで質問してました。
ポジションに関係なく、その人の期待値っていうのがあると思うので、そういうのを感じながら仕事をしていれば苦労話はいくつか出ると思ってます。
上記経験があるから、打ち合わせではその仕事ならではのエピソードを語る
自分がフリーランスになって、お客さんとなる方との打ち合わせでは、なるべく相手に響きそうなエピソードを語るようにしています。
「私には特技がない。でも...」女性WEBデザイナーが10年以上フリーランスで活躍してきた秘訣で触れてるようなグレーゾーンの仕事って自分も割りと好きな方だし、これまでのエンジニアとしての経験＋前職の人材系の経験を活かす意味でもそういうのは積極的に拾うようにしたい意識もあるので、そういう所が伝わるようなエピソードをなるべく話すようにしてます。
お客さんとなるような方が、比較的規模の小さいベンチャーっぽい所なので、1つのことしか出来ないというよりも、あれもこれも出来る人のほうが重宝されるのかなと思ってます。
自分のエピソードを引き出すためのプロダクト/ポートフォリオ作り
そんな自分ですが、ちょっとしたきっかけで、自分のプロダクトというかポートフォリオというかそんなものを作ってます。
プロダクトとかポートフォリオってなると、何かすごく大変そうな気もしそうですがここ最近仕事で身につけたスキルの習熟度を確認しつつ、自分が好きな商品を集めただけのサイトをRailsで開発（ついでにGitHubで公開）する感じなので、そこまで大したことはやっていません。
過去に関わった仕事を振りる過程を通じて
- 出来、何がどこまで出来る・出来ないのか自分なりに把握できる
- 振り返る中で「最近の仕事でやった○○のおかげで、昔はxxで苦労したのも今ならどうってことない」とか「あの仕事の実装は今ならこういう感じでアプローチ出来るんじゃないかな？」という確認や気付きが得られる
ということに繋がってるので、自分のエピソードを引き出すためにプロダクト/ポートフォリオを作っておくのは大事なのかと思ってます
参考までにプロダクト作りを通じて自分を振り返ってみた
上記プロダクトを作りながら、ここ1年弱を振り返ってみるとこんな感じで、40代になった自分としてはそれなりに頑張ってるのかなと。
- RailsとAngularとの住み分け
- BDDな開発のやり方にやっと馴染んできた
- Railsで新規に開発するケースならRSpecでRoutingのスペックを書いて画面遷移の振る舞いをまずは決める。
- その上でControllerのスペック書いて・・という感じでEveryday Rails - RSpecによるRailsテスト入門で書かれていた外から中へというアプローチについて腹落ちしてる
その際はエンドユーザーがアプリケーションを使ってタスクを完了させる手順を考えてください。これは 外から中へ(outside-in) のテストと呼ばれる一般的なアプローチです。
フリーになって9ヶ月経過したので振り返り
以下のように定期的に振り返ってるので、今回も振り返りまとめようと思ってます。
良かったこと・反省点
まず良かったことですが、前回の振り返りで
未経験でWebエンジニアになりたい人にずっと教えてたけど、自分のツテを通じてアルバイト的にエンジニアとしての仕事が出来そう。
と書きましたがエンジニア経験無い人を教える＆働き先を紹介するまでの話で書いたとおり、これ実現できたのが良かったことかと(^_^)
自分が常駐してる所で、毎日ではないですが一緒に働いてて、私がフォローしながらですが成果物となるものをつくり上げることが出来ました
ただ、その過程を通じて見えてきた課題（どちらかというとチームで仕事をする上での心構え的なやつ）もあって、そういうのは仕事に付く前のプログラミングを教えてる段階で気づきを得るようなしかけをいれておくべきだったかなと反省してます。
反省点としては、この３ヶ月間は久しぶりに働き過ぎた感じがして、特に最近２ヶ月は週5.5日稼働にしてしまったことかなと。
稼働を増やしたりしていたので、やりたいことに着手できてない状況になってるのでそのための仕組み作りみたいな所を今後意識してやっていきたいと思ってます。
今後に向けて
4月に入って少し落ち着きつつあって、今後に向けて動きやすくなりつつあるので、まずは自分で稼ぐ仕組みを作る作業にちょっとづつ着手していこうと思ってます。
1人でやれる仕事に限界があるので今後どうするか考えてみたでもちょっと触れてますがやりたいことが色々ある反面、それを実現する手段が確立できてないのでその辺りはフリーランスな人＋αでジョブシェアリングできたらとなんとなく妄想してるのでちょっとその点について触れておこうと思います
フリーランスな人＋αでジョブシェアリングとは
「ジョブ・シェアリング」とは、通常、フルタイム勤務者1人で担当する職務(ポスト)を2人以上が組になって分担し、評価・処遇もセットで受ける働き方。仕事と育児、介護、勉強などとの両立を可能にするワークシェアリングの一形態で、より多くの人材に雇用機会を与える方法として注目されています。 コトバンクより引用
こんな↑感じに近いことが出来ないかなあと。
なんとなく考えてるのは仕事としては1人分の仕事を受注しつつ以下の様な仕組みが出来ると、働く側もですが、企業の側としてもエンジニア1人分の仕事力を確保できるのかなと思うので、みんなにとって損はないのかと思ってたりします
- フリーランスの人同士でペアーになるパターン
- メイン担当の人が最低でも週3日はコミットして基本的にはこの日数は常駐するようにする。
- 相手のフォロー役となる人がいてその人がメイン担当の人のサポートをする感じにする。メイン担当が当面やらないといけない技術的な調査とか下調べとかを行う。（技術調査みたいな名目でメイン担当からサブ担当に対して業務を発注するようにしてしまう感じかな？？）
- フリーランス＋今後エンジニアになりたい人同士でペアーになるパターン
前者のパターンですが、以前トークイベントに登壇いただいた方からのご紹介でたまたま縁あって、フリーランスのRailsエンジニアの方とゴハンを食べに行く機会がありその人も私と割りと近い考えがあったのでこういう人が身近に増えていけば可能性あるかなと
後者についても
- 今後エンジニアになりたい人は一定数いる
- そういう人を育てるとか教えたい人も結構いる（これ最近気づいた）
- 上記のような人たちいるのに着目してる人も少なくとも自分の身近な所（前職の人ではない）で数名いる
という状況なのでこういう人同士がちょっとづつ繋がると面白い展開になるのかなと。
頭数を足し算するだけはチームスキルを正確に反映しない
ちょっと長くなったので先にポイントだけ書きます
- １人が経験浅い人が含まれる2名１チームの場合のチームスキルを考える場合に1+1＝2ではなく、チームが生み出せるアウトプットｘ頭数として考えて、(1 x 0.5) x 2＝ 1という感じな気がする
- なぜ、２ではなく１になってしまうかは、経験浅い人に対して、技術的な側面に限らないフォローをもう1名がやらないといけないためチームが生み出せるアウトプットが少ない
- フォローをする側の人間が1名で全部抱えても結局はチームスキルは１のままなのでフォローするアプローチを変えて、ちょっとだけ改善の兆しがみえてきた。
以下それぞれ深堀りしていきます
実際の状況でチームスキルについて考察
エンジニア経験無い人にプログラミングを教えて、アルバイトとして職場を紹介したとこの前書いたのですが、そこで
しばらくは自分も出来る範囲でフォローするのでアルバイトで採用とかどうでしょうと打診し
と書いてるように、現在その人のフォローをしつつ自分の仕事もしています。
諸事情あってスポット的に作る必要のものが出たので、彼が基本作業して足りない所を私がフォローしてという感じで作業を開始しました。
まず仕事力というものを考えてみた
作業開始段階で、頭数として1+1＝２名なので、ほぼ２名分のチームスキルとおそらく私含めてみんなそう捉えていたのかなと思います。
ところが、エンジニア経験、正確に言うと社会人としの経験もそこまで多くないので、自分が勝手に名付ける仕事力がまだまだ不足してます。
仕事力は抽象的すぎるのですが、Web系のエンジニアとしての仕事に限ると
- 技術的な側面
- 自分が頼まれてるタスク（チケット）をどの程度で完了させることが出来るか作業を見積もれる
という所かなと思ってます。
後者の位置づけが、読み手によって違和感を感じそうなので補足をしておくと、会社規模的には数十名規模で、チームといっても2〜3名規模でニュアンスとしてはひげろぐさんという方が1年位まえに書いた久々にチーム開発したのでメモがすごく伝わるのかなと。
２名チームなのに１名分のチームスキルになってる
上記で書いたエンジニアとしての仕事力というのを、私の仕事力はを１人、フォローしてる人の仕事力を0.5人程度とした場合に単純な足し算だと、
1 + 0.5 = 1.5
というのがこの２名のチームのスキルになるのでしょうけど、この数字ほどにチームとしてのパフォーマンスが出ないなぁと感じてました。
まず２名の力を組み合わせた時のスキルというのを算出するためにそれぞれの仕事力を掛け算してみます。
1 x 0.5 = 0.5
上記の仕事力に対して頭数である２名を掛け算してみます
0.5 x 2 = 1
２人で仕事をしてるのになぜか１名分という数字になりました！数字遊びをしたいわけではないのですがでもこの数字は自分の肌感覚ではかなり正解に近いんですよね(^_^;)
まとめ的にチームスキルの定義を考えてみました
まず
- 技術的な側面
- 自分が頼まれてるタスク（チケット）をどの程度で完了させることが出来るか作業を見積もれる
という観点でそれぞれのエンジニアの能力を考えます。
技術的な側面については
みたいな感じで利用する技術領域ごとに以下のような感じで数値化するとより正確になっていくのかなとーこれ書きながらふと思いました。
- 0.5: 他の人のフォローがないと作業が進められない
- 1.0: 過去似たものを作ったことがあるので多少調べながら作業が進められる
- 1.5: この↑レベルよりも作業がすぐに終わるしより保守性とか意識した作業もできる
上記でそれぞれのエンジニアの能力が把握できると思うので、チームが生み出すであろうアウトプット力を算出するため、それぞれのエンジニアの能力を掛け算して、チームが生み出すであろうアウトプット力を得ます。
チームが生み出すであろうアウトプット力が得られたら、それに頭数を掛け算してチームスキルになるのかなと
チームスキル＝チームが生み出すであろうアウトプット力 でしょうかね。なんかこういうのは偉い人がまとめてるのかもしれないけどひとまず自分の頭で考えてみたことなのでまとめておきました
なぜ１名分になるのか？
これは当たり前なんでしょうけど、経験浅い人に対して、技術的な側面に限らないフォローを色々やらないといけないから。
Issueの機能を利用して、そこで当面やってほしいことの単位に落としこんで作業をしてもらうようにしていたのですが、こちらの意図が正確に伝わらないケースがあって、そのIssueで期待してること以上のことまで作業してて、そこで行き詰まってしまって思ったような成果が出ないということがありました。
当初はそこが気づけず、時間がかかる背景がわからなかったため、それ以外の未着手のIssue（しかも簡単そうなもの）が溜まっていくため、そこのフォローに時間をさいていたので、自分が本来着手しないといけないことは遅れ気味になるので、そんなことが積み重なると１名分のチームスキルというのもあながち間違ってない気がしてます。
現状課題に対してどうしたか？
フォローをする側の人間が1名で全部抱えても
- チームが生み出すであろうアウトプット力 →１のまま
- 頭数→本来2名チームだけど1名で抱えると１になる
なので、1 x 1 = 1となり、結局は１のままになってしまうため、それを続けていっても長期的にはプラスになりません。
なので、フォローするアプローチを変えることにしました。
問題が何かを明確にするための工夫
そこで当面やってほしいことの単位に落としこんで作業をしてもらってるはずが、そのIssueで期待してること以上のことまで作業してて、そこで行き詰まってしまって思ったような成果が出ないというのが自分達のチームにおける課題かなと思ってました。
少なくとも経験少ない人には大丈夫？とか何か困ってない？という質問は避けるようにしてました。
※スタートアップな会社で技術責任者してる知り合いがスタートアップの"カオス"を生き抜く開発術で生産性を阻害するたった1つのありふれた問題で何が問題なのかが分からない以降の話が参考にしてたりします。
これはエンジニアに限らず仕事の経験少ないうちは自分がやってることを人に説明出来ないのでどんなプロセスを経て現在仕事をしてるのかを意識させる仕組みを入れてみたほうがいいのかなと思って90分単位でWIPなプルリクエストを出させるようにしました。
ひとまず、一定の時間軸の中でできることを意識させたり、プルリクを出すという作業を通じて、xxを見てたけどわからないという形でもいいので、少なくとも何らかのアウトプットを出させる意識を持ってもらうようにしました。
劇的な改善っていうのはないのですが少なくとも以前よりもどういうプロセスを経て作業に着手しているのかが見えやすくなってきたので、フォローの質が変わってきたかなと思ってます。
改善策についてせっかくなのでネーミングを考えた
90分という単位に深い意味がないのですが、互いにサッカー好きなのと、現場のリーダーもサッカー好きということもあって何かサッカーにちなんだネーミングを付けてもいいのではと提案して、90分単位でプルリクだすのをゲーゲンプレスとしました。
ネーミング大事っていうのはインフラで実践したチームビルディングそれはサバ天を書いてるume3_と少し前に飲んだ時に教わったのでそこの学びを活かしてやってみました。
ゲーゲンプレスというネーミング通り、経験浅い人には大分ハードな戦術なのでネーミング通りの制度かなぁと思ってます
最後に
最近色々考えることが多くって、ブログにしっかりまとめたいけど、ポイント絞ってまとめるのが難しい。。。
エンジニア経験無い人を教える＆働き先を紹介するまでの話
タイトルで全て言い尽くしましたが、自分がやりたかった
教える（正確にはコーチング）⇔開発する
の両方が相互に作用するような自分がイメージしてたことがようやく実を結びました！
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人の方と直接お会いして実際にお話を聞いていたら、もっと大きな課題が見つかり、そっちの課題解決のためには、技術的にちょっとチャレンジする要素があるのですが、しっかりと収益の見込みが立てられそうな気がしてるので、フリーのカメラマンさんの日頃の課題を解決するサービスを作ります。
最初は日頃の課題を解決するサービスを作りたいって書いていたけど、ここは言い切ることで自分に言い聞かせることにします(^_^)
大分長くなったけどこんな感じで今季というか今年取り組んでいきます
