技術テーマの起案チェックリスト

企画を起案したいエンジニアと会話していると、ものすごくプロダクトアウトの話になるか、自分のやりたいことをばかり話されるのでちょっと食傷気味になる。特に課題解決の技術テーマでいきなりプロダクト在りきでは企画として筋が悪い。

であるからして、企画を起案する際のチェックリスト的な流れを踏まえて整理し直すと少し事業会社の企画として受け入れやすいというか話の土台合わせを飛ばせるので頭の隅に入れておいて頂けると助かる。

  • 目的・課題・ニーズ
    何を解決するために起案するのかを書く。このあと(以下に進んだとき)やりたいことはこれでいいのかと戻る場所になる。とても重要。
  • 範囲
    よくあるのが企画する際の対象を曖昧にしたまま始めてしまうケース。対象のずべてを定義した上で、この企画の対象を決める。決めた範囲は、このあとの制約で変わる(小さくすることが多い)が、企画の目的から広げられることもある。
  • なぜそれをするのか
    目的、課題の起因となるもの。法対応や経営上の課題などでそれをやらないとどうなってしまうか書く。裏付けとして、省庁のガイドライン、社内規程、裏付けを調べておく。
  • 企画概要
    企画の概要は進め方を1段階詳細化したものになる。キーワード的には上下の項目を取り込む形で表現される。期間やコストから制約をもろに受けるのでここで風呂敷を広げない。広げるのは次フェーズにおく。
  • 受益者
    その企画を実現することで誰が便益を得られるかを明らかにする。
  • 進め方
    起案の範囲での進め方を図式化する。ざっくりしたもので良い。現状調査、課題整理、方式調査、プロトタイプ、評価、次フェーズ以降の計画など。
  • 日程
    ざっくりしたもので良い。
  • 成果物
    企画での成果物は、次フェーズのインプットになれば良い。企画の報告書や調査結果資料でよい。
    次フェーズがITのプロジェクトであれば、RFPを出してベンダ選定までになるが重いので覚悟すること。
  • 費用
    企画での費用。経費で対応するため、物は買わない。サービスとして支払う。

一旦、ざっと書いてみると企画のスコープを広げすぎていることに気づくはずだ。特に、エンジニアが起案するとその傾向が強い。

企画として実現できることを起案すること。

 

 

ワークショップと学び3 まなびほぐしのデザイン

ワークショップと学び3 まなびほぐしのデザイン

 

 

コミュニケーション力はエラーハンドリングで向上させる

コミュニケーション。プロジェクトの失敗の原因を聞けば『コミュニケーションが』、エンジニアも技術ばかりではなく『コミュニケーション力が必要だ』、広く世間では必要とされるのにコミュニケーション能力がないと『コミュ障』と使われるそれ。

エンジニアが業務や社外で使うコミュニケーションとは何だろうか。

その前に、自分の『コミュニケーション』の解釈はこうである。

コミュニケーションとは意思伝達であり、伝えたい意思の目的に応じて伝える相手にその目的を達成するように働きかける振る舞い。

どうだろうか。

