島までは遠い

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

「状況に合わせて適切に情報が流れるのが良い組織ではないか」という仮説

f:id:ms2sato:20190411141726j:plain

はじめに

長すぎたのでブログ化

組織化について

基本的に組織化されている状態について多くの人が思い浮かべるだろう表現を書いてみると「トップからの情報がツリー状に伝達されることで効果的に末端まで行き渡るさま」だと思う。これはいわゆるトップダウンという山型の組織である理由だろうとも感じる。

表現を変えると「トップの意思の素早い全体反映に特化した情報伝達の形態」とも言えるかもしれない。

ただ、これについて多少のイメージの違いがあり「末端で起きていることの中枢への伝達」についても考えるべきではないか、というのが私の仮説である。

人体を参考に表現する

基本的に私たちは大脳で考え、行動している。頭で考えたことが手足に伝わり、体を動かしている。これは通常時の体にとってはごくごく当たり前の事だろう。

逆に通常ではない状況を考えてみる。たとえば熱したヤカンに触れてしまった時、たとえば尖がった針が指に刺さった時、危機的な状況があると体は大脳に情報が完全に届く前に反射を始める。それと意識する前に指を引っ込めるはずだ。

前者はトップダウンで大脳から情報が伝わっているが、後者は大脳での意識の前に小脳などで判断し行動している。危機的状況への対応とはこのようにショートカットして起こるべきなのかもしれない。

組織に戻してみる

これを実際の組織に置き換えると、順序を通り越して一気に判断まで持っていくことが必要ではなかろうか。その際「通常伝わってくる山型の経路をショートカットして直接判断できる存在まで伝達する」べきかもしれない。

私自身の場合だと、経営や営業からコードを書くところまである程度把握しているので*1、コードを書く現場で起きていることも自分の判断が行える。針が刺さったところを見せて貰えれば「どうしておけば良いか」ある程度責任を持って判断できると思う。

このような感じに2-3ステップすっ飛ばして「責任を持って瞬間的に判断できる」存在まで情報を伝えてしまうのは大事な気がする。特に何か問題が起きた時に「そのレイヤーではどうしようもないかも知れないが、他の人なら十分調整できる」という事は多数ある為だ。わかりやすい例を挙げれば「開発が遅れているけれども、営業が顧客と相談すれば期日を伸ばせるので、開発が残業地獄にならなくても済む」というような事がよくあるという事。

弊社について振り返る

今のところ自分は大脳と小脳を兼ねているので、基本的に会社の隅々まで意識を行き渡らせようとしている。以下のような事はそういう自分の感覚の発露でもありそうだと振り返って感じた。小脳としては指先が傷ついたりしていないかを常に確認したいのだ。

  • 必要そうな時に気軽に声かけしてもらうように*2して、なるべく早くその人と直接会話する。
  • 自分が帰るのは他のメンバーより早い事が多いが、出ていく際にデスクを回って声かけをしている。
  • なるべくメンバー全員が昼食を一緒にとるようにしていて、雰囲気が感じられるようにする。
  • オフィスで過ごしている際に自然に雑談している(これは意識していないので単純にキャラクターの問題だけれど、プラスに働いていると思う)。

どこかで小脳的な存在にバトンタッチする必要は感じていて、どのようにシフトしていくのかは課題でもある。

(おまけ)今後のことを考えてみる

人数が増えて、並行して進むプロジェクトが増え、書かれるコードが増えると、私の能力が会社のボトルネックになってしまうと感じ始めた。

実際最近コードレビューをメンバー相互にやって良い形に移譲したりしている。これはこれで正直不安な事もあって「どんなコードが書かれているかを自分が保証しているから自信が持てている」状態を捨てなければならないから。

多分「プロジェクトに責任を持つ存在がコードについても保証できる人である」というのは至極理想的な状態で、それを崩すのは本当は良い形では無いのだろう。弊社の扱うプロジェクトは規模が比較的小さいのだから、理想的な形を追っても行けるのでは無いかと思っている。まだまだ工夫の余地があるのだ。

今後今までよりももう少し人数規模が大きくなる想定で進んでいるので、私の今の仕事をうまく別の人に移譲するのは大事な事だけれど、スムーズなやり方を模索しないといけない。

こういうポジティブな悩みが発生しているのは良い傾向でもあるので、向き合ってうまく着地させたい。

*1:最近怪しくなってきてて課題の一つではあるが

*2:これ自体も色々と工夫が必要そうだけれど

一号社員齋藤の門出に向けて。もしくは最初の社員を雇う時に起きたこと。

f:id:ms2sato:20190323155727j:plain

はじめに

先週の3月15日に、いくつかの節目がありました。それについて記しておこうかと。 同日に短時間正社員だったメンバーががフルタイムになったり、契約社員だったメンバーが正社員になったりしています。何より大きいのは一号社員齋藤のサークルアラウンド卒業でした。

少し彼と私のことを残しておこうと思います。

出会い

実は入社かなり前から彼とは面識があり、もともと私の教え子でした。弊社の第3期は一人株式会社で、私はプログラミングの非常勤講師として外部の学校で教えていた時期があります。

ある日学校主催で海近くの施設でイベントがあると誘いを受けて参加したところ、そのイベントの中で出会ったのが齋藤でした。ちょっと色々とあって砂浜へ行くことになったのですが、私と齋藤が海岸のレジャーシートで荷物番をしながら酒を飲む、という構図になっていました。真夏の海辺で周囲はチャラい色黒のイケメンやギャルがいる中、青っ白い我々が飲みながら話している、という変わった状況です。

