下流工程ばかりやってきた50代SEはずっと穴を掘る

20代前半は仕事の仕方を覚える期間で、30代半ばまでには少人数でもチームを抱えて、40代半ばにはプロジェクトチームを従え、50代半ばにはプロフェッショナルとして活躍して欲しいなーと期待するのがマネージャというものです。そうだな、お父さん的な目線で見ている感じですね。見方を変えれば、鵜飼の鵜匠なのでエンジニアの方がたくさん魚を採ってきてくれれば褒めるのは当たり前です。魚は回収するけど。

50代SEに期待されていること

大の大人ですからね。それも50代なら仕切れて当たり前。30年もエンジニアで飯を食ってきているのだから、技術も専門性のエリアはプロフェッショナル。全部当たり前の領域で勝負していることを自覚すべきです。

もちろん、ちょっとコンサルぽい領域だって走りながら勉強して情報をインプットしつつ、周りにいる識者を動かしながら進捗させることを期待されるのです。

これは決して無理難題ではなくて、仕事の進め方、課題の設定の方法は身につけているのは当然として、じゃあ、今、顧客が抱えている課題を解決するための道具は、専門家も使いながら、対策を進捗させるために導く先導者として振舞うことが期待されているのです。

周りを巻き込んで自滅する

そういった期待値の上で、実際に50代のエンジニアがどのようなアプローチを取っているかというと、中堅エンジニアでもセンスのないエンジニアのアプローチを取ることが多いです。

 一担当してなら、決められた範疇でプログラムを書くとか、パラメータを設計するとか、実現仕様の実現性を製品仕様から整合性の裏を取るとかしてもいいし、するのが勤めだと思うのです。

でも、仕切ることを期待されてのポジションの場合はそれでは自滅します。50代エンジニア一人で自滅するのではなく、まとまってそれに関連する周りを巻き込んで自滅します。

なぜなら、興味を持った仔細な、技術的なところばかり掘り進んで進むため、議論をするにしても枝葉末節であまりにもスペシフィックで様々なケースの極一部だけを取り上げるので全体がどこに進んでいるか誰一人知ることができないからです。

地図もないのに穴を掘ってどこに向かっているか誰も知らないんです。本来は、掘ろうと声をかける役の50代エンジニアが先頭を切って興味のある方向に掘っているだけなのですから。

忙しくするだけの仕事を大量生産する

何が起きるか。まあ、想像に難くないでしょうけれど。

一見、すごく仕事をしているんですよ。自分の関心がある方向に掘りますからね。たくさん資料を作るし、そこだけは異常に具体性を持っているわけです。当然、仕事も自分で拵えるので残業もするし、その残業も自分が作っている仕事だからやりたいんです。

困ったことに。

ところで、50代エンジニアに期待されていることってなんでしたっけ。

（再掲）50代SEに期待されていること

顧客が課題だといっていることの真偽を見極め、本当の課題は何であるかを発見することです。

本当の課題を解決するための仮説を立て、必要なリソース、例えば専門家が必要であるとか、仮説を検証しながら進めないと博打になるのでステッピングしましょうとか、専門家としての助言をしつつ、顧客のリソースを最大限に活用できる範囲でゴールを設定することです。

確保したリソースの内輪で成果を確保するために、周りを巻き込んで、仕事を振って、期日ごとにアウトプットを顧客に届けることです。

楽して下流工程ばかりやっているから…

期待されていることはトップダウンのアプローチでの課題解決です。なぜなら、課題というモヤっとした顧客の業務上で支障となる事柄を具体的な策で解決する必要があるからです。

これは、ウォーターフォール型のシステム開発が、要件から解決するシステムを実装する手法と同じアプローチです。

つまり、限定された領域の情報を自分で集めることもせずに貰うだけで、実装しかやってきていなかったというキャリアの偏在を露呈しているだけなんですけどね。

こうした仔細に情報が揃わないと実装できない仕事の仕方をすると情報が集まらないと仕事を進められないから、情報を欲しがるという無限ループの穴に入って出てこれなくなってしまうのです。

そうじゃないんだよ、限られた情報で仮説を立てて、ちびっとずつ進むんだよ。

