調達 デスマーチからはじまる異世界狂想曲

なんか、１話が…な噂を聞いて原作でも読むかという気になったし

デスマーチからはじまる異世界狂想曲 (単行本)

持っていない情報では作れない

何かを作ること、特段、仕事で作業して資料を作るとかコードを書くとかプロジェクトの運営の仕組みを作るとか、何か具体的なアウトプットをするためには情報を集めることが肝心です。

なんだ、簡単なことじゃないかと思うかも知れないけれど、エンジニアの中でどれだけの数のエンジニアが自分に任された作業に必要な情報を自分自身が手と頭を使って集めているかといえば極端に少ないのが現実です。

ドキュメントレビューをしていると極めて限定的な範囲や極端な前提やあまりにも身勝手な暗黙が隠されている事がままあり、それについて説明をしてもらうとしどろもどろになったり、たまたま視界に入った情報だけでアウトプットを無理くりにでっち上げている事だってあります。

いやいや、こういった情報があるじゃないと思うけれどどこまで知っていて、どこから知らないかはそれを実現するエンジニア本人しか状態を周囲に教えられることはできません。どこまで知っているか知らないかはエンジニア本人が周囲にアクセスすることで周りも知る事ができるのですけれど。

ではどこまで知っているかをどうやってしればいいのか。今作業している仕事の情報を自分で取りに行ったか、と自問する事で自分で判別する事ができます。多くはお膳立てされて、情報を外から与えられて作業をさせられている環境を作られている事を考えれば、自分の頭を使ってどこまで情報を収集しようとしているかで自分でアウトプットを組み立てるときに必要となる情報の輪郭が見えてくるからです。

情報を集めるということはどういった情報が必要だろうとあたりをつけるところから自分でしなければなりません。一旦、この辺りの情報があれば実現しようとしているアウトプットを作れるだろうと仮説を立てて、この辺りとぐるっと必要だろうと思う範囲を決めるわけです。

この、この辺りまでと決めることでさえ、少ない手持ちの情報から推測して仮決めする意思決定を働かせる必要があります。この範囲を決めること自体にあまり意思決定の重さはなくて、どちらかと言えば意思決定した考えの軸の方が意味合いは重かったりします。それは事を進めていくとこれでいいんだっけという自分自身が行った過去の意思決定への問いかけだったり、他者からなぜこう判断した事が正しいのかと問いかけられたときに立ち戻る根拠となるからです。

軸を持って一旦は収集する情報を集め始めればいいのですが、次に考えなければならないのはどこまで集めればいいのかという判断です。時間をかければある程度は集める事ができるけれど時間をかければいいアウトプットができるかと言えばそうでもないのです。それを決めるのは情報を組み立てて輪郭を作れるかどうかで判断します。

輪郭を作れたら集める情報の軸で実現しようとしているアウトプットがイメージできれば先に進めましょう。イメージアップできないならまだ情報が足りないか軸がずれているかも知れません。アウトプットの完了基準に照らして検証しなければなりません。

ここのプロセスをやらないために情報不足がアウトプットのチープさを引き起こすんですよ。

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

進捗管理の設計の基礎

進捗管理を「される」ことは嫌ですよね。ええ、放っておいてと言いたいです。でも作業の計画を作っておいて出来ていないというのもちょっと気が引けます。でもちょっと計画どおりに進まない進捗上の障害がありまして…。と切り出すのもちょっとした勇気と踏ん切りとその後に始末をつけないといけないという覚悟が混ざって一歩を踏み出せずについついいうタイミングを逃しがちの月曜日ですが、進捗はいかがでしょうか。

2つの面を持つ進捗管理

進捗管理は、エンジニアの立場から見れば報告するだけだと思っていませんか。違うんですよ。エンジニアの立場であっても2つの意味合いがあるのです。

1つ目は、誰もが知っているしやっているプロジェクトマネージャやマネージャに対して行なっている担当作業の計画に対する実績と見通しの報告です。作業計画に対して実績が前倒しで進んでいるのか、それとも計画より進み方が遅れているのか。その実績からこの後どうなるのか。これが１番目ですね。

2つ目は、チームのメンバの進捗の予実を知って、自分の作業への影響を知ることと困っているチームのメンバに対して自分が経験した解決策を共有したり実際に解決のための手助けが必要かを申し出るなどのチームとしての進捗の目線で捉える、です。 

作業計画との関係

進捗管理と切り離すことができないものが作業計画です。作業計画の設計がイマイチだとどう頑張っても進捗管理で知りたいメッシュの進捗は知ることができないからです。つまり、進捗管理の要件は作業計画の制約条件になる、ということです。制約条件になるということは、作業計画の設計をするときには進捗管理からのオーダーを取り込まなければいけない、ということです。

