エンジニアに必要な思考フレームワーク

「エンジニアはインプットを続けなければならない」
「実現した夢はいつでもさっと言えるくらい考え続けなければならない」
「閃きは、馬上(ばじょう)、枕上(ちんじょう)、厠上(しじょう)だ」

 

どれもよく言われているようでよく耳に(目に)することじゃないかと思うのです。このブログでもエンジニアのインプットについては(多分)何度か言及してきたテーマですし。2つ目の実現したいこと(=夢)はどうかな。記憶がないですね。3番目は昔から言われている教えのようなものです。

これを一つひとつ聞くとそうだな、しか思わないのではないでしょうかね。それに一つひとつ目の前に出されるとついつい渋々同意するようなフリをして、でもできない理由を言い始めたりしていませんかね。わかるんだけどインプットをする時間が…とか。

実現したい夢はいつも考えているからとっさに実現したい夢を聞かれてもさっと答えられるかもしれないけれど、そればっかり考えていられるほど暇じゃないんだよ、とか。

閃く場所はそうかもしれないし、そうだったかもしれない、程度で。

ところで、この3つをセットでと言われたらどう捉えますか。

知らないことでしか閃かない

閃きはそれまで気付かなかった2つの事柄を結び付けられるということに気づくことではないかと思うのです。

例えば手持ちの事柄(=情報)があってその中から2つの事柄を結びづけたら何かありそう、ということが閃きだ、ということです。

それが閃きのプロセスであると仮定すると、手持ちの事柄は多い方が事柄同士の組み合わせが選択肢として純粋に増えることになります。

逆に言えば、手持ちの事柄 が少なければ閃く組み合わせが少ないので閃く確率は限定的になるわけです。

夢はさっと言えるくらいに

 そのくらいいつも考えていなければ、夢は実現できないとも言われます。さて、これはどうしてでしょう。

いつでもさっと言えるということは、さっと言えるだけ夢に対するディテールを持っているという状態なのだと思うのです。自分の中で仔細までイメージアップできているからどんな夢かを具体性を持って説明することができるということです。

具体性を持っていて、仔細がしっかりしているということは夢を実現するために何を揃えればいいかを知っているということですし、揃え、組み立てれば夢が具現化するので作業レベルまで想定上では計画性を持っているということができます。

馬上、枕上、厠上

閃く場所が特定されているのですが共通項があるのですよね。必ず一人なんですよ。閃くことが2つの事柄を結びつけることだとするなら、一人になったときに実現したい夢を考えているときにその夢を構成する1つの事柄とインプットし続けてきてストックされてた事柄の組み合わせで今まで組み合わせたことがなかったカップリングがあることに気づいた場所がそこだった、と。

 

インプットを続ける

 ↓

実現したいことをイメージアップする

 ↓

一人でいくつも組み合わせを考える

 

というサイクルになるんですね。そしてもう一つ。PoCをしないと。Proof of Conceptですね。閃いたことの実現性を試さないと。

 

インプットを続ける

 ↓

実現したいことをイメージアップする

 ↓

一人でいくつも組み合わせを考える

 ↓

PoCで試す

 

 これってエンジニアの仕事だといつも出てくるんですよ。これも一つの思考のフレームワークなんです。

試してみてね。

 

アイデアのつくり方

アイデアのつくり方

 

 

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

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

 

 

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

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

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

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

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

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

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

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

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

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

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

 

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

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

 

 

進捗管理の設計の基礎

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

2つの面を持つ進捗管理

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

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

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

作業計画との関係

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

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

細かさの粒度(=程度)

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

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

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

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

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

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

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

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

把握する場作り

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

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

 

 

 

 

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

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

 

 

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

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

 

www.byosoku100.com

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

 

 

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

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

 

 

調達 UNISON SQUARE GARDEN

 予習せねば。

 

 

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

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

 
Dr.lzzy(通常盤)

Dr.lzzy(通常盤)

 
Catcher In The Spy(通常盤)

Catcher In The Spy(通常盤)

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

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

 
Populus Populus

Populus Populus

 
JET CO.

JET CO.

 
UNISON SQUARE GARDEN

UNISON SQUARE GARDEN