はじめに

12/16に大田区産業ホールPiOで行われたPHPカンファレンス2018に行ってきました。
寝坊して14：00すぎに到着したのは秘密です…。
セッションは2つ半しか聞けませんでした。
フルで聞けた2つ分だけまとめておきます。



お金が必要な時にお金がある人生設計 〜エンジニアが企画力を身に着けたら鬼に金棒〜

吉政創成株式会社　代表取締役　吉政忠志さん

目次

  1. 自己紹介
  2. お金が必要な時にお金がある人生設計
  3. 企画書の書き方

1. 自己紹介

PHP技術者認定機構　理事長をされている方で、
徳丸試験（Webセキュリティの試験）を一緒に作るそうです。

2. お金が必要な時にお金がある人生設計

会社では、なにか新しいプロジェクトを始める時に必ず稟議を通す必要がある。
稟議というのはすなわち企画書である。
技術に明るいエンジニアが企画書を作ると地に足の着いた企画になる。

この辺は私も含め皆さん納得感があるように見えました。
今までいかに納得感のないプロジェクトに取り組んできたのでしょうね…笑

上長面接で企画書を出してみるとよい。
1回で折れないで何度も出し続けてほしい。

この発想はなかったなと思いました。
週1の1on1で一度チャレンジしてみたいです。
（さすがに毎週は出せそうにありませんが…）

3. 企画書の書き方

企画書の基本ロジック

「主張」「理由付け」「データによる証明」というロジックの三角形が重要。
理由付け：いいね、って思う理由
データによる証明：スケジュール、予算、人員体制、実績、方法論

主張の決め方

企画書を提出する相手が実現できる内容で、やりたいことでないと企画は承認されない。
Web上の挨拶、朝礼の挨拶、上長とその上長の会話等をヒントに考える。
例）
社長＝会社の戦略
役員・部長＝部門年間目標や戦略

相手の立場に立って主張を考える、ということですね。
確かに、相手にとって何がありがたいか？が企画が通るかどうかに直接的に関わりそうです。
直接企画に対してOK/NGを出せない人であったとしても、
その人からさらに上に通してほしいということであれば、
その人のことをちゃんと考慮する必要がありそう。

基本構成

  1. 現状と課題（理由付けの裏返し）←ここで心をつかむ
  2. 解決案（主張＋データ）
  3. コスト＆スケジュール（データ）
  4. 投資対効果（理由付け）

実際の企画書

派遣スタッフの教育に関する企画書を見せてくださいました。
1枚にきれいに収まるわかりやすそうな企画書でした。

奥義

企画を提出する相手が、普段使っている言葉を使用してフォーマルにDraftを作る。
違う言葉を使っていると、それだけで違和感になって距離が生まれてしまう。

これも先程の「相手の立場に立つ」ということですね。

長くてまとまってない企画書や、ロジックが苦しい企画書は読む気がしない。
基本構成にあげた各項目を1ページずつに収めた計4枚で構わない。

上司にレビュー時間をもらうと、却下されにくい。

一緒に時間を使って作り上げた企画書は、却下されにくいそうです。
なるほど確かに、自分もアドバイスをしたとなるとその立場上真っ向から切ることはできませんね…。

金曜の夜に上司の机に企画書を印刷しておいておくといい。

たしかに、なんとなく一息ついたタイミングでペラペラ〜なんてこともありそうですね。

最後に

とにかく数をこなすと良い。
またサラリーマンであればたとえ採用されなくてもいい流れが作れる。

企業で働くことを前提にした「企画書の作り方、提出の仕方」でしたが、
「相手に合わせて、相手の立場に立って作る」という大切なポイントを教えてもらえるセッションでした。



Webサービスを育てるための組織づくりと文化づくり

株式会社オミカレ　曽根 壮大さん

目次

  1. 自己紹介
  2. Webサービスを育てる
  3. 組織と文化とチーム作り
  4. 試行錯誤の奇跡

1. 自己紹介

株式会社オミカレは、婚活パーティの情報検索アプリを作成しているそう。

2. Webサービスを育てる

