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

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

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

「我慢」はし過ぎるな。麻痺するから。

はじめに

www.bengo4.com

痛ましい事件だと思いました。ここから思ったことと似たようなことをあるところで人と話していたのですが、そのことも絡めて書いておきます。

「痛みは体のサイン」

最近私がこの言葉を発したのは、プログラミングする際の姿勢の話とか、椅子の話とかだったのですが、体にも心にも同じようなことが言えるのではないかと思うのでそこから始めます。

多分何か身体に無理がかかった時に「痛み」が発生するのではないでしょうか。つまりその時は「何か気をつけないといけない!」と体が発信してくれていると考えられます。よくない姿勢であったり、体に合っていない椅子に座り続けた時などにこのサインは起こるのでしょう。

そういう時、私たちはいくつかの対応策を考えて行うことができます。たとえば

  • 基本的な姿勢を変える
  • 休憩時間を入れるようにする
  • 椅子・机など設備を変える

のようなことですよね。

我慢できる

実は痛みに関して人間は他にも対応策を持っています。「我慢」という行為です。ある程度痛みがあるにせよ「痛みに耐える」ということができる仕組みになっています。通常は一瞬や短時間なら耐えながら物事を行うと思います。

本来この「耐える」というのは「いきなり活動不能にならずに、上記のような対応策を取る時間を稼げるような『バッファ』として体が発信している」とも考えることができそうです。痛みをこらえながら病院に行くようなことを考えていただければ想像しやすいでしょうか。

我慢し過ぎ

我慢強い人、我慢できない人など、人には色々と我慢耐性の度合いがある様子に思います。通常のイメージで考えると我慢強い人の方が頼りになり、物事を達成しやすいような性質として捉えられていると思いますし、確かにそういう傾向は強いと思いますが、私は時折不安になる時があります。

我慢するにも限度があるので、本来対応策を取るべきだったのに取らずに進んでしまうと、どこかで「我慢の限界」は訪れるはずで、治るはずなのに治らない大きな傷になったりするのではないでしょうか。

身体と心

そして身体だけではなくて、心にもおなじようなことが起こると思います。最初は我慢できたことかもしれませんが、ずっと我慢し続けている間に心に大きな傷を作ってしまうことがあります。昔私が現場で一緒だった知り合いでも、そういう方がいらっしゃいます。我慢強さが仇になってしまうということではないでしょうか。

真面目だったりひたむきだったりする人が、或る日突然折れてしまうことはあると思うのです。

私の会社は真剣に仕事に取り組みたい人ばかりなこともあり、結構気を配っている「つもり」ではあります*1。勤怠がゆるくても別のところで大きなストレスを受ける可能性もありますからね。

逃げてもよい

聞いたところによると、我慢が慢性化すると「通常」がどういう状態かわからなくなってしまうらしいです。

下手するとある程度痛みを我慢していないと「ちゃんとやっていないのでは無いかと不安になる」とか「刺激が足らない」とか思うそうです。個人的には過度の我慢は避けて、痛みとして感じられるうちにある程度距離を置いていくのは必要だと思うし、やって良いと思います。

また、わからなくなった時に誰でも良いので第三者に相談するのは良いことでしょう。会社のことを会社に全然関係ない人に相談したり、公的な機関に頼ってみたり、なんでもいいから「その環境の外に」いる人の客観的な意見を聞いてみるのは良さそうです。

ただ、第三者で適切な意見を言えるかと言うと、それは結構難しいことなのでなかなか対応に苦慮するところでもありますね。私も実際に適切な対応が取れる自信がありません。相手が他社ならまず介入は難しい筈です。

我慢しないのは怠け者?

「我慢しないことが単なる怠け者とどう違うのか」と聞かれれば「従業員においては決められた時間内を真剣にやってくれていれば(我慢などしなくても)怠けてないのでは無いか?」というのが今の私の見解です*2。ただ、仕事って別に怠けててもいいんですよ。どんなに気持ちが入っていなくても望まれた成果さえ出してくれれば会社というチームは存続できるからです。

