ブログトップ 記事一覧 ログイン 無料ブログ開設

室長のひとりごち このページをアンテナに追加 RSSフィード Twitter

2016-08-25

[]リーダが倒れたときに立て直す方法 08:13 リーダが倒れたときに立て直す方法を含むブックマーク



電話すみません申し訳ない…」

「どうしたの。何かトラブルでも」

「いま病院から電話してます入院することになったので…」

「わかった。病院名と病室教えて。お見舞いに行くから

「それよりプロジェクトの方が…」

「いいよ。やっておく。さしあたり今週の定例でしょ。メンバに聞いてなんとかしておく」

「ほんとスミマセン…」


「Bさん入院したの知っていますか」

「そうなんですか…」

「精密検査しないとわからないらしいです」

「(代打するんだろうなぁ)」

「(偉い人が)お呼びです」

「なんでしょう」

「Bさんの代わり、キミにしか頼めないんだよ」

「(やっぱりそうなりますよねぇ)まぁ、そうですね。やってみます


だいぶ設定は変えていますが、どちらも実際の話で、実際に代打してまして。つくづく思うのは、仕事


「経緯がわかる資料は残しておいてね!」


ただ、それだけです。はい


どうしようもなかったのが、後者のケースですね。ほんと、最終更新資料しかのこっていない。一緒に動いていた人は、指示され系のオジサンSEで何を聞いても物事をはっきりしない。幸い、会議承認された資料が残っていたのと情報を整理した最終更新資料があったのでこそから過去の経緯を壊さない範囲で組み立て直して前に進めるしかいかな、と。


最初にしたこと

後者のケースですが最初にしたことは、最終更新資料所在確認識別です。聞く相手がオジサンSEしかいないので、心穏やかに尋ねます


スケジュール、ほら、直近というか最新のここ数ヶ月のスケジュール作られていませんでしたっけ」

「これかなぁ(モニターに想定の資料を映す)」

「えっと、会議予定を見ると先週の資料にありそうだけど」

「あぁ、それですか。これですか」

「(これですかじゃないだろうに)その資料スケジュール入っていましたっけ」

「えっと、どこだ…」

「11ページくらいにありませんか」

「あぁ、これですか」

「それ、一番新しいスケジュールと思っていいですか」

「あ、はい


信じられないと思いますが、事実なのでしょうがない。あなた、その会議出てたでしょ。ほんともう…。


「あと、検討してきた資料って、その資料の中のことが決まっていることとおもっていいですかね」

「そうですね」

「これまで、関係者を集めて会議されてたとおもうんですが、会議議事録とかメモとかは会議フォルダに」

「作っていませんよ」

「そうなんですか。じゃあ、常に検討資料に反映されているんですね。ところで、質疑で課題も出てくると思うんですが課題一覧は」

「作っていません」

「そうですか。今日からは『作って』くださいね


