UNIX的なアレ

UNIX的なこととかいろいろ

HiveShibuyaに通っていました

f:id:wadap:20180628133649j:plain

HiveShibuyaのエントランスにて。

本日まで、 HiveShibuyaというコワーキングスペースに週2くらいで通っていました。というのも現在は割と自由な立場でいろいろやっているのですが、家にいるとYouTubeNetflixをダラダラみちゃうんです(しょーもない)

というわけでこれは良くない!と反省して、起業しろで有名な木下さんに相談して、席を借りていたという流れになります。

HIVE - Skyland Ventures — Skyland Ventures

しかも自分がいた席がNYAGOを運営していたUndefinedのチームがいる席で、とにかく若いエネルギーを感じました。年齢半分くらいですよねぇ、彼ら...

undefd.com

やっぱり渋谷の道玄坂ってすごく好きな雰囲気なんです。nanapiもこのあたりにオフィスを構えていた時期はありますし、同じビルには投資先のフラミンゴも入っています。

やっぱり道玄坂って自分としてもすごく居心地がよい地域なんですよね。それにHiveShibuyaにいたことによる出会いや、それによって決まった投資の案件などもあったりしました。

一旦は拠点を変える予定ではありますが、基本的には渋谷近辺で活動をしていく予定です。短い間ではあったのだけど、すごく楽しい思い出ができてよかった!

とくに同じ席にいたこともあり、UNDEFINEDは大好きなチームです。がんばって!

f:id:wadap:20180628132710j:plain

Supershipを退職しました

表題の通り、2018/5/31 をもってSupership社を退職しました。現在に到るまでの経緯ですが、長く、そして若干のややこしさはあります。過去のエントリーでその辺り触れています。なお、退職の理由は割愛します。

wadap.hatenablog.com

wadap.hatenablog.com

wadap.hatenablog.com

これから何をするのか

正直なところ「これをする!」といったものは現在はありません。現在は本当に縛られるものがないので、とりあえずはいろいろと自由にやってみようかなーというところです。そんな中で現在やっていて、今後も継続するだろう活動は以下の3点です。

  1. 音楽活動
  2. エンジェル投資
  3. 顧問・コンサル

音楽活動

僕自身ギタリストとしてやっていきたいという思いは10代のころからありその思いは今でも変わっていません。自由に動ける今だからこそできるギタリストとしての活動スタイルというものを考え、これからも引き続きやって行きたいと思っています。また自身のバンドもあるのでそちらも含めて活動はやっていく予定です。

エンジェル投資

まだそこまで社数は多くないとはいえ非常にやっていて楽しいです。投資を通じて知り合う人もいますし、投資をしている立場だからこそ見える様々な世界もあります。リターンは出るに越したことはありませんが、リターンというよりもスタートアップと関わり続けるための入場券的な意味合いもあります。本当にエキサイティングなフェーズを見られるのはいまだに影響されますね。

顧問・コンサル

一応受ける予定はありますが、あまり積極的に増やす予定はありません。面白そうな事業だったり、自分自身が興味のある分野や課題を抱えている会社、もしくは人間関係的に手伝ってあげたいと思う会社のお手伝いをしていく予定です。

ご連絡はこちら

ふらっと海外とか行っちゃうので東京にいないことはわりとありますが、定期な予定はほぼ入っていない状態なので、割と時間の自由はききます。ふらふらしつつも、基本的に今後もこの業界に身は置き続けるつもりです。

相談に乗って欲しいとか、投資を検討して欲しいとか、ギター弾いて欲しいとか、飲もうぜとかありましたら、以下のフォームからお願いいたします。

問い合わせフォーム

リモートでの働き方を考える

リモートワークの可否に関しては様々な意見がありすでに国内でも導入している企業は増えてきています。実際に働き方改革の取り組みとしても実際に上げられています。

テレワーク推進に向けた政府の取組について

とはいえ、実際にリモートワークで成果を出すのは今まで通りの時間管理を前提としている業務の考え方では難しく、挙げ句の果てにはこういった管理方法すら出てきてしまうのが現状です。

