大西ブログ

All your blog are belong to us

父さんまたブログを書こうと思うんだ

長く更新していないブログを再開するのは、行きつけだったが足が遠のいてしまった飲み屋の暖簾を久しぶりにくぐるような気まずさがある。聞かれてもいないのに「最近仕事が忙しくてね…」なんて言い訳をしてみたり。

この記事はそういった類のものである。言い訳と自分語りが苦手な人はここで引き返してください。

TwitterがXになり、ポストTwitterサービスも盛り上がっている。いくつかそれらのサービスにアカウントを作ってみたものの続かず。SNSもいいけど、やっぱりブログを書こう、自分の折々の気持ちをちゃんと書き残そうと改めて思ったのであった。

近年、ブログもSNSも全然更新しなくなってしまった。
なぜブログを更新をしなくなったかを振り返り、過去を乗り越えて、またブログを書いていこうというセルフリハビリテーションのためにこの記事を書いている。

2018年8月30日

話は5年ほど遡る。2018年の私は非常に胃を痛くしていた。2011年にはてなブログを立ち上げたときから、いつかはなさねばならないと思っていた、はてなダイアリーを閉じるという宣言をするのだ。

ユーザーの皆さんからの反響も大きかろうと覚悟をしつつ、それをどのように伝えるかは悩ましい事柄であった。信頼のおける同僚に編集を手伝ってもらいながら、どういう内容をどういう語り口で伝えるかは試行錯誤の末に最後はえいやと投稿した。

この記事には沢山の反響が寄せられた。かなり悪い想像もしていたが、その悪い想像に比べたらずっと温かい反応だった。それでも、惜しむ声や悲しむ声、たまに怒りの声もあった。

この記事への反応に限らず、いろいろな場面でお叱りを受けることも多くなった。十分覚悟していたとはいえ、別の文脈で油断していたところに不意に出くわすと、思わぬダメージになったりもした。覚悟も準備もどれだけしても、し足りないことがある。

一方で、記事の反響が大きかったことにやや興奮もしていたその日、Facebookにこんな投稿をした。

今日は1000ブクマ集め、TwitterトレンドとYahooニューストップを飾り、たくさんの実績を解除できました

この投稿には、たくさんの労いや励ましの言葉をもらった。直前に胃が痛かっただけに承認の言葉は天に昇る心地がして有り難かった。恥ずかしながら言うが、この投稿へのコメントはその後心が折れそうな時に何度も読み返して励みとさせてもらった。

たいへん有り難かったのと同時にこの時、「SNSは麻薬」という言葉が頭に浮かんだのだった。

エンジニア文脈で「キャッシュは麻薬」というフレーズがあるが、同じノリだ。インターネットの荒野で風雨に晒されることに慣れていたつもりだったが、実際に晒されている最中に不意に出くわしたオアシスで飲んだ水は随分と心に染み渡った。甘美な味は、それに慣れると危険だという警鐘を心のなかで小さく鳴らした。この甘い水を飲んでいていいのか。慣れてしまうともう戻れないのではないか。

2018年10月4日

終了の告知から5ヶ月の間に、ダイアリーのブログへの統合へと方針を定め、「ブログ統合プロジェクト」と名付けた。そして書いたのがこの記事。ダイアリーに書かれた記事をなるべく損なわずにインターネットに残したいということと、それを著者が将来にわたって編集やあるいは削除できる権利を保有できる状態を保持するのがベストだと考えた。

この決断にもたくさんの励ましと、そして批判もいただいた。多くの方にはさっき書いた意図を理解いただいたと思うが、やはり強制的な措置であるし、強引さの自覚もあった。
この頃、不意にもらう批判に慣れると同時に、自分からなにか積極的に発信していこうという気持ちになれなくなってもいた。

2019年1月29日

さらに時は流れ、ダイアリーのブログへの統合は粛々と進んでいった。この日、まだいくらかのサブシステムが動いているものの、「日記を書く」という機能を閉じたその瞬間は今も記憶に残っている。