おーい、いつまでも穴を掘っていないで一度、外に出てきてどうなっているか確かめてごらん、といっても声は届かないんですけどね。

KPIに稼働率を入れるとリソースとしてのエンジニアは幸せになれない

これは過去の経験談です。そのときにも思想的にはわかっていたことだけれど、組織上のKPIがあると新規事業の創出は基本的に無理だよね、ということをこれから書きます。

次世代を育てるために専任化する

マネージャになったとき、それまでメンバをパートタイマーのように使っていたアサイメントを育成の観点での障害を危惧して原則、一気通貫の専任制に方向転換させたんですね。

出来上がっている専門家であれば、勝手に自己研鑽するし、既にひと通りの経験をしているだろうから（これは後で外れた）、これから次世代を背負うだろう、中堅や若手に経験する機会を創出することを念頭に置いて。

KPIへの影響

 SIerだとどこでも稼働率というコストのほとんどを占めるエンジニアのコストを顧客の対価と交換している比率のようなもの（雑でわかりにくい説明だ）のKPIを持たされているはずと思われるのだけれど。

パートタイマーのようにエンジニアをアサインしようが専任化で特定のエンジニアをアサインしようが総量的に見れば全エンジニアに対する稼働率となるので影響は全くありません。

ただ、KPIのトレースの単位がエンジニア単位に落ちると途端に影響が出始めます。パートタイマーでアサインしていると何かしら業務にアサインされているので稼働の高低はあるにしても稼働しているのでカモフラージュできるんですね。

KPIがマイクロ化されると無駄が増す

一方、専任化するとたまたまアサインする仕事がないと稼働がゼロになっていきなり問題化するわけです。

ここで無理をして案件を取ってきたりすると普段なら掴みもしない採算の怪しい案件を取ってきたり、リスクをろくにみないで取ろうとしたりするわけです。そんなんなら、稼働させない方が何倍も特なのですが。

例えば、採算の怪しい案件なら稼働させて手に入れる対価とコストが同党の場合、なんのために働かせているかが甚だ疑問です。

さらにリスクの高い案件を取ってしまったら、お値段以上のリスクをテイクすることになるので管理コストも増え、結局、マネージャから現場までお疲れさんとなるだけです。

何か、エンジニアの育成のリターンがあるとか、新技術の習得があるとかあればいいのですが、そこまで考えておらずそうした理由づけは後から屁理屈として作られるだけです。

どう足掻いても、誰も幸せになれない。 

リソースとしてのエンジニアと稼働率とKPIの三竦み

 リソースとしてのエンジニアを業務にアサインすることがビジネスであれば、エンジニアを業務にアサイメントしないと事業が成り立ちません。だから、エンジニアを売る（リソースのコストに変える）必要がある。売り方は色々あるけれど。

ビジネスの状況を財務的に把握するためにはエンジニアをどれだけコスト化しているかを把握したくなるものです。わからなくはないけれど、それを率にしてしまうところまでやってしまうとやり過ぎです。コスト化の状況を把握するだけなら金額で把握すればいいのだから。

 KPIにするのは事業としての採算ラインを確保したいためのコントロールの指標のためですが、それひとつだけでも実はないということもあって。

それは、アサインされているエンジニアから見たとき、稼働していないエンジニアが楽をしているように見えてしまうことです。アサインされない理由もときどきなのですが。

例えば、たまたま案件がない、技術がフィットしない、などなど。これを変な公平という概念を持っていくると途端におかしくなる。アサインされない理由によって売れないエンジニアの策を必要に応じて立てればいいのに。

システムインテグレーション再生の戦略 ~いまSIerは何を考え、どう行動すればいいのか?

これからのSIerの話をしよう エンジニアの働き方改革 (Think IT BOOKS)

SIerの教科書 ~クラウド時代のSEの常識

エンジニア自身がテーラリングに参加することがチームの状況を適切に把握するための近道

ウォーターフォール型のシステム開発手法は、極論を言えば労働集約型の特性を持っているプロジェクトに適用するのが適切です。一方、プロジェクトの要件が曖昧であったり、市場の反応を捉えながら要件を変えていく要件を持っているのであればアジャイル開発の手法の中から選択するのが適切です。

