UNIX的なアレ

UNIX的なこととかいろいろ

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

日本の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ヶ月くらいかかります。なので最終的には採用するにしても、まず目の前の問題は内部で解決せざるを得ません。

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

リズムをつくる開発サイクルと会議のペース

gihyo.jp

先日発売されたこちらで取材された内容なのですが、せっかくなのでもう少し詳しく書いてみようと思います。スクラムの実践方法というよりも、円滑に回すために会議や意思決定のタイミングを工夫した内容です。

前提条件

以下が実施した条件です。

  • iOS/Androidのアプリ開発
  • アプリはリリース済みで、機能追加やアップデート対応
  • iOS2名、Android2名、サーバサイド2名、デザイナー2名

会議のリスト

イテレーションは2週間で切っていて、その中で以下の会議を実施しています。

開発者全員が参加するもの

  • 朝会
  • スプリント計画
  • 振り返り
  • プロダクトチェック会
  • 仕様レビュー会

プロダクトオーナーが参加するもの

会議の実施内容とタイミング

Daily - 朝会

これは毎朝実施されます。デイリースクラムも呼び、その日のやることや問題となっていることなどを共有する場として使っています。

Day1 - スプリント計画

これは開発期間の開始日に実施します。その時点で決まっているプロダクトバックログをベースに個々のタスクに落としてアサインしていきます。

最終的にはカンバン化して物理的にホワイトボード上で管理をするようにしています。

実施するものはプロダクトバックログの単位でGithub上にisuue化しておきます。milestoneはリリース日にして、以降のその機能に関する議論はisuue上で行います。

Day1 - プロジェクト運営MTG

プロダクト開発そのものよりも、チームとしての問題やその他環境問題などについて話す場です。マネージャー陣中心になる会議でかつ頻繁に問題がでるものでもないので、終わり次第すぐに切り上げます。

Day6 - プロダクトバックログMTG

開発するものの一覧の整理と、優先順位を見直す場です。こちらもマネージャー陣のみの参加です。新しい要件などの追加もこちらで話すようにしています。

ここにはデザイナーであるプロダクトオーナーが参加をしていて、次のイテレーションで実施されるだろうもののラフなデザインを作り始めます。

Day9 - プロダクトチェック

今のイテレーションで実装された内容が動作しているかチーム全員で動作確認をします。ここででた不具合や実装のモレなどを可視化してリリースまでに修正をします。

Day9 - 仕様レビュー

次のイテレーションで実施する内容をチームに共有します。この時点でプロダクトオーナーが作ったラフなデザインが共有されます。チーム全体に共有されるため、仕様的な問題点などはここでクリアするようになっています。

問題がなければ、ここで共有された内容が機能一覧としてisuue化されて、リリース時のチェックリストとして使います。

Day11 - リリース

今のイテレーションで実装されたプロダクトの最終チェックをプロダクトオーナーが実施し、チェックリストが全てチェックされた時点でリリースとなります。

なお、iOSは申請のことをリリースと呼んでいます。審査が通り次第、Androidとタイミングを揃えてAppStoreに出すようにしています。

振り返り - Day 11

この2週間のイテレーションを振り返ります。出来る限り次のイテレーションに振り返りを活かせるように、可能なものはタスク化し個々にアサインをするようにしています。

また、この直後に Day1 のスプリント計画を実施していて直前の振り返りを活かせるようにしています。

上記を実施する上でのポイント

いろいろ試行錯誤した上でこのペースになったのですが、考える上でのポイントは以下の点でした。

  • イテレーションの期間は2週間とし、できるかぎりその単位で出せるアウトプットを意識する
  • 会議の日は出来る限りまとめて、分散しないようにする
  • 祝日などがあって営業日が少ない時も同じペースで実施する(長期の休暇が入る場合は要調整)

最後に

この会議のペースや内容なども全て振り返りを中心にいろいろ実施していって生まれた実施ペースです。自分のチームとしてはかなりワークしているという実感はありますが、これはあくまで一つの実施方法です。

そのためにも振り返りをしっかりとやり、そこから改善につなげていくといったアクションが大事ですね。

WEB+DB PRESS Vol.98

WEB+DB PRESS Vol.98

管理画面と業務フロー

最近また管理画面に近いものをつくったりしていて感じたのですが、事業会社において管理画面がどのタイミングで実装されているかというのがすごく重要だなと感じたのでちょっと書いてみようと思います。