オフィスでいつも通りの軽い口調で機能クローズのデプロイを指示し、何事もなかったように業務を終えた翌日に、Facebookに投稿しようとしてテキストエリアに書いたまま、投稿ボタンをついに押せなかった文章がこちら。

はてなダイアリーを終えてブログに統合すると発表し、粛々と準備を進めている。
昨日はついに更新機能を停止し、新しい記事というものが生まれなくなった。
後継サービスのはてなブログはダイアリーを遥かに上回るアクティブユーザーで盛り上がっている。
それでも、ダイアリーを止めることは自分で自分の子の首を絞めるような罪悪感に駆られ、SNSでの発言もあの日を境に激減し、昨夜は悲しい気持ちで夜中にエンジニアの作業を見守った。我ながらチキンで情けない。せいぜい今はこの気持ちを大事にして、統合後にやってよかったと思える世界を実現したい。

これをテキストエリアに書きながら、投下したらまたいいねが沢山つくかな、と思う自分がいた。今、まさに麻薬に手を染めようとしているなと思ってしまって、投稿をやめ封印して今に至った。

投稿できなかったのだからそのまま忘れ去ればいいのに、下書きを残して今このように開陳しているのは我ながら自己愛や開示欲が強くて赤面する。

2023年11月

唐突に現在に戻る。結局、このブログに2018年から本日まで、4記事しか書いていない。

会社役員になったり立場が変わって話せることが減ったこともある。でも、折々に書きたいことはあり下書きも溜まってきた。この記事も何年も前に書き始めた下書きを掘り起こして今書いている。

先日、YAPC::Kyoto 2023 に登壇し、自分の内面について話す機会を持った。この記事はあの登壇と同様に、自分の中で長年溜まった澱や膿なのだ。それを吐き出すことで、止まっていたものをまた動かしたいと思っている。

最後に

そんなこんなで、ブログを長く止めてしまい、また書こうとしている。

父の名前をググってこのブログを見つけた私の子どもたちは、何年も更新されてなくがっかりしているだろう。君らが生まれた日のことをブログに書いていたけど、君らの成長をあまり綴れなかったのは興味を無くしていたからではない。

上の子は来春から進学して一人暮らしをしたいと言っている。成長を驚き喜ぶと同時に、塾や学校の送迎中にぽつりと話すようなコミュニケーションすらなくなってしまうのは寂しくもある。今後は別の方法で、父の様子を知ってもらいたい、一方的にでも。

書かなかった言い訳はもう十分書いたし、これから父さんまたブログを書こうと思うんだ。

YAPC::Kyoto 2023 に参加し、キーノート喋ってきました裏話

ブログを書くまでがYAPC!!ということで、YAPC::Kyoto 2023 に参加し、恐れ多くもキーノートを話す機会をいただいて喋ってきました。

資料はこちらですが、資料に書いてない喋った内容が本題なので、そのうち動画が公開されたらそちらで見てください。→ 4/10 追記 公開されました!


発表者ノートつきのkeynoteオリジナルファイルは社内に共有しているので興味ある人は入社してください。 → 採用情報 - 株式会社はてな

YAPC::Kyoto 2023 感想

久しぶりのオフラインイベント楽しかったですね!懐かしい顔がたくさんあって同窓会みたいでした。Perlの同窓会でもあり、はてなの同窓会のようでもあった。
charsbar さんが最新の Perl の話をして、dan さんが正規表現の話をしたり発表にツッコミ入れたり、nekokak さんのエモい話を聞いて、爆笑LTを聞いて、と、久しぶりにYAPCに来た!という気持ちでいっぱいになりました。miyagawa さんが来るの知らなかったので会えてびっくりしました。naoya さんが来られなくて残念。
キーノートを指名いただき、緊張して発表しましたが、多くの方に良かったと言ってもらえてありがたかったです。「僕も頑張ろうと思いました」と感想を言ってくれる人が何人もいらっしゃって。まさに、そういう話をしようと準備したので良かったです。
聞いてくれてありがとうございました。

キーノートの裏話

構想2年制作2日