さて、どちらの場合でも共通的に起きることがチームの状況を適切に把握できるかという観点です。この観点に対し、前述した2つの開発手法はどのような性質を持っているかを知った上で、さらに、いくつかの切り口を与えるとどうなるかを考えてみることにします。

チームの状況の適切な把握について

ウォーターフォール型システム開発

上述したとおり、ウォーターフォールは労働集約型のシステム開発に向く特性を持っています。それは局面を区切り、要件から局面毎に実現仕様を詳細化することで部品の仕様を決定し、製造工程で一度に生産し、試験工程で品質検証を行うという、スコープ確定型の製造システムだからです。

この製造システムは局面毎に作業か確定しているため、機能分担では単機能となるのでリソースの割り当てでは単機能工を手当てすることが可能となります。組織構造的には、プロジェクトマネージャやサブシステムリーダと単機能工の組み合わせとなります。

プロジェクト上でのチームの状況把握は労働集約型であること、プロジェクトは単機能工からの情報吸い上げの形態になるので縦割りや作業範囲のみしか情報を持っていないという情報の分断化についてもプロジェクトの性質として潜在的に持っていることになります。

これを踏まえて、プロジェクトチームの状況を適切に把握することはとても労力がかかることは想定されることです。

アジャイル型システム開発

アジャイル型システム開発は、顧客やそれに相当するPOが要件を提示することができない、または、作り、マーケットにリリースすることで得られるKPIの数字をみながら模索したいという要件を具体化しながらシステムを開発したいという性質に向いています。

やはり、システム開発手法としての特性に短期間の開発を繰り返し、都度、リリースするという考え方にマッチするからです。この短期間で開発を繰り返すという性質を生かすためには、同じメンバで、同じ場所でとコンテキストの高い状態を作り上げることが必要です。同じメンバではもちろんですが、同じ場所でチームが揃うことができない場合は、同程度のレベルの情報共有ができる手段で代替することと、代替する手段をチームの行動様式の中に組み込むことが必要です。

状況を把握するための可視化について

メンバが置かれている、若しくは、メンバ自身が自ら置いているプロジェクトでの状況は、何かしら外部にある手段を使わなければ他のメンバに伝えることはできません。

炎上するプロジェクトでは、こうした基本的なことを後回しにして炎上してから朝会やホワイトボードによる情報共有を始めます。最初からやっていれば炎上もボヤ程度にすむはずですが。

情報を伝達する手段はデジタルならチケット管理システムが代表でしょう。アナログであれば、付箋紙やホワイトボードに直書きです。

これらの情報共有のデジタルとアナログも別の切り口、例えば、リモート開発のメンバがいるとか、オフショアニアショアを使うとなるとデジタルとアナログの特性はメリットデメリットが出てくるのは容易に想像できることです。

重要なことは、プロジェクトの特性を踏まえた上で、チームの活動を制限する制約事項を捉えてから情報共有の仕組みを選択することです。

つまり、闇雲にチケット管理システムがいいとは言い切れない、ということです。

さらにチームのコンテキストの高低のレベルや適用するシステム開発手法の習熟度により、選択できる手段が制限されることを理解しておく必要があります。

メンバの意識について

 適用するシステム開発手法により、メンバがどれだけ意識的に行動できるかの差が出るのであれば、それは採用するリソースとして不適切であると言いたいところですがエンジニアの意識は個々に依存するためそれは踏まえた上で、どのようにチームとしての意識的な行動や判断基準を揃えるかという観点に絞ると、少し捉え方が変わってきます。

メンバの意識がクローズアップされるのは、チームとしてというよりはプロジェクトマネージャとしてのプロジェクト運営の指針に対してどれだけメンバが方向性と適合しているかどうかということができます。

採用するシステム開発手法に対してメンバの慣れ不慣れはプロジェクトマネージャの運営指針とずれやすいもので、そうした状態でもチームとして一定の行動様式をさせる必要から、何かしらの対策が必要となります。