japan.cnet.com

時間管理をしたほうが効率のあがる業務なのであればこのマネジメントの考え方は1つの手法としてあるのかもしれませんが、正直なところ非常にナンセンスな管理方法だと思います。

高度プロフェッショナル制

そして実際に導入が検討をされている高度プロフェッショナル制ですが、これは成果に対する評価が賃金であるということが前提となっています。しかし時間管理が染み付いているワークスタイルだとやはりどうしてもコンフリクトしてしまいます。

そのためこの制度を悪用することが懸念された結果、残業代ゼロ法案と揶揄されていたりもします。実際に業務に対する正しい評価がされない環境であればそうなる可能性はあるため、法的な制度以上に企業側の人材評価に対する見直しも必要となってきます。

その上で業務内容を改めて整理し、現代の仕事内容に合わせたワークスタイルを定義しなおす必要があります。

business.nikkeibp.co.jp

リモートの向き・不向き

業務内容は大きく以下の3つに分類できます。

  1. プロジェクト型
  2. 依頼対応型
  3. ルーチン型

この3つの業務種別の配分次第でリモートの向き・不向きがあります。

特にこの中でリモートに向いているのはプロジェクト型で、ある程度まとまった期間でのアウトプットに対して評価をするというスタイルです。そう考えると業務設計に幅ができ、実際に多様性のある働き方ができます。

業務設計

リモートワークはどうしても一つの特別な働き方として捉えられがちで、リモートでの働き方に最適化したツールの導入などの話に寄りがちです。そのため業務設計を見直すことなく、現在の仕事を新しく導入したツールや手法論などで解決しようとするわけですが、多くの場合それでは解決しません。また、現在行われている一般的な手法(時間管理など)はリモートワークの思想と相反するので、そういった考え方は一旦取り除く必要があります。

リモートワークだとメンバーが管理できないということは、仮に出社をしていたとしても正しい評価をくだせていないということが上げられます。そのため、リモートで働いている人であろうが社内で働いている人であろうが、顔を合わせていることによるバイアスを除き、正しく業務に対する評価をできていることが大事です。

自チームでのリモートワークのやり方

それぞれのメンバー同士で以下のそれぞれの項目を求めることが大事だと思っています。

  • Expectation(期待)
  • Consensus(コンセンサス)
  • Share&Review(共有・レビュー)

この3つを行うことを前提に定められた期間でのタスクを設計します。これはただツールを導入するだけでこの項目は達成できません。また時間をかけてチーム内にカルチャーを作っていく必要があるため、片手間で実施することは難しいです。そのためこの項目を遂行するための担当者がいたほうがスムーズに実施できます。

Expectation(期待)

これは、同じチームに属している人同士がお互いに期待をしてもいい仕事内容ということになります。それは、技術的な得意分野だったり、いままで作ってきたシステムの担当分野だったりそういったものを含みます。お互いに期待をしてもいい内容というのがわかっている時点で、タスクの振り分けが明確になりお互いの進捗についても納得感が生まれます。

Consensus(コンセンサス)

決められた期間でこなすべきタスクの量や内容がお互いにコンセンサスがとれている状態を指します。これはただ与えられた業務で実施することは難しいため、改めてチーム内で仕事を分解し個々にアサインをする必要があります。また個々のタスクに関して、お互いにどういったタスクを持っているかが見えていることが重要な点として上げられます。

また、コンセンサスは期待をベースにその都度作り上げる必要があります。誰もが仕事だけをして生きているわけではありませんし、休暇もとるし家庭の事情もあります。そのため事前の期待を踏まえた上で、この期間ではここまでのアウトプットが限界というコンセンサスをとっておくことが大事です。

Share&Review(共有・レビュー)

個々の仕事について共有をしレビューします。タスクそれぞれの精度に関してはコードレビューなどを通じてされていることが前提となっているためここでは含みません。予め実施する予定の期間に定められたタスクの量が適切だったか、タスクの粒感は適切だったかなどのレビューを行います。

実績への評価