もともと、YAPC::Kyoto 2020 のときにキーノートのお声がけがあり、その時から暖めていたネタです。
聞いていただいた方はわかると思いますがエモーショナル成分多めのため、話す内容はだいたい決まっているけど、なかなかテンションが上がらず、結局直前2日間で一気に資料を作成しました。進捗が悪かったため社内の人にはご心配をおかけしました。

顔面神経麻痺

1月の末くらいから、顔面神経麻痺になってしまい現在治療中です。顔の右半分が麻痺してほとんど動かない状態からだいぶ回復してきた感じです。まだちょっと話しづらいところもあるので、トークの最初にお断りを入れようかと思ったけど余計なノイズだなと思ってやめておきました。

気をつけたこと
  • YAPCへの感謝と、できれば聞いてくれた人を励ます内容にする
    • できたかな?
  • 自虐になりすぎないように
    • 全体として自虐トークだったわけですが、自虐が過ぎると不快に思われる方もいるだろうと、最低限に留めました。はてなにはずっと優秀なエンジニアが揃っているので、劣等感が育つ機会は多かったのですけどね
  • 自慢になりすぎないように
    • 逆に、頑張った自慢、大変だったマウントにならないようにも気をつけたつもりです
  • 人とサービス
    • 20年間を彩ってきたたくさんの人について話し始めると40分なんてあっという間に終わるので、登場人物を相当絞らせていただきました
    • また、20年間を彩ってきたたくさんのサービスについて話し始めると以下略

スライドの最初の方に出てくる表だけ見ながら何時間でも話せますね。そういうイベントがあったら呼んでください

テーマソング

たまたま最近 LiSA さんの曲をデビュー当時から順に聴くというマイブームがあって、彼女のソロデビューアルバム「Letters to U」収録1曲目、「Believe in myself」の歌い出しの歌詞

いつか この曲聴いた 誰かが今を 愛せたらいい

が、ばっちりシンクロしてしまったので、この曲をテーマソングとしてずっと聞いてました。もし私のトークを聞いた誰かが今を愛せたらいいですね。

特別付録

スライドにある表の元シートを公開しております。

最後に

YAPC::Kyoto 2023 参加者の方、実行委員の方お疲れさまでした!
そして、キーノートという滅多に無い機会をいただけたことを感謝します。配信を家族で見てくれたようで、子どもに親の仕事を知ってもらう機会にもなりました。
ではまた、次のYAPCでお会いしましょう。

はてなのエンジニア×人事の取り組み

久しぶりにブログを書きます。
この記事は、はてなエンジニア Advent Calendar 2022の22日目の記事です。

本記事は、株式会社はてなにおけるエンジニア×人事の取り組みを紹介するものですが、前置きとしてエンジニアだった私が人事部長になった経緯も書かれています。自分語り長文注意。

まず、私は

id:onishi です。はてなの創業メンバーの一人で、現在は取締役、組織・基盤開発本部長、人事部長などを兼任しています。加えて言うとおたくです。

2001年の創業から10年ほどはアプリケーションエンジニアとして、はてなの初期サービス群や、受託部門のエンジニアリングを担当していました。
2006年にはてなで初めてのチーフエンジニアという肩書を持ち、エンジニア組織のまとめ役をしていました。
2011年からエンジニアを主務から外し、この「はてなブログ」の立ち上げディレクターをやりました。
その後、事業責任者やサービス開発全体の責任者を経て、現職に至ります。

人事部長になる

2022年5月の 組織変更及び人事異動 (PDF) で、組織・基盤開発本部長、人事部長を兼任することになりました。
エンジニアからサービス開発のディレクションやチームマネジメント、事業推進、会社の経営執行と、業務の幅を広げてきました。
その際に、やはり自分のベースはエンジニアであり、エンジニア的な視点、アジャイルな姿勢は職種によらず傍らにあり、未知の領域に飛び込むときも、まずは自分で触ってみること、改善のサイクルを回すことを意識してきたのかなと思います。

2022年7月期 通期決算説明会資料 (PDF) にも、「取締役の大西を、組織・基盤開発に専念。エンジニア出身であることを活かし、開発陣含めた全職種の採用・配置・育成に手腕を発揮することを期待。」と書かれています。プレッシャーがでかいぜ。