それが作業のプロシージャの可視化と実績の可視化なのです。

• チームの状況の把握＝共有
• 行動様式の統一
• コンテキストの底上げ
• 成果の可視化
• 言葉の統一

おまけ

 実際、チームに慣れないシステム開発手法で開発をしてもらう必要があったり、無意識に隠蔽されてしまうメンバが持つ情報を可視化するのであればこのスライドの対策は1つの実例として適当でしょう。

コメントに若干局所的にネガティブなコメントがついていますが、これまで述べたことの制約事項を踏まえて自らテーラリングすることを忘れているのではないかと思うのです。

そのテーラリングはエンジニア自身が行う範疇なのですから。自らしようと行動しないのは単なるオペレータです。

speakerdeck.com

マネージャの情報収集術 2017年秋

ふと、自分が情報収集しているポインタがすっかり変わってしまったと気づいた2017年の秋。

秋とは言っても、3シーズンのスーツをクールビズが終わる最終日に着て行ったら早朝は涼しくてまだ良かったけれど、帰りはまだ蒸し暑くてダメっぽい。夏の上着とトラッサーズの組み合わせに戻すかなぁ。それよりクールビズが終わると今のオフィスはネクタイしていないといけないくてねぇ昔ほどお気に入りのネクタイを着用しているだけで嬉しいなんてなくなってしまったし。

何を情報収集しているか  

情報収集するという行為は、収集する主体者が気にかかることを広く集める行為だから、ワタシが何に関心があるかということになるわけです。

で、どんなことを気にしているかと書き出してみたら、大したことはなかった。

・プロジェクトマネジメント
・エンジニアの育成
・チーミング
・組織運営
・技術書籍
・アニメ（見ているのだけ）
・身近な（都内くらいの）グルメ情報

まぁ、エンジニアだし、プロマネだし、マネージャなのでそれに間することを表現しているブログや記事やスライドを読んでそうだねとか、違うんじゃないのとか思ったり、考えたりするわけです。要はインプット目的で。

これまでの情報収集

まとめやはてブで知ったサイトをせっせとRSSに突っ込む運用をしていた感じですがそれが続かなくなったというか他に時間を使っているというか。

アンテナ（自分で気になったサイトを登録する系）

最近、Chromeのタブは開いているのに見なくなったタブがあることに改めて気づいて。アンテナだったんだけれど。アンテナがというより、アンテナに入っている記事でときどき見ていた記事を見る頻度が限りなく下がったというか。

feedly（これも自分で気になったサイトを登録する系）

これも気になるブログやサイトをまとめてあるのだけれど、雑多といえば雑多になんでも入っている。技術サイトもあるし、エンジニアのブログもある。

feedlyから見ているのさまざまなめりっとくらいかも。

まなめはうす（オーナが気になった情報を登録する系）

※現時点ではブログサイトに移行

もう、だいぶ経つけれどニュースサイトとしてのサイトが閉店するまでは重宝していたサイト。エンジニア同士だから関心ごとがシンクロするところがあって便利だった。ただ、こうしたまとめサイトはまとめるオーナの嗜好でまとめられているから踏まえて部分的に活用するつもりでないと楽しめない。

はてブ（ユーザが気になったことを登録する系）

これが鉄板だったような。まあ、上記のオーナの嗜好でを鑑みれば、はてなユーザの嗜好のバイアスが順位として掛かるからそこはそうしたことを踏まえて、ですけれど。

そういった感じで眺めているとやっぱり傾向があるんだよなぁ。そんなものだけれど。

ツイッター（ツイートやリツイートを拾い上げる系）

はてブやtogetterにまとまる前の元ネタや狭い界隈での情報が回っている状態で見つける感じ。ツイの特性上、時事ネタやアニメを広あげている感じ。

 

2017年秋の情報収集

すっかりソーシャルというか知り合いの口コミに頼っているといっていいのかも。まあ、はてブやツイが残っているのでパブリックなsnsでの情報収集は相変わらずの部分を占めているんだけどね。

はてブ　継続情報収集中

ツイッター　継続情報収集中

slideshare/speaker Deck　情報収集対象

カンファレンスのスライド共有