当時彼は就活を控えて今後の人生に悩んでいて、そんな話を聞かせてくれました。私としてはいくつか話をしたような気がしますが特に強く伝えていたのが「若い頃は全力投球したいと思えることにできるだけ取り組み、少し歳を重ねてから効率よく生きることを考えたら良いのではないか」という話です。全力投球の回数が成長に繋がると考えているので、若いうちからあまり「うまい生き方」を意識してしまうのは成長を止めてしまうのではないかという論旨でした。

その時はなにか判断のきっかけになるものが生まれればいいなという感じでおわりました。

JavaScriptゼミ

当時の私はJavaScriptにご執心だったため、学校の方でもJavaScriptの専門家として色々と教えていました。ゼミという企画を始めることになり、「佐藤ゼミを持って良い」という話が持ち上がりました。受ける人は学校側で選んでくださるということで、4人ほどの受講生がおり、その中の一人に齋藤も混じっていました。ちなみにこの時の受講生は優秀な2人と、まだまだこれからの2人くらいの構成で、齋藤はまだまだこれから組と私の中でイメージされていました*1

半年の期間で毎月私の講義があり、その間はSlackとgitでオンラインフォローをしていくという形式で進めました。講義の際には「プロとしてプログラミングをする私たちの心理」が理解できるような切羽詰まった課題を出したり、JavaScriptの特徴的な機能を講義形式で伝えて、それに即した課題を解いてもらうなど、かなり実践的かつ「手を動かす」ことを中心の私好みの形で運営したのを覚えています。

この年の最後に、非公式で私たちの卒業制作発表会を行いました。また、私の用意したいくつかの尺度からアンケートを行って「年間MVP」を決めたのですが、齋藤はそのMVPを獲得したのです。単純に能力が高いかということでは無くて、どれくらいの努力をして、結果成長が見えたかなどの切り口も用意していた事もありますが、少なくとも自分で簡単なシステムを作成することができるレベルまで到達できたことは大きな前進だったと思います。

のちに齋藤とこの時の話をした時には 「PHPを勉強してみてあまりプログラミングはできないなと思っていて、JavaScriptゼミで無理だったらプログラミングは諦めようと思っていた」 と語っています。確かに当初コードに関する勘はまだまだ無く、調べながら必死についてきている感じでした。

その晩の打ち上げ飲み会で私が 「ここのメンバーだったら困ったら相談くれればうちで面倒見てもいい」 的なことを口走ったらしいですが、当の私はスコーンと忘れていたんです。ダメな大人です。

入社のご提案

ゼミが終わってから数ヶ月して(ちょっとこのへん私の時間感覚が曖昧です)。「相談したいことがあるから時間欲しい」と呼び出されたので、新宿の居酒屋で飯を食べることになりました。当初「多分就活の相談で、紹介できる会社とか用意しておけばいいかな?」などと考えていたのですが、ちょっと話の流れが違う様子でまさかの「サークルアラウンド社に入社したい」という話でした。

正直私は面食らいました。とにかくその日は落ち着いて色々と情報を交換しようということにして「一人株式会社である弊社の現状」をとりあえず洗いざらい伝えてみて、そのリスクの高さを理解してもらおうと試みたんです。きっとビビって諦めるだろうと。 フリーランスをやったことある方ならわかると思いますが「一人を面倒見るのが精一杯で、とても他人の面倒など見れない」というのが大抵の一人事業主の実態だと思うんですね。

とりあえず「現状共有したから考えてもらって、二週間くらいしたらまた対面しよう」とその日はお開きにしたのです。ただ、その後のメッセージのやりとりが完全に「入社したら」が暗に枕にある内容ばかりで「あ、ヤバイこいつ本気だ」とまさかの私が追い詰められる展開。

従業員が初めて入社するということ

ここまで本気だと二週間待つまでもなく彼の意志は変わらないでしょう。私も受け入れを真剣に検討すべきです*2。まず弊社の当時の状態で、ある程度彼を受け入れるポジティブなポイントはありました。

  • 直前で私がとにかく受託開発しまくっていて、ある程度のキャッシュの余裕があったこと。一年程度は彼が一円も稼がなくても会社は潰れないと計算できたこと。
  • 受託開発の仕事は継続していたので、仕事がなくて困ることは暫くなさそうなこと。
  • 先のゼミの彼の成長ぶりを考えると、最短半年もあれば彼にある程度お金を稼げるようにしてやれると推察できたこと。

上記を組み合わせると 「最長一年間我慢できれば一人有能なメンバーが手に入るかもしれない。そうすれば会社は潰れない。」 という解に至りました。会社的には受け入れ可能という事ですね。

この準備を持って、2度目の会話は入社意思を確認して受け入れが約束された形です。

次にやったのは「会社に社員を入社させる際に必要なことを調べる」です。それまでの弊社は取締役がいたことはありましたが、従業員という存在がいたことはなかったのです。そして会社に社員を入れるには下記のようなことがポイントになる様子でした。

  • 事務所を持っている
  • 年金事務所に登録する(この為に事務所が必須)
  • あと入社前後で色々役所に登録しなきゃいけない(もう忘れました)

当時私はバーチャルオフィスで登記していたので、ちゃんとした事務所はありません。年金事務所に電話すると「どうしてもシッカリした事務所がなければ年金の登録は不可能」の一点張り。当時自宅が事務所にできない事情があった私としては、なにがしかの形で事務所が必要になりそうです。

この後色々とあって、最終的に高田馬場にある CASE Shinjukuさん のシェアオフィスに入ることを決めました。

2015年4月 入社以後

彼と私がCASE Shinjukuさんのシェアオフィスで一緒に活動を始めたのがここからです。 日中はシェアオフィスでもコワーキングスペースでも自由に使えるという事で、私たちはその日の気分で居場所を変えていました。とりあえず「先生」と私のことを呼んでしまうのを直してもらったり、Rubyを勉強してRailsチュートリアルなどやってもらったりしていました。git/GitHubを学んだ時にはそのまま勉強会を開いて成功体験を作ったり、女子の大学生をインターンで連れてきて教える練習をさせたり、私としては「辞めてしまわないように必死(でも必死さは出さない)」のような時間が続いていました。

