エンジニアの思い込みの代償
もうだいぶ前のことだ。コミュニケーションツールで営業陣と会話をしているときに、自分の発言が言い過ぎだったことがあったらしい。
自分の発言後、発言を前提としたことが担当営業から情報共有があり、取り違えていたことがわかった。自分としては取り違えていたことが解消されたので、そのまま放置していた。
その流れで、営業のリーダ役の方から、担当営業にごめんなさいしないと、と諭された。
自分では気にしていなかったことを周りは気にしていることに気づいた。
これはいけないことをやってしまったのか、と。
諭され、時間を空けずに『ごめんなさい』と担当営業に謝った。
実際腹のなかでは怒っていたかもしれないが担当営業は大人の対応をしてくれた。
話は飛ぶのだが、仕事をしているとコミュニケーションしてきた事案についていくつか解釈できてしまうケースが多々ある。実際、最近もあったばかりだ。
伝えようとしてきた真意を確かめるのに、アプローチの方法はいくつかある。
- 複数の取り方があるがどっちかを確かめる
- 思い込みで決めつけ話を進める
割と後者のリアクションをするエンジニアを見かけるような気がする。そうでもないだろうか。
こうしたとき、どうでもできる解釈の確かめ方でそのエンジニアの仕事に対する姿勢というか、感度がしれてしまうと思う。
得てして、後者は思い込んでいるから感情的になってしまう。前者のアプローチでどちらかを尋ねて共通の論点のポイントを置いてから進めた方が手戻りが少ないし、エンジニアにとってもエコのはずなのだが。
後者のリアクションをしてしまったら、その後に決めつけていたことが間違っていることがわかった時点で、素直に間違っていた認識を伝えないと謝れない人と印象を残してしまう。
組織内の人間なら次第に周りから疎まれるし、業務委託なら直近の期間満了でおしまいになってしまいかねない。
周囲はそうなることを誰も望んでいないのに、思い込みの後の対応の代償は意外と大きかったりする。
エンジニアに悪魔は手軽な達成感ばかり囁く
某所で某エンジニアが参画して数ヶ月が経ったころ、そのエンジニアの評判がすこぶるよろしくない。理由は採用したときに、担って欲しいのは業務システムの改善で、他に運用サポートも期待していることを伝えていたらしいのだが、蓋を開けてみれば、肝心の業務システムの改善は一向に進捗していなかった。
某エンジニアはポテンシャル採用でもなければ中堅層のエンジニアとしてでもない。相応の、自走できるエンジニアとして採用されていた。つまり、結果を出して欲しいところは、業務システムの改善でだった。
某所はフラットで、トップまでの声が上がりやす文化であったから、システムのオーナチームから上にクレームが上がる。それはそうだ、人は増えたのに改善しないのだから。
期待されている間に某エンジニアは何をしていたか。
目の前で困っているユーザの運用サポートばかりしていたのである。
色々とそうなってしまったカラクリはあるらしいのであるが（色々と聞いていて一方的に某エンジニアを責めるのは違うと感じた）、エンジニアとして何に対してコミットして結果を出していくかを再認識することになった。
悪魔の囁き
本来、期待されている業務システムの改善ではなくて、運用サポートばかりしていたのは某エンジニアの耳元で悪魔が囁いていたのではないか。
では悪魔は何を囁いていたのだろうか。
- 目の前の困っているユーザをサポートすると達成感を味わえるぞ
- 怒られていないのだから業務システムの改善はまだ手をつけなくていいぞ
- 楽な方の仕事をしよう
天使の不作為
悪魔がいれば天使もいるはずである。天使は訴えていたはずであるが声は届かなかった。
- 期待されている業務システムの改善を始めよう
- 時間の配分を変えよう
- 自分で成果のある仕事を選ぼう
仕切り直す
そこでは、成果に対する対価は割と厳格で技術レベルに応じた対価を支払うと言っていた。つまり、どれだけ技術レベルが高いと主張しても、仕事内容が易しければ成果に対する対価も相応らしい。だから、本来期待していると伝えている業務で結果を出さないと困ってしまう（成果に応じて見直さなければならない）。
- 事実としてあったことを冷静に確認する
- どうしたいか実現したい将来を合わせる（袂を別ちたいわけではないはずだ）
- 双方の期待値と対価を出し合う
- 短期間の目標とチェックポイントを設定する
PMBOKのステークホルダーマネジメントは組織のハックかもしれない
諸事情があって、差し戻しになった案件をリスタートさせるエンジニアがいて、主体的に進めようと活動を再開し始めた。
差し戻しになったときには基本的にwillを持っているエンジニアが自主的な判断で進めれば良いと思っていたので、口は一切挟まず任せていた。結果的には、チェックポイントで差し戻しになり、リスタートをすることになった。
介入しようと思えばいくらでもできて、進め方の段取りを聞いたり、アウトプットの作り方、ステークホルダへの具体的な依頼内容を聞けばいい。
それに対して自分ならこうする的なことをいい、スケジュールにマイルストーンを設定させ、それに対して予実をトレースすればいい。
でもそれは人は育たないし、自分の仕事ではなくなってしまう。
その観点で言えば、全部自分でやりきったという事実において差し戻しになったとはいえ、途中までやりきろうとしているし、諦めていないので失敗ではない。
コンピテンシ的には、
- リーダーシップ
- 課題設定
- 推進力
などを発揮している。ただ、ステークホルダーをマネジメントすることにおいては意識が回っていなかった、というところだろうか。
なるほど、こういうときにPMBOKのステークホルダーマネジメントを活用できるのか、などと気づかされる。
ステークホルダーマネジメントでは、
などあるが、それは、
- 組織内の政治と権力構造の理解
に左右されるからである。
それでステークホルダは何に関心を持つかと言えば、
- 利益、権利、所有権、知識、貢献
などが関心事になるようであるが、既得権なり裁量に対してどのような影響があるかで判断すれば良いのだろう。
つまり、先様の損得を考えずにいきなり持っていくと地雷を踏み抜くことがあるから、何に関心を持っているかを踏まえて、物の言い方を考えなさい、ということだろう。
例えば本社部門が施策をする際に、事業部門にコスト配賦をするとき、伝える内容は同じでも、物言いを上手くした方が受けれられやすいということだ。
PMBOKにこうしたことがプラクティスとして章を割いて載せているということは世界どこでもどの業種でも同じ構造だと知ることができる。
まあ、エンジニア的には組織のコミュニケーションをハックするような物で、物言いはコードの書き方のような話なのかもしれない。
プロジェクトマネジメント知識体系ガイド PMBOKガイド 第6版(日本語)
- 作者: Project Management Institute
- 出版社/メーカー: Project Management Inst
- 発売日: 2018/01/01
- メディア: ペーパーバック
- この商品を含むブログを見る
意外と作れない基本設計の目次構成
プロジェクトマネージャになったとき、流石に失敗したいとは思わないのでどうすれば成功できるか、そのために何をプロジェクトマネージャになる前から準備しておけばいいかを考えていた時期がある。
結果的にそれは後に生きたわけで、そうした準備は必要で頭の中で考えるだけ絵ではダメだと実感することになる。
とはいえ、準備できることとできないこともある。そこの分界点と準備しないことで何が起きるかは自覚しておかなければならない。
必要なのはシステム開発手法の作業標準
プロジェクトマネージャなのだからプロジェクトマネジメントを一生懸命準備しても意味はない。ここに気づくこと。
誰と何を成し遂げるか。
その誰に、何を伝えるか。
成し遂げる対象は、準備をする時点で何も決まっていない。
アサインされていないのであるから当たり前。
そこでできることはシステム開発手法の作業標準、つまり、どのように進めるかの段取りのモデルを作っておくこと。
ウォーターフォールなら工程（局面）と中身のWBSのアクティビティ。
アジャイル開発ならどの開発方法かとその中身のアクティビティ。
さて、アクティビティはどうするか。
目次構成
特にウォーターフォールなら目次構成の雛形は必須である。
特に基本設計（外部設計）が重要。
インプットの要件定義は基本設計の要件としてカバーしていればいいので逆に作れる。
詳細設計は基本設計で決めたシステム方式でカバーしていれば抜け漏れは防止できる。
目的、概要、論理構成、物理構成、機能仕様、非機能仕様、セキュリティなどで構成する。
このレベルでは荒すぎるのでもう1つくらい詳細化しておく。
機能仕様は業務の機能を分解するので内部の目次構成は同じになる。
非機能仕様は多岐にわたる。セキュリティはここに含める方が良いかもしれない。
何を残すか
作業の結果は、成果物か提出しない内部のアウトプットか何も残さないのどれか。
字工程（後続のアクティビティ）のインプットにならなくてそれでも必要ならメモ程度にする。
特に要員計画で工程の途中からエンジニアを入れる場合、検索可能なプロジェクトのリポジトリを用意し、タグをつけて放り込んでおくこと。
意外と作れない目次
それだけかとここまで引っかからずに読めていたとしたら、それはもともとスキルが高いか、怖さを知らないのどちらか。
基本設計の目次をレベル3くらいまでスラスラ作れるか。
過去の経験でインフラからアプリ、システム運用をカバーできるかどうか。
経験ベースで作ろうとしたら、インフラ視点かアプリ視点のどちらかが欠損する。
今はブログやIPAの資料を探して自分なりに整理し、作る目的を理解できればいいので、載っているから作るではなく、必要なものを選べる方が重要。
新版 システム開発紛争ハンドブック -発注から運用までの実務対応-
- 作者: 松島淳也,伊藤雅浩
- 出版社/メーカー: 第一法規株式会社
- 発売日: 2018/07/07
- メディア: 単行本
- この商品を含むブログを見る
デスマよりひどい寿司と呼ぶには憚られる握りでSAN値がゼロになる
家電は故障し始めると伝染するように故障する。その時期は少し前にまとまってあって、それ以降は小康状態である。適当に世代交代をするような感じだ。
うちの洗濯機は割と長持ちで結婚してから現役は2代目である。かれこれ10年以上毎日何度も運用している。
参考画像 これは型番から後継機ぽい。
最近、洗濯中に止まってしまうことが多くなったらしく、困っているとワイフから相談があった。
これまで洗濯機を選んでいる。これまで機能としてこれは必要だと言って選んでいるので、困っているなら欲しいものを買ってくれればいいのにと思わないことものないがそれは言わない。
何かこだわりがあるのかもしれないと気を使ってくれているのである。
そうして相談をしてくれたので、早速見に行こうと週末にお出かけすることにした。
ホールセールのお店、つまりコストコとヨドバシどちらにと聞くとコストコ、と。で行ってみたら、型遅れぽいドラム式と多機能の縦型とドラム式の洗濯機。選択肢が少なく比較できないと言うので駅前の大型家電チェーン店に。
昼過ぎに到着したのでお昼をと思ったが不案内なところと台風明けでどこも遅いお昼の時間から営業で、オフィスビルに入っているテナントの洋食店に行ったらかなり待たされそうで隣の回転すしに入ったのが間違いだった。
これは経験的なところがあるので根拠はないのであるが、オフィスビルであたり（美味しい）と思うお店があった試しがない。
それがちょっと脳裏をよぎった。
値段はそこそこ取る店で、店内はほぼ満席で、割りとするっと入れたのでラッキーくらいで入った。
思った以上にお腹が減っていたのだろう。
あとタッチパネル式の注文も行けなかったのかもしれない。
確かめもせずバンバン入れてしまう。
それから待たされる。
それは良いとして。
出てきた鰯の握りの解凍の失敗したような風貌と味。
煮切りを塗り忘れたシャコ。
風味のついた醤油だけの品揃え。
届かない小肌。
極め付けは噛んでも水と生臭さしかしない烏賊の握り。
会計し、小肌はこれからになると言うことでキャンセル。
なるほど、そこそこする値段。
伊豆のクルクルで食べた美味しい鰯の半分くらいを期待していたが0（ゼロ）にも満たない。
これなら個人営業の寿司屋に行くべきであった。
人生は身銭を削って経験すると深く記憶に残る。
実名型のグルメサイトに評価をつけるなら無限大のマイナス評価である（つけられない）。
もしくはnull。
それから夜はずっとダメージを受け続けている。
HPは残っていないしSAN値もゼロである。
口の中におかしい感覚が残るのである。
胃がおかしくされたと思って仕方がなく太田胃散を頓服するも、メンタル的なダメージは回復しない。
身を呈して得る経験は他のものに代え難いし、エンジニアであれば失敗してなんぼではあるが、これはデスマ以上である。
前振りの洗濯機は結局コストコに戻って安価なドラム式をチョイスされたのであった。
プロジェクトマネジメントは海鮮丼である
もともと土曜日は引きこもってタスクを消化しようと考えていたところに令和ちゃんが15号の続けざまに19号を持ってきた。
いくつかやらなければならないことの1つの優先順位を入れ替えて、別のタスクの脳内にあるぼんやりしたイメージを言語化にする。
タスクによっては、いや最近は割とタスクをするときに裏付け的な根拠のための書籍の引用を紐づけておくことをしているので、必然的に書籍を読んだり再読したりすることになる。
それは結局、時間を使うことになるから進捗が想像の1/3まで落ちる。読み直し、言語化までの考える時間、言語化それぞれで時間を必要とする。
プロジェクトマネジメントの知識体系とはストレートに言うとアレである。そうPMBOK。
この本でプロジェクトマネジメントを適用するプロジェクト、例えばSIプロジェクトを成功できたらびっくりする。
なぜならこれはプロジェクトをマネジメントする知識とプラクティスの丼なのであって、プロジェクトの目的を達成するためのアプローチ的な方法については書かれていないからである。
プロジェクトの目的を実現するためのアプローチ的なものを作った計画通りに推移しているか、監視、コントロールするのはPMBOKの役割である。
どこの組織でも、エンジニア、非エンジニアに関わらず、プロジェクト、プロジェクトマネジメントは割と聞くキーワードだろう。
それは業務の中でプロジェクト化することが珍しくなくなったと言うか、もともとプロジェクト的な業務をプロジェクトと定型的な業務と分離するようになったからである。
2000年ごろにプロジェクトマネジメントが流行して、割と賞味期間が短く、でも残ったのはプロジェクトを監視、コントロールすることによるメリットがあったからだろう。
プロジェクトマネジメントの丼の中にはプロジェクトの目的を達成するアプローチを実装せねばならず、その上には生産性やプラクティスの具を載せなければならない。さらに、それを美味しくいただくマインドセットが必要なのである。
プロジェクトを美味しくいただこうと思ったら海鮮丼を提供するつもりで取り組まなければならない。
最短【当日発送】ワンランク上の贈り物!海鮮丼セット(生ウニ,ネギトロ,イクラ醤油漬) ＊14時までのご注文 ヤマキ食品 イカ屋荘三郎
- 出版社/メーカー: ヤマキ食品
- メディア: その他
- この商品を含むブログを見る
令和元年台風19号のメモ
社会、防災インフラは大事。
社会、防災インフラに従事する人も大事。
ソーシャルネットワークでNHKの報道がポストされるのでNHKの存在は価値がある。
インターネットで常時情報を収集できていたことは大きい。
放射状の高速道路は通行止で遠隔地に避難は無理であることを知る。
台風通過直後の方が風が強く不安を覚える。
隣接する地域で停電が一時的にあった。
自宅、自宅周囲で被害はなし。
ほぼTVは見なくて済む。
13日以降、事業継続の復旧計画に着手する組織が多いのだろうと想像。
被災地域が広範囲こととオリンピック対応で回復には相当の時間がかかりそう。
山善 防災リュック 30点 セット 幅32×奥行16×高さ43cm 一次避難用 給水バッグ 携帯用トイレ 大容量 レッド YBG-30R
- 出版社/メーカー: 山善(YAMAZEN)
- メディア: ホーム&キッチン
- この商品を含むブログを見る