主にfacebook経由で書いた本人やカンファレンスのスタッフからシェアされるケースが多いのだけれど。

これでシェアしてもらえるとメモを取ることをやめられるし、それって話をよく聞けるんですよね。あと、スライドの写真も撮る必要がなくなるし、良い事尽くめなんだよねぇ。

facebook　情報収集対象

お友達の幅がドカンと増え、エンジニアのクラスタがだいぶ増えたことで情報発信を拾いやすくなったというのが背景にあるかなと。お知り合いなので、割と率直に意見を添えたり、書評を述べられていたり。

自主開催イベントや所属する組織のカンファレンス情報もいち早く入ってくるのは嬉しい。

お友達に技術書の著者も多いので、新書情報も以前より感度が上がっている感じ。本を買って会う機会があればサイン本にできるという著者の心をくすぐる作戦がいつでも投入できるし。

リアルお友達

カンファレンスやセミナーで知り合いになったエンジニア系のお友達と割とメッセンジャーで会話していると「この本でさ」的な会話になると「どれどれ」とみんなでアマゾンで検索→ポチるとかなりやすい。

背景的に同じ関心ごとでコミュニケーションをしているし、考え方は会話で共有されているので何か気づきがあるかなという半分安心感もあるのがいいのかも。

kiitaとかないの

kiitaとかPOSTDとかは、記事がはてブで上がってきたりツイで気になったら見ているので分類的にそっちに入れてます。

つまり、情報収集するのに最初にどこからアクセスしているのか、という事です。これって、情報発信をするサービサーからは気になるところですよねぇ。

調べる技術・書く技術 (講談社現代新書 1940)

カリスマニュースサイト管理人が15年続けたシンプルな情報収集術 (impress QuickBooks)

仕掛かり中のお仕事フローを把握せよ

仕掛かり中を増やすと作業負荷が見えなくなり更に仕事が増えるんですよ。だって、ギブアップしないんですから。で、大抵は溢れかえった状態で誰かが見つけるんです。ボトルネックになっているって。

いや、それボトルネックじゃないし。

そうなった原因を、ギブアップしないエンジニアに対して「ギブアップする前に教えてよ」というのは間違った助言ですし、無責任だし、もはや無茶振りでしかないです。

ギブアップしないのは出来るからならこういった問題は起こさないのでそういうエンジニア以外の、ギブアップを自らできないエンジニアは自分のキャパシティを知らないのです。

というか、キャパシティという概念さえ持っていないのです。だから、都合よく仕事を振られると今自分の容量に対してどのくらいの作業の嵩があってあとどのくらいならアップアップしないで処理できるかを確かめることをしないのです。

原因はどこにある

なんでもトラブルを人にあるとするのは間違いです。それがギブアップしないエンジニアが仕事を溢れさせても。

どうして溢れるまで仕事を回したのかという判断を何を持ってしたかを解明しなければならないのです。

結局、だれかれを問わず「仕事を振る」という判断をした基準があってその基準が間違っていたから目に見えている事象が起きているわけです。

その誤った判断基準はなんであるか。

仕掛かり中のお仕事フロー

 今どれだけお仕事中の仕掛かりがあるかをエンジニア別にキャパシティがわかっていないから容量を超えた作業を振ってしまっているんです。

原因は、仕掛かり中のお仕事をどれだけ抱えているかフローを見ずに振っているからです。

そりゃもう少しで溢れそうなところに入れようとすれば何かが溢れるのは当然ですし。

フローが多くなると効率が落ちる

 複数のお仕事を同時に抱え込ませればエンジニアは気になる仕事を優先するけれどそれも進まず、あっちをやって、こっちを手につけてと、手を掛けた成果の形にする前に他の抱えているタスクが気になったり、周りからせっつかれたりしてどれも中途半端になるんですよ。

で、気持ちだけ焦って何も進まず…と。

複数のお仕事フローを回すには

 そうはいっても、いくつかの仕事を抱えることが業務スタイルのお仕事もあります。

そうした時にはどうすればいいか。