社内向けの管理画面の実装って割と後に回りがちで、最後に仕方なくなんとか実装するようなケースが多いと思うんですよね。そして、ある程度発生してきたオペレーションの実態に合わせて実装するみたいな流れになるのではないかなと。

それはそれで一つの実装の手法だと思うのですが個人的には逆のほうが良いのではないかなと思っています。

管理画面からオペレーションを設計する

まず、以下の理由から管理画面ありきでオペレーションを設計したほうが良いと思っています。

  • 既存のオペレーションありきで管理画面の要件を出すため、イノベーションがうまれづらい
  • 組織の最適化より管理画面の最適化のほうが合理的に行える
  • エンジニアの合理的な思考がオペレーション設計に向いている

まず管理画面を実装するということは社内のオペレーションを定義することになります。そのため、社内向けの管理画面をある程度作り込んでおくと、それに従って社内の業務フローができあがります。その上で実態と異なる部分を調整していくくらいが良いかなと思います。

管理画面こそクリエイティビティの発揮場所

サービスの仕様から、このあたりは社内の作業で編集したりするかな、いろいろと業務フローについて考えながら実装したりするのが管理画面だったりします。

特に新しい機能だったりするとそれに関わるオペレーションの人もいないため、当然ヒアリングすらできません。だからこそエンジニアが考えるべき部分ですし、そこの工夫がサービスの成長に寄与できるんじゃないかなとも思っています。

新しいサービスのKPIを正しく理解し、それに付随するだろう社内オペレーションを想像し、それを効率よく行えるための実装をするというのが理想的な流れですね。

管理画面を通じて表現される運営方針

また、管理画面を実装する上で作られる制約がそのサービスの運営方針にも直接的につながることもありただ機能として実装されていればいいというわけでもなかったりします。

たとえばすべての情報を閲覧・編集できるのではなく、ある種の制限などをつけておくことが、サービスの運営方針につながるということもあります。

社内向けの管理画面という意味からは少しズレますが、mediumの記事投稿画面なんかはわかりやすい例かなと思います。文字色の変更や文中における不要な文字サイズの変更などは許可しておらず、あくまで情報を伝達するメディアとして読みやすい表現に制限している。

こういった理由のある制限などはまさに管理画面でこそ実装されるべきもので、これによってサービスの運営方針や本来の使い方を感じることができます。

というわけで

管理画面をオマケとして考えるんじゃなくて、前のめりに自分からガシガシつくっていってほうが良いんじゃないかななんて思います。当然つくって終わりではないので実態に合わせて進化し続ける必要はあるわけで、その都度最適なものに作り直すくらいのスタンスが良いんじゃないかなぁなんて思っています。

以前に書いた記事です。新規サービスの立ち上げのときにはこちらも。

wadap.hatenablog.com

StartupBaseのメンターをやってきた

f:id:wadap:20170328095627j:plain

つい先日、StartupBaseというイベントのメンターをやってきました。ビジコン的なイベントではあるのですが、ポイントは高校生以下ということ。今回参加している中で最年少は中学1年生の子もいました。

startupbase-u18.com

どういうことをするのか?

f:id:wadap:20170328102904j:plain

1チーム4名くらいで、4チームつくり2日間かけて事業を考えてプレゼンをします。実際に調査という名目で、街中に出ていろいろなアンケートをとったりヒアリングをしたりして事業の実現性やニーズなどを固めていくといった流れになります。その中でちょっとアイデアが出てきたかなーというあたりでメンターとしていろいろとアドバイスをするという感じでした。

実際にやってみて

f:id:wadap:20170328101855j:plain

彼ら・彼女らにとって、事業を自分らで考えて説明をするなんて当然人生で初めてだと思うんです。別に一生そんなことしなくても生きていけるし、人生の必修科目ではない。

でもやっぱりこの年齢でこういう場に飛び込むだけでもすごいと思いますし、これからとんでもない速度で成長するんでしょうね。中にはエンジニアになりたい!といっている子もいて高校生くらいの年齢でエンジニア志望の子が出て来る時代になったんだなぁなんてすごく嬉しくなりました。

やっぱりそういった子たちは全力で応援したいですし、個人的には特にエンジニア志望の子なんかは応援したくなってしまいます。実際にこの場で出会ってサービスを作っている子達も居るようで、そういった仲間が見つかるなんてのも良いですね。

またこんなイベントがあれば参加してみたいなぁなんて思っています。

※ 写真は掲載許可をもらっています