島までは遠い 〜サークルアラウンド株式会社代表佐藤のブログ〜

佐藤正志@サークルアラウンド株式会社のことが少しわかる場所。プログラマーを育てるトレーナーとして、現役のソフトウェア技術者として、経営者の端くれとして、想うことをつづる。

法人向けトレーニングをメニュー化しました。道のりの振り返り(長文注意)。

はじめに

これまでお知り合いベースでは法人さんのトレーニングをしてきたのですが、この度ちゃんと看板立てることにしたんですよ。パチパチパチパチ。

circlearound.co.jp

ちなみに、ここに至るまで個人向けの 個別トレーニング を始めてからそこそこ長い道のりがあったりして感慨深いので、心の声を残しておこうかと思います。

個別トレーニング誕生まで

弊社の創業時はWEBサービスやアプリを売るスタートアップになろうとしていたんですが、私がスタートアップ向きじゃなさそうだったので一回全部綺麗にして*1、一人株式会社で受託しながら今後どうやっていくか悩んでいました。

当時からいわゆるスクールっぽいところ(今巷に溢れているタイプのとはちょっと違う感じです)の外部講師はしていましたし、個人でIT技術を勉強している人を応援したりもしていました。創業前ですが下記の記録はそこから生まれたものです。 qiita.com

「プログラミングを学び合うシェアハウス」という期間限定の企画にも参加できて、年長のオジさんポジションで暮らしてたりもしました。 storys.jp

仕事の現場のプログラマーとしても、新人の個人やチームの面倒をOJTで見てきて、10人くらいは自分なりに育ててきました。人の成長は楽しいし、会社勤めしている時も「人が成長できない会社は傾く」と思っていたので、そういう気質はずっと強かったです。

というわけで人を育てる軸で何かやりたいと思っていたのですが、経営としてやるからにはお金をある程度稼ぎつつ続けられないと、私や関わった人が死んでしまいます。即お金になりやすいのはこれまでのOJT経験を押し出して会社に当たっていく、研修講師的な位置付けでした。

とは言え、以下の2点のような理由でそれは却下しました。

  • 「私が一人で生きていく」のは容易いのですがチームメンバーを増やした時に同じことができる人がかなり限られる
  • 「営業して人に何か買わせる」のは今までの自分の経験上やりにくいと思っていた

別の視点で考えると、当時よく個人の方から相談されていた事があります。

  • 「今後起業したいけれどシステム開発がわからないから知りたい」
  • 「HTML/CSSは自学できたけれどJavaScriptはうまくできない」

提供していた下記のようなセミナーにも、そういう方が結構いらっしゃっていました。

www.street-academy.com

セミナーは伝えるべきゴールを事前に決めて、ある程度一般的な内容を展開せざるを得ません。私の強みは目の前の個にフィットさせる課題解決だったので、「もう少し個人にフォーカスできる形」ならより高い価値を提供できそうだと考えました。今で言うプログラミングスクールのようなものも世間に出始めた時期なので、流れに乗れそうだという事もあります。

というわけで、個人向けにピンポイントで課題オーダーに答える 個別トレーニング を始めることにしたんです。マインドとしては過去培ったOJTの経験があるので、その時のエキスをしっかり伝えていくことを軸にしました。初学者向けも、ある程度経験のある人も教えることはできるので「相談とお互いの納得次第でなんでもあり」としました。

弊社にメンバーが増えたら、その人が得意な技術を限定すれば人に教えてもらえるだろうと考えました*2。トータルで出来上がっていることを望まれがちな法人向けよりも、力になってくれる人も得やすいと思います。

社内の技術力アップへの取り組み

弊社は受託開発も行なっているので、トレーニングの担当者は受託と並行して指導します。バランス取りは私の仕事で、流動的なトレーニングの顧客獲得に合わせて、受託を減らしたり増やしたり、メンバーそれぞれのタスク量も調節します。

トレーニングで伝授できる内容はその導き手のレベルによって変動するので(自分がマスターしていないレベルのことを背伸びして教えようとしても、適切にポイントを伝えて伸ばすことはできないですよね)、少なくとも私が知っている事はなるべく社員メンバーが吸収していくように、これまで続けてきました。たとえば2週に一回「技術定例」という名目で、技術に関することを何でも意見交換しています。

ここでは普段の業務では聞けないようなことをお互いに送受信したいと思っているので、例えば以下のようなことを自由に会話します。準備は全くしないで、ホワイトボードや実際に書いたコードを使って交流して、基本的にキッカリ一時間で切り上げます。

  • 個人で開発しているサービスで困っていることを質問
  • 最近気になるあの技術について意見交換
  • チーム全体を良くするための意識合わせ