定期的にお互いの業務をレビューし合うため、そのレビュー内容が個々の評価になるようになっているのがベストです。査定などは半年〜1年くらいで行われることが多いと思いますが、この定期的なレビューがログに残っていることで半期単位での評価でもその内容が使うことができます。

評価にはOKRが使われることが多いと思いますが、Key Resultの効果測定になるくらいしっかりとしたレビューの結果が残っていることがベストです。

スクラムとリモートワーク

上記の業務設計とスクラムでの仕事の進め方の相性が非常に良いので、結果的に自チームではスクラムと組み合わせて実施をしています。コンセンサスをとるためのスプリント計画だったり、レビューのための振り返りなどスクラムでやるべき会議体と非常に似ています。

また、大事なことは1度業務を設計したからといってそれ以降は勝手にチームが回っていくなんてことはありえません。常に問題点があればそれをお互いでシェアし改善に取り組んでいく必要があります。そのため、振り返りの会議の際はプロダクトだけでなくチーム運営の問題点などについてもシェアをするようにします。

このあたりのスクラムの運営方法に関してはこちらの取材でお話させていただきました。

gihyo.jp

会議体や報告フローなど

これは、リモートでもオフィスにいても同じようなフローで行われる方が望ましいです。どちらかのステータスが特殊なものとして扱われてしまうことで情報の偏りが生じてしまいますし、その時点でワークしづらくなります。

そのため自分がみているチームでは朝会などは会社にいてもいなくてもすべてHangout上で行うようにしています。そうやって実施することで、Hangoutでコミュニケーションをとることが特殊じゃなくなり顔を合わせても合わせなくても同じコミュニケーションをとれるようになっていきます。

使用しているツール

リモートワークを推進するためのツールはいろいろとありますが、最終的には使い方次第です。またリモートのときにしか使わないツールだと普段から使っていないためつかっていてしっくり来ないということも実際にありました。結果的に自チームで使っているツールは以下の3つです。

おそらくこの3点セットは同じ業界の人はほぼ同じセットで導入されているはずで大きな差はないと思います。特殊なツールを導入せずとも、基本的なツールだけで十分に回せます。またそれぞれのツールがスマホからまともに使えるため、出先で使いたいときも問題なく使うことができます。Sneekなども導入したことありましたが、正直いまいちワークしませんでした。

最後に

リモートでの働き方に憧れる人・導入してみたいチームなどはたくさんいると思います。しかしながら、リモートで働くということはそれ相応の結果に対する責任が伴います。

また働き方の多様化における銀の弾丸ではありません。当然、それなりの業務設計をやり直す必要はありますし、業務における向き・不向きもあります。一方で、リモートというワークスタイルが増えることで多様性を生むことができるのも事実なので、一つの選択肢として考えてみるのも良いと思います。

日本のエンジニアの地位をあげるために

日本のITはなぜ弱いのか? 日米でこんなに違うプログラマーの扱い - まぐまぐニュース!

確かにその通りで、やはりエンジニアは言われたものを作る職業という認識をされているケースが多いです。最近のエンジニアが主体となったベンチャー企業などでは変わってきているとはいえ、業界の割合でいえばごく一部といえると思います。

上記の記事にもある通り、サラリーマン経営者による個人の責任を極限まで減らした意思決定を行いそれによってプロジェクトが遂行されることが正義とされてしまうと、どうしてもエンジニアとしてのクリエイティビティを出すチャンスは減らされてしまいます。これに対してどう向き合えばいいのかを考えてみました。

なお、英語学んで海外に行けばいいじゃないかという個人にフォーカスした視点はいれません。

IT人材の人数は2019年がピーク

IT人材の育成(METI/経済産業省)

こちらのデータを見る限り、2019年にIT人材の人数はピークとなりそれ以降の平均年齢は上がり続けるという傾向にあります。一方で需要は増え続けるわけで国内におけるIT人材の需要と供給のバランスが今まで以上に崩れていくという予測がたっています。

