興味ないですプロマネなんて。だって見ていると大変じゃないですか。

某TLでコミュニティの参加者が15年も経っていることもあって(当時は30代だったメンバが)すっかりベテラン勢になってしまい新しいメンバが入って欲しいのにいつも同じ顔ぶれだ、どうしたらいいかと言うのを見つけて。

コミュニティ活動していると毎回の参加者の固定化や参加者の減少があると既存のメンバのアクティビティをあげようと考えるよりコミュニティ外から新規のメンバを取り込みたいと思うのはなんで何だろう。

ここまでつらつらと思い至って関連して思い出したのは、文化としても産業としても衰退している(と言われている)分野がいくつもあってそうした分野が共通的に持っているのが決まり事や暗黙のルールが多いと言うことなんですよ。言い換えればお作法をその分野の中で作ることで格式めいた権威づけをしているのです。

f:id:fumisan:20180128084742p:plain引用  和装振興研究会報告書

衰退傾向を辿りつつも未だ消滅していないと言うことは新規参画者があるんだろうけれど、回復しないと言うことは離れていくか退く方が多いと解釈することができます。

新規参加者<離れていく既存の参加者

新規参加者が衰退しているとしても一定の新規者がいると言うことは潜在的にもっと多いんですよ。候補者の母数としては。ただ、新規参加者とならないのは諦める理由があるはずです。

例えばやってみたいと思ってもコストがいくら掛かるか分からなければ躊躇するのは新しいことに使えるバジェットがある程度の予算感を持っているからです。女性なら(最近は男性も仲間同士でお揃いの紋付を装っているシーンを見かけることが増えましたが)七五三や成人式や卒業式で着物を着るか対象の候補になるのではないでしょうか。その際に、高くいくらでもコストが掛かることと手間の複雑さを知るのだろうと考えられます。

衰退をしている分野で規模を維持しようとすると取る手段は減少している既存参加者へのコスト増、つまり掛かる費用を品質を上げることで全体の規模を維持しようとする戦略です。平たく言えば客単価をあげていく手法です。

f:id:fumisan:20180128085037p:plain

引用 経済産業省繊維課

それが、お作法を強制する厳しさ、難しさ、将来のコストに対する不安ではないかと仮説を立てていますがどうでしょうか。

ここまで思いながら、関連して思ったのはプロマネやマネージャやアーキテクトのなり手が少ないのは引用した分野での衰退と同じ構造を持っているのではないか、と言うことです。マネージャが次世代、次々世代のプロマネ候補がいないと嘆くのは、プロマネになりたいと思っても実際にメンバとしてプロマネをやっているプロマネやマネージャの仕事に対する社内で守らないといけない規程やお作法が多すぎるし厳しすぎると言う実態を垣間見ていてやろうと思うか、と。

さらに言えば、顧客との折衝や社内からの管理部門のモニタリングと本来はレビューしたら同意しているはずで味方にならなければならないはずが突き上げの先頭となっている実態をプロマネ自身が愚痴を言っているのを見たらやりたいと思わないでしょう。

つまり、候補者が増えないのは増えないと言っている側が増えない環境を作っているのではないかと。

そこまで辿り着いて思い出したのがこれ。

 同士を増やしたければ自ら楽しみ、与えよ、なのでは、と。それがTLでコミュニティで候補者を増やしたいと言う1つの回答かと。でもそれって続けることなんですけれどね。

アビスパのツイから連想するとプロマネの薄い本が必要なのかも。 

ティール組織――マネジメントの常識を覆す次世代型組織の出現

ティール組織――マネジメントの常識を覆す次世代型組織の出現

 

 

職場の飲み会が面白くないのは若手SEだけじゃない

そろそろ2月と言うのに新年会をするのでと案内があり、立場的に出た方がいいだろうと思って出てみたけれど、職場の飲み会が面白くない。

これがまた、プロジェクトチームの飲み会だとちょっと違うのは、プロジェクトチームの飲み会だと日常から接しているメンバに関心が持てるので普段の仕事では話す機会がないこと(でも当たり障りがない程度で)について話し掛けようとこちらから話し掛けようと思う気にはなるんですけれど。それはそれで気を使っている(話題作りをして心理的なハードルを下げたい)と思っている上でやっていることなのでそれなりにアレだけれど関心があるだけまだいいんですよね。

で、戻ると職場の(管理職同士の)飲み会はほんとツマラナイ。嫌なら出なければいいじゃないかと思うだろうし、実際そうした方がいいのだろうけれどプロジェクトチームの先に出ているとプロジェクトチームのプレゼンスが希薄になるわけです。それは逆にプレゼンスを出したいのである意味組織内の広報役としてメンバは頑張っているよとアピールしたい、と。

関心が持てるなら楽しめる

つまり、そう言うことです。管理職同士も普段からどれだけ会話しているかで共通の話題や関心を知ることができるし、仕事を共同でしていれば色々あるだろうけど一緒に同じものを食べて飲むと言う生きるための行為に近い体験が親和度を引き上げるのだろうと思うのです。