想定通り半年もすればある程度書けるようになり、私の仕事の裏側で彼がコードを書いている状態も作ることができ、お客さんに半人前としてではありますが、認知してもらえるようになりました。初年度の年末には業務委託の方と一緒にシステムを仕上げて引き渡すところまではいけて、計画通りに成長を達成できたことになります。

私としてはそういう流れを後押ししつつ自分でもコードを書きつつ、会社の次のステップを探っていたりしました。結論として「資金調達がある程度必要」と考えました。たとえ売上が暫く立たない時期が来ようとも、彼が路頭に迷わない形を作りたかった為です。私個人はどんな状態でも生きていける自信がありますが、齋藤がそこに達していないのは間違いなく、会社が無くなる事態は避けたいというのが当時の心理です。

幸い CASE Shinjuku さんは事業を後押しすることを積極的にやられているシェアオフィスなので、資金調達に関する軽い相談も受けてくださいました。右も左もわからない私としてはこちらで支えていただいて初期のステークホルダーとの関係の持ち方など多数学ばせていただきました。この結果、金融機関からの資金調達、創業助成金の獲得など、会社の安定のためのキャッシュの獲得を行えたのは大きな幸運でした。

とは言えこの頃私は多くの時間をこれらに費やしたのでヘトヘトでソファに転がっていることも多く「佐藤さん死んじゃうよ?w」と心配されたりもしています。まぁ、必死でしたからね。

2年目以降

だいたい良い感じになったので、Dockerを学んでもらったり、お客さん先に露出していって最終的に私と立場をスイッチしたりとよく活躍してくれました。特に丁寧に真面目に取り組む姿勢から客先の評価がすこぶる高く、今回の退職を期に引き上げになる際には大変惜しんでいただけたそうで、コードを書く腕前もマインドも高い評価をいただけていたと思います。

弊社のトレーニングのトレーナーとしても自身が苦労してプログラミングを学んだこともあってか、初学者の方に寄り添う姿勢が素晴らしく、私よりも低くかがんで目線を合わせられるという「確固たる自分の居場所」を確立していました。彼の丁寧なサポートでコードを書けるようになっていった方が何人もいます。

私から学び取れるものはとことん取っていこうとしていたので、設計に関する勘所や、サーバーサイドのシステムの扱いはかなり継承されたなと思っています。

そして今

懇意にされている方が新規事業を興されるということで、最初に現場を牽引するエンジニアとして声かけをされたと相談を受けました。当初は弊社から業務委託でやれないかも探ってくれてはいた様子ですが、新規事業は片手間でやるようなものではないと私も合点しており、最終的に弊社を出て行く決断となりました。先に副業で次の現場で活動を始めていて、既に2人ほどのメンバーの面倒を見ながら進めているようです*3

私としてはもちろん痛手ではありますが、弊社のメンバーが成長し現場を牽引する立場に至ったことは大きな価値を生めたのだと自分を納得させています。将来リードエンジニアからCTOのような立場になってくれるだろうとも思っています。冒頭にも書いているように、最初から物凄くセンスがあるタイプではなかった彼が、努力の継続によってここまで至ったことは私にとっても誇れる存在です。弊社の文化を最も身につけた存在が、外で新たに文化を広めてくれると思っています。

下記のサービスを今後は盛り立てていくということでした。遠くから応援したいです。

sharekura.com

齋藤への大きな感謝とともにこのエントリを締めくくります。ありがとうございました。

*1:この優秀側にも思い入れのある人物がいたりしますが、それはまた別で語れればと思います

*2:酔った勢いとは言え約束したはずなので、覆すのはなるべくしたくはありませんでした

*3:実力もっとアップさせるのに弊社トレーニングで協力できないか?のような話も出ていたりいます

ITにおける警察と私たちの判断の乖離について

f:id:ms2sato:20190307162305j:plain

はじめに

最近の世間の動きを見ていると、下記のCoinhiveの利用者の逮捕や

tech.nikkeibp.co.jp

nlab.itmedia.co.jp

簡単ないたずらスクリプトのURLを掲示板に貼り付けただけでの補導、家宅捜索などが話題になっています。

japan.zdnet.com

私は法律の専門家では無いですが*1、一ソフトウェア技術者として行き過ぎた判断が行われていないかを危惧しています。

また、この問題を今の私がどのように受け止めて理解しているかを記しておくことは、この先自分自身が振り返った時に大事なポイントになりそうな気もしています。

私の考える3つの課題

A. 被害程度への理解についての課題

これは警察の担当者(令状を出す裁判所も?)が問題の程度を適切に判断していないと推察される為の課題です。

  1. (ブラウザの外で動作する)実行ファイルによるワームで個人情報を抜き出したり、ディスクの内容を破壊したりするような行為
  2. (一定の範囲でユーザーが守られているブラウザ内で動作する)JavaScriptでCPUパワーを利用する行為
  3. (一定の範囲でユーザーが守られているブラウザ内で動作する)JavaScriptで、ポップアップを連続で出す行為

1が最も甚大な被害(破壊行動、個人情報流出を引き起こす犯罪行為)で、3が最も軽微な被害(子供のいたずらレベルと呼んでいい)であると私たちソフトウェア技術者は認識すると思います。どうもこれらの差を適切に認識されていない節があります。1ならまだしも「3で補導される」「3で家宅捜索される」のはどう見ても行き過ぎであると私は考えています。

ここで2に言及しなかったのは次の「犯罪予見性についての課題」に関係するからです。