ただし、会社にどんなメンバーを望むのかは文化によって違います。例えば弊社の場合には怠け者は居心地悪いだろうから来ない方が幸せでしょうね。

おしまいに

一定の我慢が必要なことはもちろんありますが、過度な我慢を長期的に続けるのは避けて欲しいなという意見でした。もしもそんな状況になりかけている人がいたら心が麻痺してしまう前に距離を置いて欲しいものです。

皆さんの心と身体の健康を祈りつつこのエントリを終わります。

f:id:ms2sato:20181018190807j:plain

*1:こういうことは、こちらがそのつもりでも相手にはそうで無い場合があると思うので、あくまで「つもり」止まりです。多分大丈夫だろうと思ってやっています

*2:経営者はよくわかりません。やりたくてやっている事業だし、それに関して怠ける怠けないという基準がそもそもうまく当てはまらない気がします

Googleが抱える問題(と、私が思っていること)

はじめに

qiita.com

からのこれ

anond.hatelabo.jp

この話自体については私は以下のような意見です。この記事は別の切り口で書いておきたいです。

問題は書き手側にあるのではなく、Googleにある

「ゴミ記事」かどうかを判定してフィルタリングするのはGoogleとそのユーザーの責務です。

他の記事でも書かれていましたが、私もこの意見には賛成です。そして、だからこそ気になっていることがあります。

私たちの仕事は検索をして適切な情報に辿り着くこともスキルの一つに数えられます。つまり検索が一般人よりも上手なはずの専門職なんだと理解しています。そういう私たちの仲間ですら「適切な情報が手に入らない」と考えているとすると、専門職ではない一般の人からすると「もはやどうやっても適切な情報にたどり着けないことがあるのではないか」という事です。

少し前に WELQ の記事に関して大きく問題になったことを思い出した人もいるのではないでしょうか。それによって改善もなされたと記憶はしています。ですが同様の問題がずっと続いている様に感じています。以下のような記事でも結果的に変わっていないというような論調で終わっていました。

seo-lpo-consultant.com

最近の他の例

medit.tech

ノーベル賞の話に関連して出てきていた記事ですが、検索ワードによっては虚偽と誤解を与えかねない情報で溢れていると指摘されています。私は対象となっているワードを検索した結果を見ましたが、正直申し上げてどれが虚偽や誤解を与えかねないのかわかりませんでした。もし当事者になってしまったら、検索の上位のものは間違い無いのだろうと思ってしまうはずです。

技術記事については私たちは一次情報へ当たることが比較的容易で、ソースコードを読んだり実際に試したりすることで虚偽は判断できます。上記の様な自分で試すこと自体が困難であったり、不可逆なことに関して玉石混交の中から選別するのは大変困難だと考えています。

同様の話は、以下のようなところにも見受けられます。

megalodon.jp

megalodon.jp

プログラミングスクールについてです。どうやら最近はアフィリエイトの記事が大量に出回ってしまった為、自身に合うプログラミングスクールを検索で探すことが大変困難になっているそうです。プログラミングのスクールは一般的に高額なので、一度試してみようというやり方で虚偽を判断することが大変難しいことの一つだと考えます。

これは想像ですが、違約金を高めに設定すれば受け始めてから良く無いと思っても、抜けられない問題があると思います。

フォークソノミーとタクソノミー

もう死語になってしまいましたが、Web2.0 時代を見てきた私にとってこの課題はフォークソノミー・タクソノミーという言葉を思い出させます。

用語解説辞典|【公式】NTTPC

ザックリ伝えると以下の様な感じでしょうか。

  • タクソノミー: Googleの検索などのように機械的に分類され、分類の結果に一般ユーザーが関与できないもの
  • フォークソノミー: はてなブックマークのように人がタグやコメントで分類し、分類の結果に一般ユーザーが関与するもの