仕事だと逃げられないから一緒の経験をしておけばその人柄、素の性質もヘンリを見せるのでどう付き合えばいいか、どう詰めればいいかも考えられる。そこまで考えているわけではなく、後付けだけど。

一方、プロジェクトチームの飲み会は逆にメンバに何かしら関心を持つことを考えておけば飲み会もそれなりに楽しめると言うことになるのかと。

もともと、職場の飲み会はどちらかといえば気が進まない方の人なので、仕事として出ているんすね。でも、あるキッカケでどうせやるならこうすればいいと言うことがわかったので。

どうせやるのだったら…

 子どもが幼稚園のときに割とイベントがある幼稚園で何かしら集められて発表を見たり子どもが覚えたことを一緒にやらされたんですね。まさに、やらされた感です。

でも、子どもは楽しそうに一生懸命に演じているんですよ。

それを見て、どうせやるならどうやったら楽しめるかと考えたんですね。子どもが相手だから、こちらがもっと楽しそうにやった方がいいのだろうと思って大げさに喜びながら演じたり反応するとね、まあ期待通りになるわけです。

チームの飲み会も同じかと。そのチームがある間は一番時間を過ごすのですから、メンバに接する時の心理的なハードルは目一杯下がった方がいいのは間違い無いので。

例えばこんな話を振る

もうファーストガンダムをリアルタイム視聴した年代は50代後半です。役員もゾロゾロです。なので不用意にアニメをdisると出禁になるかもと言うネタがあるようですが。

今期アニメや音楽、音楽はメジャーどころもOPで使っていることが多いので。聖地巡礼も結局観光なので知らない土地の話だと面白く感じますね。

 

 

 

 

 

コストマネジメントとは数字と対話してプロジェクトで起きていることを知ることである

プロジェクトマネジメント にコストマネジメント、一般にはコスト管理の方が通りがいいかもしれません。でもですねぇ、コストを管理するだとコストがfixであることが前提じゃないかと思うんですよ。イメージし易く言い換えれば、プロジェクトを開始する時に予算化が済んでいて月々の費用のキャッシュアウトを電卓をたたいて計画値の範囲に収まっているかどうかを眉間にシワを寄せてにらめっこしている感じ。だいぶ昭和のイメージですね。それはコストマネジメントじゃないぞ、そのfixする前のコストの積算はどこで誰がやっているのだと。それを含めるからマネジメントではないかと。

コストを把握する

コストを見積もると言うことは、見積もる対象が何で出来て(構成要素として把握できていると言うこと)、出来上がる順番を把握できて(組み立てる順番を変えるとかかる費用が変わることもある)、見積もる対象(直接費、間接費、配布費用)を漏れなく見積もる若しくは見積もりを取ることができる(費用を積算できる) ことが必要です。

コストを計画する

コストをマネジメントすると言うことはプロジェクトでかかる費用のキャッシュアウトとキャッシュアウトのタイミングを把握してプロジェクトのバジェットがショートしないようにコントロールすると言うことです。

例えばSIプロジェクトでWebサービス(IaaSとか)を使うことを前提としているならいつのタイミングから使用するか、どこから課金されるのか(Webサービスなら使用タイミングからだけど)を約款を読んで計画しておかなければならいです。

エンプラのパッケージソフトの場合は少し違って、プロダクト利用(=商用)のタイミングとか、実装のタイミングとか開発環境なら課金されないとかややこしいのでベンダ営業にねじ込むんですけれど。

キャッシュアウトのタイミングも調達の支払い条件で翌月とか翌々月とかあるのでその辺りも押さえおく必要があります。が、プロジェクト観点では月次に使った経費はアウトしたとして押さえておけばいいのですけど。どちらかと言えば契約として知っておけと言うくらいで。下請法とか制約事項があるので。

コストをモニタリングする

 今月にかかった経費を締めたら計画値より多かった、少なかったと増減で喜んではいけません。これは進捗管理の予実管理と連動しますけれど、使った経費が計画したアウトプットをプロジェクトで得られているかどうかと言う問題があるからです。

かかった経費が予算より少ないけれどアウトプットが得られていれば、見積もり精度が甘い(見積もりが過大かリソースレベルの前提が上回ったか)と言うことだし、先々の見通しのブレ幅が大きいと言うことが予測できますし、逆であれば見積もり過小かリソースレベルが低いかその他プロジェクトがトラブっているとかプロジェクトマネジメント サイドでToDoがあるはずです。

だから、ただ数字を見るだけじゃダメなんだよ、と言うことなのです。数字とプロジェクトの現場で何が起きているかを対話しなければならないのです。

 

 

女騎士、経理になる。 (1) (バーズコミックス)

女騎士、経理になる。 (1) (バーズコミックス)

 

 

 

 

見えない鎖を自ら繋ぐSE