担当した塊としての作業はまるっとしていても、自分がやるときには作業を成果の出る単位に分割するのが最良です。中間生産物でもいいので、アウトプットできる最小のタスクに分解してから手をつける。

他の仕掛かりにスイッチする場合は、最小の作業が終わってから。

これ、TSSですよね。リソースは自分ですけど。

ひとかどのプロジェクトマネージャは風邪をひかない

「ひとかど」かどうかは他者が勝手に感じることなのだろうけれど、プロジェクトプロジェクトマネージャとしての役割がプロジェクト計画書で設定したQCD（品質、コスト、納期）であれば全戦全勝なので嘘にはなるまい。設定したQCDを実現することはそれほど難しくはないんですよ。例えばCのコストは計画したコスト見積もりより1円でも少なければ目標達成ですから。そんな屁理屈よりは、ひとかどのプロジェクトマネージャにどうしたらなれるかのヒントを書いた方が有益そうなのでそちらに移りましょう。

バカなので風邪をひかない

20年くらい前のプロジェクトでのカウンターのリーダは

「僕はバカだから風邪をひかないんだ」

と赤らめた頬と鼻声で言っていて「風邪が移るから帰れよ」と思ったものです。

風邪を持ち出したのは体調管理をしよう、と中途半端に言われても「でどうしろと」と思うなーと。ワタシが読み手なら。だから具体的に且つ誰でも罹りそうな風邪を出して来たのです。

風邪はリスク

クスリはリスク。そんな医療事故っぽい回文はいりませんね。リスクの話です。

プロジェクトで風邪を引きやすのは緊張しているときより、山場を過ぎたあたりの方で気が抜けると途端に薄ら寒くなって「おかしいな」と。

あるあるですね。

基本はここでQPゴールドαやモンエナや葛根湯を飲んでいつもより睡眠時間をとって寝て翌日にはなかったことにすることが大事です。

【第3類医薬品】キューピーコーワゴールドα-プラス 260錠

アサヒ飲料 モンスター カオス 355ml×24本

【第2類医薬品】葛根湯エキス顆粒Sクラシエ 30包

ひどい場合には市販薬は処方箋の1/10程度しか効能はないので、専門医に見てもらうのが懸命です。

あ、これプロジェクトで技術的に嵌ったときはその道の専門家に頼むのが一番解決が早いしコストが安くつくパターンと同じですね。

QCDのCやDに繋がっていましたね。

さすが、ひとかどのプロジェクトマネージャです。

風邪になる前に対処する

これ、課題を放置しないでくすぶる前に火消しをしてしまうようなものですから、プロマネとしては馴染みのある対処方法かと思います。そう、変に引っ張るとそれにもリソースを割かれるのでやりたいことの半分もできなくなるのは自分がよくわかっていると思います。

なんでもないだろう課題に気を止めないで気持ち放置気味だったのがいつのまにかクラスチェンジしてリスクに格上げなんてしてしまったらそれこそいくらリソースがあっても今のメンバではそれを対処するワークロードなんて見越していないんだから…。

プロジェクト・リスクマネジメント―リスクを未然に防ぐプロアクティブ・アプローチ

これ、リスクマネジメントですね。

さすが、ひとかどのプロジェクトマネージャです。 

体調を幅の中で調整する

別の観点では、毎週、週末にフィットネスジムやスポーツの予定を入れておくと体を動かすことが習慣になるので、週末に体調をいい感じに持って行きたくなるので自然と平日の体調の変かも気にかけるようになるのです。

体調は継続するものですから、ある幅の中でコントロールしておくようになることは大事です。

定量的品質予測のススメ―ITシステム開発における品質予測の実践的アプローチ (SEC BOOKS)

で、この幅の中に収まるように調整するのもどこかでやっていますよね、プロジェクトマネージャなら。そう、QCDのQの品質管理ですね。

さすが、ひとかどのプロジェクトマネージャです。  

寝る

 プロジェクトも何か活動するためにはリソースが必要です。それがなければエネルギーがなくて動けませんから。

食事も大切ですが睡眠がもっと大事です。だいたい、風邪を引くときは睡眠不足か電車の中で鼻毛を抜いて傷を作ってウイルス感染するからです。