今タクソノミー的なGoogleの検索結果があまり有益な結果を運んでこないとすれば、フォークソノミー的なアプローチを混ぜた別のあり方を模索したくなります。

私のやってみたいこと(妄想)

プログラマー向けは別のアプローチもありますが、一般向けならGoogleのSearchAPIを使って検索結果を出し、その結果をフィルタできるシステムを作ってみたいですね。たとえば以下の様なフィルタを用意します。

  • 正規表現で特定のURLやドメインを含むサイトを弾く
  • 特定のURLに対して + or - の信憑性評価ができて、多くの人がどのように捉えているかがわかる
  • ユーザーに対して特定の専門分野への特異性の重み付けをつけられる(たとえばガンに詳しい医師の方が + をつけるガン関係の記事は有用であると考えられる思います)

誰でもフィルタをつくれますが、フィルタはフォークしていくらでも複製可能かつ全て内容がオープンにされており、透明性の高いものとして機能するようにします。ソースコードもオープンで良いと思います。この仕組みは作為性が疑われると崩壊するからです。

他にも妄想はありますが妄想で埋めても微妙なのでこれくらいで。

おしまいに

Googleは毎日利用させていただいている素晴らしい検索エンジンだと思っています。ただ、それを逆手にとって自分の利する形を作っている者がいるという現状の様子です。個人的にはこういう課題は人が必死に何かをするようなことではなくて、そのシステムの改善が必要ではないかと考えます。

ちょっと時間できたら色々作ってみたいものです。

本当はこういうものをビジネスに昇華できればもっと多くの時間をつぎ込めるのでしょうが、皆にとって利益のあるものを作ろうとする時、その結果会社や個人にお金が入る形を考えると公平性が失われるのでは無いかと考えてしまうところがあります。いい手は無いものか。

f:id:ms2sato:20181011124316j:plain

燃え尽きない定年退職エントリに寄せて

はじめに

d.hatena.ne.jp

最近週一くらいで更新しているのですが、今週も色々とキャッチーな話題はあったかもしれないけれど*1、このエントリーへの言及は今しかできない気がするのでしたいなと思ってキーを叩きます。

私は著者とは2000年代のデブサミでのご縁で一回飲み会で同席したことがあるくらいです。なので特別濃厚な何かがあったりするわけではありません*2。あの頃鼻息荒かった私が42才オッサンになるのだから、当時Miracle Linuxにいらっしゃった吉岡さんが定年退職もなさいますよね。時間が経ったのだなと思います。拝読していたらMiracle Linuxにいらっしゃった時期が今の私と同じくらいの年齢だったので、あの頃とこれからに思いを巡らせるなどしてしまいました。

私の心に残ったことを何点か触れさせてください

「私たちには既にわからなくなってしまった過去のこと」を記してもらえること自体に価値を感じました。DECでの開発手法を拝読して、クールな開発手法は時代が変わってもそれ程変わらないのではないかと感じます。「デイリービルド」など、名前は聞いたことあったけれど...というものがCIとなって当たり前になっているのも再発見した気持ちでした。

ちょうど私が現場に出た頃はPCがシステム開発の当たり前になった頃で、いわゆる「オープン化」の流れのようなものがありました。 この言葉は私の実感としては薄い言葉で、少し年かさの先輩が話してくれたような内容から「へーそうなんだ」という形で記憶しています。どうやらその頃に、開発のスタンダードというものがゴソッと代わり、PCが現場に入ること前提で色々と作るようになったらしいです。

私も少し後に出てきたJavaのことを「おもちゃ言語だな」などと言っていたら、あれよあれよと言う間に業務システム開発のスタンダードになったのですから、おもちゃは侮れないなと振り返って思います。かく言う私も一時期はJavaのフレームワークを作る仕事を何本かやらせてもらえて、現場は徹夜上等のとんでもない働き方だったとは思いますが、それなりに魅力的な内容に携われる時代でもあったのでしょう。