B. 犯罪予見性についての課題

「過失」という言葉と関係すると思うので、まずそれについて確認させてください。

過失という言葉を噛み砕いて表現すると「違法な結果を予見することができたにもかかわらず、対応を怠った」で良いと思います。

つまり、違法かどうかの判断が行えなければ過失は存在しないはずです。まだ何の判例もない内容について違法性を洞察することが難しいものは無数に存在すると思われます。このような難しいものについて「行為者に犯罪予見性があったに違いない」という判断が行われている節があります。Coinhiveは特にこの傾向が強いのですが、長くなりそうなので付録の方へ譲ります。

程度の差がありますが、以下2点は同じようなことを言っています。ポイントは「犯罪予見性の認識」の有無です。

  • 「一般のソフトウェア技術者でも判断が割れるものについて『犯罪である』との判断が事前に下されており、行為者が認識していた」というような前提で行動していると推察される事
  • 「一般人(ソフトウェア技術者に限らず)が特に犯罪視しないものについて『犯罪である』と行為者が認識していた」との判断が事前に下されている様子に見えること

今回訴訟にまで発展しましたが、有罪の判決が出てはじめて「犯罪である」との正しい認識が発生するはずです。時間軸が噛み合っていない事がわかると思います。

C. 逮捕までのプロセスにおける課題

この課題はこれまでのA、Bどちらかが適切であればおそらく発生しないです。しかしA、Bが適切でない方向へ判断された為「突然の家宅捜索」という形で現れてしまったと考えています。「(よくわからんがこれは重大な)犯罪行為だ!しょっ引け」という事ではないかと推察しています。

このプロセスはあまりに盲目的過ぎると思われます。ソフトウェア技術にある程度詳しい人間であれば、A、Bのような推察は容易にできるはずで「これはまだ強行して進められるレベルのものではない」と発信する事ができたはずです。そういった抑制の仕組みが逮捕までのプロセスに存在しないのは大きな課題だと私は考えています。

私が社会へ願う事

  • 国家権力を持っている側に、現在のソフトウェア技術に関して適切に判断できる素地を持っていただきたいです。
  • 逮捕までに「より適切に判断できる専門家の見解を求める段階を設ける」など誤った方向へ進んでしまわない抑制力を持っていただき、無闇に逮捕しないでいただきたいです。
  • 誤認と認められた際に、行為者とされた方が失った名誉や仕事上の不利益を回復する仕組みを作っていただきたいです。

[長い付録] Coinhiveの違法性の難しさ

Coinhiveがマルウェアであるのか?

おそらく以下の記事などが実情を知るのに良さそうなのでリンク入れておきます。

www.itmedia.co.jp

今回の内容が広がった際にIT技術者の中に様々な見解があったという背景を示しています。海外でのアンケートを抜粋します。

上記のスレッドを追うと、とても興味深い発言を追うことができます。ポイントをいくつか拾って要約しました。論点としていくつもの切り口があると理解できると思います。

  • ユーザーの同意の取り方によって違う
  • 広告とどちらにするか選べる方が良い
  • CPUパワーの利用程度によって見解が異なる
  • マルウェアではあるが、好ましい
  • モバイルでないなら許せるが、モバイルでは動かしたくない

マルウェアとの差異

マルウェアとは|マルウェアの脅威とその対策

マルウェアについて改めて調べてみると、Coinhiveはウィルスやワームの一種であると判断された可能性があります。感染もせず、自己拡散もしないけれども(WEBサイトを閲覧中に背後で動き、閉じれば消えて無くなるため、どちらも行えない)、 CPUリソースを借用する という点です。また、他のマルウェアのように情報の盗み出しを行うものではない為です。

「ユーザの意図に反する、有害な作用を及ぼす」とはどういったことなのか

がやはり焦点になるのでしょう。

広告との差異

そもそもの経緯から考えるとCoinhiveは以下のような課題を解消すると目されていました。広告同様に売上を発生させながら、広告に比べてより優れたユーザー体験を提示できる可能性があるのです。

  1. 現在のWEBサイトは多数の広告に支えらえてビジネスが行われている事が多いです。
  2. 1のため、ユーザーに対して以下のような問題が発生しています。
    • 見たくない広告を見せられる心理的負担
    • (見たくない動画などによって)リソースが利用されるという浪費
  3. Coinhiveを理想的に利用する事ができれば、ユーザーから心理的負担を取り除き、以下の1点だけを受容してもらう事でビジネスが行える可能性がありました。
    • リソースが利用されるという浪費

残念ながらCoinhiveはサービスを終了してしまいましたが「今後同様のサービスが出る可能性についてどのように対応すれば良いのか」という岐路に私たちがいるような気がしてなりません。ひいては「私たちの社会がまだ見ぬ新しい技術についてどのように適応していくべきか」という課題も提示していると思います。

私が想像する事

今後も広告の代わりになる何かを発明した際、きっとCPUやメモリなどのリソースを利用して何かをする事が引き換えに必要になると推察されます。その利用程度をガイドラインとして定めるなどすると、世界が平和になる可能性があります。

例えばブラウザが抑止能力を持ち、広告代替に対しては行き過ぎたリソース消費を抑えるような仕組みが検討できると良いのかもしれません。

海外でも話題に

JavaScriptの作者さんにまで現状が届いていて「日本に来て、専門家として話をするかもしれない」とまで言ってくださっています。

www.itmedia.co.jp

おしまいに

「権力を持っている側は、その力が適切に行使されているか自身を監視する能力も持つべきではないか」と強く感じました。私としては今の見解をここに残す事ができて満足しています。少なくとも10年後、20年後社会がどのように変わったのかの差分をこの件との比較で行えると思うのです。