組織・基盤開発って?

ところで「組織・基盤開発本部」ってあまり耳慣れない組織名だと思いますが、今回新たに立ち上げた部門です。
組織開発と基盤開発の両方を管掌することで、全社の事業を推進することを企図した本部です。具体的な管掌部門とその役割は以下のものがあります。

  • 組織開発(人事部)
    • 採用
    • 労務
  • 基盤開発(プラットフォーム部)
    • サービス基盤 (たとえばはてなID・はてなスターなど)
    • システム基盤 (たとえばインフラ・クラウド管理など)
    • 情報システム
  • 職能組織
    • エンジニア
    • デザイナー
    • カスタマーリレーションプランナー

気持ちとしては、コーポレートと事業の間を全部やる、という意気込みです。

インターネットに新しいもう一つのオフィスを作る

本部ミッションとして掲げたフレーズが「インターネットに新しいもう一つのオフィスを作る」です。
フレキシブルワークスタイル制度」を導入し、リモートワークも増え、働き方も変わってきました。出社率は平均10%程度という状況です。そんな中、実オフィスだけでなく、インターネットこそが新しいもう一つのオフィスである、と考えれられます。
そんなインターネット上の新しいオフィスで一緒に働く仲間を増やし、オンラインで労務を管理し、サービス基盤やシステム基盤、社内の情報システムを整備・運用し、快適なオンラインワーク環境を整えていくこと、それらを組織開発と基盤開発を横断して行うことが当本部の役割だと考えています。

やっていること

もともと事業側から採用に関してはコミットしていたのですが、人事部長になってまずは一通り自分もメンバーの一員として振る舞うことにしました。母集団形成、エージェント・媒体対応、候補者対応、日程調整、面接、オファー、オンボーディングと、全ての工程に関わっていますし、自分の手もまあまあ動かしてます。
事業側、採用人事側の両面の事情がわかることで、効率化を進めました。何がボトルネックになっているのか、ボトルネックを解消するためのワークフローの改善から取り組みました。

採用において重要な指標となる応募から内定呈示までのリードタイムの計測と改善は特に採用率・採用数の向上に貢献したという感覚があります。一緒に業務改善に取り組んだ id:motemen が採用管理システムのデータをインポートしたBigQuery やそのコネクテッドシートでの分析の仕組みを整えてくれたことも大きなポイントでした。リードタイムだけでなく様々な数値上の分析と、分析に基づく仮説検証という武器が得られました。

採用サイトでも、エンジニア採用専門の特設サイトを拡充したり、社員インタビュー・座談会コンテンツを増やしたり、エンジニア採用の採用ピッチ資料も作成してもらいました。

採用以外では、人事データの一元管理とその活用を進めました。サービス基盤部門が協力し、SmartHRのAPIを活用して、社内システムを制作し、業務改善に進めました。

人事データを活用したシステムの例としては、はてなのユーザーアカウントシステムにスタッフの特権フラグを自動で付与・解除するシステムであったり、組織別トラックバック一覧の自動生成であったり、報酬通知書の作成システムであったり、幾つも実際の業務に取り入れることができました。

アウトプット推進

人事を中心とした取り組み以外にも、エンジニアの情報発信には長年力を入れてきました。
Hatena Developer Blogの運営は、チーフエンジニアを中心に、楽しくアウトプットをサポートすることに尽力してもらいました。また、社内の編集者からも支援を受け、コンテンツの品質向上に貢献してもらう体制を確立してもらいました。中でもはてなで働くエンジニアにアンケート連載は、社内の編集者の強いサポートを受けて運用できています。

エンジニアを中心に普段の姿を気楽に伝える新しいチャネルとして、ポッドキャスト Backyard Hatenaを始めたのも、この1年の出来事でした。「社内の雰囲気がわかる」と求職者の方からも好評の声をよくいただきます。

技術勉強会、Hatena Engineer Seminar もチーフ×エンジニア×広報×企画の有志チームで定期開始を実施、毎回クイックにレポートに書き残すことで、やるだけではないコンテンツ化にも取り組んでもらいました。