前述した1つ目の報告で報告を受ける側のニーズを把握していないとチームの都合だけの進捗管理となってしまい、報告を受ける側（＝マネジメントなど）のニーズには応えられずに後から進捗管理の設計からやり直すという二度手間になるし、過去の進捗は把握できないからその作業期間の進捗自体が使い物にならないことになりかねないということを招きます。

細かさの粒度（＝程度）

どの程度で作業の計画の予実を知りたいかはチーム＞マネジメントの優先順位があるのは現場で進捗の予実の較差のインパクトを受けるのはチームだからです。

でも、進捗管理を含むプロジェクトマネジメント はマネジメントからのオーダーなのは経営にインパクトを与えるかもしれないとマネジメントサイドが捉えているからです。

でも、いくら必要だと言われても進捗管理の単位が細かすぎれば報告のための作業の管理になってしまうので本末転倒です。

ところでマネジメントサイドは何を知りたいのでしょうか。それを知ればどうすればいいかが見えてきます。

マネジメントサイドは、チームの計画した作業の実績はある意味どうでもいいのです。特に計画通りに進んでいるなら。遅れているのもまあちょっと気になりますけどそれほど優先順位はちょっと下がります。トッププライオリティはじゃあどうなるのか、です。そう、見通しが知りたいのです。

それを伝えられる進捗管理になっていればいいのです。

ではチームではどうするか。

進捗の把握＝作業のロットが大きくなればなるほど予実の較差が大きく開きます。それをどこまで受け入れられるかが把握する範囲を広げる方向でどこで区切るかの判断ポイントです。逆にどこまで小さくするかはどこの粒度で遅延がわかるとリカバリができるか、で判断します。ある作業が今日おわらなければ翌日以降の作業でリカバリができないほどのリソースが足らないなら時間単位で把握する必要があるでしょうし、2−3日以内でリカバリができる余裕があれば日次か半日が把握する最小の単位でいいでしょう。

把握する場作り

 進捗管理の把握する粒度を決めて作業計画にインプットできたとしてもそれを吸い上げる場が必要です。粒度に応じて予実の較差を把握できる頻度で場を設定してください。

ただ、頻度が高いと場の開催回数が増えるので１回あたりの時間は相対では増えないようにしないとこれまた進捗報告のための場になってしまいます。そこは注意しましょう。

スモール・リーダーシップ チームを育てながらゴールに導く「協調型」リーダー

多重請負のエンジニアが闇から光を掴むために

金融系のN次オンライン更改とかシステム統合のような超大規模プロジェクトだったりすると多重請負があったけれど、メガバンなどの金融系は再々委託を禁止しているところが多いので建前上は、顧客＞顧客情報子会社＞プライム＞サブコンの形態までのはずで、それより以下はグレーゾーンだし、あったとしても知らぬところで契約違反をしたと言われかねないので下に入れないでサブコンの横並びで派遣に切り替えたりしているんじゃないかとと思うんですけれどねぇ。

www.byosoku100.com

まあ、これがいまだ存在するなら闇としか言えないし、2000年くらいの頃だったらまだそうした再々委託禁止とかは聞かなかったので4次、5次受けのエンジニアだろうを見かけたことはあるような気がするのだけれど。

多重請負のエンジニアに期待されること

 契約を守るコンプラ意識の高いプライムコントラクタであれば契約を直にするとか派遣にするとかで何とかしてでも欲しい人材なら下から上に引っ張り上げるだろうけれどそこまでのエンジニアがいたとしても契約手続きの面倒さと上の説得のコストを考えると、いる人材がたとえ無能であってもなんとかしようという心理が働くので結果的にN次受けのエンジニアがプロジェクトのキーパーソン的なロールにつくことはゼロなんですよねぇ。

N次受けのエンジニアがそのプロジェクトに参画するということの期待値は、労働集約型のプロジェクトとしてのリソースに見合う貢献をしてもらうことです。設計の下工程がそうした労働集約的な仕事のボリュームが出るのでそこで頑張って、となるわけです。

具体的には、（顧客用語かプライムベンダ用語の工程の総称に依存するけれど）詳細設計から結合試験の作業が割り当てられるわけです。

多重請負のエンジニアにできないこと

前述の割り当てられていない仕事全部なんですけれど。プロジェクト上の作業でできない＝経験が、という意味で。

多重請負のエンジニアの闇から抜けるために

いくら優秀でもN次受けのエンジニアでいたら一兵卒のエンジニアでしか仕事は回ってきません。全てにおいて契約がたちはだかりますから。コンプラを守らせようとする部門のチェックははいるし、顧客からもコンプラ順守をきつく申し渡されるので。

