2017-12-20

問題を読み、あなたの判断を答えなさい。

on SEサバイバル SIer エンジニアシステム開発トラブルプロジェクトマネージャプロジェクトマネジメント

「あなたはたまたまプロジェクトの会議資料を準備するためにオフィスにいたところを担当役員に呼び止められ、否応もなく会議室に連れ込まれた。役員の話では、どうやら大規模プロジェクトのあるサブシステムでプロジェクトマネージャを交代しなければならない事情があり、代わりを探しているらしい。大規模プロジェクトは、金融の分野でそのあたりの土地勘を持っている、つまり過去に金融の大規模を経験しているプロマネは出払っていないという。そのシステムは上場企業の基幹的なシステムでユーザ数も桁外れらしいとは噂では聞いていたが担当しているプロジェクトもありそんなプロジェクトもあるんだ、くらいの感心しか持っていなかった。そのプロジェクトは現行システムがありリプレース案件のため、システム移行には相当苦労することが予想される。顧客は官僚的な文化でベンダをコントロールしきれないとキャリアに傷がつくと過去のプロジェクトで実しやかにささやかれていたその顧客と同じ部門だった。プロジェクトの体制は、統括プロジェクトマネージャはリーダシップはあるが、全体的に進捗が遅れ気味であることと要件確認が思うように進度が上がらずかなり焦燥し始めているらしい。役員から相談されているサブシステムのプロジェジェクトリーダが事情がありプロジェクトから退場させ、金融セクターの経験を持つプロマネに交代させたい。チームのメンバは20名ほどいるがリーダ格のエンジニアが前任のプロジェクトを抱えており兼務であるようだ。他のメンバも委託先以外、つまり再委託と再々委託と大規模プロジェクトではよく見かける多重請負構造になっているようで詳しくはわからないという。ただ、サブコン、一次受けのパートナー企業が一括して請け負っているのでそこは問題がないと役員は言っている。プロジェクトは始まってから３ヶ月の要件定義のフェーズで、6週間経ったところらしい。プロジェクトはその後、設計フェーズに入るが、検証環境を設計フェーズの完了迄に一旦リリースしなければならなく、要件定義をしながら検証環境の設計やHWやSWの手配、回線の調達など日々残業が続いていると役員はそこまで話した後、今夜飲みに行こうという。」

あなたは金融セクターでの大規模プロジェクトの経験があり、プロマネの経験も十分持っている。これまでこの役員や他の上司に頼まれ、炎上プロジェクトの立て直しをしてきた。ただ、現在担当のプロジェクトもありそれはそれで楽しいのでそれを他のPMへ渡すのも惜しい気がする。

あなたの判断は、はてブのコメント欄にどうぞ。

成功するシステム開発は裁判に学べ！　?契約・要件定義・検収・下請け・著作権・情報漏えいで失敗しないためのハンドブック

作者: 細川義洋
出版社/メーカー: 技術評論社
発売日: 2017/03/07
メディア: Kindle版
この商品を含むブログを見る

2017-12-19

コードは下から駆け登り、プロマネは上から降りていく

on エンジニアシステム開発センパイプロジェクトマネジメントプロジェクトマネージャプロマネを育てる先輩後進育成

「今日のお昼は何食べましょうね」
「もうちょっと待ってて欲しいんだけど…」
「それ、今片付けないと午後に困るんですか」
「キリが悪いだけ」
「じゃあ、行きましょうよ。出遅れると混んじゃいますよ」
「でもなぁ」
「ほら、今こうしてお話ししているのだってやめちゃっているのと同じですよ」
「それもそうか。じゃあ行こうか」
「素直でいいと思いますよ」
「それで今日は」
「そうですね、久しぶりにベトナム料理とかどうですか」
「いいんじゃないの」