このように人材不足が発生する見通しとなっており、この不足分を供給するには国外の人材に頼るしかないわけですが、このままだと社会における母数が減ってしまうエンジニア出身の人間が経営や意思決定に関わる可能性がより減ってしまうということが数値上にも起きてしまいます。

エンジニアの地位を上げるには

しかし、意思決定のレイヤーに関わる人にはエンジニア出身の人が増えれば業務そのものが変わってくるでしょう。ここでいうエンジニアとは「新卒の頃に研修でJava書いたことがあるとかで昔おれはSEやってたんだぜ」とか言い張る変なおじさんのことではありません。ちゃんと前線でコードを書いて開発をしていた人のことを指しています。

そしてそういったエンジニア出身の意思決定者を増やすにはどうすればいいか。シンプルなことでエンジニアの総数を増やすのが一番良いと思っています。単純に幹部候補生となる人材の候補にエンジニア出身の人がいるということが重要だからです。

もっと全体のレベルをあげる対策をという考え方もありますが採用・育成をしていた経験上、まずレベルのトップラインは勝手に伸びていきます。どちらかというと、数を増やした上でボトムのレベルをどこまで上げていくのかというのが大事な論点になるかと。

プログラミングの義務教育化による変化がどこまで起きるのかはわかりませんが、ボトムのレベルを上げるという観点は大事かと思っています。

http://www.kantei.go.jp/jp/singi/keizaisaisei/pdf/2016_zentaihombun.pdf

ロールモデルの不在

わかりやすいロールモデルの不足というのはあります。確かに業界を引っ張っている有名なエンジニアの方は沢山います。しかし、エンジニアからみたロールモデルであり、これからエンジニアを目指す人からみたらロールモデルとしてはいまいちイメージするのが難しい。あまりにも遠すぎるし、高尚すぎる。

そのため必要となってくるのが、わかりやすいロールモデルです。これからエンジニアを志望する可能性があるだろう人に向けたロールモデル。そういった人が出てくることで、これからの若い層が目指すエンジニア像というものが少しは具体的になってくる可能性があると思っています。例えばそれが、メディアでよく見かける有識者とかすごい金持ちみたいな、俗っぽいことでもいい。そういった扱いが表に出ることが大事だと思っています。

マクロ的視点でみる

当然、こういうことを言うとレベルが低い層ばかりふえてうんちゃらみたいな話になりがちです。しかし、確実に潜在的にIT人材に向いている人はいますし、実際に就業してからその楽しさに気付く人もいる。

自分自身の周囲というミクロな環境に限っていえば当然、そんな層が増えたら困るのはわかっています。一方で、マクロな観点でいうとエンジニアになりたいだろう人材の母数が増えその中から一部の優秀な人材が生まれてくると考えるのであれば、母数を増やすということは非常に大切なことです。

そしてさきほども書きましたが、ミクロな環境における不幸をなくすためにもボトムのレベルを上げるという施策は必須になってきます。

できる施策や方向性はいろいろある

対策としてできることは1つではないと思っています。実際に、技術のトップラインを支え続け産業のレベルを上げ続けている人達は心から尊敬していますし、その活動自体本当に素晴らしいと思っています。

一方で私自身が興味があり、自身でとりくみたいと思っている方向がまさにこのあたりです。様々な方向から日本のIT産業を支える必要があるのではないでしょうか。

落とす面接と通す面接

ottiee.hatenablog.com

同僚のデザイナーが良いことかいてました。最近は採用活動には携わっていないのですが、以前に似たようなことを採用において感じたことがあったので書いてみようと思います。

不慣れな人ほど落とす

私自身も面接官トレーニングというものをちゃんと受けたことがあるわけではないので、いわゆる「正しい面接」というものをできているかどうかはわかりません。

ただ、過去にやっていた採用活動においてまずよく起こるのが面接に不慣れな人ほど簡単に人を落としてしまうということでした。

なぜそうなってしまうのか。理由としてはシンプルで、通すことよりも落とすほうが簡単だからです。相手の嫌な部分やダメな部分なんて自分が思い込んでしまえば簡単に作ることができるので、落とす面接は簡単に仕上がってしまいます。場合によっては単純な好き嫌いだけで合否を決めてしまうこともある。1の良いところをみつけるより、10の難癖をつけるほうがよっぽど簡単です。