などなど、たくさんの取り組みがありました。自分が主となったものもあれば、完全にお任せしたものも多数あり、多くの人を巻き込んだ取り組みができたなと感じています。役員が人事に、特に採用にコミットするという姿勢を見せ続けられたことが一番できたことかもしれません。

できたこと・できていないこと

採用リードタイムを始めとした、採用フローにおける数字面の改善は大きく結果に影響したと感じています。フロー改善により、単純に選考回数も倍増できましたし、伴って採用数という結果にも出ています。採用数が◯人に!前年比◯倍!とわかりやすい結果が出ていますが詳しい数字はこの場では控えます。

また、こうした取り組みや、その結果の成果については、外部からの表彰という形で顕れたことも良かった出来事でした。
Owned Media Recruiting AWARD 2022 by Indeedでは、特に情報発信について高く評価いただき、グランプリを受賞することができました。企業のオウンドメディアを推進する会社として、自社の取り組みがこのように評価されたことは大変うれしかったです。

一方で、まだまだできていないこともたくさんあります。

たとえば採用フローもまだまだ改善ができると感じています。手作業を自動化していくこと、ボトルネックを徹底してなくす。採用の各フェーズのコンバージョンは現時点でも悪くない数字ではありますが、さらなる改善・向上の余地があります。
アウトプットについてもより推進していくべく、「アウトプット表彰」という新制度を考えました。一般に人材紹介手当を出す会社は多いと思いますが、「採用に結びついたアウトプット」を表彰する試みを始めました。
そういった新しい試みは常に仮説を立てて、試してみて、結果を見て改善する、というサイクルを回していきます。
組織開発と基盤開発の横断的な取り組みもまだまだ発展の余地があります。現在「組織・基盤開発合宿」として不定期に組織の課題を技術で解決するというテーマでハッカソン的なイベントをしていますが、これもより戦略的に、大きな課題を解決できるようになりたいですね。
そして、人事組織自体の強化もこれからです。今、超少人数で超高効率を実現していますが、これをスケールさせるのが次の課題です。

さいごに

というわけで、いろいろやっているわけですが、冒頭にも書いたように、自分のベースはエンジニアであり、エンジニア的な視点、アジャイルな姿勢は職種によらず傍らにあったなあ、と一年を振り返っても再実感しています。そして、エンジニアもディレクターもそうだったように、人事という新しい仕事も楽しいと思えたのが何よりの収穫でした。
まずは手を動かしてみる。動かしながら学ぶ。仮説を立ててそれを検証する。小さいサイクルでリリースをする。そういった姿勢は、多くの場面、たとえば採用人事といった場面でも強みとなるなと感じています。エンジニアのみなさんの活躍する業務領域は、みなさんが思っているよりも遥かに広大で、いろんな領域にそれぞれのやりがい、楽しみがあるのだと思ってもらってもいいのではないでしょうか。

はてなでは、事業を牽引するエンジニアも、それを支える人事も募集しています!特に一緒に人事をやってくれる人はご連絡ください!

以上、はてなエンジニア Advent Calendar 2022の22日目でした。
昨日の記事は、私がキーノートを務めさせていただくYAPC::Kyoto 2023のコアスタッフでもある、id:papix による「カンファレンスの中の人」でした。
明日の記事は、id:yajimasan です。お楽しみに!

小学校高学年の子どもに読ませている本

この記事は何らかのアドベントカレンダーに参加している記事ではありません。
近年はアドベントカレンダーに参加してやっと年一記事を書くという体たらくですが、今年はアドベントカレンダー参加にもミスってしまった。けど何か書いてみる。

現在我が家には中2、小6の子どもがいる。自分が子どもの頃そうであったように、願わくは本好きに育って欲しいと思って、なるべく欲しがる本を買い与えたり、本を勧めたりしています。そんな事を書いてみます。

ちなみに記事の著者の小説の好みはこちらに詳しいですが、古いし偏ってます。

「子どもを本好きにするには」