Webサービスは生き物で、常に成長し、変化するもの。
SNSでバズったり、予想しない使われ方をしたりと意図しない成長がある。

予想通りにはならないので、変化に強くなる必要がある。
障害対応を迅速に取れる体制や高速にPDCA回せるリリース体制を作ったり。

そういった特性を踏まえ、「育てる」という単語を使っているようです。
「これで安心」ってことはないんですね…。

3. 組織と文化とチーム作り

組織とは

共通の目的を持った集まりで、
ビジョンがあるから意図的に作られる（＝自然生成ではない）

チームとは

目的を達成するための集まりで、目的ありきで生まれるもの

組織はチームを内包する
組織がチームのカラーを決める

コンウェイの法則

組織のコミュニケーション構造がそのままサービスに反映される
良い組織が作れば、良い文化が作れる
良い文化が作れれば、良いチームが作れる
良いチームが作れれば、良いサービスが作れる

このあたりは最近私も実感していて、
全く簡単なことではないけれど取り組んでいかねばと思っています。

4. 試行錯誤の奇跡

組織は意図的に作れるので、決定権がある人が決めることができる。
組織が自由を与えられなければ、ボトムアップにはならない。
チームが自立すれば文化が作れる。
文化を作れれば、組織が変えられる。

上司によって裁量が与えられない場合は、チームは文化を変えられる。
そうすると、自然に組織が変わる。
組織とチームは相関。主従ではない。

どうしても組織が変えられない場合、変えてもらえない場合は、
チームから組織を変えていくことができるという勇気づけられる内容でした。
プレイヤーの立場から諸々を変えたいと思っている私からすると、
そうそう、まさにこれ！という一言でした。

マネージャーは組織から、プレイヤーは文化から変える

これ、非常に響きました。
今回はマネージャーサイドのお話でしたが、
PHPカンファレンス仙台でプレイヤーサイドのお話があるそう。
さすがに仙台には行けないので、資料だけでも見ておきたいです。

「適切なサイズの問題を設定する」

適切な問題が生まれれば、自然と解決する人が生まれる
これはOSSに似ている。

  • 細分化する
  • 適切な人をアサインする
  • 解決できるように人を育てる ※誰も解決できないとき、だれも適切なサイズでない

人が成長できるタイミング

  • 行動をしたとき
  • 振り返ったとき
  • 限界を超えたとき

自分の限界は自分が決める。
限界よりも少し大きな問題にチャレンジできる文化を作る。
「少し大きな問題」で「文化」を作ることが重要。

どんな問題が起こっても放置でいいというわけではないし、
解決できるような環境を作ってあげないとそもそも解決はできないと。
マネージャーの立場だったら、
チームに裁量を与え、心理的安全性を確保しないといけないのかなと思います。

問題がチームや文化を作り、そして組織を変える。
プレイヤーの本質は問題解決。
マネージャーの本質は問題提供。

適切な問題を用意して、チャレンジを評価する。
適切な問題設定ができれば、Webサービスは育つ。

失敗を恐れない文化、組織を作らなければ、チャレンジは生まれないということ。
日本人の性質もありますが、なかなか難しいところです…。

5. まとめ

適切な問題とは何かを常に考える。
答えは常に変わる。

考え続けることが大切なのでしょうね。
なかなかしんどいなと思いますが考えなくなったら終わりでしょうね。笑

チャレンジしているか？
あなたにとって適切な問題はなんですか？
適切な問題を解決するのはプレーヤー。
技術で解決していきましょう。

最後の問いかけと一言はドキッとしました。
マンネリしていたし、なかなか技術で解決できずにいたり…。
でも、技術者なんだからコミュニケーション的な問題ももっと技術や仕組みで改善していこうと心に決めました。



終わりに

PHPのカンファレンスなのに、まとめの内容はPHPが一回も出てきませんでした。
業務でPHPを利用するので申し込みましたが、
私の関心事は企画やチームビルディングなんだなと改めて感じさせられました。
（こうなった主な原因は寝坊ですが…）
とはいえ1エンジニアとして、
これらは技術との両輪で学びを深めていけたらと思います。

スポンサーリンク