不安ゾーンにいた開発チームがラーニングゾーンに入るまで
はじめに
こんにちは。@oturu333 です。私はフリーランスエンジニアとしてモチベーションクラウドの開発チームに参画しています。
もともとEMをやっていたので、参画当初よりEM業務（組織やプロセスの改善など）に携わらせていただき、現在は複数ある開発チームの1つのPO業務も経験させていただいています。
今回はそのチームが2ヶ月で「不安ゾーン」を抜け「ラーニングゾーン」に入っていったお話をしたいと思います。
最初「自分たちは何でも屋なんで」と言っていたhotfixチームが、スクラムを取り入れ「もっとベロシティを上げられないか」「仕事を楽しめている」と言えるチームになるまでを語ります。
「不安ゾーン」「ラーニングゾーン」については、以下のブログが参考になります。
「hotfixチーム」と言われたチーム
モチベーションクラウドには複数の開発チームがあり、それぞれのチームに名前を付ける文化があります。現在私が所属しているチームにも「ドラゴンハント」というチーム名がありました。
そのチームは当初「バグを直す」「お客様からのお問い合わせに対応する」ことをミッションとして与えられたチームでした。
バグをドラゴンと呼ぶあれで「ドラゴンハント」というチーム名になっています。
しかし「ドラゴンハント」というチーム名がありながら「hotfixチーム」と呼ばれることがありました。
まさに当初のドラゴンハントチームは「hotfixチーム」でした。
学びはなく、ただ期日通りバグを直すことにコミットし、チームは不安ゾーンのど真ん中でした。
そんな中、そのチームにPO補佐としてジョインすることとなりました。
タスク管理ツールの導入と状況の可視化
私がジョインしたときには、バグをスプレッドシートで管理していました。
過去はプロジェクト管理ツールを使っていましたが、諸々の事情で一時的にスプレッドシートで管理しているということでした。
スプレッドシートは秘伝のタレ状態。
- スプレッドシートを把握しているのがPOのみ
- POは進捗状況の把握だけで精一杯
- 内容がわからない
- エンジニアはスプレッドシートを更新したくないのでGitHub Issueとの二重管理
- 二重管理によるヌケモレ、ステータスの差分が散見
- 進捗共有のためのMTGに1h / 日を費やす
そこでまずは新たなプロジェクト管理ツールの導入を提案し、せっせと移行作業に勤しみつつ、運用プロセスを設定しました。
チームリーダー就任
2018年末くらいから、ドラゴンハントチームのチームリーダーとなりました。
プロジェクト管理ツールの移行完了から半月ほどで進捗把握秘伝のタレ問題は解消し、進捗共有MTGは 15〜30m / 日 というところまで抑えられるようになりました。
テクニカルサポートチームとの連携もスムーズになり、管理にかかる工数も徐々に減っていきました。
エンジニアもスプレッドシートを離れられた喜びに満ち溢れました。
それまでチームメンバーは流動的でしたが、1月よりチームメンバーも固定化され、以前のような大混乱期は越えられました。
この時期にはそれまで明確なログを残すこともしていなかったのを是正していました。
「ちゃんとログを残そう。ログを残せば良いことがある」。そのくらいの進捗でした。
チームビルディングワーク
1月22日（Slack漁った）、やっとチームのキックオフMTGをすることができました。
キックオフでやったことはマシュマロ・チャレンジと、「自分のキーワードを50出してみよう」というアクティビティです。
キーワードのアクティビティは以下を参考にしました。
マシュマロ・チャレンジにおいては終了後に組織の三要素の話に触れ、チームには共通の目的が必要だよね！このチームの目的ってみんななんだと思う？という問いかけをしました。
共通の目的のアップデート
チームメンバーそれぞれに「このチームの目的は何だと思う？」と問いかけたところ、以下のような回答が多かったです。
- バグを直す
- 何でも屋
そこに今自分たちが苦労している原因の根本であるプロセス、組織の改善を組み込むことを提案しました。
バグをなくすには、ただ直すだけではなくバグが起きにくい環境をつくらなくてはいけない。
属人化を解消しないといつまでもチャレンジができない。
共通の目的は「開発チームの『当たり前水準』を上げ、安定した運用をするための土台を作る」としました。
共通の目的をコミットメント化
などを盛り込み、それらを3ヶ月で達成するようマイルストーンを置きました。
厳しいかなぁと思いましたがチーム全員の合意を取ることができました。
hotfixから恒久対応へ
共通の目的を高く置いたことで「とりあえず」という思考がなくなり、
「こういう依頼が来ているんですが、このように対応したほうが良いと思う」
「この作業は手戻りが多いから、フォーマットを作ってスムーズに連携したい」
そのような会話が出てくるようになりました。
「スクラムブートキャンプ」輪読会の実施
これまでもモチベーションクラウドではスクラムを取り入れてきましたが、ドラゴンハントチームではまだやっていませんでした。（hotfixだったので）
あえて輪読会を行ったのは以下のよううな理由です。
- あらためてドラゴンハントチームでスクラムを取り入れるにあたって、共通の認識を持ってスタートしたい
- 自分たちはどのようにやっていくかを考えたい
- 会議体、ロールなどが形骸化しないように「目的」を捉えよう
ロール、会議体ごとにセクションを分け、それぞれ発表資料を作成し、LTしました。
そこでこれまでリーダーと自称していた私の業務が、スクラムを取り入れるとなるとPO兼SM兼開発チームという状態になってしまうことが議題となり、SMを他のメンバーがやると挙手してくれました。
そして私はPO兼開発チームとなりました。
SMとなった彼はスムーズに業務を進行するためのbotの作成などをすぐにやってくれました。
デイリーでのProblem収集
輪読会の中でSMから「Problemは一週間またなくてもいつでも言えば良いじゃない」という提案がありました。そうだなと。「フライングKPT」と呼んでいます（Kないですが）
思い立ったときにSlackからつぶやいてスプレッドシートに連携。スプリントレトロスペクティブで振り返るという手法を取り入れています。
忘れないうちにあがるのでたくさんあがってとても良いと思っています。
ここで収集したProblemからTry（解決）を探していくことにしています。
FDL
この記事を書こうと思ったのは、スプリントレトロスペクティブで「ファン・ダン・ラーン」をやってみたことがきっかけです。
フライングKPTとは別にこれをやってみようと思ったのは、チーム状況が良いのはなんとなく分かっているので、こういう明るい振り返り手法を取り入れてみようと思ったからです（あと、個人的な趣味と興味です）。
ファン・ダン・ラーンをやり、その中からKeepしたいことを抽出してネクストアクションを作ろうとしました。
では、KPTやれば良いじゃん！となるかもしれませんが、大きな違いはファン・ダン・ラーンをやると、チーム状況が可視化できることです。
- ファン & ダン & ラーン（ど真ん中）が多い = ラーニングゾーン
- ファンに絡む物が多い = 仕事を楽しめている、心理的安全性が高い、チームの雰囲気が良い
- ダンだけのものが少ない = ただただ作業が完了するだけではない（以前のhotfixチームではない）
また、 ファン・ダン・ラーンを経てKeepを抽出しようと提案したときに以下のような発言がありました。
- 以前と違って考えて仕事ができているから、学びがある
-
もっとベロシティを上げられないか、もっと工夫できないか
Keepを出そうと思ったら、ポジティブなTryが生まれました。そしてすぐに着手。
ファン・ダン・ラーンをやったらうまく行くというわけではありませんが、今のチーム状況にはマッチしたのかなと考えています。
この1ヶ月強で起きた大きな変化を振り返る
「何でも屋のhotfixチーム」から「当たり前水準を上げるチーム」へ。
自分がやったことは共通の目的をアップデートしてファシリテーションをしただけですが、メンバーが大きく変化してくれました。
ファン・ダン・ラーンをやってみて、それを強く実感し、全部をまとめてみたくなりました。
今はプロセス改善が短期ゴールですが、今後CREチームにスケールしていけたら良いなと思っています。
コンサルティング同行で学んだ、エンジニアリングマネージャーとして新しい組織にジョインして取るべき姿勢
おはようございます。いしげ（@oturu333）です。
このブログは Engineering Manager Advent Calendar 2018 - Qiita 10日目の記事として書いています。
一般職からエンジニアリングマネージャーになり1年くらい経ったときに「ここでしかマネージャーができないんじゃないか」という思いになったことがあります。
知っている会社、プロダクト、メンバーだからできているだけじゃないかと。
そう思ったのは自分のやっていることを抽象化できなかったからだと、今になって思います。
その後コンサルティングに同行させていただく機会があり、外部の組織、人へのアプローチの仕方を間近で見て、コンサルティングの手法は新しい現場でマネージャーになるときにも使えるなと感じました。
今回はその学びをアウトプットしていきます。
エンジニアリングマネージャーの仕事だと思っていること
一言で表すならば、環境整備、仕組み作りだと思っています。
- 組織の三要素を満たす環境創り
- 共通の目的をもっていること（組織目的）
- お互いに協力する意思をもっていること（貢献意欲）
- 円滑なコミュニケーションが取れること（情報共有）
- スループットをあげるための仕組み作り
- 成長実感やビジネス貢献を感じられる仕組み作り
- 継続的な改善活動を行うための仕組み作り
- etc
これをはじめましての現場でやるにはどうしたら良いのか。
新しい組織に入って一番やってはいけないと感じていること
過去すべてやったことがあることですが、以下のようなことを気をつけています。
- べき論だけで議論すること
- 相手の知らない言語、舞台で話すこと（エンジニアではない人に対して）
- 受け身になってしまうこと
- 決めつけてしまうこと
逆に言うとこれらをしないということになるので「積極的にファクトを洗い出し、課題を見つけ、相手に分かりやすい言語で伝える」というプロセスを意識しています。
積極的にファクトを洗い出す
人を知る
一緒に働くメンバーがどんな人で、どんな技術があって、どんな仕事をしていて、どんな悩み、課題を持っているか。まずはそのあたりが知りたいです。
ただ「教えてください」と言っても話してくれる人は少ないと思うので、まずは自分から話すようにしています。
自分のキャリア、書いたブログ、こんな事を考えている、こんなことが得意 / 苦手だ、お酒が好きだ、こんな失敗をした、などなど。なんでも良いので、この人に話しても大丈夫だという信頼を得る努力をする必要があります。
主にやっていることは以下のようなことです。
- Slack の雑談板で一人語りしてみる
- ランチに誘ってみる
- なにか悩んでいることを話してくれたら、一緒に解決策を考える
- やると言ったことは必ずやって報告する
歴史を知る
新しく入った人にとっては不思議に感じるプロセスや文化も、だいたい歴史があります。
頭から否定するのではなく、その経緯や理由を詳しくヒアリングするようにしています。
ヒアリングをする際には以下のようなことを意識しています。
- 認識齟齬にならないよう、あいまいな言葉は意味やアウトプットを確認する
- 矛盾を感じるところは深く話を聞いてみる
- 歴史、現状と合わせて課題感を話し合い、認識を合わせる
- 議事録は終わった直後にパブリックな場所で共有する
あいまいな言葉は「大変」「複雑」「忙しい」というような個人によりけりなものだけではなく、一般的な言葉にも潜んでいます。
例えば「システムテストをしています」と言ったとして「システムテストだからこんなことをやるんだろうな」ではなくアウトプットまで見ないと認識がずれたりします。
総じて無邪気に、興味をもって話を聞く
誰かに何かを聞くときに「それってなぜですか？知りたいです！教えてください！」の姿勢が大事です。
例えば「どう考えてもおかしいなぁ」と思っても、斜に構えずに聞く姿勢のほうがお互いに話しやすいですし、提案も通りやすいからです。
「謙虚なコンサルティング」を読んでからこれを意識するようになりました。
謙虚なコンサルティング――クライアントにとって「本当の支援」とは何か
- 作者: エドガー・H・シャイン,金井壽宏,野津智子
- 出版社/メーカー: 英治出版
- 発売日: 2017/05/17
- メディア: 単行本
- この商品を含むブログ (2件) を見る
課題を見つける
環境整備、仕組み作りでいかに解決できるかを考えます。
すぐに100点になる必要はなく、最低限今より良い方向へ、最終的にこうなりたいまで考えられるようにしています。
相手に分かりやすい言語で伝える
例えばこのプロジェクトを提案したとき「サポート切れてるフレームワーク使ってるとかダメでしょ」と言っても伝わらない状況だったので、提案資料では技術的な観点にはほぼ触れませんでした。
サポート切れの状態のままでいることで起こりえるおそろしいできごと（例：エンジニアのモチベーションが下がることによる離職率増や伴って採用、育成にかかるコスト増）など、相手が共感できる話題を探して承認をもらいました。
まとめ：最終ゴールは「相手に動いてもらうこと」であることを忘れない
組織に属していると、人や組織との関係が深くなるにつれ感情的になり、主張をおしつけあってしまうことがあると思います（私はこれが大いにあります）。
ただ、コンサルティングに同行して強く感じたのは、私が本当にやりたかったことは「相手に動いてもらうこと」だったということです。
動いてもらうというのは「承認してもらう」「一緒にやってもらう」「誰かに何かをやってもらう」などです。
このゴールを失わないための姿勢を、コンサルティングから得ることができました。
1年半取り組んだWebプロジェクトマネジメントを振り返って、やって良かったこと、やっておけば良かったことをすべて書く
おはようございます。いしげ（@oturu333）です。
このブログは モチベーションクラウド Advent Calendar 2018 - Qiita 1日目の記事として書いています。
今回は過去私が1年半に及ぶWebプロジェクトのPMをした経験を語ろうと思っています。
この記事でお話することについて
プロジェクトの概要は既存のWebシステムの全面リニューアルです（MCSではありません）。
ざっとやっていたこと
- サービスをすべて作り直す（リプレイス）
- PHPのメジャーバージョン2つくらい一気にあげた
- CakePHP -> Vue.js + Laravel の構成に変えた
- AWS構成をがっつり変えた
- 一部マイクロサービス化した
- 機能の見直し、UI全刷新
- ドキュメントが全然なかったのでいろいろ作りつつ進める
当時の私の立場は、開発チームのマネージャーであり、今回お話するプロジェクトの企画者であり、PMであり、サーバサイドのエンジニアでした。
開発手法、プロジェクトマネジメント手法などの記事はたくさんあるのでここでは言及せず、当時の私自身も知りたかった、PMのより具体な部分「実際何をやるものなの？」を書いていきます。
また、PMと同時にマネージャーでもあったので、プロジェクト中にマネージャーとして意識していたことなどもまとめてみます。
そして最後に反省している点に言及します。
やってよかったこと
ピープルマネジメント
みんなで決めること、一部の人で決めることを分けた
このプロジェクトの企画骨子は私が作りましたが「こんなことやりたいんだけどどう思う？みんな何がしたい？」という意見を集めました。
PHPのバージョンの上げ方からお察しいただけるところもあると思いますが、プロジェクトの目的の一部として、だいぶ積もってしまった技術的 / 非技術的負債の抜本的な解消、そしてエンジニアのモチベーションのアップがありました。
長いプロジェクトになることは見えていましたし、人は誰かにやらされるのは嫌いなので「みんなで考えたこのプロジェクトを成功させよう！」というストーリーからモチベーションを作りたかったのです。
また、メンバーと仕事をする上で「この四象限の2つ以上を同時に達成する」ということを意識していたというのもあります。
その点で「メンバーと一緒に計画を立てる」はとっても素敵な案件で、人間関係、部下育成、仕事の改善が一気にできてしまいます。おすすめです。
タスクを依頼するときもただお願いするのではなく、一部のスケジュール管理と一緒にお願いしたり、設計からお願いしたり、コミュニケーションを取りながら進めたりすることで複数を達成できます。
目的をみんなで決めたことの副産物として、プロジェクトの方向性がずれそうだなとなったときにこの目的に立ち返ることができたことが良かったです。
「このAPIはこういう設計で良いですか？」
「その設計だと目的のこれに反してるからこうしたほうが良いと思うけど、なんでそうしようと思ったの？」
「実は…」
のような会話ができ、判断に迷うポイントが減りました。
逆にみんなで決めなかったことは技術採択やサービス設計など、要するに決めでしかないところです。みんなから意見はもらうところもありましたが、最終決定は少人数で行いました。
どこまでがみんなで決めるべきで、どこまでがそうでないべきなのかはっきり言語化できていません。今後のお題にしようと思います。
プロジェクトの事前準備
1. 参考になるプロジェクトの事例を集めて共有した
リニューアル、リプレイスなどの手法や、過去リニューアルプロジェクトを経験した方々の知見をあさりました。
特に以下の「backlog UI リニューアルの舞台裏」はリリース後にまで触れられていてとても参考になりました。
2. 事前にやらないことを決めた
やらないことを定義したのは以下の理由です。
- ただでさえリスキーなリプレイスという手段を選んでいるので、最大限リスクを回避するため
- 長期間プロジェクトのため内外からの要望に変化が起こる可能性が高い。もともとの要望を変えないため
具体的にやらないと定義したことは以下です。
- 既存スキーマの変更は基本行わない（リスクヘッジ）
- 変更してでもやるべきと判断できる改修は、現サービスに先行して反映させることをルールとした
- 新機能の開発（リスクヘッジ、要望変化への対応）
- 既存機能の拡張、縮小、削除はあり。ただし新規機能はなし
3. プロジェクト後（リリース後）の対応方針について定めた
事例調査や、自分たちの経験から「おそらくリニューアル後に十分な計測期間を取らないまま、元に戻したほうが良いという話になる可能性はあるよね」という議論になりました。（プロジェクトの性質上「戻す」のは無理なので、必死に直すことになりますが）
定めたことは以下のようなものです。
- リニューアル後はお問い合わせが増えるだろうし、批判的な意見も出るであろうということを「ほぼ確実に起こること」としてチーム全員に共有した
- 慣れたUIが変わるので仕方ない
- 一定期間の計測をしてから方針を判断するということの合意をとった
- 上記の内容を会社全体に周知
- 社内ユーザーからの声にも対応するため
4. プロジェクトゴールのその先について事前に語った
負債返却を含めたプロジェクトだったため、1→10というよりはマイナス→0でした。
「とりあえずスタート地点に立とう」と。
プロジェクトが始まる前から、プロジェクトのその後にやるべきことを平行して整理していこうという話をし
- 全員の方向性がずれないよう、事業のミッション・ビジョンの制定
- 負債をなるべく生まないためのルール、フローの整備
- ドキュメント作成と既存ドキュメントの整理
などを行いました。
メンバーもしんどい時期もあったと思いますが「これ終わったらこんな機能作るべきだと思う！」「デザインスプリントやってみたい！」など活発に話ができたのはとても楽しかったです。
進捗管理
1. 進捗は誰が見ても分かるようにした
ガントチャート（は作ってないですが）などを作成するも予実がずれていって、結局今の進捗はどうなってるの？という状態になることってありがちかなと思います。
予実を数値化し、今どういう状態なのか分かりやすくするようにしていました。
2. スモールステップの進捗目標を立て、週次で振り返った
プロジェクトの全体スケジュールが年超えだったので、月次の進捗目標を立てました。
しかしそれでも何かを改善するにはチェックポイントが足りないので、振り返りは週次で行っていました。
振り返りと言っても、数字をSlackでコメント付きで送るというものです。
オンスケだったら感謝と喜びのコメントを。遅れ気味だったら「なぜ遅れているか」の共有、実行中・考えている改善施策の共有などと、フォローのお願いなどを行いました。
3. コアメンバーで進捗について語り合うチャンネルを作り、改善策を出し合った
この板ではスケジュールコミットに関わるメンバーだけで以下のようなやりとりをしていました。
- 進捗が芳しくないときに、どうやってスピードを上げられるか（ボトルネックの特定）の議論
- 私が気づいていなくても「このままだとやばいと思います」というアラート発信
チャンネル内で話した、ボトルネック特定と解決策の例
- レビューに時間がかかりすぎる
- 画面デザインの仕様書が見づらい
- 複雑な画面から優先してZeplinへの移行を行った
4. 基本的にはロジカルに、たまに無茶なお願いをした
基本的には根性論で解決せず1つずつ課題に対処しましたが、これはあとはもう頑張るしかない！となった時もありました。
そのときは「友情・勝利・勇気」がキーワードになっていました。楽しかった。ランニングハイ。
アサイン調整、タスク管理
以下のようなことを工夫していました。
- 共通機能、複雑な機能はなるべく前倒し
- メンバーのアサイン時期を調整する
- 参考になる1つ目の処理は、技術力の高い人にお願いする
やっておけば良かったこと
事前にちゃんとお勉強することが必要だった
プロジェクトマネジメント手法を何も知らずにPMをしていました。無知ゆえに経験と勘ですべてをこなしました。
プロジェクトが終わってからCCPMなどについて勉強しましたが、もっとこうできたなと思うことがいくつかありました。
- なるべく早く終わらせたいという要求もあり、無茶な進め方をしたところがある
- 正しい進め方が分かっていなかったので議論ができなかった
- タイムラグのあるタスクを調整しきれなかったり
- CCPM を取り入れたり、要素分解してスケジュールを考えたりすれば、もう少し不安要素の少ないマネジメントができたかもしれない
- 検討漏れ（結合テスト後の修正の時間が特に大きかった）タスクが発生し、プロジェクトバッファをだいぶ食い尽くした
もともとあった開発プロセスの課題が顕在化した
進捗に遅れが出たときに発見されたボトルネックは、プロジェクト中だから発生したわけではなく、もともと存在していたものもありました。
プロジェクトの前に見つけることができていれば良かったなと思います。
- 気づいていたけど着手できていなかった問題も顕在化した
- 気づいていなかったものに関しては、マネージャーとして興味のチャンネルが狭かったなと感じる
1人で抱えすぎた時期があった
進捗を可視化しても感じ方はそれぞれで、私は「もうちょっと今はすすめないとなー」と思っても、メンバーはそうじゃなかったり。結果1人でタスクを抱え過ぎたりしました。
私のほうからコミュニケーションができなかったなと思います。
途中からメンバーとそういう話をするようにしてから、だいぶ楽になりました。
突然ですが、マネジメントのおもしろさについて少し語る
エンジニアとエンジニアリングをどのようにマネージメントしたらいいかが面白くて、知的で、リスペクトされる仕事にならないと怖いので誰もやりたくない仕事になってしまう。そうすると、いつまでもエンジニアリングの経営が日本に宿らない。だから #EMFM とかで少しでも面白い仕事だよと伝えたい
— 広木 大地/ エンジニアリング組織論への招待 (@hiroki_daichi) November 25, 2018
マネジメントは楽しいです（という引用…ｗ）ピープルマネジメントも、プロジェクトマネジメントも。
知的な仕事なのに人間味があって泥臭いところもある。
マネジメントをやるようになってから自己開示に勤しんだり、組織や人について知ろうと思うようになったり、自分の中の変化がたくさんあって驚いています。
自分が何をしたいのかを見つけられれば、エンジニアリングマネージャーは楽しいです。と思ってます。
この記事のまとめ
- 不確実性をへらすための事前準備
- プロジェクト運用に対する知識 ☓
- プロジェクトの方針の決定 ◯
- プロジェクト後の方針の決定 ◯
- スケジュール設定 ☓
- 事前から解消できる問題の回避 ☓
- プロジェクト中
- その他
- このプロジェクトのPMができてよかった ◎
- 辛かったけど楽しかった ◎
事前準備をしっかりやりましょう。お勉強しましょう。きちんと会話してPDCA回しましょう。目的があれば厳しい状況でも楽しめるので、全力で楽しみましょう！が今の私のまとめです。
このプロジェクトを始めるときに「しんどいこともあると思いますが、二度とこんなことやりたくないと思うようなプロジェクトにだけはしないようにしよう。せっかくの挑戦の機会を楽しもう！まぁ、二度と起こしちゃいけないけど」というようなことを言ったことを覚えています。
終わったあとに「まぁあと数年はやらなくても良いかなー」なんて話せたのも良い思い出です。
良い経験をさせてもらいました。感謝をこめてログを残しますm(_ _)m
ハッシュタグ #弊社のろけ話 のツイートから見えた、みんなが自社を好きな理由ベスト5
おはようございます。こんにちは。こんばんは。いしげ（oturu333）です。
ツイッターのハッシュタグ #弊社のろけ話 を眺めていたところ、これをまとめたらみんなが大好きになる会社の特徴が分かるのでは？と思ったので、なるべく具体的に集計、ランキングしてみました。
ランキングは2018/10/27現在のツイート121件を対象に、1ツイートで複数要素があるものは分解して出しています。
主観でカテゴライズしているところはあるのでご容赦くださいm(_ _)m
具体的なコメントは抽象的にまるめているものもあります。
第一位 人が好き
みんな大好き編
- 優しい、良い人が多い
- 自分だけじゃなく家族のことも思いやってくれる
- 褒めてくれる、認めてくれる
- 自発的に働ける人が多い
- 個性豊か
- 口だけではなく行動する人が多い
- 約束を守る
- 働きにくい人が少ない
上司大好き編
- 上司がフランク
- 優しくも厳しい上司が好き
- 上司が部下を鼓舞してくれる
- 社長がおもしろくて冗談が通じる
第二位（同率） オープンコミュニケーション
- 企画や事業にも意見が言える
- GithubやSlackの活用により、考えや議論をオープンにしようという文化がある
- 職種間、役職間の隔たりがない
- 意見が言いやすい。意見を尊重し合える
- 言いたいことを言っても引きずらない。建設的な議論ができる
- 意見や助けを求めると、みんなが議論に参加してくれる
第二位（同率） 適切な権限委譲 / チャレンジができる
- 提案したことをやらせてもらえる
- やりかたや手段（技術採択など）を自分で決められる
- 求める以上、経験以上の裁量を与えてもらえる
- 学んだことを実務でやらせてもらえる
第四位 福利厚生に満足
- 旅行プラン、娯楽施設が割引きで利用可能
- 社員旅行
- 職場飲食（ランチ、おやつ、飲み物など）が安い、無料
第五位（同率） 尊敬できる人が多い
- 尊敬できる先輩が多く学びがある、楽しい
- 社員全員Github使える
- 全員が自立している
- 本質的、長期視点の議論ができる人が多い
第五位（同率） 変化を恐れないマインド
- 未来志向ができる
- 内省ができる
- 悪しきルールは変えていく文化。変わることに抵抗がない
- 変化に協力的な人が多い。変えようと声をあげると協力者が多く名乗り出る
- 変化が多くて飽きない
第五位（同率） 仲が良い
- 仕事終わりに和やかにお酒を飲めたり、ゲームをしたりできる
- 上司をいじれる
- メンバーが会社になじめるよう、上司が手助けしてくれる
- おふざけできる
第五位（同率） 勉強を支援してくれる
- 通常業務内で成長のための時間を取れる
- 勉強会参加や本の購入などの予算が十分ある
- ランチLTがある
- みんなで切磋琢磨する空気がある
- 社内合宿がある
- 大量の本を置くための本棚を購入してくれた
番外編（順不同）
- オフィスの環境が良い
- オフィスの立地が良い
- 仕事のツール、環境（マシンスペックなど）に満足している
- 給与が適正 / 評価に納得ができる
- 休みが取りやすい
- プロダクトや事業内容が魅力的
- 役職者との物理的、心理的距離が近い
- ワークライフバランス
- フレックス制度
- 会議が少ない
- 部署や役職の希望が通りやすい
- 副業可能
- 服装、髪型が自由
- 仕事に関係ない備品を購入してくれる
いかがでしたでしょうか？
#弊社のろけ話 を眺めていると、自社を大好きな人が多くてほっこりします。
良い会社のエッセンスがぎっしり。ぜひツイッターも覗いてみてください。
調べてみたら思ったより少なかった！女性エンジニアの人数を算出してみた
はじめまして、いしげ（@oturu333）と申します。Web系のエンジニアです。
私のキャリアは未経験でエンジニアになったことから始まり、28歳でチームリーダー、29歳でマネージャーを経験し、今はフリーランスとしてIT企業のコンサルティングに同行したり、開発案件の受託をしたりしています。
エンジニアになってから「女性のエンジニアって珍しいよね」「自社に何人くらい女性エンジニアいるの？」という質問はよく聞かれましたし、
個人的には、同年代（20代・30代）女性エンジニアでマネージャー経験者はどのくらいいるのかなと気になっておりました。
肌感としては女性エンジニアも、マネージャー経験者ともに少ないことは感じていたので、定量的に理解しようと思います。
（今回は主にソフトウェアエンジニアに限定して調査しています）
1. 他職種と比較したソフトウェアエンジニアの女性比率の比較
IT人材を巡る現状について （データ編） / 経済産業省 情報処理振興課によると、IT技術者の女性比率は以下の通り。
ソフトウェアエンジニアの女性比率は14.4%です。
他職業と比較してもIT技術者の女性比率は少ないことが分かります。
2. ソフトウェアエンジニアの女性の数
ソフトウェアエンジニア人口は20代後半〜30代が最も多い層となっています。
女性エンジニアは上記の通り全体の14.4%で、46,610人です。
ソフトウェアエンジニアに限らず、IT技術者は他の職業と比較して平均年齢が若い傾向があります。
3. 日本企業の女性マネージャー比率
2017年国際労働比較 / 独立行政法人 労働政策研究・研修機構によると、日本企業全体においては、女性マネージャー比率は、12.5%です。
4. 日本企業における年齢別管理職割合
国勢調査によると、職業に係わらず30代女性マネージャーは0.2%です。
20代のデータはありませんが、40代になっても0.3%なので、20代も0.2%未満程度でしょう。
5. 以上の数字から、20代・30代女性エンジニアマネージャーの数を考える
この章はあくまで推測の数字になるため、悲観的、中間的、楽観的な数値を算出してみました。
それぞれにおいて、マネージャーのうちの10%が20代・30代だろうと仮置きしています。
5.1 悲観的観測
エンジニアは他職種と比較してそもそもの女性比率が低いです。
そのため、全職種の女性比率 : 女性マネージャー比率 = 43.2% : 12.5%
という計算式を、ソフトウェアエンジニア女性比に置き換えると、女性エンジニアマネージャー比率は4.98%。
この比率で計算すると、女性ソフトウェアエンジニアマネージャーは232人となります。
5.2 中間的、楽観的観測
3の数字を利用し、他職種と同じくソフトウェアエンジニアの女性の12.5%がマネージャーだとすると、20代・30代のソフトウェアエンジニアマネージャーは583人となります。
また、4の調査の数字を利用し、全体の0.2%が女性マネージャーだとした場合でも、932人となります。
まとめると、
悲観：232人、中間：583人、楽観：932人となりました。
エンジニアは他職種と比較して女性比率が低い上に、スペシャリストコースに進む方も多いため、悲観〜中間の数値が現実味があるのかなと思います。
6. まとめ
ソフトウェアエンジニアのすべての女性の総数は46,610人。
そのうち20代・30代は34,740人、さらにマネージャー経験者は多くて500人くらい。
ボリュームゾーンの20代・30代の中でもマネージャー経験者は1.4%。
100人の20代・30代女性ソフトウェアエンジニアに会って、1、2人会えるかどうか。
7. 感想 / および自分語り
現状なぜ女性エンジニア、マネージャーが少ないかについては言及しませんが、女性エンジニアが少ないことは、今後さらに女性が活躍しにくい環境を作るんだろうな、と想像します。
というのも、自身がマネージャーになるときも、本当はぎりぎりまでお断りしようと思っていました。
周りに女性エンジニア、及びマネージャーがいない（エンジニアでない女性マネージャーも少ない）状況で、自分に務まることなのか、結婚・出産などの未来を考える上でやるべきなのかという悩みがあり、また、相談する相手もいなかったからです。
そもそも、エンジニアの仕事は忙しいので、将来的にエンジニアを続けるべきかどうかも当時は迷っていました。
私の場合最終的にとりあえずマネージャーになってみた結果、なって良かったと思ってるんですが（笑）そういう悩みを相談できるコミュニティーなどを今後やっていけたら良いなと思っています。