そのため、落とす面接というのは質問項目さえあれば誰でもできる面接でもあります。

通す面接は難しい

まず、通す面接というのは基準を甘くするという意味ではありませあん。

そして、通す面接は圧倒的に難易度が高い。こっちが求めている点と相手が売り込みたい点が合致するというケースはそこまで実際には多くない。だからこそ、相手の良い部分を引き出してあげるような面接をしなければなりません。

また、落とすことよりも通すことのほうが責任が伴います。特に自分の後の面接に自分よりも立場が上の人がいるとさらにその難易度が上がってしまう。だからこそ何も考えないと落とす面接になりがちなのかなと思います。

さらにいうと、面接というはあくまでそういう場なだけであって基本的には大人同士の会話なんですよ。そこでマッチするかどうかをお互いに見極めるってだけなので、こっちも見られているんです。面接官も選ばれている側という意識が大事です。

決定権がある人を一次面接に

これを面接のステップのアーキテクチャに組み込むとしたら、一次面接を決定権を持っている人が担当するのが良いのかなと思っています。

当然、このレベルの人は他の人よりも面接の経験にも長けているでしょうし、ある程度自分の責任において採用をすることができます。そして一次面接を通したら、二次面接の担当者にはちゃんとその人の良さを伝える。そうすることで二次面接以降に関わる人が好き嫌いだけの判断を減らすことができると思っています。

実際に私が採用活動を行っていたときは全てこのステップでした。当然、面接で100%正しい決断を下せるわけがないのですが、このステップでやっていたときは納得感のある採用ができていたかなと思います。

「ノーアジェンダ・どうしましょうか会議」の傾向と対策

wadap.hatenablog.com

先日、こんなエントリーを書きました。割とエンジニアやデザイナーの方は経験したことがある会議ではないでしょうか。このワードに反応されていたので、少し掘り下げてみたいと思います。

「ノーアジェンダ・どうしましょうか会議」とは

もうこの名前に全てが詰まってはいるので、経験したことがある人はすぐにわかるとおもうのですが、以下の点が揃っているとまさにその会議かと思います。

  • アジェンダが用意されていない
  • とりあえず関係がありそうな人を呼ぶ
  • 会議が始まり次第「どうしましょうか」的な空気が流れる
  • ダラダラ長い
  • 丸投げ感満載

というところでしょうか。会議そのものに主催者側の専門性があるものでは起きづらいのですが、自身が理解できない or 経験の無い領域の話になるとわりとこういう会議になりがちなのかなと思います。

会議の傾向

そしてこの会議が始まり「どうしましょうか」的な気まずい空気が流れます。呼ばれた側も事前にあまり話を聞いておらず、割とどうしようもありません。

そして会議をまともに仕切る人がいないため、気になった点の議論だけが行われプロジェクト自体が前に進みません。わかり易い例としては、作るプロダクトの詳細も決まっていないのに言語選定とか自分が現時点で理解できる範囲の話になりがちです。

そしてよくわからないまま会議が定例化されダラダラとしたプロジェクト運営が進みます。

対策 - 出席者

この出席者側の対策としては以下の点に注意することです。

  • プロジェクトのマイルストーンを明確にする
  • 点の議論にならないように意識する
  • 主催者側 vs 出席者という構図を作らない

これは本来は主催者側の仕事といえばそのとおりではあるのですが、そのままじっと座っていても自分が参加しているプロジェクトが辛くなっていくだけです。そのため、いかにプロジェクトをストレスなくすすめることができるかという点に注力すべきです。

たしかにこういう会議が開かれると戸惑いを超えて腹立たしいこともあるのですが、呼ばれた以上関わる可能性があるのでその瞬間から主催者側に協力的になったほうがトータルのコストでみると得です。

対策 - 主催者側