そんな取り組みの成果もあってか、初学者の対応は中心メンバーの小笠原がかなり積極的にやってくれているので、私の時間は「オブジェクト指向をもっと深く理解したい」とか「他のメンバーがあまり得意でない言語や環境」など、サブ的なポジションにいても大丈夫な形になってきました。

受託開発とトレーニングのマリアージュ

弊社が個人向けのトレーニングを行なっている事は、受託開発で一緒になった会社さんや個人さん、イベントなどで居合わせた方々に大抵お伝えしています。そのお陰もあってか、これまでもピンポイントで新人を育てるような依頼を何社かお引き受けしていました。

[ケース1] 指導からの受託

少し傾向が変わってきたのが 2018年に受講した人の就職先からのトレーニングの依頼です。オーダーとしては

無事に入社はしたものの先導して教えてくれるような先輩がおらず(周囲が業務委託ばかりだった為)、実開発でのアドバイスを通じてもう少しレベルアップに協力してくれないか

という事でした。弊社としてはトレーニングを巣立っていった人が活躍して欲しいですし、このタイミングで頼っていただけた事は私たちの成果を認めてくれていたという事なので、大変有難い事です。二つ返事でお引き受けしました。

その後、アドバイスのみならず受託で開発のお手伝いもするようになり、本当にOJTのような指導が実現しています。今は私はそちらの現場は離れましたが、小笠原と松倉で指導と開発を行なっています。

[ケース2] 受託からの指導

同様のケースが逆のパターンでもあります。最初は受託開発としてお引き受けしていた仕事のお相手から「新しい社員を迎えるのでトレーニングして欲しい」という依頼です。こちらの会社も先輩社員として牽引するような存在がおらず、仮に社員を迎えてもその人が自力で伸びなければならない環境でした。会社としては成長を加速させて早く独り立ちできるように促したいとのことでした。

受講者のゴール感は私たちがJOINしているサービスを熟知する事なので、ある程度実力がついてからは実際の会社のサービスでIssueをこなしながら学習もしてもらうステップを踏んでいます。もう独り立ちフェーズに入ってきたので、そろそろ我々はお役御免になる予定です。自分たちが居なくてよくなる事が最後の目標なので、あとはなるべく早くその日を迎えるべくメンバーが励んでいます。

今私はどちらのケースも深く関わっていません。私以外の人でもある程度まわせる状況になったと考えるには十分だと思います。

今こそ形に

そんなわけで昨年の5月くらいから、もう少し立てつけをしっかりしてメニュー化するということを進めていました。まぁ、それも「やるから頼む」と、小笠原にムチャブ...ではなく、任せて進めてもらった形です。そしてマーケティングやデザインに関しては助っ人をお願いしました。