なかなかレベルの高いオジサンSEだなぁ(褒めてない。


「あと直近の作業ってWBSでいいんでしたっけ」

ちょっとちがっています

「(WBSって意味が変わったのかな)じゃあ、午前中にいまの作業ざっとエクセルにでも書いてくれませんか。あと、納期担当も」

「できました」

ありがとうございます(開いて…えっと、これ、なに?)。あの、この作業名に資料名前書いてあるじゃないですか。これ、どんな内容なんですか」

「こんな役割の人とかあん役割の人とかが使いますが」

以下略


どう立て直すか

この状態でどう立て直すか、と。なかなか難易度の高い話です。はい。まったくもって、おじさんSEの話を信じるわけにはいかないです。再構築するようなイメージを持たざるを得ないですねぇ。とほほ。


会議資料承認されているので、その会議の重さの範疇意味を持ちます。なのでそこから逸脱するならそれなりに手回しをしておかないといけないので、その情報収集ってとことです。


前提を整理するのは、ワタシに依頼してきた偉い人に後でグダグダ言わせないためにです。それとオジサンSEに対して前から刺す意味合いだけです。


それで前提条件とやるつもりだったことが想定できるのと、なにまで決まっていて、なにをするつもりだったかの仮説を設定します


さてさて、現状のアクティティを知るのは、これからなにをするつもりだったかを知るためです。つまり、なにが決まっていないかを知ることができます


まあ、それもズブズブなわけですが。


だいたい、こんな感じで対応すれば多分、大丈夫

2016-08-24

[]スキルマップスキルは細くしてはいけない理由 08:19 スキルマップのスキルは細くしてはいけない理由を含むブックマーク


プロジェクトマネージャでもマネージャでも、実はメンバが持っているスキルを知らないことが多いのですよ。「えーうそー!」とおもうかもしれないけれど、そんなものです。


キャリアシートのような経験してきた業務経歴では案件名と主な適用技術しかかかれないですから。無論、ずっと一緒にやってきたメンバなら覚えていることもあるかもしれませんが、そうしたケースは稀です。マネージャもメンバも動いてこの瞬間、偶然一緒になっただけなのですから



チームのスキルマップスキルの軸は細かくしない

スキルマップはメンバの名前スキルの2つの軸で表を構成ます。メンバの名前はズバリのでそのままメンバの名前記載ます。考えて書きたいのはスキルの軸です。


 スキルAスキルBスキルCスキルD
名前 

このスキルマップを作る目的はなんでしたっけ。一人ひとりのマネージャにより、そのスキルマップの使い方は違うと思うのですが共通しているのは、



というように目的とそれを実装したら運用が伴うということです。スキルマップ作成した目的を達成すれば不要になりそうですが、人は動きますから少なくともマネージャ業務を担っている間は必要そうです。


続けられる程度にしておかないとスキルマップを維持すること自体負担になるので、あったらいいな、のような目的と密接に関連しない情報は載せることはやめたほうが良いです。


なので、目的を横目で見ながらスキルの軸を決めていきます。そこでオススメなのがざっくりと括ってしまう、というものです。



スキルはロールを記号表記する

メンバが持っているスキルは、ただ持っていると表記してもそれで作られた表にあまり価値はありません。どんなレベルのスキルレベルかまで表現しないとせっかく一覧化した目的が果たせなくなってしまいます


それぞれのマネージャスキルマップを作る理由はあるのでしょうけれど、少なくともスキルレベルを識別できなければ価値はそれほどないし、育成のプランを考えたり、育成を意識したアサイメントでは使えませんから


 スキルAスキルBスキルCスキルD
名前 

なので、記号スキルレベルを表記ます。つまり記号意味を持たせる、ということです。そのときのレベルは定義必要です。一覧表ですから、様々なスキルの種類が記載されることになるでしょう。そのときに、スキルごとの記号が違ったり、意味合いが違うと可読性悪くなりますから記号意味一定定義ます


スキルマネジメントしたい単位以上に細かくしない

その記号で何を表すかはマネージャスキルマップを作る目的によりますが、考慮したほうが良いのは、細くしすぎない、ということです。記号の種類も3種類くらいで表せるようにしたほうが良いでしょう。


凡例 ◎=プロジェクトマネージャ ◯=リーダ △=数回の経験 なし=未経験


スキルの列に役割表記することに違和感があるかもしれませんが、スキルビジネスソリューションや業種に結びつくので、そうした案件定義をすると理解しやすいでしょう。つまりスキルを使ったビジネスがあったときにどんな役割を担えるか、という意味です。


マネージャならビジネスに紐付けられますし、プロジェクトマネージャなら機能分担で紐付ければ良いでしょう。なので、あまり細かくする必要もないのです。

2016-08-23

[]10年後もシステムエンジニア自分のために種を蒔く 08:14 10年後もシステムエンジニアの自分のために種を蒔くを含むブックマーク


とある歓送迎会で送り出される方がいて、その方は定年退職をされたんですが、その方には随分と仕事上で助けらたので感謝のつもりで出かけていったらたまたま席順が隣になったので、次は何をするかをお尋ねしたら今の仕事とは全く関係のないことをするのですと。


その方は優秀だったしそれ相当の役職だったので、関連企業などに行けばいい待遇で迎えられるのではと思っていたので、人の関心ってわからないものだという思いとワタシも頭が硬いのかなというのと。


その方は年齢も体力のこともあるので、次の仕事は細く長く続けられる仕事がいい、と。そうですね、年齢は体力とリニア関係していますから


読者の方は多分、40代、30代くらいなのかなと仮定を置くと、その方たちは、10年後、20年後にはいまのワタシと同じ年齢になるでしょうし、さらにもう10年したら、退職された方と同じ年齢に達するわけです。


そのとき、何をして行きていくか。


でもですねぇ、そのときになって種を蒔いたとしても遅いんですよ。だいたい、種を蒔いたところで自分という土壌で上手く育って花が咲いて、実が付くかなんて種を蒔いてみないとわからないんですよ。


プランターと同じで、新しい用土知識技術更新しないと種の芽が出ても育つ養分がないのですし。芽は出てても花は咲かないかもしれない。実がなったとしても美味しいかどうかもわからないし。


からですね、いまから、10年後を考えて種を蒔く必要があるし、試験栽培してポテンシャル検証しないとけない。


このとき目標をどう設定するか、何を検証するか、判断基準を何にするか、こうした、いま仕事でやっている方法論が役に立つんですね。そして、戻ってこれない沼に嵌らないようにピボットをしながら残りの人生システムエンジニアとして生きる。


いや、別にシステムエンジニアじゃなくてもいいのですが。


次の10年のために種を蒔く。


これ自体が、システムエンジニアを育成するための、自分を育成するためのプラクティスなんですけれどねぇ。

[]シンゴジラをなぜ立川まで出かけて観たいと思うか 07:43 シンゴジラをなぜ立川まで出かけて観たいと思うかを含むブックマーク


立川といえばシネマシティですが、まあ、そう思うようになったのはガルパン地元で散々観たのに噂の爆音体験してみたいから、と思ったからですねぇ。1回くらいは縁起物としていいだろう、と。


その日は2本続けてみましたけれど。ガルパン


エキシビジョンマッチで始まるシーンの効果音地元映画館でもすごいなと思っていたから楽しみではあったのですが…なるほど、でかいわ。音が。って感じでした。はいガルパンブルーレイでも効果音が大きくて我が家普通テレビでもいい効果音していますからね。それが爆音になったらどうなるかと思って2本続けてみたわけです。


立川で。


それで今度はシンゴジラです。地元で見て、あ、蒲田くんはウツボだな、と思いながら観ていたら、「これ立川などうなんだろう」と思うのも自然なことです。はい


そんなことをTLに流していたらお友達から立川行こうよ!」とお誘いがあって、さっと予約して見に行きました。これ、すっかり手の内にはめられている感ありありですが、なんか基準ができてしまったのではないか、と。


パターンとしては、こうです。


地元映画を見る → もう一度見たい映画であること & 立川音響でみたいと思うこと → 立川なう


大事なことは「もう一度見たい映画であること」と思えるかどうか、ですねぇ。ガルパンならまだ見たいですけど。家でもですけど。はい


そういう意味では、立川で見たい映画は、ワタシ的には何度も見たい映画という基準を超えている映画として太鼓判映画なのですよねぇ。

2016-08-22

[]システムエンジニアを育成する立場の違いによる観点あれこれ 08:11 システムエンジニアを育成する立場の違いによる観点あれこれを含むブックマーク


マネジメントシステムエンジニアを育てるための観点

ビジネスを生むシステムエンジニアになって欲しいなら相応の報酬を与える」

「機会を作る」

時間を与える」


マネージャシステムエンジニアの育成で考慮しなければならない観点

エンジニアリングアーティスティックな2つの領域がある」

エンジニアリング領域は体系化された形式知を学ぶこと」

アーティスティック領域属人的領域であり画一的に育成はできない」


システムエンジニアを直接育成する立場での考慮

「『生まれ持った性質』と『経験により身につけた性質』を無視してはいけない」

「マイナスに見える性質の特徴は別の見方をすればプラスの特徴として捉えることができる」

個人好き嫌いアウトプット品質とは結びつかない」

「機会を与えること」


システムエンジニア自身自分を育成する観点

「図式化するとバーンダウンになるがゼロにはならず、維持するために最低量の継続的学習必要になる」

「現状評価を行う習慣を身につける」

「将来像を持ち、年間で育成するプラン実践する」

「見込み違いが当たり前でピボットしながら領域を広げる」

好き嫌いより、結果が出ている領域を伸ばす」

2016-08-21

[]MECEより大切なバウンダリという思考 08:53 MECEより大切なバウンダリという思考を含むブックマーク


ううう、ネットが切れてコミットしようとしていたブログが飛んだ…。泣く。


今日の書いておきたいことは、これ。




機能仕様Aを書くとき、A以外を考えようというのがMECEです。でも、そのAもA以外もある世界の中での分別です。その世界分別するのがバウンダリ、つまり、界面です。


バウンダリこそ、さまざまな情報を集めて、そのときに集められた情報の中でロジックを組み立てて、境界線を引く必要があります。


これを間違えると、AとA以外のはずがBもCも混ざってしまい、AとA以外という関係そのものが成立しなくなります。

なので、バウンダリの仮説を立てられるスキル必要です。


そして、このスキル上流工程で使いますが、上流工程でなくても身につけることができます。


と書いたとことでお時間です。