それでコミュニケーションの何を話したいかというと、難しそうだったり、ハードルが高そうだったりするが、実際には達成したい目的をはっきりと認識さえしていればとてもイージーモードなのだ。例をあげながら話を進めよう。

 

  • 仕事で頼みたいことがある
    頼みたいことを話す相手にやってもらい期待する結果を得たいという目的がある。相手は関数、APIだと思うことにする。
    お作法を守らなければエラーで返ってくる。お作法とは相手を尊敬、仕様を理解した上で接するということである。
    こちらが欲しい情報を相手が持っているかもしれないので持っているか尋ねたければ、気持ちよく教えてもらえるように
    ・聞きたいこと(「◯◯のために教えて欲しいんだけど」)
    ・背景(必要なら「実はこんなことをしたくて」)
    ・保険(尋ねた相手が知らなくても知っている人を教えてもらう「知っている人を知らないかな」)
    ・お礼(「ありがとう」)

 

  • 繋がって今後情報交換したい
    カンファレンスや社外の場で繋がっておきたいと思うこともままある。例えばその分野での第一人者とか今をトキメクエンジニアとか。繋がりたいということは相手に認知されたいとうことだ。
    名刺交換は持ち合わせていれば交換はできるが名前と顔が紐ずかず忘れられてしまう。平成であるからその場でソーシャルネットワークを利用して繋がっておこう。その前に、声をかけなければそれは実現しないが。
    あと、話すネタが必要だ。カンファレンスであれば講演内容に対するレスポンスの意味合いでの疑問、以前に公開されたスライドからの意見。重箱のすみを尋ねるよりは、その先とか言及されていない少しずれた領域を尋ねてみるのも良い。
    どう繋がっても、結局は相互にgive and takeの関係を作れなければ自然消滅してしまうが。
    ・リクエストメッセージを投げる(「◯◯で△をやっている■■です」
    ・ワーニングを投げる(「講演の◯◯をしないというのは、組織文化に依存すると考えるのですがそれを実現させるために必要な条件は」)
    ・お礼(「ありがとうございます。ソーシャルで繋がってもいいですか、今ここで繋がっちゃいましょう」)

 

  • 要望をきく
    友人や家族に対し自分のやることをついでに必要かを尋ねるケースもままある。こうした普通の会話的なコミュニケーションでも相手の意思を確認することの積み重ねで日常はできている。大げさに捉えればそういうことだ。このことからわかることは、コミュニケーションは日頃から使っているのだ。
    例えば最近コーヒーや緑茶を飲みたいと思ったときに、自分で入れるが一緒に飲むかと誘うことが増えたのでそのケースで。
    ・インフォメーションを投げる(「コーヒー入れるけど入れようか」)
    ・レスポンスを受信する(「じゃあ入れるね」)
    ・共有する(「美味しいね」)

 

仕事を除き、残りの2つは想定外のレスポンスが返ってきても上手にエクセプションを握り潰せば気が楽になる。実はコミュニケーション力をあげるコツはこのエラーハンドリングである。

  • お礼(「ありがとうございます。ソーシャルで繋がってもいいですか、今ここで繋がっちゃいましょう」)
  • エラーハンドリング(「あー、やってないんですね。ではまた今度」)

 

  • インフォメーションを投げる(「コーヒー入れるけど入れようか」)
  • エラーハンドリング(「そう、じゃあ、あとでね」)

 

 

 

500円でわかるエラーメッセージ―パソコンのトラブル緊急脱出! (Gakken computer mook)

500円でわかるエラーメッセージ―パソコンのトラブル緊急脱出! (Gakken computer mook)

 

 

 

 

 

心理的安全性は求めなくても手に入れられる

ここ数年、心理的安全性について言及されるエントリやカンファレンスでのトーカーを見かけるようになった。御多分に漏れず、当ブログのエントリでも取り上げている(はず)。

心理的安全性』で検索してみると2件ヒットした。

 

fumisan.hatenadiary.com

fumisan.hatenadiary.com

 

各方面で心理的安全性を取り上げるのは、裏返しとして心理的安全性を保たれていない現場が多すぎるのではないか、と思うのだがどうなんだろうか。必要だと言われるものは、そこにないから、なのだろう、という理屈である。

ところで、心理的安全性を保持している現場とはどのような現場なのであろうか。

 

他者の反応に怯えたり羞恥心を感じることなく、自然体の自分を曝け出すことのできる環境や雰囲気のことを指します。

心理的安全性とは?googleが発見したチーム生産性を高める唯一の方法 | BizHint(ビズヒント)- 事業の課題にヒントを届けるビジネスメディア

 

何も気兼ねなく言いたいことを言える、振る舞える環境とでも表現すれば良いのだろう。逆に言えば、表現者を否定しないということではないだろうか。

ところで、今のチームでは業務をしていればあれこれしたい、これはどう思うかとメンバから相談を持ちかけられる。そうした相談で一度も否定をした記憶がない。

組織内でルールに沿わなければならないようなケースであれば、ルールを確かめた上で進められるならワークフローを申請するように伝える。ルールは自分の裁量でどうにでもなるものではないためである。ルールにないものであれば、主管部門の責任者に裏を取り、フィードバックする。

プロジェクトであれば、方針を合意したあとは、それに沿っているかどうかで判断してもらう。もし、ずれていると判断したらずれているまずい点はどうするかを尋ねる。

本人が気づくけばそれでもいいし、周りが気づけばコメントをつける。急いでやらなければならないときには、急ぐ理由を説明すると納得感を持ってもらいやすい。

こうした現場は参考になるだろうか。

雑談はするし、相談もよく出る。各自の意見を持っていれば聴き終わってからどうするかを話し合う。意見がヒートアップすることもある。意見がぶつかったままでも昼になればランチを一緒に摂る。

わざわざ心理的安全性と言わなくても、メンバは自然のままに思うことをさらけ出せているように自分は受け止めているのだがどうだろう。

何を持ってこうした環境を維持しているのか、である。それはメンバのパフォーマンスを十二分に発揮して欲しいから、ただそれだけなのである。自分のチームにとってこれが普通の状態なのである。

単に、チームの成果を発揮するためにどうしたらいいかそれを考えた結果、こんなチームが出来上がっていたのである。

自分のチームに来ればいいのに。

 

 

情報処理教科書 情報処理安全確保支援士 2019年版

情報処理教科書 情報処理安全確保支援士 2019年版

 

 

どうやってチームを機能している状態にすれば良いか

(開発)チームはなぜ作られるか。それは、予算を持っているプロジェクトオーナやスポンサーが課題だと考えているイシューについて解決する手段を手に入れたいからだ。そのイシューを解決するために編成された人的リソースの集まりがチームである。であるから、そのチームはイシューを解決する手段を実現するスキルを持ち合わせなければならない。ただ、イシューを解決するための実現方法はチームを作る前からわかっていることもあるし、わからないままチームを作り、チームが試行錯誤しながら実現する手段を探っていくこともある。

前者の場合は、チームを作る前にどのようなスキルを持っている必要があるか、予め知ることができる。なぜなら、イシューを解決する実現方法を知っているからだ。後者の場合は、イシューを解決する実現方法をチームを作ってから探すため、出来ることは、多分イシューはこのやり方で解決するかもしれないという予想の範疇を超えられない。

便宜上、実現方法を知っているチームをAチーム、実現方法を知らないチームをBチームとする。

Aチームは、イシューの実現方法を踏まえ必要とするスキルを持っているメンバでチームを編成するから、チームを編成し、チームが活動を始めることで成果を得られることを期待できる。Aチームの活動で起きる活動上の障害は、チームとして持っているスキルを期待する成果に結び付けられない問題の発生の可能性についてである。具体的には、解決方法の進め方、成果の品質などが挙げられる。イシューを解決する手段は有しているため、スキル面がチームの進度を妨げることはないため、イシューの解決を望むオーナーからの変更に対する対応は困難ではない。

Bチームは、イシューの実現方法を知らないからイシューの実現方法を手探りで発見する活動から始めなければならない。その意味合いでは、イシューの解決する実現方法を見つけるチームと見つけた解決方法を実現するチームでは人的リソースの構成を変える必要を伴うかもしれない(が変えない方ことを進める)。イシューを実現するスキルをチームが持ち合わせていないのであれば、チームはイシューを解決する手段を手に入れるために教育を行う必要性を迫られる。これは時間と人的コストの先行を必要とするが技量不足を原因とする手戻りと品質不良とリカバリの総コストを負担する覚悟とバジェットを持ち合わせていないのであれば、着手する前に計画的に組み込むことで結局安い買い物となる。

Aチーム、Bチームともチームを作るためにエンジニアを集める際に重要なことの1つに、チームの構成でどこのロール(ポジション)がチームの要になるかを見極め、そのキーとなるロールを割り当てるメンバは必要十分なスキルを持つ要員を是が非でも調達することである。これは以前のエントリでも書いているが、妥協してはいけない。キーとなるロールの人材を妥協した瞬間、チームはほぼ機能しないか、機能するまでに相当のサポートをする覚悟とリソースを確保していなければならない。それができないのであれば、幹部候補生を短期間で育てる鬼軍曹の役を担わなければならない。具体的には『愛と青春の旅立ち』に出てくフォーリー軍曹を演じたルイス・ゴセット・ジュニアになり変わり演じるということである。

 

 

愛と青春の旅だち (字幕版)

愛と青春の旅だち (字幕版)

 

 

 

あなたの習慣は良い習慣、それとも悪性の習慣のどっち

ちょっとした理由で年末から酒を全く飲んでいない。たかだかひと月くらいなので自慢するほどでもないことだが、飲んでいない。途中から、このまま飲まないことを願掛けという理由にしておけば、対外的な『お酒を飲まない理由』にすることができると気づいた。

通年、年末の11月から1月に掛けて変化することがある。ズバリ体重である。じわじわと11月から右上がりになっていく。1月を超えた頃にまずいと自覚してジリジリと下げる活動に入っていく。ウエストもキツくなるし、運動の負荷も掛けなければならないし、食事も気ままにしないように少しだけ気を配るのでいい気分ではない。

年明けにフィットネスジムに行き、早歩き程度で走って汗を流した後に体重を測ると年末の数字と同じで増えていない。

素晴らしい。

以前は、飲みながら料理を作り、食べながら飲んでいた。その飲みながらの部分をアルコール取り去ったわけだが、はて、これはいわゆる惰性というか習慣で飲んでいたのではないかと気づいた。

習慣にすることを苦手とする人もいるが、習慣がなんでも良いとは限らないということかもしれない。習慣よくよく吟味しないと悪害しか及ぼさない習慣があるということである。

何も飲酒くらいで目くじらを立てなくてもと思うかもしれない。それは人それぞれで、自分の場合は年末年始に余計に飲んでしまうとお釣りが体重となって戻ってくるのでそれは好ましくないと思っていたわけだ。

それであるきっかけを上手く使ってそのまま習慣的に飲んでいた飲酒をお休みしてみたら、意外と苦痛もなく、渇望することもなく続けられている。これは飲む必然性は実はなかったのだと気づいたわけだ。

あと、最近は、いわゆるスナック菓子を口にすることお休みしている。スナック菓子は割と粉を加工したものが多く、そうした物を口にすると口の中がザラザラとした食感を覚えるので、そんな風に感じるくらいなら果物の方がいいや、と思うようになった。

当たり前のようにしていた習慣を『本当にそれやる意味あるの』と問いかけ、自分の価値観と合わないものは止めるのではなく『お休み』にシフトしておくとどうしても戻したければいつでも戻せるので気楽である。

  • 習慣を作ることは今を変えるので難しい
  • 習慣にしたことを止めることも難しい
  • その習慣が習慣にした頃の価値を持っているかを確認した方が良い

その習慣を止めると少し時間を作れる。こうして時間を捻出するのである。習慣が悪性の習慣、つまり惰性になっていないだろうか。

 

 

小さな習慣

小さな習慣

 

 

 

メンバが技術志向を訴えてきたときに

考え方は色々あって構わないと思うし、属する組織の事業形態に依存する部分もあるからどのようなアドバイスをするのも構わないと思うが少しきになる。

 

medium.com

 

アドバイス部分は引用エントリを見ていただくとして、

 

Q 得意な技術で仕事をしたい
A 得意技術で仕事ができるとは限らない。技術を使うビジネスケースを考えよう 

 

と読めたのだが、読み違いだろうか。

まずはそのメンバの技術を使いたいという勇気ある行動に同意しないのだろうか(もしかしたら書かれていないだけでそうされているのかもしれない)。

それはされているとして、エンジニアであるのだから、その技術で『何を解決するか』を尋ねないのだろうか。

技術は何かしらの課題を解決するためにあるのではないか。その課題を解決するに対価を払いたいと思えるかどうか。これを考えているかを尋ねてみたいと思うのだが。

それで気になったことである。

特定の技術分野に対して、応用事例や運用まで考えてある程度広く浅く日頃からインプットをしておいて、ビジネス的価値が見えたときに「ここぞ」とばかりに自分から提案してコア技術を学べる力があるからこそ技術が仕事になるのです。

そういったアプローチもあるかもしれないけれど、それでは時間がかかり過ぎないだろうか。時間が掛かり過ぎる上に、広く浅い知識に返って縛られて課題を解決する導線を自ら狭めることにならないだろうか。

余計な心配であることはわかっているが。

自分の観測範囲で言えば、知識を多く持てば持つほど、経験を積めば積むほど課題解決のために技術を組み合わせる発想は狭まってしまう。それを再び広げるためには長い時間を費やす。腹落ちするまでに理解し、思考を転換するためには多大な労力を必要とする。

ましてやビジネスケースに持っていくのであれば、それこそ課題解決のためのアイデアを無数に発想しなければ筋の良いアイデアにたどり着けない。

あともう1点。

マネージャやリーダの立場であれば、メンバのやりたい気持ちは伸ばしたいという方向に伸びるように支援をするのがその役割だと考えている。ビジネスとは違い、相入れないのであればそれは無理して同じ仕事をすることは不幸を産むだけである。

言い方を変えれば、当該メンバは目指す音楽性を主張しているのであるから、それを受け入れられるかどうかという岐路に立たされているのである。音楽性の志向が違うまま同じバンドを続けられるか。それは早々に別れた方が良い。

少なくとも生産的な面でも品質的な面でも良いものはできないことは容易に想像できる。

年長者のエンジニアはメンバが志向の話をしてきたら、素直に聞いた方が良い。その上で、自分の考えと違いイラっとしたり、何いっているんだなどと感情を揺さぶられているかどうかを確かめなければならない。

メンバの志向をどう活かせるかを考えられるかどうか。年長者自身がこれからも生き残れるか試されていると自分に自分の人差し指を向けて判断するときなのである。

 

 

『ぷしゅ よなよなエールがお世話になります 井出直行』

待合の時間が長そうだったので手元にあった積ん読からサコッシュに詰め込み所用に向かう。想定通りの時間に着いたところで券を忘れたことに気づき、受付に申し出ると予約票で問題ないと処理をしていただき、予約のメニューを順に済ませる間に、ページをめくる。

著者のてんちょことヤッホーブルーイング井出直行社長の講演を伺ったことがあるのだが、とてもお話が上手である。一瞬で会場の空気を掴んでしまう。話し方もくだけつつも丁寧に話される。

ちなみに、講演のスライドの内容は、積ん読の『ぷしゅ よなよなエールがお世話になります』に書かれていることの抜粋だと思ってほぼ良い。ほぼと書いているのは、スライドの後半でまとめられていた箇条書きのまとめ方が少し違う。

エンジニアの育成で必要となるスキルをレーダーチャートにプロットしたいとする。基準を目指す直近のロールに定め、比較するエンジニアのスキルをプロットすると基準を超えている項目もあるだろうし、基準に満たない項目も出てくる。こうしたとき、マネージャでもエンジニア本人でも基準を超えているスキルをもっと伸ばすか、基準に満たないスキルを無理にでも引き上げるかどちらをするか躊躇するものである。

自分が若い頃は目指すロールになりたいのだから、低いスキルのロールを伸ばす方が良いと考えいた。そのあと、マネージャをするようになり、何十人ものエンジニアの育成に関わり合ってきた結果、得意なスキルを伸ばす方が良いと思うようになり、今は得意なスキルを無限に伸ばすように促している。

てんちょも、同じように『得意なことを仕事にすると、人は輝く』と書いている。人は得意だと自負している才能を使い、上手にできると楽しいと感じる。その感じたとき、人はなんとも言えない幸せに触れ、輝くようにみえるのだろう。

メンバのエンジニア自身が自分の力で生き残るために生存戦略を考えることを促してもなかなかスパッと出てこない。それは自分の長所をエンジニア自身が自覚していないからという1つの要因もある。面白いことに、当のエンジニアは自分の長所に気づいていなくても一緒に働いたことのあるメンバや顧客がその長所を好意的に捉え、一緒に働きたいとリピートオーダーすることもある。いわゆるご指名である。

『僕らの個性ってなんだ?』では、ヤッホーの個性を知ってもらい、興味からファンになってもらうことを目指したのだという。エンジニアという職業は、チームで働くが、一人ひとりの基礎スキルと技術スキルをひどく精査される職業である。チームで働くというところで基礎スキルを晒され、システムデザインや仕様のコード化で技術スキルを試される。その点からも、エンジニアは自分の個性を把握し、どの程度の貢献を自身で知っておく方が、より多くのファンを作るために何をすればいいかに繋げやすい。エンジニアも売れて(プロジェクトへ参画して)ナンボ、である。

プロジェクトマネージャになり、チームを編成するとアサイメントしたチームメンバのスキルの総和ではプロジェクトで必要となるスキルやスキルレベルの閾値に満たないことが多い。そうしたとき、無理やり時間(残業)で押し切るよりは、閾値に満たしていないことを認知し、プロジェクト内研修で必要とするレベルから着手できるように研修を計画し、実行する必要がある。これはPMBOKの古い版にも書かれていることである。

『スキルは挑戦しながら身につければいい』としれっと書かれている。

イシューはチームビルディングであるのだが、その前に書かれている『リーダーの不満は自分自身を写した鏡』で重要なことを述べられている。リーダーの目指す方向と同じ方向にメンバも顔を向けられなければ、メンバはリーダのいうことを理解していないということである。アジャイル開発でよく言われる『同じ方向を向く』や『同じバスに乗せる』と同じなのである。それを確かめるには、リーダの進む方向のタスクをメンバの理解だけで進められるかどうか、を見れば良い。具体的にはリーダが不在期間を作って実際にいなくても進んでいれば良いのである。

そして肝心のチームビルディングであるが、楽天にそうした楽天市場の出展者向け(だと思うのだが)に大学が用意されていて、出展者教育を行なっていることを初めて知った。楽天から見たとき、楽天を反映させるには出展者が楽天で儲けを出し、サービス料を払ってもらうため(もちろん研修は有償である)を考え、間接的にリターンが得られる支援策を取っているのだろう。

『早ければ早いほど、最高のチームができる』で立て直しの頃に将来の拡大を見越した視点を持ってチームとして機能させるための活動に取り組まれたとある。全くもってその通りで、これはプロジェクトチームの立ち上げでも必要な必修科目でもある。それをやらず(何も同じチームビルディングの研修をやる必要はない)にチームを立ち上げることは、プロジェクトをネジを碌に閉めないままに稼働させるようなものである。

話の場は、ヤッホーというブルワリーでのことであるが、組織の中でのメンバ、メンバが機能するチーム作りのヒントを得られるだろうし、そうした知識や経験を持っているマネージャは言語化により形式知として学び直しができるテキスト的な本である。

 

 

ぷしゅ よなよなエールがお世話になります

ぷしゅ よなよなエールがお世話になります

 
よなよなエール 350ml×24本

よなよなエール 350ml×24本