枕 安眠 肩こり対策 快眠枕 熟睡 低反発枕 いびき防止 首・頭・肩をやさしく支える健康枕 頚椎サポート頭痛改善 横向き対応

活動するための必要なリソース確保はプロジェクトマネージャがプロジェクトの目的を達成するために必要です。これがなければプロジェクトなんて出来やしないです。足らないリソースがあれば最初からそれで結果がこんなになるよ、というプロジェクト計画を作らなければならないです。

さすが、ひとかどのプロジェクトマネージャです。  

鼻毛は抜かない

あと、鼻毛は本当かどうかより、不用意に鼻毛を伸ばしておかないで日立の鼻毛カッターで定期メンテナンスをする習慣を持っておくことの方が大事です。

何か自然と状況が変化していくことに気遣いするということは、メンバの体調管理に気を配るというのと同じです。

メンバがいなければチームは成果を出せないのですから。

HITACHI 鼻毛カッター BM-03 S

身だしなみからメンバの体調に気遣う。

さすが、ひとかどのプロジェクトマネージャです。  

 

マネジメントはアジャイルを受けれられるか

PMBOKの第6版の目次を眺めて何気なく改めて思ったことはマネジメントという活動をコントロールする考え方の有無と捉え方の違いがあるな、ということです。

ぼんやりとした表現なので伝わりにくいと思いますが、書いている本人もまだ曖昧模糊としているのでこれから明瞭になればいいのだけれど。 

コントロールとは

プロジェクトマネジメントのマネジメントとは、プロジェクトをコントロールすることをしたいのです。ただ、闇雲に何かをコントロールしたいのではなく、コントロールしたい対象に対してこれから起こることの期待値を予測し、その期待値が許容する範囲の中で収まるように制御をしたいのです。

予測とは

予測とはことの成り行きや結果を推し量ることです。結果を推し量るためには期待する結果が必要で、プロジェクトでは期待する結果を予測して表現した結果がプロジェクト計画です。

計画がなければ予測はあてずっぽうでしかありません。単なる期待、希望の類です。個人のイノセンスな願いであればそれもでいいのでしょうけれど営利企業ではそれでは事業継続が怪しくなるのでそうはいきません。

だから、事業が計画通りに拡大するように事業計画を立て、進捗をモニタリングしているわけですが。

計画とコントロール

計画を立て、期待値に収まるようにコントロールしたい。そこには計画したことを計画の期待する結果の許容範囲で到達すればいい。

プロジェクトマネジメントにはそうした力学が働いているとするならば、それを実現する手法としてのシステム開発手法はどれが適切か、と。

マネジメントの観点から言えば、期待する許容範囲で収まればどれでもいいのだけれど、プロジェクトマネジメントの考えの組み立て方と実現するシステム開発手法の適合性から言えば、ウォーターフォールが同様に計画を立て、計画通りに進めていくのでフィットするのは当然と言えば当然なのですが。

ゴールとは

一方、アジャイルはどうでしょうか。完了まで、例えばスプリントの中ではバックログの範囲の中でしか開発しない（割り込み案件がない）ので計画を立て、スプリントの中で期待値の範疇で納めるのであまり変わらないけれど、これをプロダクトとして全体噛んで俯瞰するとスプリント計画を作る際に実現したい要件が毎回再構成するのでプロダクトライフサイクルの観点ではゴールは、ウォーターフォールとは違う結果になっていても全く不思議ではないのです。

というか、変わります。

ここがマネジメントをする際にこれまでのマネジメントとは違う感覚を持たなければならないポイントです。

より、プロダクトにマネジメントが踏み込む必要がある、と思うのです。ウォーターフォールで作ってー、とはいかなよ、作ってーと言ったときと違うものが出てくるよ、その覚悟はしておく必要があるよ、と。

何せ、人は最初に見たものが正しいと思いがちです。同じ機能を実現していても、当初計画とその後に変わったものを並べれば、当初計画の方を正と脳内で補完してしまうので。

実現される付加価値への期待は基本的には同じです。実現手段と実現仕様が変わるだけなのですが。

図解リーン・スタートアップ成長戦略