意味のない手続きを省く技術
職務柄、多（他）部署から相談を受ける。クライアントからの問い合わせへの回答をどうしたら良いか、的なものが多い。
問い合わせのシートを眺めると、こんなことを問い合わせてなんの役に立つのかさっぱり理解できないが、問い合わせている内容＝問い合わせ元の組織のルールやシステムの仕組みであることを察することができる。こうした問い合わせは、ある意味、手の内を明かしているようなものだ。
問い合わせ元の組織のルールも容易に想像がつく。多分に2000年前後から秘伝のタレのようになったルールにつぎはぎを重ね、さらに関連するルールが法規制の追加により横並びといくつもの関連文書として作られてきているのだろう。
たとえ1つのルールの文書であっても、その文書を根拠として働く社員以外には読まれることはない。過去の自分も同様に自分ごとになるまでは読む必要性はなかったから、よくわかる。
問い合わせ内容を眺めていると本来、その問い合わせを考えた狙いとは違い、形だけのアンケートになっているのではないかと疑わざるを得ない。
- それを聞いてどうするのか
- わざわざ書かせて、それを見てどうするのか
- 項目が埋められていることに満足するくらいなのではないか
もし問い合わせ内容を本当に聞きたければ、質問の回答の裏付けになるアーキテクチャを見なければ、その質問で回答させていることが機能しているか判別つかない。
考え方をガラリと変える必要がある。
- 運用の手続きを減らす
- つかないデータは持たない
この2点だけの視点で、いけていない現行の管理データを見直せば結果的に運用はシンプルになるはずである。
エンジニアならリファクタリングで鍛えられているからできるのではないか。
リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)
- 作者: Dustin Boswell,Trevor Foucher,須藤功平,角征典
- 出版社/メーカー: オライリージャパン
- 発売日: 2012/06/23
- メディア: 単行本（ソフトカバー）
- 購入: 68人 クリック: 1,802回
- この商品を含むブログ (140件) を見る
エンジニアならバグ票を書き慣れているので『事実と意見』を分けて話せる
仕事をしていて、状況をヒヤリングしていると、事実と話し手の意見の混同というか、話し手が質問を理解できなくて自分の思い、いや、感想を話し出すことはしょっちゅうある。
一方的に話し手の思いがダダ漏れしているというよりは、コミュニケーション自体、質問する側からの投げ掛けがキッカケなのだから、受け側の話し手のリアクションが期待するものでなければ、問いかけ側の質問が悪い。
例えば、次のエントリの中に出てくる会話はよくある上司と部下の日常的な風景に思えるかもしれないが、であれば部下へ聞きたいことを効率的に聞こうと思ったら、部下の返答の癖（事実と意見を区別できないこと）を知っているわけだから、上司の聞き方は上手とは言えない。
そういうときの質問の仕方も曖昧だったりする。聞き手が最短で聞きたいことを質問するなら枕詞として、
「先に事実だけ教えて。そのあとに意見を教えて」
と誘導すればいいだけの話だ。業務として区別して話すことを必要とするならば、OJTで指導すべきことだ。それをせずに、グダグダと事実と意見を区別できないというのは管理監督者の職務としてやることをやっていないのではないか。
話し手自身が何を聞かれているかを注意を向けられるように質問を続ければいいだけの話である。
エンジニアもこの事実と意見（意見というよりはエンジニアの思い込みの方が多い）を混ぜて話し出す人が割と多い。
では混ぜて話してはいけないのかと言えば必ずしもそうではない。使い分けてくれれば割とどうでもいい。
ただ、事実と思いを分けて欲しいときには、TPOに合わせて分けて欲しい。それはいつかと言えば、バグ、障害、インシデントを共有するときである。
エンジニアは予定していた作業をしてたとき、作業内容に応じて状況を共有（報告）する必要に迫られることがある。トラブルを起こしたときがそれである。
そのとき、
- やろうとしていたこと
- やったこと
- 起きた事象のこと
- 起きた事象の原因
について時系列で報告してくれないと何が起きているか、どこで事象が起きたか理解できない。
特に監視中の環境でトラブったらトラップがバンバン上がってたまらない。
まあ、作業ログは残っているだろうから、それを確認しながら教えてくれればいいのだけれど。
幸い、エンジニアは全ての人がバグ票か障害報告書（とても形式張っているやつ）を書き慣れているので事実と思いを分別して言語化することは訓練されているから問題ない、と信じたい。
成長の目標設定は半年くらいがちょうど良い
業務の目標を1年にしている組織は割と多いのではないか。
目標設定、つまり業績評価を年1回にするのはエンジニア的にというか、怠け者のエンジニアだった頃はそれで十分だった。評価されるような仕事をしていると自覚をしていれば、相応の目標を設定し、KPIもそれに見合う定量的な設定をしていたから、最低限このくらいというあたりは見切りができた。
立場が変わればそうも言っていられなくなり、担当事業の良し悪しで結果は想像がつくから、期待値は下げてしまうのでちょっとやそっとの結果では驚きはしない。
結論から言えば、1人のエンジニアとしての目標設定を1年にしておくのは長すぎる。
なぜか。
それは１年間、自分の目標を覚えていられないからである。
3ヶ月もすれば記憶の隅から消え始める。半年経ったくらいのフォローアップの時期にリマンどされてもそこまでの評価のフィードバックがなければひと月もすれば記憶から消えてしまう。
年度末の評価期間に入り、この1年何をやったかを思い出そうにも、役割として、例えばプロマネとしての数字を残せていたとしても、それは何か自分の成長を伴って数字を残しているのか、保持しているスキルでやれてしまったのか判別つかない。
他のエンジニアはどうかわからないが、自分は通年、目標に設定したスキルをアップする項目を認識続けて活動などしてられない。
第三者の目線で見ている限り、メンバもあまり変わらないように感じるが、あなたはどうだろうか。1年間、設定したどのスキルを伸ばすのかを意識し続けられているだろうか。
中間にフォローアップを取り入れていたり、1on1を取り入れていたりするならば、それは期間が長すぎることへの対策なのである。
であれば、本来は目標設定の期間を短くすることでフォローアップを削減できるので対策的には正しい。それをやらない理由は、そうした発想をしない、現状に疑問を持たないからだろうし、それはそれで如何なものかと思う。
目標設定の期間を短くできない理由はない。やろうとするとそれに関わるワークが増え、トータル的にはフォローアップをした方が安く済むとしているからだろう。
でも、エンジニアの成長の観点で言えば、1年は長すぎる。成長への意識は希薄になるし、小さな成長に鈍感になる。
業績的には年度でもいいが、エンジニアのスキルを成長させる目標については業績と切り離して、最低半年でマネージャとエンジニアで会話した方がメリットが多そうだ。
もし、半年で成長に取り組む目標を設定できないとしたら、その業務から離れた方が良いのである。成長できない業務に依存する理由は全くないのだから。
プロマネを教えることの難しさ
講座のコンセプトを作っている。なかなかイメージアップ出来ず産みの苦しみを足掛けひと月以上味わっている。
長々と引っ張っているのは、そのイメージアップを頭の中でやっているからであり、それは悪手だとわかっていながらそのままズルズルと引きずっていたのは、心のどこかで先延ばししても『まだ』大丈夫だと思っていたからだ。
もう11月である。
さて、講座はプロジェクトマネジメント系で、ただ、想定している受講者はエンジニアをスコープにしていないから、前提知識を下げなくてはならない。
それを踏まえた上で、どう経験をして、知識を得る方法を作り出すか。
講座を設計するとき、ついつい伝えたいことを並べてしまいがちである。それは知っていることを頭の中にある記憶から順番に引っ張り出してくるから起きてしまう。
あるあると言えばあるあるである。
プロジェクトマネジメントだけ教えても
全く仕事に役にたつとは思えない。これについてはやはり以前ブログのエントリに書いたような気がするがどこかは覚えていない。それほど前ではないと思うが。
プロジェクトマネジメントを教えようと思えばとても簡単である。
PMBOKの概念、知識エリア、プロセスの要約をテキストにすればいい。
それを座学で知って、更にワークショップをやってもいいがそれでも面白くはないのは同じである。
知らないことを知って、知識の好奇心をくすぐられる受講者もいるかもしれないが、ほとんどの受講者は、へーとかそうなんだ、くらいの感想しか持たないだろう。
座学は興味を持てないと退屈で苦痛でしかない。
エンジニアにも共通していること
イメージアップの中で設計している講座の目的、伝えたい流れを書き出しては、消しながら関連を紐づける。
その中で自分で書いたことを他人事のように眺め直してみると、割といいことを書いていた。
所詮、プロジェクトマネジメントはプロジェクトでの目的を分解して再構成するアクティビティをコントロールする仕組みでしかない。
この文章は2つの要素を含んでいる。
- 1つは『プロジェクトは目的を分解して再構成するアクティビティである』ということ
- 2つは『プロジェクトマネジメントはアクティビティをコントロールする仕組み』であるということ
それを正として、前者の目的を分解して再構成するアクティビティのアクティビティ自体を作れないエンジニアが存在する。
なぜ作れないのかを見ていると、多分に目的をイメージアップ出来ないのである。イメージアップ出来ないから、目的を定量的にも定性的にも表現できない。説明を求めるとぼんやりしているのはそのせいだ。説明を求めると、それっぽい方向性のことを言うこともあるが、ディテールを質問すると答えに窮するのはそれが原因なのだろうと考えているがどうだろうか。
そんなことを自分で描いたメモを見直して、さてどうするかと再度悩む。
まあ、共通になりそうなテーマを提示して、あれとそれを紐づけるのだろうなぁ。
その際、前提知識のハードルを無意識にエンジニアに設定してしまうから、それを下げるアプローチが必要になる。そこがうまくいくかどうかもまた、やってみないとわからない。
この講座も素振りをするときの受講者を意識しないと実際に講座を受けるセグメントとずれてしまうので、それはバイアスをつけてみなければいけないのも頭痛のタネではある。
任せてしまうと終わらないエンジニアが終わらせるとしたら
私は「任せてしまうと終わらないエンジニア」だから耳がいたい https://t.co/OqSv3865SG
— こばせ🥴 (@kobase555) November 2, 2019
想像するに、全く、何もが終わっていないということはないと思う。もし、渡したタスクが全く、ひとつも終わっていないとするならば、今もエンジニアとして生き残れるほど寛容ではないはずだ。
という仮説が成り立つとするならば、任せられた途中までは終わっているか、任せられて期待されている納期に完了基準に到達していないの途中のどちらかに違いない。
任せる→終わっていない→エンジニアとして続けられていない→このルートはない
＋→途中までは終わっている→Aルート
＋→納期に完了基準を満たしていない→Bルート
Aルート
終わらないのは、期待されたこととやる側のエンジニアの次のギャップだろう。
- 双方の作業ボリュームが任せる方＜エンジニアになっている
- 力量が合っていない
- 合意した仕様に検討していないことが見つかった
- 作業期間に割り込みが入った、入れた
- 正味の作業期間に終わらせることを最優先にしなかった
これらは、作業自体の難易度の見誤り、力量の見誤り、仕様の検討もれ、優先順位の謝り、差し込みによる納期の再設定忘れが原因である。
Bルート
このルートは納期に間に合ったが内容が伴っていない。
- 判断基準がチームに統一しバリューとして存在しない
- エンジニアの価値判断を基準としてチームに合わせていない
- チームの作業プロセスが存在しない
- やってから必要に応じてルールを決めればいいと思っている
これらは、エンジニアがルールを守っていないか、チームにルールや意思決定の基準がないために起きる。
対策
AルートもBルートも反対のことをやればいい。これは、任せてしまうと終わらないエンジニアに限ったことではないことに気づくだろう。
そういうこと。
任せてしまうと終わらないエンジニアと早く結果を見せてくれるができの悪いエンジニアのどちらを選べば良いか
執筆のスピード（出来高）について
これは単なる感想というか現状の自分に対する心理的な壁というか、もしくはあの頃と違ってやりたいことが増えすぎてリソースを集中できない状態を表しているのではないかと思えなくもないのであるのだが。
書くことの出来高については、あるケースで日別の出来高を記録していたことがある。
それを改めて見直すと、もうあのときの出来高をアウトプットすることは無理なのではないかと思えてならない。その点だけで言えば、やりたいことにリソースを全振りして集中的に没頭するというのはものすごく成果として残る。
今はやりたいことが山積みで結果的にリソースを成果が出るように配分できておらず、タスクが積み上がっている。
書くことについては、誰もがわかっていることであるが頭の中で悶々と考える時間があれば、ネットを巡回したりTL警備員をやっている時間があるならブラウザを閉じて原稿を書く行動を自分に取らせればいい。
これが一番難しい。
スピードと品質
自分としては、書く際に品質を求めてはいけないと思っている。最優先しなければならないことは、とにかく書ききることである。どんなに駄文であっても書ききる。
間違っても、前日書いたところを自分で添削を始めてはいけない。添削を始めると前々日の書いた箇所も気になってくる。当然、もっと前から読み直してしまう。
これも過去のエントリに何度か書いているが、進捗の出ないエンジニアから進捗を引き出すためには、タスクを1時間や30分のサイズに小さく切り出して、一つひとつ終わらせる成功体験と実際の実績を積み上げていくことを伴走するようにサポートをすることが必要だと主張してきている。
一方、とにかく早く、でもポカミスを仕込んでアウトプットするエンジニア。早く成果を見せる（終わっていないが）ことは、早く間違いを見つけられるという可能性を持っているということだ。業務処理能力は高いが予測できないエラーを含んでいる。
任せてしまうと終わらないエンジニアと早く結果を見せてくれるができの悪いエンジニア。
今必要とされるエンジニア
今必要とされるエンジニアは早く結果を出すエンジニア一択だ。任せてしまうと終わらないエンジニアと早く結果を見せてくれるができの悪いエンジニアならどちらが現場で必要とされるか。
見方を変えよう。
任せてしまうと終わらないエンジニアは、タスクを小さく作業員として扱えば結果が出る可能性がある。あくまでも可能性。
早く結果を出してくれるができの悪いエンジニアの方は、少しマシだ。なぜなら、開発プロセスや開発環境の中で出来の悪いポカを避ける仕組みを入れれば出来の悪いものをアウトプット前に排除できる可能性がある。
やはり、できたと言い切れることは最大の魅力だ。
なぜなら早いサイクルでアウトプットを継続することに耐えられるエンジニアが求められるからである。
実際、今の自分の担当部門のエンジニアとして欲しい方は、後者のエンジニアである。
そう判断する背景
結局、マネージャでもプロマネでもアウトプットに対して要求品質を備えなければ完了としないしできない。要求品質を備えていなければ、それが露呈した瞬間、いくら善良に注意義務を果たしていたとしても、リカバリをしなければならないことに巻き込まれることを知っているからだ。
後工程になればなるほど、当初から実現しておけば安価に対応できた要求品質の1000倍も労力を必要であることも経験的に知っている。
だからQCDがいくらトレードオフだと言っても、品質は固定化されトレードオフされない。だからこそ、CDで歪むのであるが、それをどうやり切るか（スコープのシュリンクを含め）。
任せてしまうと終わらないエンジニアと早く結果を見せてくれるができの悪いエンジニアとは関係のない、次元の違う話に読めるかもしれないが、それは違う。
エンジニアのアウトプットの積み上げがプロジェクトのアウトプットの結果なのだから。
PMBOKはどう使えばいいか
PMBOKの第1版はB5サイズで、本文は126ページと用語解説は44ページの少し厚い薄い本だ。
それが第6版になるとA4サイズになり、目次と図表の索引で30ページ近く割くようになった。本文は530ページを超え、紙で読みたいと思うようなものではなくなった。
プロジェクトマネジメント知識体系ガイド PMBOKガイド 第6版(日本語)
- 作者: Project Management Institute
- 出版社/メーカー: Project Management Inst
- 発売日: 2018/01/01
- メディア: ペーパーバック
- この商品を含むブログを見る
PMI会員であれば、ベネフィットとしてPDF版を入手できるのでPDF版一択である。紙媒体はどうやらコピー対策で可読性がとても酷い状態らしいとamazonの書評で多数書き込みされている。
第2版である2000年版で既に厚く大きいサイズになり、当時から手を余したものだ。
読み物としてのPMBOK
第2版あたりからとても読みづらい本となった。第1版は別に意味、誤訳で読みづらいと聞いたことがあるがそれほど気にならなかったのは、第2版が出る直前で買い、ろくに読んでいないからかもしれない。
知識体系であるから目次も知識エリアごとに統一されており、これが返って読みづらくしている。
体系のツリー構造図、概念から始まり、プロセスのインプット、ツールと技法、アウトプットを繰り返し説明する。プロセスのデーターフロー図は1つの知識エリアに多数含まれるプロセスがあることを証明しているようなものだ。
システム開発を上手くやりたいなら、プロジェクトマネジメントとシステム開発の運営を理解できる本を読んだ方がいい。
アプリ開発チームのためのプロジェクトマネジメント ?チーム駆動開発でいこう！?
- 作者: 稲山文孝
- 出版社/メーカー: マイナビ
- 発売日: 2015/04/28
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
課題ログ
目次の中に課題ログと言う項目がある。いわゆる課題管理であり、本文と課題管理で管理したい項目が列挙されている。
箇条書きの項目を見る限り、実際に課題管理に使いたい項目よりは少ないのはPMBOKが業種を横断してプラクティスを集め、それらからどの業界でも使えるように共通項を抜き出したからだろう。
それでも、プロジェクトマネジメントの経験のないエンジニアが課題管理で（最低限の）課題管理をしようと思ってPMBOKを読んだとしたら、これで管理項目は作れるだろう。
統合変更管理ツール
統合変更管理での統合変更管理ツールを読むとPMBOKが何であるか片鱗を知ることができるのではないか。考え方としなければならないことの説明が書かれている。
2000年代に日経BPあたりがPMBOKを流行らせたとき、PMBOKがプロジェクトを成功に導く銀の弾であるかと飛びついた経営者達は現場にPMBOKを導入することを求めた。現場はこれでどうしろと言うのだと思ったに違いない。
それはその通りで、日頃から書いているようにPMBOKは器でしかない。考え方だけだ。前述の課題ログのように項目が記載されているだけでもマシなのだ。
テーラリング
PMBOKは体系であるから、業界を問わずプロジェクトとして事業をする業界に適用できるように作られている。
結果、共通項だけになるのはもちろん、体系であるかこそ冗長に書かれる。それをPMBOKではプロジェクトマネジメントを行う側のプロジェクトに合わせてテーラリングを行うことを求めている。
この辺りの考えは標準化をするときと同じである。
品質
EOF2019あたりでも品質のことについて言及があったようだが、エンジニアが開発プロセスでプロジェクトの要求事項を製品なりサービスなりが備えられていることを担保してくれれば、そもそも品質マネジメントなど必要はない。
それができないから、品質マネジメントの切り口で、尺度を定め、データを収集し、分析し、品質の監査を行うのである。
繰り返せば、開発プロセスで品質を考慮しないケースで失敗を繰り返すから、知識体系として品質マネジメントを入れているのである。そうもしないと品質のリスクからプロジェクトが失敗しかねない。
QCDのQはQualityであり、3つの１パーツでしかない。
どう使えばいいか
それはシステム開発のプロセスから得られるデータや情報に対して、PMBOKの観点でプロジェクトが期待するように進捗しているかをモニタリングする仕組みとして使う。
プロジェクトをモニタリングしたいメッシュで情報を持っていなければならないから、システム開発側では情報を要求される単位で持たなければならない。
言い換えれば、システム開発とプロジェクトマネジメントのインタフェースを決め、そのインタフェースで得られる情報でプロジェクトをコントロールする仕組みを作ればいい。