当時は30過ぎてプログラムを書いているのなんか頭がおかしいと言う風潮が日本にはあった、

30までの若い人材は激務で使い倒されて、それを乗り越えられるようなコード書きにはマネージメントをさせるという流れが当時は特に強かったと思います。この言葉からもそれが伺えます。

Netscapeのことは本当に驚きました。元記事で明言されていませんでしたが、この話はFirefoxが誕生する前身の話なんですよね。MosaicというWEBブラウザがあり、Netscapeが生まれ、後発のIEとの競争の末、オープンソースにするという決断をする。下記の記事が詳しいかもしれません。

tech.nikkeibp.co.jp

「オープンソースという魔法の粉を振りかければすべてがうまくいくわけではない」

という言葉の通り、衰退していくことになったのは残念でなりません。でもその後もFirefoxとして今も私たちが利用するブラウザとして残っているのは、OSS化の功績であるようにも感じました。

システム開発の仕方が安定していない時代

少し脱線します。今多くの人たちはPC向けのシステム開発は基本的にはブラウザ上で動くものを作るのだと思っているかもしれませんが、以前は専用のクライアントソフトを開発する*3いわゆる「クラ・サバ」があったり、WEBブラウザ上のJSがAjaxやプロトタイプ志向オブジェクト指向で再発見される前で非力であるというような背景がありました。

その為「今後のシステム開発はどのように進めていくべきなのか」というところが大きな話題だったりしたんです。「配布の容易さ」という面で有利なWEBであるけれども、「操作の快適さ」という面ではクライアントソフトには叶わないという、今のスマホアプリの開発と同じようなことを「PC上の開発をどうするか」というテーマで行なっていました。

その中で両者のいいとこ取りをしようという リッチクライアント/RIA というポジションが現れます。典型的な仕組みの一つとしてはブラウザにプラグインを入れて、そのプラグイン経由で当時のWEBよりもリッチなUIを提供するというような考え方です。

thinkit.co.jp

私はそういう中で、リッチクライアントを推進している会社に関わっていて、自分自身も理想の作り方を有志のメンバーと模索していました*4

そして2009年〜今

デブサミのコミュニティ枠*5でLTさせてもらったのが2009年だったようです。多分ほぼ初LTでこの大舞台だった気がします。

発表者が事前に集まって顔合わせした時に吉岡さんとお目にかかったのでした。昔過ぎて記憶がおぼろげですが、楽しそうに話すナイスミドルだったという印象は強く残っています。その後はイベントに参加した時などお話しされているのを一方的に見かけているだけになってしまいました(ビビリィなんで自分から話しかけるの苦手でごめんなさい)。

そうして10年近くの時がたっている中でも、ずっとコード書きとして生きていきたいなと改めて思った矢先に、冒頭のエントリを拝見して胸が熱くなってしまいました。私も35歳定年説などなんぼのもんじゃと思ってやっています。そのあたりは下記エントリへ。

ms2sato.circlearound.co.jp

おしまいに

ずっと現場でIT技術を扱い、定年などものともせずに一生成長を続けられるような素晴らしいロールモデルだと感じました。私も後進を育てながらそんな風に生きていきたいです。そして区切りまでには胸が熱くなるような何かを発信できたらなと願っています。

遠くからですがご活躍を応援しています!

f:id:ms2sato:20181004185528j:plain

*1:毎度のごとく「あれがダメこれがダメ」って言っているよね。もうお腹いっぱいだよ

*2:おそらく吉岡さんの記憶に私はいないでしょう。なのでひっそりエントリ書こうかなと

*3:スマホのネイティブアプリのイメージが近いかも

*4:まさかまだWEBページがあるとは。懐かしいけど気恥ずかしくもある

*5:当時はそういうのがあって、デブサミは開発者コミュニティがかなり自由にブースを出したりできたんです。最近は違う様子かもしれませんが