どのように広めるかの企画立案には、以前からお知り合いだった宮本さん( @yahsan2 )、デザインには個人向けトレーニングのチラシもお願いした Manatyさん( @ddw_designer | http://www.manaty.tokyo/ )にお声かけさせていただきました。二人の手練れのお陰で、当初の我々のボヤッとした内容がキチッと具現化されたと思います。宮本さんが提案された「カードを利用して既に私たちと知り合っている人から広げていく」手法は人との対面のつながりを重視している弊社らしい入り口になりますし、Manatyさんに至っては「現場の生々しさを伝えたい」ということで弊社にいらして写真撮影までこなしていただきました。お二人の献身に感謝します。

そういった何人もの脳汁と汗が結晶したのが冒頭にご紹介したLPです。大変良いものが仕上がりました。

circlearound.co.jp

こちらは宮本さんの提案から生まれた名刺サイズの割引カードです。弊社メンバーからこれを手に入れると25%オフになります!

f:id:ms2sato:20200224113039j:plain

お互いに価値を認め合えるような顧客と長いおつきあいが出来たらと考えています。沢山の会社さんを一気に引き受けられるような体力も無いですし、トレーニングしかできなくなってしまうとトレーナーの実力が落ちるので、やはりバランスが大事です。マインドの会う会社の方、いらっしゃいましたら是非お問い合わせくださいませ。

おしまいに

そんな感じなので、お困りの方いたらとりあえずお声かけいただければ幸いです。相談だけなら無料なので、まずは状況教えていただけると嬉しいです。言語や環境については、会社としてはRuby on RailsやJavaScript、AWSをよく扱っていますが、他言語や環境も内容に応じてお力になれると思います。

ちなみに事前にお声かけさせていただいたある会社さんとはお話が続いていまして、まずはこちらをキッチリとゲットしたいところです。

*1:これはこれで色々キツかったけどゼロから始めるのは嫌いじゃないのでアリでした

*2:実際に、弊社の一号社員の齋藤には「git/GitHubの扱い方を初心者向けに伝える」という十八番のレクチャーがありました

親は子供の未来についてどこまで口出しすべきなのか

はじめに

今年の正月に実家で甥と話したこと。残しておきたくなった。

登場人物紹介

  • ms2sato: 40過ぎのオッサン。
  • K: 姉の長男で、ms2satoの甥。今度高校を卒業して働きに出る。妹思いでマジメないいヤツ。

本題

Kは地頭はそこそこ良いタイプだと思うがあまり勉強は好きではなかったようで、高校受験はあまり力を入れなかった。その結果としてあまり学業の優秀では無い学校(本人曰く「このあたりの底辺」)に入った。部活も勉強もそこそこシッカリやって、勉強は学年でトップレベルらしいから、勉強も最初から真剣に取り組めばできたんだろう(叔父の贔屓目もあるが)。

ただ、入ってしまった学校によって就職先が狭められてしまったように感じていて、希望するような職業には就けなかったらしい。彼の希望としては姉夫婦のような銀行の仕事などをやりたかった様子だが、その道は開かれていないそうだ。就職担当の先生に阻まれてそういうパスは得られないと言っていた。そして、以下のようなことを話してくれた。

  • 「できることなら、高校受験からやり直したい」
  • 「高校受験の時に親がもっと意見してくれたら良かったのに」

姉夫婦はいわゆる放任主義で、僕も姉も放任主義の家庭に育ち、それが概ねいいんだろうと感じている。ただ、甥としてはこの未来が解っているなら止めて欲しかったのだろう。僕からは以下のような投げかけをしてみた。

ms2sato「でも、高校受験の時に勉強はもうしたくないと考えて勉強しなかったのはKだよね?」 
K「うん」
ms2sato「もしもその時に『将来の選択肢が狭まるぞ』と言われたとして、志望校を変えた可能性はある?」
K「たぶん変えなかったと思う」

ということなので、やり直しても結果が変わらないことは明らかなのだ。他にも色々と話はしたけれど「過去には戻れないのだから、この後どうするか考えて『今から』やろうよ」という話をして終わった。あと、プログラミングの話はチラッとして「もしも興味があってやるんだったら僕に相談してくれれば良い」と伝えておいた。

考えたこと

親があれこれ指図してレールを敷いてしまうことはあまり良いことではないと思っているのだけれど、今回のようなケースもあるので、どうすべきなのかとても難しいと思った。強制しないまでも一緒に色々と考えを巡らして悩んでおくのは大事なことなのかもしれない。きっと両親と相談して様々なことを考えた過去があれば、Kの後悔は発生しないのではないかと感じたから。

f:id:ms2sato:20200119230815j:plain

ボヤッとした目標を達成可能なところに落としこむ手法

f:id:ms2sato:20200103232723j:plain

はじめに

新年なので新しく目標を立てようと考えている方、多いのでは無いでしょうか。ただ、漠然と宣言するだけだとなかなか達成が難しいと思います。せっかくなので、目標の具体化とか達成しやすい整理などを一緒に考えられると良いな、という感じのエントリーです。

ちなみに「昨年本を20冊読んだから、今年は30冊読む」のような定量的な目標を量を増やしながら達成している方よりも「そもそも何すると良いんかな」と迷ってしまう人向けです。

ぼやっとしている内容から「よしこれをやるぞ!」までのブレークダウンのようなエントリーです。

達成したい大まかな方針を決める(ぼやっとした希望)

おそらく様々な目標はあれど、単なる欲望の発露でない限りは「理想と現実のギャップ」がそこに存在していると思います。つまり「問題があって、解決したい」というようなことが多いのではないでしょうか。例えばよくあるようなことだと以下のようなものですかね?

  • シェイプアップする(体が弛んでいる)
  • 恋人を作る(恋人がいない)
  • 仕事で活躍できるようになる(今活躍できていない)

ちなみに「シェイプアップしたい理由が、恋人を作りたいから魅力的な自分になりたい」みたいなこともあると思うので、その場合には頭の中で最終目標としてのイメージはあると良いと思います。とは言えあまり考え過ぎるとと進まないと思うので、そこそこぼんやりでも大丈夫です。必要なのはあくまでも方針(どのような方向に自分を高めたいか)でしょう。

大まかな方針を要素に分解する

例えば「仕事で活躍できるようになる」と方針を決めたとして、仕事で活躍できるにはいくつもの要素があるとわかります。仮にプログラマーであれば以下のような感じに進めていけるかもしれません。

こういうことするのに マインドマップを使う人は多そうですね。ツールを利用する方がやりやすい場合にはそういうものを使うのも手です。まぁ、単なるまとめかたの問題でもあるので、箇条書きをインデントしていくだけでも十分だったりします。

「何か綺麗にまとめないといけないのではないか」という心理に駆られてしまうタイプの人は一旦そういうことを置いといて「出してみること自体に価値がある」と考えてくれると良いのではと思います。まずはドバーッと出してしまって、あとで整理すれば良いでしょう。大切なのは出力された内容そのものであって、整理されているかどうかはその次です。

  • コードを書くのが遅い
  • コードにバグが多い
  • レビューで突き返しが多い
  • 仕様の理解不足で間違ったものを作ってしまった
  • 「なぜ早く相談しなかった?」といつも言われている
  • もっと大きな機能を実現できるようになれないといけない
  • 人の話からどういう機能が必要か提案できるようになりたい
  • 相手が理解しやすいように説明することができない
  • 同じ失敗を何度も繰り返してしまう
  • 関数の名前がいつも適切にできない

もしかしたらネガティブなことが出まくって多少憂鬱になってしまうかもしれませんが、気にせず沢山出してみるのが良いです。一人ブレストです。「振り返り」をしている人などは以前の振り返りを参考にしたりすると良さそうですね。ちなみに私がどちらかと言うと課題に気付きやすい人間だからか、上記がネガティブな表現になっていますが、「仕事で活躍できるようになる」という要素の分解だと「コードを書くのがはやい」というような、ポジティブな表現で結果が表現される人もいるでしょう。どちらでも大丈夫で表裏一体だと思っていただければ良いかと。

分解したものを整理し、気づいたものを追加する

  • 開発についてのポイント
    • コード自体について
      • コードが仕上がるのが遅い
        • コードを書くのが遅い
        • レビューで突き返しが多い
          • コードにバグが多い
          • 関数の名前がいつも適切にできない
    • もっと大きな機能を実現できるようになれないといけない
    • 人の話からどういう機能が必要か提案できるようになりたい
  • コミュニケーションについてのポイント
    • 仕様の理解不足で間違ったものを作ってしまった
    • 「なぜ早く相談しなかった?」といつも言われている
    • 相手が理解しやすいように説明することができない
  • 全般的なもの
    • 同じ失敗を何度も繰り返してしまう

少し整理してみました。数を出している時は内容の粒度がバラバラなので、うまく原因と結果を意識できるとやりやすそうです。例えば「コードを書くのが遅い」と「レビューで突き返しが多い」は結果的にコードが完成するまでに時間がかかることなので新たに「コードが仕上がるのが遅い」とまとめています。

こうやっていくと、新たに気づいたりもします。追加したり整理したりしましょう。

  • 開発についてのポイント
    • コード自体について
      • コードが仕上がるのが遅い
        • コードを書くのが遅い
          • どこを変更したら良いのか考え込んでしまう
          • 既存のコードの把握に時間がかかる ★1
        • レビューで突き返しが多い
          • コードにバグが多い
            • 既存のコードの影響している範囲が掴めていない ★1
            • 動作確認が足りていない
          • 関数の名前がいつも適切にできない
            • 「良い名前」のストックが無いからでは? ★1
    • もっと大きな機能を実現できるようになれないといけない
    • 人の話からどういう機能が必要か提案できるようになりたい
  • コミュニケーションについてのポイント
    • 仕様の理解不足で間違ったものを作ってしまった
      • 一旦自分の理解を誰かに確認すればよかった? ★2
    • 「なぜ早く相談しなかった?」といつも言われている
      • エラーで動かないことで頭に血が上っていて声をかけられない ★2
    • 相手が理解しやすいように説明することができない
      • 緊張してうまく話せない ★2
  • 全般的なもの
    • 同じ失敗を何度も繰り返してしまう ★3

星をつけてみたのは、比較的大事なことで、どうやら同じような根っこでは無いかと思われるものです。

  • ★1 は「ソースコードが読めていなかったり、内容把握ができていない」という事
  • ★2は「誰かに話しかければ良いところを、(おそらく上手に話せないために)端折ってしまって失敗している」という事
  • ★3「同じ失敗を何度も繰り返してしまう」は結構クリティカルなのでどうにかしたいですね。"改善できない"という事になりますし。

この例の人の場合には、ソースコードの読み力を上げることはかなりの効果がありそうであるし、もう少し人に気楽に話せる状態になることは大事そうです。また、そもそも何度も同じ失敗を繰り返すというのは改善を阻むのでどうにかしたいですね。

アクションを見つけて、期限を決める

ポイントは見えてきたのでそれぞれ改善を考えたいですが、長くなりそうなので少し巻きます。★1 は見えやすいので掘り下げてみましょう。

  • 先輩にこの課題点を相談してみる
    • いきなり対面だと難しそうなので文書でまとめた上で1on1で聞く
  • ソースコードを読む事について何か良い書籍が無いか探す
  • 社内の勉強会のテーマにできないか提案してみる(先輩たちはどうしているの?)
  • 実際の仕事の時に、コードを読む時間を適切に確保する。読みが浅そうな時は...どうしよう
    • 一旦先輩に相談してみる?

適切なアドバイスくれそうな人に整理して意見を求めたりするのは結構有効なので(特に同じような経験を乗り越えている人なら尚良し)、相談できそうなものは相談してみるアクションになりました。

ここまで落とし込めば、意味のある目標が見出せそうです。仮に先輩と相談するようなワンクッションを挟んで、色よい返事がもらえたりすれば以下のような具体的な形に落とせるかもしれません。協力を仰ぐのが難しいケースなら自分だけでできることに落とし込みましょう。

  • ソースコードの読み力向上に役立ちそうな本を5月までに2冊読む(実際どの本が良いのか私はわからないのだけども、それを探すこともこの場合目標の一つかもしれません。良い本あったら私も知りたい)
  • 社内勉強会で自分が弱点に感じていることをテーマに勉強会が開けないか、相談して実現する(4月までには一回やる)

こんな感じでしょうか。最終的には「いつまでに、何を」まで落とし込むの大事です。あまり年間トータルのような長期にこだわると「いつでもやれる」という心理になって進まないので、もし年単位の長期になっても月間◯回とか刻んでチェックできるポイントを作る方が良いと思います。上記の例はまず最低限のステップを進み、それからもう一度目標を立てるイメージで出してみました。

おしまいに

達成できずに終わってしまいそうなぼんやりした目標を、小さなアクションに落とし込むことで一歩ずつ進められるような内容に落とし込む過程を文章にしてみました。皆さんの新年の目標立ての参考になれば幸いです。

[PR] 新年の目標に「プログラマーとして転職する」というような内容を掲げた方、目標を達成するにあたり先輩たちに相談したいことありませんか?また「実際にどのような仕事になるのか」とか「転職する際にやってみた方が良い事」など先輩に聞いてみたりしたくないですか?なんと、ちょうど良いイベントを1/25に行うのでチェックしてみてください。

ms2sato.circlearound.co.jp

「生殺与奪を握られている」という錯覚に気づくこと

f:id:ms2sato:20191231151112j:plain

はじめに

年末なので、いつもの友人Sと飲んでいた時の話より。

ms2sato.circlearound.co.jp

前回彼に聞いた「美味いフグを食べながら熱燗飲むとメッチャ美味い」という話を受けて、フグをまともに食べたことない私にその気分を味あわせてくれる為のフグ忘年会を行うことになった。

店に入って席に着くなり「ちょっと報告があって。来年から中国にゆくことになった。」と。

雇われている時に持ってしまう「下手にコトを起こせない」という心理

聞くとどうやら中国で新たに事業立ち上げをするメンバーに選ばれたらしい。3年程、嫁と子供を置いて単身赴任だそうな。

S曰く「転職もしようかとも思ったんだけどね」 前回夏頃に会話した時になんとなく仕事に関して全力投球ではない感を感じていたが、そういう中での話なら転職を選びそうなものではないか。

「なんとなく『ここまでしてダメなら』というところまで付き合ってみようかなと思ってね。今の現場と環境を変えらえるならそれもいいと思ったんだよ。」

そういうものか。自分とは違う判断基準を持っているのだろうなと思うし、ヤツもそう思われていることは気づいているだろう。

色々聞いている中で 「嫁と色々と話してたら『予想通りいかないことがあっても私も働くし、好きに選択したらいいよ』という話があって、なんか吹っ切れた」 という言葉からSはいい人を嫁にしたんだなと感じたし、それは素直に伝えておいた。彼の表現を借りるなら「運命共同体なので、親兄弟よりも信頼が強い」とのことだった。

そんなことがあってから、彼自身も言いたい事を発言するような事を上司なり周囲にできているとも聞いた。なるほど。そういう効果もあるんだな。つまり「別に辞めてもいいや。辞めても最悪の事態にはならない。」という心理になったんだろう。

この感覚は、自分が若い頃に仕事をしながら持っていた感覚に似ている。もともと社員という形で社会に出なかったからか「別にこの場所でうまくいかなかったとしても、元に戻るだけだ。だったら我慢ばかりする必要はない。」という心理。それがある種の思い切りの良さにもなるし、自分の軸を維持して行動できる原動力の一つだったと思う。

それと同じ感覚に、彼は嫁さんの言葉からたどり着いたんだなと、二人で合点した。

Sは「自分は成長が遅かったな」と言っていたが、こういう感覚は大勢と同じ流れに乗っている時には気づきにくいものではなかろうか。単純に気づける経験が目の前にあったかどうかだと思う。それに、彼が手に入れた今の経験値と成長は、今の家庭丸ごとひっくるめて出来上がっているのだから、ただの強がりから始まっている私のそれよりも余程強固に感じられた。

あんまり家庭を羨んだりしないのだが、彼と彼の嫁の関係はちょっと良いなと思ったりしている。

会社の生殺与奪と自立する社員について

会社がその権力を強くする一つの方法は「お前とお前の家族の生活は会社が握っており、そこから離れては生きていけない」と錯覚させることだ。実はそれは錯覚でしかないのだけれど、実際に会社から離れたことのない人には途方もなく大きな後ろ盾を失うような気がしてしまうのではないだろうか。この圧力によって「言いたい事を言えない、言わない」という状態を作ってしまう。実はそれは全体から見るとリスクなのだ。

そうでない形を目指すには「会社に依存するのではなく、自立した社会人として自分は外(別の会社や個人事業でもなんでも)でも仕事ができる」という事を名実ともに実現する事なのだろう。自分は元々会社組織が好きではないので、できればメンバーが個として独立できるレベルの能力を持った上で一緒に働けることを目指していきたい。

昨年、今年と新しいメンバーを迎えたけれど、最初の一年で目指しているのは彼らが「フリーランスしたい」と思った時にできる程度の技術力と人間的能力を身に付ける事だ*1。それは経営としてはリスクになるのだろうけれど、メンバー全員の幸せが大きくなる方へ舵を切るならこの方針で間違っていないはず。

もしも個人で活躍できるようになった途端に出て行ってしまうなら、そういうものだと割り切るしか無いだろう。そういう一時的な拠り所としての価値しか認められていない会社を省みる必要がある。私もまだまだ道半ばだと思わざるを得ない。

おしまいに

学びの多い場だったので、記しておきたいと思ったポイントを置いといた。未来の自分が読み返して思い出せる程度は書けているはず。

とりあえずふぐ刺しの実績解除をできたのだが、熱燗と一緒に食べると確かに美味だった。こうやって経済レベルが下げられなくなりそうな自分が怖い。

[PR] 直近のイベント

主にプログラマーとして転職したい方向けに先輩エンジニアの経験談や今だから思うことを色々聞けるイベントやりますよ! techdrive.connpass.com

*1:もちろんフリーランスはそれだけあればできるものでは無いが、最低限持つべきものはあると思う

プログラマーの現場経験1年くらいの人に就活〜現場の仕事まで聞いてみませんか?

「プログラミングを仕事にしたい!」と思っている方や既に行動始めた方に向けて、弊社メンバーが企画したイベントが来年開催されます!あまり色々聞けないこともクローズドなイベントでツッコンで聞いてみると、あなたの欲しい情報が手に入る筈ですよ。

techdrive.connpass.com

就活前や就活中、以下のような不安ってあったりしませんか?

  • 仮に実際に就職できたとして、どんな働き方になっていくのかのイメージがわからない
  • 就職したいならどういうアプローチがあるのか
  • 就職を目指した時にやったほうが良い事があるなら知りたい

こういうことを色々な切り口から会話できるような場所を用意しました。大きく2パートにしています。どちらも時間の余裕を多めにとって、疑問を余す事なく聞きだせるような場づくりです。

  1. 登壇した方ご本人の目線からの自由なプレゼンを聞いた上での質疑応答
  2. 緩めの懇親会で抱えている疑問をジックリ聞く

登壇者については弊社の個別トレーニング受けた人になってしまっているので以下のような雰囲気です。多少のバイアスがある事はご理解くださいませ。

  • システム開発の受託、スタートアップ/自社サービスはバランス良い
  • 言語はRuby中心。お一人がiOSでSwift。

世間では様々なことがTwitterに流れてきたりするので「確からしいことがよくわからない」という方は多いと思います。生に近い最新の情報に触れることできっとあなたのお役に立てるはずです。

techdrive.connpass.com

「俺はお前のママじゃ無い」をカッコよく言おうと思ったら「自己管理型」という言葉が近いらしい

f:id:ms2sato:20190722174503j:plain

はじめに

自分なりにやっていることや考えていることについてうまい名詞があると他人に伝えやすくなると思います。 最近社内で伝えていたことに近い言葉が無いか探してみたら、少し前に目にした「自己管理型」という言葉が近そうだったのでメモしておきます。 ただ、実際にはチーム全体の自主性を考えた言葉の様子なので、私の思うそれとは若干違うのかもしれません。

私の考え方

  • 自分のタスクの管理は自分でできること
  • 気づいたことや問題と思うことを個々のタスクの中で感じたら、早めにまとめ役に相談して良いこと(勝手に忖度して引っ込めずに積極的に相談して良い)
  • 情報の流れはトップダウンよりもボトムアップの方が活発

なんとなく過去私が知っていた組織のパターンだとあまり上記の感じになっておらず、まとめ役がいちいち確認しているような気がします(ポーリングっぽい感じ)。そのタイミングを定例的にするか都度にするかはわかりませんが、全体像はまとめ役だけが理解しており、その人の手足を延長するような形でそれぞれのメンバーが存在しているイメージです。

求めるのはもう少し勝手に動いてくれるもので、手足が伸びたと言うよりも、良きに計らってくれて信頼が高いイメージでしょうか。放っておいても自分で管理してくれる雰囲気です。

その為の条件の一つは「自己のタスク管理を個人で行える」ということです。以前タスクの抜け漏れが多いメンバーによく言ってたのは「俺はお前のママじゃ無い」的な話でした。タスクの抜け漏れ自体はツールを上手に使うだけでかなり改善できるもので、「基本的にタスクが抜けるもの」という観点のチームと「基本的にタスクが抜けないもの」という観点で進められるチームでは信頼感がまるで違うと思っています*1

ところで「俺はお前のママじゃ無い」は、表現としてはわかりやすいものの、あまりカッコよく無いですね。

世間の内容を少し調べてみた

www.infoq.com

自己組織化について論じている文章ですがここで言う 自己管理型チーム という言葉は私の理想と近そうです。「誰に責務を与えるか」は私が決めていますが、最終的に「どのように進めるか」はアサインされた人によって決められていくイメージですね。もっと上の権限を与えていくのも良いのかもしれませんが、メンバーの報酬や獲得して欲しい経験は私が握っていることが多いので、「自己管理していて欲しい」ということに集約されるのでしょう。

結果として期待していること。実際に起こること

以下のような感じですかね。

  • 「順調」という報告よりも「問題の相談」や「不安点の確認」のような 現在や未来のスムーズな進捗を確保する ための行動が増える。
  • 問題があれば勝手に相談くれるため、基本的にはこちらから義務感を持って話しかけなくともよくなる*2
  • まとめ役側のコストの低下

気をつけている事

物事よくわかっている人ほど「まとめ役の時間が貴重だからあまり話しかけてはいけない」と思ってくださるので積極的に話してくれなかったりしますが、個人的にはどんどん聞いて良いと思っています。問題や不安は前提知識が適切に伝わっていない場合にもよく起こりますし、必要な情報が揃っていないサインとも思います。この辺りを「まぁ、いっか」と放置したり「時間を奪う」と忖度した結果、あとでより大きな課題になって返ってくる事が多いのでは無いでしょうか。とりあえず相談しやすい空気をこちらが作り続けるのは結構大事ですよね。ちなみに自分の場合

  • 相談されたら出来るだけすぐ聞く。できない時は「xx分後」などと発信してこちらからアクションする。
  • 伝わっていなかった何かがあっても極端に不機嫌にならない。伝えたことを取りこぼしている様子ならこぼさない工夫を一緒に模索する。
  • 基本的にポジティブに聞く。問題や不安を増大させずに解消する方向へ舵を切る。

おしまいに

あんまりまとまってませんが「そんな感じに日々考えていますよ」ってことで。

*1:最終的に自身に合うツールや管理方法を確立してくれたので、件のメンバーのタスク抜けはとても減り、信頼できるようになりました

*2:私は無駄に話しかける時もそこそこあるんでついでに教えてもらえたりしますが

「フリーランスになればリモートワークができる」チョット待って!

f:id:ms2sato:20190516174404j:plain

はじめに

Twitter見てたら流れてきた話に反応します。 「『フリーランスになればリモートワークができる』という言葉、解釈が複数あるので気をつけてください」という話です。伝え方によってミスリードを起こすことができます。

私はプログラマについてしかよくわからないのでその観点で読んでください。あと、法律の専門家ではないので何か間違ってたらそっと教えてくれると、とっても嬉しいです。

前提の契約形態の知識(知ってる人は飛ばしてください)

前提となったTwitterの話題では契約の話も触れられてたのでちょっとおさらい。 フリーランスは「業務委託契約を結ぶ個人事業主」とさせてください(他にあるかは知りませんがこの辺りが崩れると事情が変わるかもしれません)。

契約でよくある形式は以下2つかと。まとめて業務委託契約と言ったりします。中身としては以下二つのどちらかを指しているはずです。私は専門家ではないですが、これくらいがポイントだと思えばいいかと。また、契約の形態に特徴はあっても優劣は有りません。そして契約なのでもしも不利だと思うのであればフリーランスなら自分で交渉しましょう。

請負契約

  • 「〇〇な仕様のものをいつまでに納品」というような「いつまでに、何を」を約束します。
  • 多くは全部完成して納品し、検収(お客様の確認)が終わったら請求書を書いてお金をいただきます。
  • 通常瑕疵担保責任が発生します。例えば「一年以内に不具合(仕様と合致しない事を不具合とする)が発生した場合には無償で修正する」など。

準委任契約

  • 「現場の指示に従って技術力を提供します」というような、時間貸しのような約束です。具体的な作業の内容は現場に任せられます。
  • 月や日、時間など稼働の単位を決めて、例えば月末などに「今月は◯時間働いたからおいくら万円」のような請求書を書いてお金をいただきます。
  • 通常瑕疵担保責任が発生しません。あくまで技術力を指示通りに提供した事で契約は満たしています。

※注意

契約書の分類は通例このような形であると言えるけれども、その内容は書かれている文章によって変わります。上記は分類としてはそういう形であると理解したほうがいいです*1

契約の形式と、労働の環境は別物です

「どの契約をすれば、リモートワークができますか?」と聞かれたら、どれでもできますし、どれでもできない可能性がありえます。書類の内容にどこで作業するかが明記されていればその場所に必ず縛られますし、書かれていなければお互いの相談によって決めることになるでしょう。

つまり「フリーランスになれば(必ず)リモートワークができる」というようなことではなく「フリーランスになれば(契約の内容次第で)リモートワークができる」ということです。どういう文脈で相手が言葉を発しているかにもよりますが、括弧に表現した部分について都合の良い解釈をしないように注意が必要です。

「そもそも、フリーランスにならなければリモートワークできないの?」

端的に言えば会社次第です。皆さんもよくご存知かとは思いますが、最近では「働き方改革」の風潮もあり会社が副業やリモートワークを実現することも増えていると思います。「フリーランスにならなければリモートワークはできない」と決めつけるのは早計です。

「リモートワークできる契約をしたいんだけど」

契約書を取り交わしたり、更新する際にご相談されるのが順当かと思います。ただ、私の観点だと以下のようなポイントはあります。

  • 「リモートでも成果量が下がらないだろう」というある程度の確からしさがあること。もしくは下がっても受け入れられる現場であること。
  • リモートではテキストコミュニケーション中心になりがちですが、この辺りが苦手ではないと推察できること。
  • 対面で確認ができない状況でも、ゴールを間違えないようなコミュニケーションを取る力量があると推察できること。

「請負で契約すれば」と思うかもしれませんが、世間でよく言われることに「フリーランスはすぐ逃げる」という事があります。都合が悪くなるといなくなってしまうフリーランスはよくいる様子です(私の知り合いにはそういう方はいないのでよくわかりませんが、経営者の方と話をするとそこそこあるようです)。請負で期限ギリギリに連絡が取れなくなってしまうようなことになれば事業としては痛手なので、ただ請負にすれば良いというものでもありませんよね。

結果的にリモートワークできるような立場を手に入れるには「仕事をある程度うまく進めるだけの仕事調整力やプログラミング力などの力量があること」というのはかなり確からしいことだと思います。

「業務未経験です。リモートワークしたいです。」

先述のようなポイントを抑えていると証明できる何かがあればできるかもしれませんが、ほとんどの方にはそれができないような気がします。よほどの幸運がなければ難しいのではないでしょうか。最初に一定の期間対面の時間を作りながら信頼を作ってリモートをいれていく人はいそうです。

私のプロジェクトでよく発生するリモートワークは GitHub-Flowを使い、Issue単位で仕事をこなしてもらう形& 時給時間単価での準委任契約です。プログラマとしてチームに参加するならこの辺りができると良いかもしれません*2

おしまいに

日本語難しいので、複数の解釈の余地があるようなことは丁寧に確認すべきかと。また、誰か一人が言っていることだけを盲信するのではなく、世間一般ではどうなのか、などの情報を自分から集めにゆくのは大切なことかと思います。特にフリーランスになるような方なら自分で自分を守らなければ。誰かが守ってくれるというような立場では無いですよね。

*1:例えば契約書を取り交わした後にE-mailなどで別の内容を取り交わして内容を上書きすることもできます。詳しいことは調べてみてください

*2:弊社のトレーニングはこの形式を基礎に作っているので、十分訓練した人は私たちのチームでうまく組めるだろうと考えています。いつも自社の宣伝をねじ込んでいくのは仕様です