調達 UNISON SQUARE GARDEN
予習せねば。
MODE MOOD MODE (初回限定盤A) [CD+Blu-ray]
- アーティスト: UNISON SQUARE GARDEN
- 出版社/メーカー: トイズファクトリー
- 発売日: 2018/01/24
- メディア: CD
- この商品を含むブログを見る
DUGOUT ACCIDENT (完全生産限定盤)CD+2DVD+Special Booklet
- アーティスト: UNISON SQUARE GARDEN
- 出版社/メーカー: トイズファクトリー
- 発売日: 2015/07/22
- メディア: CD
- この商品を含むブログを見る
- アーティスト: UNISON SQUARE GARDEN
- 出版社/メーカー: トイズファクトリー
- 発売日: 2013/02/06
- メディア: CD
- クリック: 3回
- この商品を含むブログ (4件) を見る
- アーティスト: UNISON SQUARE GARDEN
- 出版社/メーカー: トイズファクトリー
- 発売日: 2011/07/06
- メディア: CD
- 購入: 5人 クリック: 17回
- この商品を含むブログ (12件) を見る
- アーティスト: UNISON SQUARE GARDEN
- 出版社/メーカー: トイズファクトリー
- 発売日: 2010/04/07
- メディア: CD
- クリック: 28回
- この商品を含むブログ (9件) を見る
- アーティスト: UNISON SQUARE GARDEN
- 出版社/メーカー: トイズファクトリー
- 発売日: 2009/04/15
- メディア: CD
- クリック: 42回
- この商品を含むブログ (37件) を見る
スキトラで立ち上げる技術
途中から参画してきたSEと既存メンバとの経験知の差があればあるほど、立ち上げたいSEを確実に、しかも垂直に立ち上げたければモブがいいです。モブ・ペアがいい。これ、実感したので。
もうね、自分の子どもくらいのSEがjoinしてきて(それはそれでWelcome)でも、立ち上げどうしようかと、書類読んでおいてと放置気味にするのもあれだし、単純作業させるのはもっとイケテナイので。考え方(判断基準)を知ってもらって、実務でケースを学んで行けばいいかと思い至ってプロジェクト業務を仔細で教えることはせずに、手順や手法として概念を理解してもらった上で、実務で演習してもらおうとざっくりとプランを立ててやってみたんですね。
プロジェクトの特性を踏まえ、
- 概念、フレームワーク的な仕組み、行動規範的な判断基準を教える
- 伝えた内容をプロシージャとして説明してもらう
- 理解できていないことはそのままにしないで聞く
を3本柱として始動しまして。
一旦、実務のトランザクションを渡して自力で処理してもらって、タイミングを見てここからモブで立ち上げのスキトラを始めます。
大型のディスプレイにjoinしたばかりのSEのPCを繋いでもらって実務のトランザクションの処理を追いながらまずは対応してもらったアウトプットの説明を一通り受け切ります。そうしないとやってもらったこととこちらん考えとの答え合わせになってしまうのでそれじゃ自分で判断できなくなってしまうからスキトラとしてはNGなわけです。目標はあくまでも自立してもらうことですから。
説明をしてもらった後に、再度トレースをします。インプット情報の読み方、疑義の見つけ方、個別判断の根拠などをディスプレイに向かってゆっくり、明快に、重要なポイントは繰り返し伝えます。
PCの操作は基本はやってもらいます、joinしたばかりのSEに。手を動かして参照する資料のありかを辿ってもらったり、資料に出てくる単語や製品名や技術用語をググってもらったりして、ついつい受け手が情報過多になりがちなところを受け手が自身で操作することでスピードをコントロールしてもらって情報を食べ続けられるようにします。
2時間が限界ですね。やってみると。休憩入れて、続きを。こうしたスキトラ的な作業であっても、先々の見通しをつけて伝えること大事ですね。事前に処理してもらった分量からだと、今のやり方ならここまでで終わるだろう、とかを。
こうして立ち上げたんだけど、最近の若手は優秀ですね。飲み込みが早くてこっちが追いつかない。
調達 アイデアのつくり方
積ん読。
- 作者: ジェームス W.ヤング,竹内均,今井茂雄
- 出版社/メーカー: CCCメディアハウス
- 発売日: 1988/04/08
- メディア: 単行本
- 購入: 91人 クリック: 1,126回
- この商品を含むブログ (378件) を見る
カンバンは雑に始めた方がいい
カンバン、そう、ホワイトボードに縦に2本ラインを入れて都合3分割して、左からTodo(やる予定の作業)/Doing(やり中の作業)/Done(終わった作業)と配置するアレです。
付箋紙を用意して、Todoを書き込んで作業を着手したらDoingに、作業が完了したらDoneに付箋紙を作業した本人が動かします。作業をメンバなら誰でも見られるようにすることで作業の進度を可視化できるようになります。
付箋紙(=作業)はメンバが自分でやりたい作業を選びます。作業をメンバ自身が選ぶことで、特定技術を特定のメンバに割り当てないことから属人化を防止する効果があります。
とまあ雑に説明するとこんなところです。カンバンとの出会いはかれこれ5年以上前ですけれど、プロジェクトの期間中にずっと使ってもらって、カンバンで得たい効果を持続するには雑に始めた方がいいかな、と思います。
雑にとは、冒頭の線を2本入れてTodo/Doing/Doneの3分割だけ、から始めるということです。3分割で始めたあとはメンバに好きに変えていいよと言い続けることだけすればいいです。印象に残っているプロジェクトが2つあって、どちらも気づいたら3分割で始めたカンバンは別物になっていました。
カンバンをメンバから始めようと言ってくれればどうぞ、どうぞ、と眺めるだけにしますが、チームの作業の進度が思わしくなかったり、作業上必要な意思伝達でチグハグなところがあったらカンバンでどこに問題があるかをチーム全体に投げ込んでしまうのがいいです。チームの問題なので。それで気付くんですよね。見えるので。誰かがどうする、こうしよう、と動き始めたら大丈夫なんですけれど。そうするともっと細かく作業のステップを知りたくなるんですね。違うな、知って欲しくなるんですね。ここまで進んだら、連携しましょう、とか。
印象に残っている2つのチームはどちらもプロジェクトの特性を取り込んで、作業プロセスを組み込んだカンバンになっているところが共通項と言えるかな、と。見た目は違いますけれど、たくさんの列に分けたところが違っているのがチームとして見えるようにしておきたい作業のステップになっているんですね。それで作業の状態を共有して次どうするかをチームで判断していく、と。
カンバンは雑に始めるんですが、プロジェクトとしては契約があるので進捗報告をしなければなりません。ここは雑にすると進捗の不整合が出て後々面倒なので報告相手に応じてレポートをします。
付箋紙だけで進捗管理をしているとあとで実績が見れないので電子データにしておきたくなるのですがここはお好きなツールでやっておけばよくて、それこそ報告業務を担うプロマネ(=PO)が情報収拾をカンバンから拾えばいいし、手が回らなければそれを代替してもらえるバジェットを渡せばいいので。
カンバンで可視化を続けるポイントは、チームの情報共有のそれこそメンバたちの掲示板になるようにカスタマイズしまくってもらえばいいのです。そうですね、マイカンバンになれば。グッズが貼ってあったり、資料が貼ってあったり、全体スケジュールが貼ってあったり、メンバの顔写真やイラストやキャラクタでチケットオーナがわかるようになってたらいいカンバンかな、と。
- 作者: Marcus Hammarberg,Joakim Sundén,原田騎郎,安井力,吉羽龍太郎,角征典,?木正弘
- 出版社/メーカー: オライリージャパン
- 発売日: 2016/03/26
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (7件) を見る
進捗管理でどこまで把握してどこまで報告するか
勝手に立ち上がった勉強会(立ち上げのお誘いを受けた限定的なもの)で共通テーマを掲げつつシステム開発手法やらプロジェクトマネジメントの事例を共有して、それぞれの専門職としての疑問や突っ込んだところを聞いたり、専門家としての見解をフィードバックしたりしているんですけれど。ある回の中で進捗管理でどこまでプロマネとして把握してどこまで(プロジェクトチームから見たときの)外部(社内もチームから見たら外部だし顧客も同じで程度の差がある)へ報告するかという話題になったんですね。
と、ここまで前振りです。
ある事例では、コンテキストを読む限り全部見せている、と。
ちょっと思い出してください。例えばウォーターフォールでシステム開発手法をやっていると、工程の最初(基本は前工程の後半で)次工程の計画を立てる(WBSからスケジュール化する)じゃないですか。ね。で、実際始めると計画外の作業が増えるんですよ。例えば、技術調査とか環境構築時のトラブルとかパッケージの問い合わせとかでトラップを踏んだ(製品バグ)とか。最初は課題管理レベルだったものが見通しが長そうなテーマが出てくるわけです。
問題なんだとその会合でも言ったのだけれど、多くのケースは良くて課題管理に押し込んでしまっていて作業として可視化しないんですよ。進捗上は見えない。チームの中でさえ、担当をアサイン(というか地雷を踏んだメンバがそのまま引っ張る)したらあとは「解決した。え、いつするの」的な感じでやっているはずです。で、ズルズルと。
だって、WBSにないですからね。誰からもトレースされないんですよ。さらに言えば、適切な解決期限も設けない。で、そのトラップが解決していなければ後続作業が着手できないところまで来て、初めて騒ぎ出す…と。
あるあるでしょう。
話を戻して全部見せている事例はそうしたこともチケット駆動でやっているのでチケットを発行しないと作業を認めない、というチケット駆動のお手本のようなやり方をしているので全部チケットに入っていく。
その上、全部見せているから管理対象となる作業の母数(=チケット)が増えていく。本来、これは顧客やマネジメントから見たら不安になるし、困るんですよ。
何が困るというと、前週と比較ができないんです。母数が増えるから。やるとしたら比率で把握するしかない。でも、比で把握してもダメなんですよね。マイルストーンまでに必要な作業が終わるかどうかをマネジメントしたいので。
どこまで把握すればいいか
標題に戻して。進捗管理をどこまで把握すればいいか。
これは全て把握してチケットなり(excelでもいいけれど)WBSに記載しなければダメです。リソースの割り当て状況が把握できないので。カンバンで可視化してWIPをモニタリングしていればいいけれど。
どこまで報告するか
これはステークホルダマネジメントの一部だと思うんですよ。あと、プロマネとしてどこまで裁量(プロマネが腹を括るか)でプロジェクトのコントロールを確保するか、統制するかの問題なのです。
顧客から見たらアウトソースしているプロジェクトが転ければ、顧客プロジェクトがパーになるかもしれないので早く悪いことは報告しろ、包み隠さず報告しろというんですよ。でも、それ真面目にやるとマイクロマネジメントとして介入されるんです。顧客が官僚主義なら100%そうなります。顧客の中で担当が詰められますから。
そう考えると(過去の報告を思い出しつつ)計画作業をベースとして予実と課題のインパクトとプロジェクトの見通しを把握できる情報をあまり加工せずに出すのがいいかと。
あまり加工しないとは、例えばチケット管理システムで、報告用のビューを作っておいてそれだけ報告するイメージ。課題は課題のチケットビューを作って流し込みしておしまい、みたいな。
社内と顧客との差はと言えば、社内のレビューアが有能ならそのまま見れば、と開放しておくのがいいと思います。お前たち用のレポートはない。これ見て判断しろ、と。エンジニアのはずなので。
アプリ開発チームのためのプロジェクトマネジメント チーム駆動開発でいこう!
- 作者: 稲山文孝
- 出版社/メーカー: マイナビ出版
- 発売日: 2015/04/28
- メディア: Kindle版
- この商品を含むブログを見る
コピペで考えない中堅SEはプロマネに夢を見る
まあ、普通は経験を積めばSEリーダ(で通じるのか。あれですアレ、サブシステムのまとめ役とか小規模案件のプレイングマネージャ的な役割)を期待されるし、アサインされます。え、されたことないんですって…それはアレですかね、多重請負でのSESや実質派遣みたいな偽装ホゲホゲですかね。それともあなた…(じっと顔を見て目を逸らす)。いえ、失礼しました。キャリアはエンジニア人それぞれですから…と鏡に映る自分…。
それはさておき、やはりエンジニアとしては最前線でいい感じでコード書いたりリーダシップを発揮したりしたいですよね。
コードを書くセンスがない
あ、ワタシのことです。ええ、わかっています。ところで貴方のコード、イケてますか。そうですかそれは何よりです。ぜひ次の案件ではご一緒しましょう。
新人で配属された維持管理案件ですでにわかっていたことです。というか、学生のときの演習でよーわからないままにしておいたことがまずかったんだろうなーと。
昔話は横に置いて、エンジニア10人並べたらやっぱり向いている、向いていないとばらけると思うんですよ。機能するシンプルなコードを書くエンジニアもいれば、コピペするエンジニアもいる。割といる。コードの良し悪しの吟味は素人ですが、エンジニアにスライド作らせれば大体わかりますね。このエンジニアじゃダメだろうな、って。ただ、ダメなエンジニア全員がそうとは言えなくて物事の仕組みを作ったり整理したり仕組み化したり概念化するのが得意なエンジニアもいるんです。実に不思議。
コピペで考えない
スライドもそうですが、他のエンジニアが作ったスライドやコードを咀嚼、つまりこれから作るコードなりで実現したいことにフィットするようにするにはどうしたらいいのかを考えずに(そう見えているのよ)他所から持って来てそれでいいのかと思うくらいチグハグなままで突っ込んで、さもしたり顔でできたというエンジニアがたまにいるのですよ。ほんと勘弁して。
もう、形式だけ、見た目だけ、技術がないから「てにをは」だけを指摘するPMOやレビューアと同列ですよ。それのエンジニア版。少なくともその作ろうとしているアウトプットと関連する領域との整合性とかあるじゃないですか。なんかエンジニアの一方的なやっつけ感で作っているような感じなんですよね(そう見えるんだよ)。
スライド(仕様とか)を作らせるとページで構成を考えているか分別できるのでなるほどなと思ったり(褒めてない)。
プロマネに逃げようとする
コードを作れないとかスライドで仕様をまとめられないとロールが糞詰まるんですよ。上に上げて貰えない。そりゃそうです。仕様もまとめられない(致命的なセンスの悪さがある)とかコードだってメンバを指導できないとか古い技術、手法しかなくて周りから置いていかれていたらそりゃSEリーダなんかにして貰えない。
でも、本人はやっつけで生きてきたからまだいけると思っているところに糞詰まると文句を言ったりストレス貯まるんですよね。いや、自分で貯めているじゃんって思うけど。
目の前にやり手のプロマネがいたりするとキラキラしているように見えるんでしょうね。見えないところでちまちまと積み重ねてロジックを作って成果物を整える割と面倒な仕事なのに。コードを書くようなものですし、スライドを作ってスタンプラリーしながら沢山のステージをクリアしていくキラキラ感なんてゼロの地味なお仕事なんですけれどそうした経験を回避してきているからわからない。そんなエンジニアに限ってプロマネになりたいとかいうんですよ。
考え直させる
そういうとき、ちっちゃい案件やちっちゃいブロックにアサインして目を覚ませることもたまにやるんですけどね。たまにです、たまに。
たまににしないとメンバやプロマネに申し訳ないというか、まあ、プロマネには後進育成だから見極めて、とお願いしちゃいますが。リソースはgivenで特性を見極めて活用する訓練を…したいですよね。プロジェクトで取り返しができないまでにはならないようにしないといけないですが。
コードが不得意でもロジックの考え方が分かるとか、物事を把握するのが得意だとか、困っていることの本質を捉えるのが上手だとか、モヤっとしていることを具体化してみせるのが上手だとか、指示の出し方、お願いの仕方がナンパ師級に上手だとか、プロマネのセンスとして必要な素材を持っているかどうかをやらせた実績で見せてどうするかを考え直させるしかないですね。選択しなさい、と。それでもプロマネしたいと言ってもここではアサインされないよ(と暗黙に)はっきりと示さないと本人が不幸になるだけなので。
専門家としての仕事をしよう
「お、こんなところで。外出してた」
「こんにちは、センパイ。そうですよ。お客様に叱られに行って来ました」
「若いのに宮仕えも大変だな」
「なんですかその宮仕えって。そうだ、こんなところで会ったくらいなんですから時間ありますよね。叱られたので甘い物を補充しないと死んでしまいます。さあ、ここはセンパイは先輩らしく後輩を甘やかすところです。行きましょう」
「なんでそうなる…いつもだけどさ。しょうがないなぁ」
「それで今日は何を叱られたんだ」
「それは教えられません。守秘義務があります」
「そりゃそうだけどさ、秘密情報に触れない範囲でならいいじゃん。そのスイーツ分だけでもリークしろよ。話せば楽になることだってあるんだからさ」
「それもそうですね。一言で話せば資料の詰めが甘かった、というところでしょうか」
「なんだ、自爆か。ふーん、そうか。それで」
「これ以上は教えられません、センパイでも」
「違うよ、何があって資料の詰めを甘いままでいいと判断したんだい」
「あ、そういうことですか。そう…どうして甘くなっちゃったかあまり自分でもわからないんですけれど。会議資料の締め切りに間に合うように出したら…」
「なんとなく分かるような気がするけどさ。まぁ嫌な感じかもしれないけれど仕事で嫌な思いをすること自体がナンセンスだしさ、潰しておいたほうが良いと思うけどね」
「…やっぱりそうですか…そうですよね…うーーーんっと、なんででしょうね時々やっちゃうんですよ。え、そう詰めが甘くて失敗するケースを」
「…まあね(そういったことは自分で答えかもしれない考え方を見つけた方がいいんだけど…なんとなくこの前のことと繋がっているような…)」
「大丈夫です。叱られるのは慣れっこですから。次また頑張ります」
「あのさ、誰のためのその資料は作ったんだい」
「え、もちろんお客様への説明のためですよ。決まっているじゃないですか」
「それはそう答えるかもしれないけれどさ、本当は」
「本当って…本当ですよ」
「違うと思うんだよ。プロジェクトを進めるため、それってチームの仕事が進むためになっているかもしれない。書きっぷりで変わるけどさ。俺たちはエンジニアだからさ、エンジニアの思いが強く出ることの方が自然なんだよ。
いや、顧客の立場でっていう人もいるけれどさ、そこはやっぱりエンジニア、専門家としての見解を踏まえた資料になっていないといけないと思うんだ。それが正しいなら資料は中途半端で作って出してはダメってことになる。そうだろう、専門家としての見解が不十分なんだから」
「難しい言い方しますよね。せっかくアドバイスをするつもりならもう少し私にわかりやすく離してくれてもいいんじゃないですか。それこそセンパイがおっしゃるように専門家として」
「あはは。そうか。まあ、アドバイスってほどでもないんだけどさ。この前に会ったときのことがずっと引っかかっていてさ。なんとなく繋がったんだよ。仕事っぷりで悩んでいるかなってさ」
「…」
「もしだよ。これはそうかも、と思っているだけだからさ。もし、仕事っぷり、出来不出来で悩んているとしたら、その成果が専門家の仕事だと言えるかどうかで判断したらいい。単純な話なんだよ。基準は自分の感情じゃない。お金を出して俺たちの技術をbuyしてくれる顧客へ渡す技術的な価値があるかどうかで判断するんだ。
エンジニアの大義なのかもしれない、なんていうと大げさかもしれないけど少なくとも俺はそうしてきたよ。参考になれば」
「…言い換えると、専門家として恥ずかしくないかどうか、ということですか。そうでうすね少し足らないかもしれません…こうしていられないです。さっきの資料を直さなきゃ。専門家として。ではごちそうさまでした、センパイ。また奢ってください」
「はいはい」
- 作者: ジェームス W.ヤング,竹内均,今井茂雄
- 出版社/メーカー: CCCメディアハウス
- 発売日: 1988/04/08
- メディア: 単行本
- 購入: 91人 クリック: 1,126回
- この商品を含むブログ (378件) を見る