同時に「私にできることは何だろうか」と引き続き考えてみようと思う次第です。

*1:間違ったこと書いてたらそっと教えてください

KPI項目の安易な決定は危険と思っている話

f:id:ms2sato:20190110005130j:plain

はじめに

年明け一発目ですね。本年もよろしくお願いします。

弊社では私が忘れ去らなければ「通年KPT」というのをやります。毎週週報をKPT形式でSlackに流してもらってコメントしているのですが、年明けくらいは年間の長いスパンでKPTするのも良いだろうという感じです。今年は少し丁寧にやったので

  • 社員個別にそれぞれKPT形式から広げつつ色々聞かせてもらう
  • 社員メンバーと私でチーム全体のKPTを行う

というような大きく分けて二本立て。私の半日使ってしまいましたが、かなりいい場ができたと思っています。*1 その中で数値目標、KPIについて話した内容を残しておきたかったのでブログっておきます。

重要であることは疑いない、けれど安易に決めれば良いものではない

きっかけは「トレーニングの受講生獲得人数など、数値目標を立てたらどうか」という意見が発信されたことです。

おそらく経営の業績にこだわる人は大好きな話ではないかと思うんです。目標たる数値があり、それに向かうための戦略を立てたりされてますよね。ただ私が知っている『よくある結果』を思い返してみると「KPIを導入するならば、どの項目にするのかを多角的に判断した上でなければいけない」ということがあります。

トレーニングでの例

少し考えてみましょうね。

受講生獲得人数

例えばですが「トレーニングの受講生獲得人数を2018年比120%を目指す」などとしそうですね。仮にそう決めたとしましょう。当然ですが目標を決めたなら本気で達成しに行かなければ絵に描いた餅です。そうすると以下のようなことが発生すると思うのです。

「この人、弊社トレーニングを受けるタイミングじゃないな...。」
「でも、ロストすると今月の目標達成が難しくなるなぁ。」
「とりあえずプッシュしてトレーニング始めてもらうようにするか。」

この結果、適切なタイミングではない人がトレーニングを受講してしまいます。途中で続けられなくなってしまったり、そうでなくとも満足度が下がったりなどするはずです。少なくとも満足度低下は2018年よりも確実に増えると推察されます。これでは本末転倒だと思うのですよ。

顧客満足度

では逆に顧客満足度を上げていくことを考えようとすると、すると満足度というのは「期待値」によってずいぶん変わることが壁になります。また、おそらくアンケートをとって集計するかと思いますが、受講した人であれば低い評価は出しにくいバイアスの大きなものであると想像できると思います。

継続期間

大抵の商売であれば、サービスの利用期間は良いサービスの指針として素晴らしい項目だと思います。

ですが、教育サービスにおいては別です。まずシンプルに考えて、短期間で高い技術を身につけられるのに越したことはありません。もしも長い期間受講するということであると、その内訳として考えられることの中には「なかなか成長できない」「受講生が依存して自立できない」のようなネガティブな理由を内包しています。

逆に、月額料金で行なっているので「その期間顧客が与えられている価値に納得してくれている」とも取れます。さてこの数値をどのように評価するのが良いのでしょう。

もちろん「ネガティブな事は起こり得ない」と切って捨てる手もありますが「目標ギリギリ達成させなければ、更新してくれて期間が長くできる」というような事がチラとでも頭によぎるようなKPIなら無い方が良いのでは無いですかね。

少しまとめ

いくつか例を挙げたりしてみましたが、結構難しい気がしませんか?

「数字を追えば良い」というのは物事をシンプルにしてくれるので、迷いなく集中できるための一つの方法であるとは思います。ですが適切な項目を見つけていくのが非常に難しいと私はよく考えます。

受託獲得の営業メンバーがいるような組織だと「どんどん営業が取ってくるけれど現場の手は足らず、常に炎上状態で結果的に仕事が終わっていかない」というような事があったりするのではないでしょうか。獲得するところをKPIにしてしまうとそういう事が起こるのでしょう。

気にしている数値

これまで社内に特に伝えてはいませんでしたが「気にしている数値」は存在すると話しました。それは

「『受講生が目標としていた技能を身につけた』と少なくとも我々と本人が合意できるような状態がどれくらい作れたか」

です。これでも主観や曖昧さが残るものではありますが、例として挙げた他の数値よりは暗黒面に落ちにくく、「できるできない」で測れる比較的曖昧になりにくい数字だと思っています。

本来は売上や利益のゴールを達成する為の数値をKPIとすべきかと思うのですが、今の所はそういう事にはなっていません。ただし「長期的にはこの考え方で発展は得られる」と考えています。

おしまいに

そんな感じで、よく世間で導入されているからと言って安易に決めると危険では?という話でした。

数字を簡単に掛け算すれば結果が出るようなものであればこんなに楽な事は無いですが、そうでないからこそ面白みもある気がします。法則に従えば良いようなものであればすぐ飽きてしまいますからね。

*1:代わりに私が疲労困憊でした(笑)

2018年のPVトップ10へコメントしとく

はじめに

こういうタイミングでしかできないと思うので、年間のアクセスを集計してよく読まれたエントリにコメントしとこうかなと。2019年以降やるのかとかは決めてないしわかりません。

実は公開当時アクセスを稼げなかったものが地味に上位に来たりしていて驚いたりもしてます。その点もちょっと触れておこうかと。

というわけで行ってみよう!順位が現在のページの力とは関係ないと調べたらわかったので雑に上から順ですー。

トップ10

1 プログラミング言語と業界での使われ方の関係こんな感じで合ってます?私目線書いてみます。

ms2sato.circlearound.co.jp

堂々の一位はこちら!公開当日に3418PVを叩き出したエントリです。Twitterでうまく広がってくれた感があります。本年の一位とは言いながら最近のアクセスでは落ち着いているので、もう役目を終えたエントリではあるでしょう。