絵本館の五味太郎さんのポスターの「子どもがどんな本をえらんでも、けっしてもんくを言わない」。これが真理で、これに尽きると思う。
( 参考: http://ehonkan.co.jp/download/honzuki_poster.pdf )

かのスタージョンの法則に「どんなものも、その90%はカスである」とあるけど、90%のカスの経験が10%の価値を知ることにつながると思っている。また何がカスで何が価値があるのかを決めるのも、経験から自分で決めること。
というわけで、子どもが欲しがる本は特に止めずに与えるようにしてる。マンガでも。下の子は気づくとジュニア空想科学読本を読んでます。面白いけど、18冊も読むかねとか思う(けど言わない)。

子どもが最近読んでる本

小6, 中2ごちゃまぜで(お互いの本を読み合ったりしてるので)

レーベルで本を選ぶ

上述のように、角川つばさ文庫をよく読んでるけど、宗田理のような古いものもあれば、新海誠の映画原作もあったり、バラエティ豊かで面白いなーと思った。
子どもも、同じレーベルは手に取りやすいので、意外と読書の幅が広がるきっかけになる。

古典ジャンル小説もある

古典なんだけど絵が今風になっていて面白い

ラノベの再パッケージ化もある

ラノベ自体がニュージャンルだと思ってるおじさんなのに、それが再パッケージされてすごい(って20年とか経ってるんだけど)

ハルヒって、スニーカー文庫、つばさ文庫、角川文庫と3レーベル制覇しててすごい。

子どもに本を勧める

子どもが読む本は全部ではないけど自分も読むようにしてて、本の感想を言い合ったりしてる。そうやって読書信頼関係をもっておいて、時々そっと本を勧めてみる。嫌がられたら深追いはしない。
失敗例もあって、森博嗣を勧めようと書店で「すべてがFになる」を手渡したら、あらすじがこう。

孤島のハイテク研究所で、少女時代から完全に隔離された生活を送る天才工学博士・真賀田四季(まがたしき)。彼女の部屋からウエディング・ドレスをまとい両手両足を切断された死体が現れた。偶然、島を訪れていたN大助教授・犀川創平と学生・西之園萌絵が、この不可思議な密室殺人に挑む。ミステリィの世界を変えた記念碑的作品。

「ウエディング・ドレスをまとい両手両足を切断された死体」で拒否反応を示して中を見ようともしてくれなかった。
この経験を活かして、人が死なないミステリを勧めようと、「ビブリア古書堂」とか「古典部シリーズ」とかを勧めてそっちはうまくいったのであった。
そのうち、人がバンバン死ぬミステリも勧めたい。その次はSFミステリを経由してハードSFも読ませたい、と夢が膨らむ。

まあそんなこんなで、本好きになってくれてうれしいという話でした。おしまい。

プロジェクト計画について思うこと

この記事は、はてなエンジニア Advent Calendar 2018 の3日目の記事です。
昨日の記事は, id:t_kyt の「time_zone設定の違うMySQLのレプリケーションについて - 角待ちは対空」でした。

最近のわたし

アドベントカレンダーでしかブログを書いてない有様の id:onishi です、こんにちは。最近はこんなことをしています。

はてなダイアリー終了とブログへの統合、利用いただいているユーザーのみなさんへの影響も大きいですし、15年続いたサービスの終了とコンテンツの移転はプロジェクトとしても大きいものです。

オープンなプロジェクト計画

というわけで、わりと雑な僕でも本プロジェクトについては、利用していただいているユーザーの方にも、社内にも、チームメンバーにもプロジェクトの意義を説明できるように、プロジェクト計画書を作り、社内に公開し、さらにそれを作る過程も社内に公開しながら進めました。
そこから得られた知見や気付きをブログにもまとめてみようと思い、本エントリを書いています。

PMBOK

今回、計画を立てるにあたって「プロジェクトマネジメント知識体系ガイド」いわゆる PMBOK (Project Management Body of Knowledge)を参考にしました。

15年続くはてなダイアリーは、社内外にステークホルダーも多く、十分な整理が必要と感じたので、より教科書的なアプローチを試み、それを社内に共有しよう、と思ったのでした。

PMBOK における 5個のプロセス群

PMBOKはプロジェクトマネジメントの知識体系であり、扱う範囲は大きいです。具体的には以下の5つのプロセス群に大別されます。

  1. 立上げプロセス群
  2. 計画プロセス群
  3. 実行プロセス群
  4. 監視・コントロール・プロセス群
  5. 終結プロセス群

今回はひとまず、この1,2番目の「立ち上げ」「計画」両プロセス群について、PMBOKを参考に「プロジェクトマネジメント計画」を立てるということをしました。

PMBOK における 10の知識エリア

またPMBOKは各プロセスをマネジメントの対象により10のプロジェクトマネジメント知識エリアとして分類しています。

  1. プロジェクト統合マネジメント
  2. プロジェクト・スコープ・マネジメント
  3. プロジェクト・スケジュール・マネジメント
  4. プロジェクト・コスト・マネジメント
  5. プロジェクト品質マネジメント
  6. プロジェクト人的資源マネジメント
  7. プロジェクト・コミュニケーション・マネジメント
  8. プロジェクト・リスク・マネジメント
  9. プロジェクト調達マネジメント
  10. プロジェクト・ステークホルダー・マネジメント

プロセス群と違い、知識エリアについては、全ての知識エリアについてプロジェクトの計画を行います。

プロジェクトマネジメント計画書

PMBOKに沿って、10個の知識エリアについて考えそれぞれについてのマネジメント計画を「プロジェクトマネジメント計画書」として作成しました。
書いてみて思った、特に意識した知識エリアについてピックアップしてみます。

1. プロジェクト統合マネジメント

各プロセスを束ねるためのマネジメント、メタな感じですね。このエリアにおいて「プロジェクト憲章」を定め、プロジェクトに迷いが生じた時に立ち戻れるポリシーを定めることが大事です。

実際のプロジェクトにおいて、日々の判断が必要であり、その判断の根拠となりうる、プロジェクトの価値観を明らかにすることは非常に大事だと思っています。リーダーが間違った判断をすることがあっても、価値観をチームで共有できていればメンバーから「それは違う」と言い出せます。そういうチームが良いチームだと思います。

3. プロジェクト・スコープ・マネジメント

プロジェクトのスコープ、つまり何をするかを定義することは、逆に「何をやらないか」を定義することでもあります。

定義が曖昧な時、しばしば起こるのは「作りすぎ」だと思っています。世の中はやれるならやった方がいい事に満ち溢れていますが、全部やってたら終わらないのです。
同様のものに「5. プロジェクト品質マネジメント」があります。必要な品質を満たし、でも過剰品質とならないこと、を意識します。

8. プロジェクト・リスク・マネジメント

プロジェクトの想定されるリスクについてマネジメント計画を立てます。
リスクについて予想するけど対策しない、ということは結構あります。「回避」「転嫁」「軽減」「需要」の4タイプに分けて、想定されるリスクに対して対応戦略を考えます。

たとえば今回のプロジェクトだと、「古いサービスを整理するので思ってもみない仕様がでてきて想定していた工数では足りない」みたいなリスクを想定した場合、「回避」対応としては「単純に工数をもってくる」とか、「軽減」対応として「ある程度の仕様について諦める」といった態度が考えられます。プロジェクト計画の段階で、リスクに対する対策を決めておくのは、実際にリスクが顕在化したときにスムーズな判断を助けてくれます(くれました)。

10. プロジェクト・ステークホルダー・マネジメント

プロジェクトに影響する人を特定しておき、マネジメント戦略を立てます。

このプロジェクトでは「ユーザーさん」から社内の各部署まで、多数のステークホルダーを設定し、関係性を明確にしました。
歴史のあるサービスは当然関係者も多く、何かの決定が思わぬ影響を及ぼしたりすることがままあり、ステークホルダーを整理しておくことで、連絡漏れとか思わぬ影響といった事故を未然に防ぎたいです。

その他の知識エリア

と、4つほど取り上げてみましたが、その他のエリアも重要ですので、軽視せずプロジェクト計画したいですね。

プロジェクト憲章とインセプションデッキ

さて、プロジェクト憲章を作るに当たって、チームメンバーから「インセプションデッキを作ろう」という声が偶然タイミングよく出てきました。そこで、プロジェクトマネジメント計画書における「プロジェクト憲章」をインセプションデッキとすることにしてみました。
インセプションデッキは「アジャイルサムライ」で紹介されたことでも有名な、プロジェクトの開始時に定義すべき10個の質問・回答集です。

インセプションデッキの質問

  1. 我われはなぜここにいるのか?
  2. エレベーターピッチ
  3. パッケージデザイン
  4. やらないことリスト
  5. プロジェクトコミュニティは...
  6. 技術的な解決策の概要
  7. 夜も眠れなくなるような問題は何だろう?
  8. 期間を見極める
  9. トレードオフ・スライダー
  10. 何がどれだけ必要なのか

これは、実際に立ててみたプロジェクトマネジメント計画書の項目とほぼ一致するものでした。「やらないことリスト」は「スコープ・マネジメント」、「プロジェクトコミュニティ」は「ステークホルダー・マネジメント」、「夜も眠れなくなるような問題」は「リスク・マネジメント」そのものですね。
そもそも体系化されたプロジェクトマネジメント知識は、アジャイルな開発における計画においても有効であり、参考にされているものだということですね。ちなみに、PMBOK6版においてはアジャイルについての解説が強化されています。

両方やって思ったことは、以下のようなことです。

  • PMBOKにおける「プロジェクトマネジメント計画書」は、方法論がしっかりしていて、これに沿って書きやすい、と感じた。一方で扱うプロジェクトの範囲が、小さなものから大きなものまで幅広いため、資源やコストのマネジメントについては(今回は)オーバースペックに感じた
  • 「インセプションデッキ」は、要素としてはPM計画書とにているが「わかりやすく相手に伝えるツール」として優れていると感じた

という意味で、今回両方を実際に書いてみてそれぞれの特徴を感じました。

プロジェクト計画の共有とアップデート

さて、プロジェクト計画において大事だと感じることは、その計画をちゃんとステークホルダーに共有すること、そして、計画を更新することだと思います。
PMBOKはウォーターフォール型のプロジェクトもアジャイルなプロジェクトも扱います。計画段階においては、どちらも計画は大事です。計画を実行するにあたって両者に生じる違いは、手戻りが難しいウォーターフォールに比べて、アジャイルは定期的に振り返り、プロジェクト自体を改善していくことができることだと思います。
その意味で、「精緻な計画を立ててそれを実施する」というのではなく、「書けるところからでも計画を書いてみる。それを定期的に振り返り、計画自体をアップデートする」ことがアジャイル開発においては特に大事だと考えます。

今回のプロジェクトでは、四半期で計画の振り返りをし、大事に思っていたことが実現できたか、当初と想定が違い優先順が変わることはなかったか、ステークホルダーの見落としがなかったかといったことを確認し、文書をアップデートし、その内容についてチームメンバーから意見も求め、結果を共有しました。
これは四半期と言わず毎月くらい実施しても良かったですね。

まとめ

計画を立てて、チームの意識を統一する、リスクへの対策を考えておくことは、プロジェクトが大きくなるほど大事ですが、小さいプロジェクトでも軽視せず、意識することが大事だと思います。インセプションデッキは必ず作る習慣をつける、とか。

最後に、ブログ統合のプロジェクト憲章(インセプションデッキ)に掲げた文章を紹介します。

はてなのコンテンツプラットフォームサービスの未来に向けた開発を行う

近頃、複数のサービスの終了のニュースが続いていますが、ユーザーさんのコンテンツを扱う、コンテンツプラットフォームサービスは、はてなの柱であり、その未来に向けた開発をしていきたい、そのための準備としての整理のつもりです。今後のはてなにどうぞご期待ください。

一緒にプロジェクトを進める仲間も募集中です!
hatenacorp.jp

はてなで一緒に働きませんか?