ただエンジニアを集めただけではチームではない
ごく少人数で割と難易度の高いテーマを扱うプロジェクトがありまして、プロジェクトのスタート日に顔を知って、
「さあ、チームとしてやっていきましょう」
とエンドユーザが言ったまでは良かったのですが。
エンドユーザとしては、プロジェクトの目的を達成するために専門家を集めてチームを編成し、チームとして成果を出すために活動し始めた…ハズでした。
チームの成果が出ない
ところが、どうやら一人の専門家であるメンバの成果が出ない、というより専門家としての資質が疑わしい。
アウトプットを見ていても、発言を聞いていても
「スレッドから言ってそういう思考はしないだろう」
と思わざるを得ない振る舞いをするのでした。
「チームとして」の意味
チームを立ち上げたときにエンドユーザが
「チームとして」
と言った言葉の意味、行間には別の意味があったのだと思っています。
さて、どんな意味を持っていたのか。
メンバが機能しなければチームにならない
チームとは人を集めればチームになることはありません。
チームを作るということは、チームでしか目的を達成しないから目的を達成するための要素を持っている人、エンジニアを集めるのです。
エンドユーザは、プロジェクト、それも難易度の高いテーマを達成するために対価を払い、メンバを招集したのです。
つまり、プロジェクトの目的を達成するための要素、技術とレベルを備えている人であることを前提に調達しているのです。
そうしたプロジェクトの目的を達成するための前提条件が揃ったから、これからチームとしてプロジェクトを推進していきましょう、と言っていたのでしょう。
ところが一人のメンバはその前提条件に満たない要素であったことが始めてからわかったのでした。
この事例で学べることは、以下のとおりです。
・人を集めるだけではチームではない
・プロジェクトの目的を達成するための要素はチームの前提条件
・メンバはプロジェクトの目的を達成する要素、技術を担う
・メンバが機能しなければプロジェクトの目的は達成されない
さて、みなさんのチームはチームとして成立していますか。
DevOps導入指南 Infrastructure as Codeでチーム開発・サービス運用を効率化する
- 作者: 河村聖悟,北野太郎,中山貴尋,日下部貴章,株式会社リクルートテクノロジーズ
- 出版社/メーカー: 翔泳社
- 発売日: 2016/10/18
- メディア: Kindle版
- この商品を含むブログを見る
自宅で台湾風かき氷が…ゴクリ。
これは欲しい。
Office 2016 週末限定セール 特別キャンペーン ■表示価格から10%OFF(2/24~26)
これは導入するかなぁ。ストレージ１TB使えるようだし。
Microsoft Office 365 Solo (1年版)|オンラインコード版|Win/Mac対応
- 出版社/メーカー: マイクロソフト
- 発売日: 2014/10/17
- メディア: Software Download
- この商品を含むブログ (4件) を見る
仕様検討の資料レビューはデモである
デモはデモンストレーションのデモ、ですね。さて、デモの意味を辞書で引くと３つ出てきます。
１ 抗議や要求の主張を掲げて集会や行進を行い、団結の威力を示すこと。示威運動。デモ。
２ 宣伝のために実演すること。
３ 競技大会で、正式の競技種目以外に公開される競技・演技。公開演技。
１番目は文脈から違うことは明らかですね。そうすると、２番目か３番目の意味合いになりますが、仕様検討をしている仕様のシチュエーションでどちらでも当てはまりそうです。ここでのシチュエーションは工程、企画段階や実際のプロジェクトのくらいのイメージで捉えると同意しやすいかもしれません。
レビューの登場人物
企画の際の資料レビューでもシステム開発での仕様検討の資料レビューであっても、レビューなので資料を作ってレビューを受ける側と資料の内容をレビュー観点を持って合否を判断する側の２つの立場が存在します。
ここでは、資料を作り、レビューを受ける側と設定します。
一歩離れればレビューってまるで…
資料レビューの当事者、レビューアとレビューイから一歩離れて客観的にレビューを見るとレビューアはレビューイから資料の内容の説明を受け、理解し、判断しようとしています。まるで仕様のデモンストレーションを見ていると表現することができます。
片や、レビューイは、作成した資料に同意してもらえるように資料をデモンストレーションしているように見ることができます。
そうなんですよね、資料レビューって資料をデモすることなんですね。一般的に使う「デモ」という言葉には、前述のとおり、２番か３番目の意味があることはすでに確認したところです。
デモの目的
２番目の宣伝するにしても、３番目の公開演技するにしてもそれが技術のデモであれば失敗することは、宣伝の失敗となりますし、公開演技のデモの失敗は、広く知ってもらうという目的を達成できなくなってしまいます。
資料レビューがデモであるとするならば、資料レビューの目的、資料内容を理解してもらい、同意してもらうために失敗しないように準備をしなければなりません。漫然と資料を作ってレビューを受けようとしているなら、準備が十分ではなく、レビューは差し戻しになっても当然の結果ということができるでしょう。
そうしたレビューの失敗から資料レビューはデモあると逆に位置付けるとレビューに対する見方を変える観点にすることができる、と思います。
まあ、物の見方、切り口は変えることに意味がありますから。
デモとしての資料レビュー
ところで、どうして資料レビューを「デモだ」と思ったかを話すと、ある企画の資料のたたき台を作り、場を設けてステークホルダーに説明したことがあったのです。
その際のステークホルダーは、資料見つつ、内容をイメージし、イメージした内容があたかもそこにあるように理解を共有しながら、提示した課題についてさらに想像を広げ、方針について同意に至ったということがありました。
それはまるでデモ環境をいじりながらイメージアップをしたように後から思えたのでした。
そう思えると、資料を説明する際には、デモで準備することをレビューでも準備すればいいのだ、と思ったのです。
できない理由を説明するよりエンジニアがやらなければならないこと
システムはエンドユーザの業務をITで代替することで省力化とか生産性などを向上させることが目的で導入します。
つまり、最初に「実現したい業務の課題がある」のです。
ベンダは、エンドユーザの「実現したい業務課題」に対する解決策を提案し、それが採用されるとプロジェクトとを立ち上げ、業務課題をITで解決するためにシステム化要件を整理していくことになります。
そうした中で起きるのが当初提案していたシステム方式（ソリューション）で実現することが難しいという技術的な課題です。
実現できない理由を説明してもあまり意味はない
「なぜ」の説明は必要です。それは当初見積もりから変更になる可能性があるからです。プロジェクトオーナーはエンドユーザですから、エンドユーザのプロジェクトオーナのミッションとして提案されていた方式が変わるというイベントが発生した時点でプロジェクトのリスクを考える必要があるためです。
また、プロジェクトオーナとはいえ、経営者に説明しなければならないので当初提案の方式で「なぜ」実現できないかを理解していく必要がありますし。
でも、それは些細なことです。エンドユーザにとって実現したい業務課題が解決できればそれでいいのです。もちろん、コストや時間的な制約があるのは先にプロジェクトととして契約をしているからです。エンドユーザは、
「じゃあ、どうしたら業務課題が解決できるの」
とすでに関心が移っているからです。
エンジニアはエンドユーザのことを知らなすぎる
こうした事態に遭遇することは珍しくありません。というか、エンドユーザのシステム環境や業務環境をシステム要件を具体化していく中で判明する事実により、
「そうだったらこんな提案にならないのに」
ということの方が多いのです。エンジニアはエンドユーザのことについて何も知らないことを知るのがシステム化要件定義だったりします。
エンジニアがやらなければならないこと
当初のソリューションでエンドユーザの実現したい目的を解決できないと判明した時点で、エンジニアができない理由を説明しても意味はありません。
なぜなら、できない理由を説明してもエンドユーザの実現したい業務課題を解消できないからです。
今、エンジニアがしなければならないことは、代替案を提示することです。
代替案にたどり着くために必要なツール
代替案をサクッと持ち出せればそれに越したことはありません。代替案にたどり着くためには、エンドユーザのことをシステム的に解決するための
・制約条件
・前提条件
を整理し、当初提案のソリューションとのギャップを把握できていることが必要です。
それを把握できたらどうするか。
簡単です。会社に戻り、有識者を集めるのです。そしてやることはこの３つです。
・組織の中の技術サポート体制の確認
・組織の中の提供できるソリューションが存在するか有無の確認
・プロフェッショナルとの解決するためのアイデア出し
ここの場でもやはり、できない理由の説明は実現しようとしていたことの説明としては必要ですが、それはエンドユーザの実現したいことではないのでさっさと切り上げて、代替案を作り出す方に移る必要があることを忘れてはいけません。
- 作者: エリヤフ・ゴールドラット,三本木亮
- 出版社/メーカー: ダイヤモンド社
- 発売日: 2001/05/18
- メディア: ペーパーバック
- 購入: 32人 クリック: 373回
- この商品を含むブログ (388件) を見る
変革の軌跡【世界で戦える会社に変わる"アジャイル・DevOps"導入の原則】
- 作者: Gary Gruver,Tommy Mouser,吉羽龍太郎,原田騎郎
- 出版社/メーカー: 技術評論社
- 発売日: 2017/01/25
- メディア: 単行本
- この商品を含むブログを見る
優秀なマネージャはビジネスとキャリア開発をどう連携しているか
優秀なマネージャは目標を達成するための優先順位をつけて自分のリソースをフォーカスしています。そうしないと限られたリソースがすぐになくなっちゃいますからね。
では、優秀なマネージャは何にフォーカスするかというと…。
メンバのキャリア開発ファースト
なぜ、メンバのキャリア開発が優秀なマネージャがフォーカスる最初のスキルなのでしょうか。
それは、事業目標を達成するためには、人的リソースであるメンバのキャパシティを大きく広げる必要があるからです。そのために、メンバのキャリア開発にフォーカスするのです。
目の前の数字を追ってばかりで、メンバのキャリア開発を掛け声だけで終わらせているマネージャがいるようですが、そうした振りばかりをしていると、メンバは持っているリソースを使い果たすまで新しいスキルを供給できず、いつかはリソースが尽き果ててぽしゃってしまいます。
優秀なマネージャはそれを理解しているのでキャリア開発を最優先にします。
キャリア開発で必要になるスキル
メンバのキャリア開発をフォーカスするスキルとして最優先すると、それに伴い次のスキルが必要になります。以下に示すスキルは
登場する項番順に必要になります。
これ、よく言われる「良き指導者」像そのものですね。
キャリア開発でビジネスを蔑ろにしない
あたりまですが、組織が存続するためにはビジネスが成り立っていなければなりません。でもキャリア開発をし続けなければ、チームは近い将来パワーダウンしてしまいます。
そうしないために、事業目標とリンクをさせてキャリア開発をするのです。ビジネスはキャリア開発で達成されるもので、キャリア開発はビジネスで継続されるのです。