「どの言語がどのように使われているか」ということに関して、私なりの見解を言語ごとに語っています。

就職のためだとすると何か就職サイトでどの会社がどんな言語で人材募集しているかをリサーチしてみるのは方針を決める一つの情報になるのではないでしょうか。

個人的にはこのアクション推します。自分がやりたい仕事がどういう言語で行われているか知ってから学ぶのでも良いかと思うんですよ。なんでもRailsやれば良いという訳ではないです。

続きのエントリはこちら。

ms2sato.circlearound.co.jp

2 実家のPCデポの解約までの話

ms2sato.circlearound.co.jp

記録のために書いておいたらアクセス稼いでるエントリ。なぜか今年の夏くらいから毎日10PV程度に安定して読まれています。 ちょうど一年前に実家のインターネットをPCデポから解約した話を綴っています。同じような人が参考になれば、というエントリーです。

3 「プログラミングスクールに一ヶ月通ったけど、自分で作れない」という人がいても、諦める必要はないよ、という話

ms2sato.circlearound.co.jp

公開当初に結構読んでいただけた様子です。今でもたまにアクセスがあるので嬉しい限り。 スクールの宣伝文句を信じてしまっていると、1ヶ月で自分で作れないことについて落胆してしまうケースがありますが、プログラミングは1ヶ月でサラサラできるようになるものではないので諦めずに続けて欲しい、という内容でした。

背景にはスクールの宣伝文句が実情を表していない、というのがありますね。今年そういう話題も出ていました。

4 「ITエンジニアは人手不足だから、スキルが無くても問題ない」の嘘

ms2sato.circlearound.co.jp

公開当初は鳴かず飛ばずだったんですが*1、10月くらいから毎日10PV強でアクセスされています。Googleの検索でいいところに入っているようですね。

「人手不足でスキルが無くても入れる現場は、スキルが望まれない場所なので成長もできないですし、将来がないですよ」という話。

5 「未経験からプログラミングを学んで就職するには」で一つのアプローチを整理してみました

ms2sato.circlearound.co.jp

個人的には長期的に読まれて欲しいエントリなのですが、最近はあまり読まれていない様子ですね。現在って史上最高の数で「プログラマー予備軍」が多い時代だと思います。数が増えたということは玉石混交になっていて、そこから抜け出すための何かが必要ですよね、という話です。

結構具体的に書いてあるので参考にして欲しいのだけども。

6 「人は激務を経なければ大きな成長をしない」に対する意見。もしくは不連続な成長をする方法。

ms2sato.circlearound.co.jp

珍しくはてブを稼いでたエントリ。私は成長には「新しい概念の獲得により、前よりも速く正確にこなせるようになる」という軸が欠かせないと思っているので、こういう表現になっています。タイトルはもう少し実態に合うものがあったかもしれませんね(逆に少しずれているから伸びたのかもしれませんが)。

ようは「気合いと根性でやれ、徹夜でやれ」という風に追い込むだけだと成長機会を逃しますよって話で。

7 Railsチュートリアルが悪い?違いますよ。Railsチュートリアルから入ってRailsの事「だけ」しか学んでないのが悪いんですよ。

ms2sato.circlearound.co.jp

これもひっそり公開しておいたものが、いつの間にかアクセス稼いでた系ですね。Google検索からの流入で1日2PVくらい稼いでいるようです。私は「初めてのプログラミング/WEB開発」でいきなりRailsチュートリアルをやることに関しては反対派です(以前は結構この流れが多くて、ワケも分からずチュートリアルを写すのが流行っていたと思います)。本文中にもチュートリアルからの引用含めて書きましたが、あれは別の言語や環境で既にWEB開発についてやテストについて知っている人が乗り換えるための文書だと思います。

Railsチュートリアルという文書が素晴らしいことには変わりがなく、誤った誘導をしている人が悪い。というのが私の主張です。

余談ですが、このエントリから弊社のことを知ってUdemyの動画からトレーニングまで受けた例があるというのがわかったので、こんな文章でもいい入り口になっていたのかと思ったりしました。

8 何度も書き写すことに意味があるのか。もしくは理解の為に必要な要素について。

ms2sato.circlearound.co.jp

チュートリアルの件と似てますね。私は「無心で写経」はやったことがないし、やる価値が低い行為だと思っているのでそういうことを書いています。

真似を繰り返すのが回数という数字になって達成感を得てしまうのはソシャゲで何回もタップすると何か出てくるとか、レベルが上がるようなのと似ている感覚ではないでしょうか。本質的に得るべきものは得られてないかもしれない、と疑った方が良いです。

言いたいことの幹はこれかな。

/auth/chrome-content-suggestions というリファラでアクセスが多かったので調べてみたら、AndroidのChromeブラウザのオススメ欄らしいです。こんなところに出たのか。勉強になりました。

did2memo.net

9 自分なりに「独身40代の孤独」と向き合う

ms2sato.circlearound.co.jp

まさかのこのエントリがトップ10に入るとは。Googleと、なぜかはてなブックマークからの流入がある様子。2ブクマなのに。これについては特に語ることはありません。なるようになります。

10 好奇心を持ってコード書いたりしたいんだ!

ms2sato.circlearound.co.jp

プログラマとしての個人的なマインドのエントリ。「生き甲斐」は何かというようなことですかね。

20代の頃にあった「今日もあのコードの続き書きたい!」という目覚め方をしていなかったですし「もっとこのコードの続き書きたかったのに!」という気持ちで寝付いてもいませんでした。

この気持ちを最近思い出せたのはとてもよかったです。

おしまいに