プロジェクトにおける業務の詳細を把握できない人がやりがちな会議ではあるのですが、以下の点をクリアにすれば少しはスムーズに運営できるのではないでしょうか。

  1. 会議の前に強く関わりそうな人に個別に相談する
  2. 会議に出席するメンバーは最小限にする
  3. 会議そのもののゴールを明確にする

この3点を踏まえた上でアジェンダを作成し、事前に話すテーマがわかっているだけで会議の雰囲気は全く変わってきます。

会議のタイトル問題

そして、わりと軽視されがちなのが会議のタイトルです。会議自体は GoogleCalendar などで設定されることが多いと思いますが、そこに表記されるタイトルです。会議のタイトル適当な会議は本当にロクな会議がない。

アジェンダといえど全員が読むとは限りません。でも会議のタイトルくらいは嫌でも目に入ってきます。そのため、タイトルがら伝わる会議名が入っていると参加者は助かります。

ありがちなのが「ご相談」や「新規プロジェクトについて」のようなざっくりしたタイトル。このままだとその会議で何を行うのかが、イマイチ見えてきません。

主催者側はタイトルを気にすべきですし、参加する側もイマイチわからないタイトルがあったら事前に主催者側に確認をしておくのが良いです。

協力関係が大事

おそらくこんな会議を経験した人が多数いるんじゃないかなと思ってかいてみました。

本来は適当な会議を主催する側が気にすれば発生しない問題ではあるのですが、どうしてもこういった会議は行われてしまうもの。そのため、参加する側も協力することで少しでもこういった会議を減らしたいものです。

現場に業務改善を求めてはいけないのか

anond.hatelabo.jp

コメントも含めこれを読んで思ったことを書いてみようと思います。

業務改善を求めてはいけないのか?

まず、業務改善は上司だけの仕事ではありません。そもそも上司といってもチームによって期待されているロールが分かれているんで一概に言えないと思います。

そして業務改善は現場の協力無しでは出来ないので、何らかの協力を仰ぐことは必須です。ただ、問題はどこまでを上司が行ってどこからを現場で行うのかという点なのかなと思いました。例えば以下のような方法です。

  • 人が辞めてしまい、業務負荷があがっている
  • リソース不足ではあるが、あきらかに業務効率が悪い点があった
  • ○○の問題を解決したいので、それを実現するための方法は何かないだろうか?

というような話の流れであれば、返答のパターンは以下の3つくらいだと思われます。

  1. その方法を試したいので、○○という手法を導入したらどうか
  2. そこよりももっと他の部分に問題がある
  3. その問題提起は間違っている

1か2の回答であれば、建設的な意見ではあるため議論を前に進めることができます。3の場合でも対話を繰り返すことで、問題の根底を突き詰めることができる可能性があります。

現場の問題をどこまで上司は把握できるか

一方で現場の問題をどこまで把握する能力があるのかという課題はあります。完全に把握することはできなくてもなんとなくも勘所はあるはず。ただこれはその部署における何らかの専門性をもっている場合です。現場がもっている専門性をまったく理解できないまま、上司というポジションになった人には非常に難しい問題でもあるのかなぁと。

このあたりを把握できない人がマネージャーだったりプロダクトに強く関わる立場になると「ノーアジェンダ・どうしましょうか会議」が行われます。一旦関係者全員が無駄に呼ばれて、さぁどうしましょうかねみたいな会議。まぁこれは現場からみて腹立つのもわかります。

前提条件としての信頼関係

とはいえ、本当にこういった返しが返ってきているのだとしたらそれは信頼関係が完全に壊れてしまっているということだと思います。率直な意見といえばそれまでだが、これは意見というよりも対象を上司 or 会社にした一つの攻撃と捉えることができます。

攻撃的な関係になってしまうとあとはどうしようもないので、これ以上建設的な議論を行うのは難しいのかもなぁと思います。

人を採用すれば解決するか

採用って採用活動を開始してから、採用活動〜入社まで順調にいっても3ヶ月くらいかかります。なので最終的には採用するにしても、まず目の前の問題は内部で解決せざるを得ません。

とかいろいろ思いました。