今のITビジネスは分けるとすると2つに分類できると思うのです。1つが従来の人月売りのSIビジネス。SIビジネスと呼んでいいのか別の呼称があるの判別しないけれど。2つ目がWebサービスやアプリなど自社プロダクトを提供するビジネス。これ別に新しものではなく、元々はパッケージソフトウェアが供給手段がメディアからWebに移っただけなんだけれど。こちらも一括りにする名前があるかは知らないけれどここではプロダクトビジネスとしましょうか、便宜上。そうそう、エンプラのパッケージでカスタマイズしないと機能しないプロダクトは2つの間くらいなので面倒だから棚上げしておきます。

SIビジネスは何を売っているかというと契約書を見れば結局SEの時間を売っているのですよね。なぜそう言い切れるかといえば、提供時間を記載した契約書が多いいから。そして、客先常駐がほとんどで、提供時間だけ座席に座っていることが顧客が理解できるお金に変換できる単位だから。

一方、プロダクトビジネスは(提供手段は別にして)パッケージを買ってPCやサーバにインストールして構成すればあとは使えたり、それもいらないで使えるソフトウェアですから、顧客はプロダクトの対価と実現できるだろう機能を交換しているわけです。そうだとしたら、プロダクトビジネスは価値を売っているということになるわけです。使ってみたら…は見る目が顧客になかったということで。

見えない鎖繋ぐのはSE

 SIビジネスは、時間を売るビジネスです。提供時間=人月いくら、で売るのですから。営業がいれば営業から、いなければマネージャからどこそこで

 

「160時間働いてこい」
「180時間で契約したから」
「残業は請求するからどんどん働いていいよ」

 

と言われて送り出されるんですよ(ほんとかな)。

そう言われると仕事ですし、普通に人が良いから言われた時間は常駐先にいないといけないと思うんです。SE自身が自分に対して勝手に思い込むんですね。契約だからいないといけない、と。

これ、SE自身が自分で自分に見えない鎖を繋げているんですよ。確かに契約では提供時間が書いてあるかもしれないけれど、派遣のような時間制の契約でなければ風邪引いたりインフルエンザで1週間休んでも文句言われないですし精算なんてそうそう言われないですよ。その事務手続きの方がコストが高いし上司や関係文書に説明が必要だし。だったら、翌月に辻褄合わせてと言いますからね。買う方は。

提供時間=価値になると

 SEの頭の中で時間が価値になると常駐先で仕事をするために自分の時間を配分することが優先順位がトップになるんですよ。SEが考える価値のあるもの=時間です。プロダクトビジネスのSEが考える価値のある使える機能を苦労して捻り出して実装するのとは対局にあるわけです。

ここまでちょっと若干修正しようと思うのでタイトルの意味合いはこんな感じです。

 

時間=価値は多くの時間を提供することに価値を見出す

 

が言いたいことです。

これ、SIビジネスのSEは自分で見えない鎖を自分で喜んで繋ぐから定時を過ぎても現場に残って仕事をする。多くの時間を提供することが契約だ、サービスだと信じているから自分の時間をどんどん削っていくんですよ。

定時で帰るのと残業を2時間した後にできることが違うんですけれどねぇ。

時間=希少価値なリソース

 と捉えるとこれまた変わるんですが。でも、提供時間がrevenueになるから長時間提供しようと働くんですよね。そんなに急いでどうするの。同じ成果を出すなら時間をかけた方が良いものができるじゃんとかよくわからないことを言い出す始末です。

提供する時間が短ければ短いほど良いはずなんですけどね、特に顧客やプロダクトビジネスのSEの視点なら。

その視点を持てるようになると、自分の持ち時間は誰でも24時間で、1人月フルフルで働くなら短い時間で成果を出して文句を言われないようにしておいて自分の売られていない時間を活用しようと思うんですよ。

だから定時で帰って技術習得をしようと勉強会に行ったり、コミュニティに行って情報を収集して「自分の将来の価値」をあげられる方に時間を使おうと考えるんですよ。

でも、SIビジネスのSEはそんなことやっていられない。だって、自分で見えない鎖を繋いでいるくらいですから、自分の価値を上げる時間を作れないし、気づく機会もないのです。だって、その常駐先にいるSE全員が同じように考えているのですから。

 

 

旅かえる

旅かえる

  • Hit-Point Co., Ltd.
  • ゲーム
  • 無料
トヨタ生産方式――脱規模の経営をめざして

トヨタ生産方式――脱規模の経営をめざして

 

 

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

馬上、枕上、厠上

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

 

インプットを続ける

 ↓

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

 ↓

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

 

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

 

インプットを続ける

 ↓

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

 ↓

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

 ↓

PoCで試す

 

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

試してみてね。

 

アイデアのつくり方

アイデアのつくり方

 

 

話題の音声入力をしてみたらネタっぽくなってしまった(ネタではない)

早朝、歩きながらgoogle docsに音声入力をしてみたところ、ネタっぽくなってしまったんだけど…。

なんでI'veとかぷくぷくそーホーズってなんなの。

 

f:id:fumisan:20180124071726p:plain