「ところで、配属された新人ちゃんがなかなか仕事を覚えなくて。メンターとしてはどうしたものかと悩んで悩んで」
「大変だ、先輩になると。まあキミが人に教える日が来るとは思いもしなかったけどさ」
「それひどくないですか、可愛い後輩が悩みを打ち明けているのに。第一先輩だってまだ私のメンターなんですよ」
「そうだよなぁ…配属されたときは期待していたんだけどなぁ」
「ちょ、それどういうことですか。今だって十分頑張っているじゃないですか」
「いやいや、こんなに元気が溢れまくっているとは思わなかったんだけだよ。こっちの方がHPを吸い取られているみたいだ」
「先輩のはいいです。イケメンに限ります」
「ははは、ならいいや。それで」
「新人ちゃんなので、ほら、テストとかコード書くところから仕事を振るじゃないですか。そこそここなしてくれるんです。いい娘です。私みたいに。ただ…」
「今なんか変なの混じってたけど気のせいかな。それでただ」
「プロジェクトの全体の進め方とかありますよね、工程とかプロセスとか。そういった仕組みづくりを理解するのが苦手みたいなんです。コード書いているときと反応もアウトプットも違うんですよ」
「まだ新人なんだろう。3年くらいは目を瞑ってあげないと」
「そうなんですが3年経ったときにしまった、となっては遅いですし。メンターですからエンジニアとして困らないようにしてあげたいんです。お姉ちゃんとして」
「そうか、3年後に困らないようにか…先まで考えられるようになった姿を見ると涙腺が緩むな。間違っていなかったんだな、俺の教え方は…よかった。ご飯も美味しいし、今日は帰るか」
「ダメすよ、どさくさに紛れて帰ろうとしちゃ。私の問題が解決していないんですから」
「そうだなぁー…その娘、作るものが見えている、いや、定義できているものを作るのは得意なんじゃないかな」
「作るものが見えているって、あ、アウトプットとか成果物が決まっているということですね。どうかな…そうかな…そうかも、そうですね。ちゃんと作ってくれますよ。だからいい娘なんですよ」
「それってさ、学校での学んできた学習方法なんだよなぁ」
「学校での学んできた学び方って」
「問題があってさ、答えに辿りつための式があってさ、で、正解がある。同じような仕事なら勉強できる子はその仕事はできるんだよ。問題はタスクでさ、答えは成果物でさ、作る手順が決まっていると、ほら、同じだろう」
「そういうことですか。へー面白いですね」
「だけどさ、プロジェクトのプロセスはそういう感じじゃないじゃん。コード書く技術知ってても役に立たない。どっちかといえば、コード書くのは小さな仕事を積み上げていくからその部品だけは知ることができるけどさ、部品を全部知らないからどう組み上げていけばいいか知らないし、組み上がったらどうなるかも知らないじゃないかな」
「えぇ、でも全体のアーキテクチャとか説明していますけど」
「多分、理解できていないよ。だって、やったことしか知識はないからさ、他の要素を聞いても想像できないんだよ。そこにプロジェクト全体みたいな世界観を持ってこられてもプロジェクト全体の仕組みがわからないじゃん。それであれこれ言われてもって」
「わかったような…わからないような」
「プロジェクトマネジメント系はさ、全体の流れを弟子のように連れ回して、プロジェクトマネジメントの中の仕事をになう存在理由を作ってあげないと。枠組みとそれを構成するマネジメントのストラクチャの中から繋がるものを一つひとつ経験させた方がいいんだよ。思い出してごらん。どうやってプロマネ覚えた」
「確かに工程の枠組みを教えてもらって、工程の中のプロセスとかそれを支える管理ビューとか切り出してもらったかも」
「だろう、それも小さなプロジェクトから始めたはずだよ。キミのレベルでもどうにか見渡せられるようにね」
「そうなんですね…コードを書くことを覚えるようなボトムアップなアプローチじゃなくて、トップダウン的な仕事の振り方をしないといけないんだ」
「そういうことさ。さあ、コンデンス入りのコーヒー飲んで仕事しようか」
「ありがとうございました」
「じゃあ何か手伝ってよ」
「そうですね、クリぼっちなら一緒にご飯食べてあげてもいいですよ」
「（ぶっ）あ…」
「あー何やっているんですか、はい、ハンカチ。しょうがない先輩ですね、全く」

Amazon Echo Dot (Newモデル)、ブラック

出版社/メーカー: Amazon
発売日: 2017/11/15
メディア: エレクトロニクス
この商品を含むブログを見る

2017-12-18

XP、モブプロを導入したいリーダが上層部を説得するための教育心理学

on 教育心理学モブプログラミング XP

人は自分なりの考え方、知識を持っているものです。子どもの頃に家庭の中でして良いこと、してはいけないこと、どちらかと言えばしてはいけないことばかりを教え込まれている（家庭により褒めるおうちもあるけれど）ので、そうした家庭の中での位置を確保するためにどうすればいいかを考え、存在を認められるための知識が積み上げていきます。こうした経験は後進的な性格の核となり、その人の行動を強く制限することになります。

その後進学とともに社会が広がり、初めて経験することは過去に積み上げてきた似たような経験を引っ張り出して繰り返し自分で経験から共通項を整理し、新たな経験に対処できるようになっていきます。それが良くも悪くも様々なことを知っている状態を増やしていくのですが、知っていることをわかっている、つまり仕組みを理解しているかどうかと言えば、多くのことについて知っているだけでわかっている状態にはなっていないのです。例えばウォーターフォールを説明してください、と問いかけたとき、説明できるエンジニアはそう多くはないのです。

知っていることとわかっていることは大きな差があります。

こうしたこと、つまり、知っていることが実はわかってないことであることは、その人が知っていることに対してどう知っているかの説明はいくらでも進んでしてくれるのですが、知らないことを進んで教えてくれることは少ないのです。

自分が何を知っているかを知ろうとしたり、どのように知識を得ているかを知ることは学習方法の習得の観点で大事なポイントですが、それを形式化したりすることは実は難しいということに由来しているためです。

「自分が何を知っているか」の自分を1人ではなく、「仲間で」に置き換えると状況は変わってきます。仲間で同じ課題を解決するためには、その課題を解決方法について自分の知っていることなのか、わかっていることなのかを伝えようとするようになります。こうした行為を相互に問題という触媒を介して理解をしようとすることで実は自分の知っていること、わかっていることに自分自身が触れるという1人では難しい経験を得ることができるのです。

さて、これは新人教育での指導役のエンジニアとのペアでの作業や、メンター、最近だとモブプログラミングが一部で取り上げられているのですが、こうした1人でやるより仲間同士でやる方が生産性が高いとかスキルの育成が早いとかの裏側にあるものなのではないかと思うのです。

ある意味、理論的な裏付け、というか。こうしたことも経験的に知っているよりはわかっている状態で手法を取り入れると効果測定がとてもしやすく、組織的な展開をする際の上層部を説得して同意を得るには効果的だと思うのですよ。