N次受け、多重請負のエンジニアでもプロジェクト全体の工程計画は比較的閲覧できるのは、情報セキュリティ事故防止的な意味合いと従来の座席に常駐させてヘッドカウントで契約させる人月商売のおかげといえばおかげだけれど、見ようと思えば見られるプロジェクトの内側にいることを改めて認識しましょう。

N次受けエンジニアが大規模プロジェクトのプロマネや開発リーダになることはゼロではないけれど、大規模プロジェクトから足抜けした後に経験するプロジェクトでリーダになる可能性は微％はあるのですから。

もし、プロマネや開発リーダになりたいと思うなら、大規模プロジェクトのプロジェクトマネジメントの方法論、やり方（実施要領的な）を標準化ドキュメントから引っ張り出して自分の知識に取り込むことをやりましょう。

ただ頭でっかちで手足が動かないエンジニアはそうした実務につけることは大手ベンダとかサブコンくらいじゃないと切られてしまうのでN次受けではいられないですよね。稀に混ざってくるけど。

実務ができること＝実際に取り込んだ方法論を一つの手段としてフォースを使えるようにすることです。

で、サブコンくらいの会社に移ること。そうしないとシステムエンジニアというなのオペレータ、単純工としての作業員のままで闇に消えてしまいます。

なぜ、システム開発は必ずモメるのか?

調達 UNISON SQUARE GARDEN

 予習せねば。

MODE MOOD MODE (初回限定盤A) [CD+Blu-ray]

Dr.lzzy(通常盤)

DUGOUT ACCIDENT (完全生産限定盤)CD+2DVD+Special Booklet

Catcher In The Spy(通常盤)

CIDER ROAD(サイダーロード)【通常盤】

Populus Populus

JET CO.

UNISON SQUARE GARDEN

調達 UNISON SQUARE GARDEN

 予習せねば。

MODE MOOD MODE (初回限定盤A) [CD+Blu-ray]

Dr.Izzy (初回限定盤)(CD+2 LIVE CD)

DUGOUT ACCIDENT (完全生産限定盤)CD+2DVD+Special Booklet

Catcher In The Spy(通常盤)

CIDER ROAD(サイダーロード)【通常盤】

Populus Populus

JET CO.

UNISON SQUARE GARDEN

スキトラで立ち上げる技術

途中から参画してきたSEと既存メンバとの経験知の差があればあるほど、立ち上げたいSEを確実に、しかも垂直に立ち上げたければモブがいいです。モブ・ペアがいい。これ、実感したので。

もうね、自分の子どもくらいのSEがjoinしてきて（それはそれでWelcome）でも、立ち上げどうしようかと、書類読んでおいてと放置気味にするのもあれだし、単純作業させるのはもっとイケテナイので。考え方（判断基準）を知ってもらって、実務でケースを学んで行けばいいかと思い至ってプロジェクト業務を仔細で教えることはせずに、手順や手法として概念を理解してもらった上で、実務で演習してもらおうとざっくりとプランを立ててやってみたんですね。

プロジェクトの特性を踏まえ、

1. 概念、フレームワーク的な仕組み、行動規範的な判断基準を教える
2. 伝えた内容をプロシージャとして説明してもらう
3. 理解できていないことはそのままにしないで聞く

を3本柱として始動しまして。

一旦、実務のトランザクションを渡して自力で処理してもらって、タイミングを見てここからモブで立ち上げのスキトラを始めます。

大型のディスプレイにjoinしたばかりのSEのPCを繋いでもらって実務のトランザクションの処理を追いながらまずは対応してもらったアウトプットの説明を一通り受け切ります。そうしないとやってもらったこととこちらん考えとの答え合わせになってしまうのでそれじゃ自分で判断できなくなってしまうからスキトラとしてはNGなわけです。目標はあくまでも自立してもらうことですから。

説明をしてもらった後に、再度トレースをします。インプット情報の読み方、疑義の見つけ方、個別判断の根拠などをディスプレイに向かってゆっくり、明快に、重要なポイントは繰り返し伝えます。

PCの操作は基本はやってもらいます、joinしたばかりのSEに。手を動かして参照する資料のありかを辿ってもらったり、資料に出てくる単語や製品名や技術用語をググってもらったりして、ついつい受け手が情報過多になりがちなところを受け手が自身で操作することでスピードをコントロールしてもらって情報を食べ続けられるようにします。

２時間が限界ですね。やってみると。休憩入れて、続きを。こうしたスキトラ的な作業であっても、先々の見通しをつけて伝えること大事ですね。事前に処理してもらった分量からだと、今のやり方ならここまでで終わるだろう、とかを。

こうして立ち上げたんだけど、最近の若手は優秀ですね。飲み込みが早くてこっちが追いつかない。

オークが女騎士を育成してみた 1 (ヤングジャンプコミックス)