今年は対外でも、対自身でも「プログラマとしての人生に向き合う」エントリが多かったようですね。

最近は弊社のトレーニングへプログラマへの転職活動をしている方がよくいらっしゃいます。現在の受講している人へ向けているエントリや、将来の方に参考になりそうな内容を選んで出していた結果ですね。

結構まだ下書き状態で残している内容もあるので、来年も引き続き色々と書いてみたいと思います。

*1:珍しく煽り気味のタイトルになっているのですが、煽れなかったらしいです(笑)

『アライアンス』読んだメモ

はじめに

からの流れで、買って読む*1

ALLIANCE アライアンス―――人と企業が信頼で結ばれる新しい雇用

ALLIANCE アライアンス―――人と企業が信頼で結ばれる新しい雇用

  • 作者: リード・ホフマン;ベン・カスノーカ;クリス・イェ,篠田真貴子;倉田幸信
  • 出版社/メーカー: ダイヤモンド社
  • 発売日: 2015/07/10
  • メディア: 単行本
  • この商品を含むブログ (2件) を見る

こんな本

だいたいこんな感じかな、と。

  • 「『終身雇用は通用しない』と認めた上で、会社と社員の間にどのような方法で長期的に良好な(互恵的な)関係を築くのか」というテーマ。
  • 社員と会社との関係に「コミットメント期間」という決めを適用し、一定の期間の間に何を求め、何を果たすのかを明確にする。
  • 社員と会社の関係は「コミットメント期間」によって複数の類型を持ち、付き合い方の深さを変えていくことができる。
  • 会社を出て行った元社員の「卒業生ネットワーク」、知り合いづての「人脈」を活用するとこで会社と社員の長期的な関係を築くことができる。

ポイントとして以下のようなところが心に残った。

  • 会社は(自社で提供できないものも含めて)社員の長期的なキャリアを応援すべき。
  • 現在就労している社員だけではなく、過去就労していた社員、さらにはその社員の知り合いすらもネットワーク化して広げる、会社に閉じないモデルを目指すべき。
  • 後半はなんとなくLinkedInという会社の事業の正当性を暗に後押しするようにも感じた(嫌味な推し方ではないけれど)。

考えたこと

変革型コミットメントを行う主体について

私はあまり従業員を固定期間的な付き合いと考えたくないので、その意味では相反する内容を提示された感覚。ただし、弊社ではこれを社員枠で行なっていないようだ。弊社基準だと以下。

  • 社員: 会社のビジョン・文化・メンバーにフィットする。
    • 完全なビジョンフィットが難しくても、最低でも文化やメンバーはフィットしているべき。ビジョンまでフィットすれば最高。
    • 本書で言う、基盤型コミットメントに近い。
  • 業務委託: シンブルに社員でカバーできない能力を一時的に補う関係。
    • ただし、これを続ける中でビジョンや文化へのフィットが確認されるケースはあると考えている。
    • 本書で言う、ローテーション型コミットメントに近い。

変革型のアクションはビジョンへの合致があって初めて本質的に実現する気がしているので、社員メンバーによって行うものと決めている。「変革するのは基盤を担う人間であるべき」と思いたい為だ。

今後短期間のコミットにより達成すべきアクションが発生したと仮定しても、やはり業務委託からスタートして社員への流れを考えそうな気がする。社員扱いを考えるようなメンバーに対しては、成長のステップをどのように用意するかをかなりコストをかけて考えている。業務委託の場合には、一定期間で離脱する人と考えて、そこまでの成長ステップを考えない(それでも自分が起業する前に関わったどの組織よりもチームメンバー個人の成長にコミットしているとは思っている)。

退職した社員=卒業生について

卒業生ということだと今はまだ社員が退職した経験を持っていないが、トレーニングを受講し、弊社メンバーと良い師弟関係を築いている別の意味の卒業生達が育ってきていると感じている。会社を退職する人はなるべく減らしたい(その為に雇い入れるハードルも高い)けれども、トレーニングの卒業生は長くとも数ヶ月ペースで増えていくので、この感じがとても近い気がしている。実際に卒業してフリーランスになった人が仕事を手伝うような場合もある。

今年の忘年会で集まった時にもこの感じを受けていて、初期の卒業生はフリーランスであったり、起業してシステムを顧客に提供したりしている事もあって、今の受講生が目指すべき背中を示してくれているし、そういう中での「濃い繋がり」にそれぞれが価値を感じてくれている気がする。特に今年は就職活動組が多く、その結果もかなり良好なのでまた3年後くらいが楽しみだったりするのだ。

考えのまとめ

本書で伝えられていたことについて、私は違うアプローチで似たような結果を生み出すような気がしている。長期的に続ければ続けるほど強くなっていくビジネスを目指しているので、卒業していったメンバーが数年後社会に大きな貢献ができるようになり、彼らと私たちが一緒に仕事したり、私たちが育てるメンバーの目指すべき背中になってくれることをとても期待している。

そういう未来への期待を実現する上でも、一人一人の受講者をなるべく望みを実現する形で送り出してやりたいと願っている*2

本書が示しているゴールを実現するには、会社は社員に嫌われてはならない。使い潰す駒のように扱う文化では実現し得ない。この点に関して私が目指している文化とかなり近いので、枝葉は違えど目指す世界が似ているように感じた。

おしまいに

経営を志す人に読んで欲しい本の筆頭かもしれない。本書には目指すべき組織文化のイメージが明瞭に描かれており、その組織の強靭さは推察に難くない為である。紛れもなく「いい会社」ができるであろうことが気持ちよくイメージできる。私はこういう会社を目指す経営者が増えて欲しいと願っているし、自身の会社が(アプローチが一致しなくとも)同様な会社になっていくことを思い描いている為だ。

ここのところ本を買っても読みきれなかったり、そもそも買うことを躊躇してしまうことが多い中で、本書はかなり私に近い思想を持って書かれていた為か、抵抗なく読み進めることができた。また、多読の方が良書と紹介されている本はやはり読んでおいて損は無さそうだ。

*1:ちなみにところどころ Siri に音読してもらってた。寝る前に読み聞かせてもらいながら眠りに落ちたこと何度か。体験的には意外によくてオススメです

*2:もちろんパーフェクトは難しいけれど、諦めはしないことが大切なのではなかろうか

別の業界からプログラマーへ転身する際の就活のこと

f:id:ms2sato:20181214181719j:plain

はじめに

最近のトレーニングの相談では「ITの業界ではないところからプログラマーになりたい」というものがちょいちょいあります。この人たちは最終目標が就職活動に成功することなので、実力をある程度上げた後「就職活動」という形になると思うんですね。そういう場合は度々これから書くような事を伝えています。

私のところのWEB等では就職に関するところはあまり表立って書いていません。実際には知り合いの会社さんに紹介するようなこともありますが、紹介することが目的ではなくて「マッチしそうな両者がいた時に声かけする」という事が多いです。成果責任を作ると「マッチしそうな」のウェイトが小さくなると思うので、今の所はあえて責任を持たないスタンスを取っています*1

経験年数と若さの壁

大抵の場合ですが、プログラマーの就職活動は"全く同じ能力を持っている人を並べた時"には若い方が有利になる事が多いと思います。プログラマーは頭が柔らかい方が良さそうとか、体力がある方が良さそうとか、あくまでイメージで「若い方が」と結論されてしまうのかなと感じます。士業のような職業なら年齢によって権威が増したりするので違うかもしれないと以前誰かに聞いた事があります。

とすると、新卒のような若い人と同じ土俵にいるのはあまり得策では無いですよね。同じように必死に頑張っても負けてしまうわけです。 実際には「完全に同じ」という状況があるわけでは無いのですが、「確からしさ」は感じられると思います。

代わりに何を武器にするのか

例えばこういうことかなぁというところで話をしたりします。その人に必ず合致することは無いですが、何かの助けになるかなというところです。実際にこれが行えて明確な結果が出た例を私があまり持てていないので、もし合致する人がいたら知らせていただけたりすると嬉しいです。

概ね「過去の経験からプログラミング以外にも役に立てる」と見せられる方が有利になりそうです。

既に持っている業界経験

すごく雑なたとえですが「飲食業界にいた方が飲食を扱うシステムを開発する会社にアプローチする」だと相性が良かったりすると思うんですよね。特に業務知識を体験で獲得している人は既にかなりの優位にいると思います。この時うまくいくと「生々しい業務知識を現場へ提供する」ということで役に立ちながら技術を学習して追いついていくという事が成り立つと思います。

これはその人を雇い入れる動機としては十分あるのではないでしょうか。

別の業務経験

ディレクションやマーケティングのような他の業務経験であったとしても「全てにおいて何もできないわけではなく、何か役に立てる部分もある」という事であれば価値は高まると思います。

前職の業務からは抜け出したくてプログラマーを目指している場合には、どれくらいの期間、どのようなステップでそれを離れていくかは事前にある程度詰めておかないと想定通りにならないかもしれません。

社会人としての能力

実は実際に仕事を始めると「仕事の進め方」のようなことや「質問の機微」のような「プログラミング以外の能力」も結構なウェイトを占めます。既に社会人としての経験を持っているなら、テキストでのコミュニケーションの内容や対面の会話での立ち居振る舞いや受け答えの中にも、一緒に仕事をする上でのやりやすさを感じてもらえるポイントはあると思います。

誰の紹介か

間に誰かが存在していたりする場合には「どんな人からの紹介であるか」は結構重要ではないでしょうか。特に「この人の紹介であれば間違いない」という実績を持っているような人と関係性を作れるのであればそれを活かすことは大事だと思います。

ただ、そういう誰かにうまくたどり着くのが難しい、というのもありますけれども。

もしも育ててくれたところが太鼓判を押してくれるのであれば、それを頼みに進めるのもありますね。私の場合には受け入れ先も受講生もうまくいきそうだと想像できないとなかなかホイホイ紹介できない気がしています*2

別の視点ですが、私が人を見る場合

私はちょっと変わったタイプなので、一般的な会社経営者の目線とは違うかもしれませんが参考にどうぞ。あまり詳しく書き過ぎないのは「情報があるということは逆手に取れる」ということなので察してください。

  • 自社の求める文化・能力に合いそうか
  • どんな経緯で私に出会っているのか、お互いのことを掴めている感
  • 言葉のキャッチボールのシックリ感、納得感
  • どれくらいコード書けるか
    • なにか書いたコード見せて欲しい(参考
    • プログラミング以外の能力でアピールできないなら、最低でも弊社のチーム開発トレーニング ができるくらいにはこなせて欲しいですね
  • どんな待遇・立場・給与などを望むか

あとは「とりあえず業務委託で付き合ってみる」はやりやすい手かなと思います。いきなり従業員にするのはちょっと気になる場合も、業務委託ならハードルが低いです。

余談ですが、最近の話

いくつか企業の面接をしている人がいるのですが、その方に最近アドバイスしたことの一つは「前の面接で言われたことや、気になった事、知らなかった事を調べてみたりするのはどうか?」というような事ですね。何回かの面接のうちにその人が成長できる事を相手に伝えられたらいいなぁと思っています。少なくとも私なら評価しそうです。

*1:このあたりはまた別の機会に色々書きたいですが本題から外れるので今日は置いときます

*2:受け入れてくれた先の会社さんともその後もお付き合いしたいのですから、誰でもねじ込めば良いというわけではないでしょう