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

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

2016-06-25

[]変わらないエンジニアのみなさまへ 08:50 変わらないエンジニアのみなさまへを含むブックマーク


昨日の英国EU離脱決定を受けた為替市場は急激な円高に向かっていますが、個人輸入を時々しているわたしにとってはこれ幸いなのです。$1=80円のときなんて、$1=100円と比べたらいつでも2割引の感覚でお買い物できるし、anual saleのときはそこから25%や40%になるのでfedexの送料や関税を支払っても国内で買うのが馬鹿らしくなるんですよね。プロジェクトマネージャ認定PMP更新料も同じなのですよ。更新するときだけは円高になって!って思う。ちょうど、イヤフォンのコードの皮膜が切れてきたところだったのでamazon.co.ukでお買い物。国内正規価格の2/3だもの並行輸入より3Kくらいやすいし。


さてさて与太話はここでおしまいで、例のアレがらみで新たなエントリがあったのでそれを下敷きに。引用しているエントリ、なかなか良いと思います例のアレ書き手の方と同じ会社のようですし、いろいろ気遣いかながら書いている感じが大変好感が持てますねー。


さて、普段わたしが言っていることと同じことを言っています。それは、ウォーターフォールアジャイルでもいいけれど)ひとつ、ちゃんとできないシステムエンジニアアジャイルアジャイル場合ウォーターフォール)ができるわけがない。


こういう構図で考えた場合、ウォータフォール型開発とアジャイル型開発の基本的な相違点として、以下があることがわかります

ウォータフォールだろうがアジャイルだろうが、ある特定ひとつ機能だけ取ると V 字型モデル。よって、段階的詳細化と段階的テストをちゃんと実践できない人は、そもそもアジャイル云々以前の問題。V 字型モデルをちゃんと実践できない人がアジャイルに取り組もうものなら悲惨なことになります;。

続・拝啓『変わらない開発現場』を嘆く皆様へ ? ウォータフォール & アジャイル編? | とあるコンサルタントのつぶやき


アジャイル開発というよりは、プロダクトバックログ優先順位の考え方やWIPカンバンの考え方が好きなので、ときどき勉強会に行くのですがそうしたところでの恣意的ウォーターフォールvsアジャイル環境を作って一方的ウォーターフォールなんて、と言っているシステムエンジニアには


別におじさんは困らないけれど、キミたちはプロジェクト特性選択することになるシステム開発手法対応できるのかな」


と内心思っているのです。余計なお世話ですが。ウォーターフォールアジャイルシステム開発手法であって、単なる手段です。それを叩いで世の中が変わるのでしょうか。叩いているあなたプロジェクトが良い方向に変化するのでしょうか。


1ミリも変わりません。


それより叩いているシステムエンジニア自身プロジェクトに対する姿勢が悪くなりますよ。だって、好きなんじゃないんですから。少なくとも、ニュートラル気持ちでいないと好きにもなれないんですよ。知り合い、友達から好きなところに気づいて片思いするのと同じですよ。


上記の引用では、ろくにウォーターフォールもできないシステムエンジニアアジャイルを始めたら「悲惨になる」とかなり優しい言葉を選んでいますけど、わたしプロジェクトマネージャならお作法程度のウォーターフォール所作ができないシステムエンジニアなんてご縁がありませんでした、と退場を謹んでお願いするところです。


ウォーターフォールでのシステム開発労働集約型でのプロジェクトが多いですからスキルスキルレベルが多少歪でもプロジェクトチームの人数が多いので自然カバーし合っていることをそろそろ気がつかないといけないのです。


言い換えれば、キミはできていると思っているかもしれないけれど、プロマネから見たら一人前の貢献もできていないところを他のメンバが補っているんだよ、ということです。そういったことを前提に「チームとしてのスキルセット」が揃うようにチーミングしているのということをマジで認識してほしいものです。


繰り返しますが、キミ自身が気づかなくてもこちらは困らないのです。チームとしてスキルセットが成立しているから。でも、個々人の単位で見たら、キミの価値はそれほどないことにキミ自身が気づかなければ、一生勘違いしたままなんだろうし、60歳くらいになっても指示待ちシステムエンジニアになってしまうかもしれないんだけれど、それはキミのマターなので言及しませんです、はい


こうした自分スキル評価をできないとか、プロジェクトが上手くいかないことをシステム開発手法押し付けているシステムエンジニアは、イメージだけでアジャイルに手を出すと火傷をします。



例えばスクラムの最適なチームメンバは5人±2人とかいいますね。そのとおりだと思います。でも、現実プロジェクトだと5人より少ないチームで組むプロジェクトもあります。この時チームで何が起きるか。


わたし経験からも少ない人数のチームは、トラックナンバー問題が如実に現れます。チームメンバの人数の母数に対する1人の占める割合が大きくなるからです。当たり前です。10人のチームに占める割合と3人のチームに占める割合全然違います


必然として、一人が「マルチ」で動けないければチームが回らないし、動けるためには相応の技術マインドを持っていないとチームが歩きもできないのです。ちなみに、この少人数のチームメンバに対する少数だからこそ精鋭化しなければチームが成り立たない、ということの本質は、アジャイルだろうがウォーターフォールだろうが同じです。というか、アジャイルは精鋭を前提にしているんですよ。


そこにはシステム開発手法ケチをつけているようなシステムエンジニアには入る余地がないのです。


たまたまわたしはそのようなビジネスを長い間マネジメントしていたのでプロジェクトマネジメント観点システムエンジニア技術的な育成の観点でどうしたら上手くいくか多分他の人よりは「チョットデキル」かなぁ、と思っていたりします。


でも、こうしたことを教えてくれる本はほとんどなくて、唯一あるのがこれくらいしか知らない。


そろそろ気づきた方が良いと思いますよ。

2016-06-24

[]2つの上手くいっているプロジェクト経験 08:18 2つの上手くいっているプロジェクトの経験を含むブックマーク



プロジェクトが上手くいっていると実感した人はどのくらいいるのでしょうか。漠とした質問ですが。


では、あなたが「プロジェクトが上手くいった!」と実感した経験がありますか。さらに、その経験をしたときのロールは何でしたか。


プロジェクトが上手くいったと実感できるということは、そう実感した人はプロジェクトについて日々考えていた人であって、その実感したプロジェクトに対して何かしらresuponsibilityかaccountabilityがあったのではないかと思うのです。なぜなら、プロジェクトという単位で実感しているから


ではそれを実感できるロールはと言われれば、プロジェクトスポンサースポンサーサイドのプロジェクトマネージャかデリバリーサイドのプロジェクトマネージャかその周囲の中枢部のメンバくらいまででしょう。


それ以外のメンバはブロックなり一担当としての役割になりますからプロジェクトという全体に対する感覚は持てないと思うのです。なにせ背負う責任が違いすぎますから


プロジェクトスポンサーとデリバリーチームのプロジェクトが上手くいった経験

これが理想であり、当たり前に求めるゴールとしての経験ですね。プロジェクトスポンサー解決したい事業上の課題解決することができ、デリバリーチームは契約ベースでの収益を上げ、契約範疇でのアウトプットを収めることができ、プロジェクト計画で設定した各種指標をなんらか達成することができた、と。


プロジェクトスポンサーでaccountabilityを持つ方は社内での方の荷を無事降ろすこととができたし、それをデリバリーチームはサポートすることができたと実感できたときにはお互いに自然笑顔になるものです。


デリバリーチームとしてプロジェクトスポンサーの方の立場垣間見ると、そちらの世界世界事業上の課題解決がかかっているので関連する部署から相当のプレッシャーがあることは、ステコミなどの場でジワリと漏らすことが多いです。


そうした場合にデリバリーチームができることは、ロジカルに、わかりやすく説明する資料を心がけてプロジェクトでは見せることです。そうしたプロジェクト資料プロジェクトスポンサーサイドの中の人たち向けの説明用の補足資料バックアップ資料として使われるので。


ある意味プロジェクトの中でスポンサーとデリバリーチームが喧々諤々やることは上手くプロジェクトを進めるために良い方向を探すためにしているわけですが、スポンサーがその中の人と喧々諤々をするときは、デリバリーチームの味方となって代弁していると思うようにするといいと思うんですよねー。


デリバリーサイドとしてのプロジェクトが上手くいった経験

わかりやすく言えば、システム開発をしてシステムを作る側のこちらは適切な対価をいただきましたので、赤字にもならず、契約ベースでの収益を確保できたのでデリバリーサイドとしては無事にプロジェクトを終了できてようございました、という案件です。


気づいたかもしれませんが、プロジェクトが上手くいった方にはデリバリーチームしかないのです。つまり、プロジェクトスポンサーはこちらが出ないところにいると。プロジェクトスポンサーやデリバリーチームを含めたプロジェクト全体でみると残念ながら上手くいったとは言えないということです。


このようなプロジェクトの上手くいったはほんと微妙です。いっそうのこと、多少苦労しても良かったから計画時に期待していたアウトプットを手に出来ていれば良かったのにと思うくらいです。


プロジェクト全体として上手くいかなったケースと向き合うことは学びが多いですが…。

2016-06-23

[]システムエンジニア結婚すると読書する時間がなくなる? 08:13 システムエンジニアは結婚すると読書する時間がなくなる?を含むブックマーク


観測できている範囲での印象なんだけれど、ブログエントリなどで家族持ちのシステムエンジニアのみなさんが勉強時間が取れないとか、家族サービス要求されて読書時間が取れないとか、脅迫されるのか惚気ているのかよくわからないんだけど、やっぱり時間って自由にならないものなのかしら。


振り返ってみたら、20歳台よりは30歳台の方が、30歳だより40歳台の方が本を読んでいる気がする。30歳の少し前には結婚したから独身より結婚してからの方が読書量は増えているし、読んでいる本も20歳台はそれこそ普通に趣味読書から技術書に変わって、ビジネス書になって、今はその中間みたいな感じでさまよっている。


わたしのケースを持ち出すと特異すぎて読む方の参考になるかどうかわからないけれど、本を読む環境は外出している方がページが進むんですね。電車が一番よい読書環境で、次が外出時の時間の隙間。一方、家では昔は持ち帰って仕事をしていたのでほとんど読書は進まず、いまは今で艦これ原稿を書いている…ときもあってほとんど読みたいという気分にならなないんですね。


やっぱり電車かなぁ。ただ、本はかさばるし技術書って鈍器のケースが多いから持ち歩きたくないんですよねぇ。とはいえ、仕事場で読むような時間もないし。


原稿や講演のスライド裏付けを取るための読書研修スライド更新するするための資料としての読書は割と好きで、稀に家で読む時もあるけれど最近睡魔に負けてしまうので、やっぱり電車がいいんだなぁ、と。


電車で読むにしても、通院時間帯の混雑してる電車をもともと避けたい、通勤で1日の半分くらいの体力を消耗したくないから朝早い時間帯の電車に乗って、空いている電車kindleで読むのが快適で良い。


そういえば、今朝もいままで別々に読んでいた本のコンテンツがある領域でつながりがあることがわかって「!」って思ったので読書大事なだなぁと。


こうして改めて読書時間や適した場所を振り返ってみると最近固定化されているような気がするし、それはそれでわたし自身にとっての1つのプラクティスなんだろうね。少しだけ早く起きて、空いている電車で本を読もう。

2016-06-22

[]アジャイル契約のはなし 08:10 アジャイルと契約のはなしを含むブックマーク


端的に言えば、請負契約をするなら請け負う仕事見積もれていることが前提になるから見積もり時点での役務仕様発注者からも受注者からも明瞭会計なのです。現実世界での請負契約の闇は一旦棚に上げて。


請負契約で「見積もる」ということは、納入する(納品ではない)成果物がどのような部品構成され、どんな仕様かを見積もり時点で明確に見積もれないといけないんですよ。部品ひとつだってコストがかかるのですから仕様不明なままでは見積もりの精度が悪くなってしまい実際に見積もり価格で受注したとしてもプロジェクト途中で部品の不足が判明したらコスト見積もりより多くなってしまい、コストオーバーランしちゃいます。不足部品によってはそれだけで赤字になってしまうかもしれません。


例えば、下表の部品でできているソフトウェアがあったとします。それぞれの部品工数積算して、プロジェクト内のその他経費に対して、コンテンジェンシコスト利益を加算すれば見積もることができます


名称個数
部品
部品10
部品30

このとき、上表の部品1−3の仕様が明確であることが必要なのは先に述べたとおりです。見積もりとして精度の高いケースは、パッケージ開発やソリューションテンプレートなど開発での標準パターンが進んでいるケースです。他のケースでも、過去実績が計測できており、定量的比較できるならある程度の精度は確保できるでしょうし、もちろん、見積もりの前提となる仕様は明確に提示できるでしょう。


では、アジャイル見積もりは何が違うかを同じ表を使ってみていきましょう。


アジャイル開発ではプロダクトマネージャと開発チームでスコープに相当するプロダクトバックログリスト化し、開発期間で必須開発の項目とできるところまでつくりましょうと2段階で開発範囲を決めます場合によっては、全部ができるところまで、としているケースもあるでしょう。


名称個数
部品2つくらいつくれるかな。でも作れなくてもごめんね
部品10つくらいつくれるかな。でも作れなくてもごめんね
部品30つくらいつくれるかな。でも作れなくてもごめんね

その上、プロジェクトを開始した後の仕様を詰めるのでプロダクトを作るプロジェクト見積もり時点ではどんなプロダクトの仕様かさっぱりわかりません。ここが請負契約見積もる時に大きな違いです。言い換えれば、見積もり時点で仕様が確定できない、ということです。


さらに、


名称個数
部品2つくらいつくれるかな。でも作れなくてもごめんね。仕様プロジェクトが始まってから決めるから
部品10つくらいつくれるかな。でも作れなくてもごめんね。仕様プロジェクトが始まってから決めるから
部品30つくらいつくれるかな。でも作れなくてもごめんね。仕様プロジェクトが始まってから決めるから

となるわけです。これでは発注者側も受注者側としても請負契約すること自体が成立しません。となれば、自然と準委任契約か、派遣契約しか契約選択肢がなくなるのです。


アジャイルをどうしても双方が請負契約でやりたいと願う場合の1つのアイデアとしては、プロダクトバックログ仕様を決めるプレフェーズを準委任契約派遣契約で行い、開発仕様を予め決めておくというやり方です。


ちょっと待って、それでは…と察した方は偉いです。そのとおり、これってスコープが明確になっているのでウォーターフォールでもできます。ただ、開発チームがどっちでやりたいかだけの話になってしまっているだけです。


もう1つの契約のやり方は、所謂保守契約を結び、その契約提供する工数の中で開発を行うものです。保守は通常、成果物を収める責任を負うような契約をしませんし、保守要員を計画して、実際にどのようなサービス提供するかは保守契約の中で提供技術仕様だけを決めておき、個別テーマは都度検討とすることが多いですから、その中でアジャイル開発の形態をとって開発するには向いています


請負契約、準委任契約そして保守契約提供する役務を並べるとこんな感じになりますね。


契約の種類役務提供方法
請負契約見積もり仕様に沿った成果物提供民法634条 瑕疵担保責任
委任契約専門性を持った役務を決めた工数または作成物で提供する民法656条
保守契約専門性を持った役務を決めた工数または作成物で提供する民法上の条文はなく、委任契約で結ぶ

アジャイルをやりたいシステムエンジニアは、契約まで知っていないとなぜアジャイル開発ができないかからないままですよ。

2016-06-21

[]ウォーターフォールメリットエントリ事業会社IT転生のエントリ契約のことを知らないと本質は見えてこない 08:12 ウォーターフォールのメリットのエントリも事業会社のIT転生のエントリも契約のことを知らないと本質は見えてこないを含むブックマーク


私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い - メソッド屋のブログ

事業会社をIT会社に転生させることが、これからのSIerのミッション - GoTheDistance

みなさんすごいなー「こんなにブクマつくほどの記事書いてみたいなー」と思ったか思わなかったかは棚に上げて。


さて、1つの目のエントリは昨日の午前中くらいだったかな、facebookのTLで流れてきたのを読んでブクマコメントを残して、今朝、というか今もう一度読み直してみたんだけれど、書いているご自身ウォーターフォールダメだと直接言っていないんですねぇ。サムがそう言っている、としか書いていない(ように読めたんだけど)。あとは最後にご自身が目指すビジョンで「技術プロセスの導入スピードを同じにしたい」と言われているのは間接的にウォーターフォールではなくアジャイルを指しているのかな。


先ほど読み直したけれど、結局、「ご自身決意表明なんだろう」と思ったです。はい。それ以上の情報はないような。


ところで、わたしブクマしたのでわたしブクマに何を残したかというと、いつも言っていることしか書いていないので進歩なさそう。>自分


システム開発方法論はビジネス要求を実現できる手法かどうかで選ぶんだ。どっちにメリットがあるとかじゃない。ビジネスが高速リリースを望んでいなければ適用しない理由があるんだよ」


1つ目のブログエントリタイトル方法論について取り上げているなら、このコメントあながち間違いではないだろう。ビジネスサイドが実現したい要求で生じるプロジェクト特性を見定めて、実現性の高い方法論を選べばいい。好き嫌い二の次あなたマネージャプロジェクトマネージャなら。それこそ、プロジェクト計画時のコストで終わらすために。念のために補足すると、計画時とかいて契約時としなかったのは、自社サービスプロジェクトだってあるからなーと配慮したまでです。


2つ目のエントリに移ります。こちらは電車待ちの間に読んでツイートしたんだけれど、


ソフトウエアを作ることがゴールになっている以上、スコープ破綻させることはできない。」


のくだりはちょっとどういう意味なんだろう。スコープが拡大する、ような意味合いかな。そのあとの終わらせて検収してはそうですよね、なんだけど。ただ、その次でわからなくなるんですよ。


請負しないんだから委任になります顧客IT部門に入り込んでその立場仕事をするのが、主流となる。仮想的な内製部隊として機能していく。こうなりますわな。」


からなくなってこんなツイートしたわけで。



請け負うとは、見積もりがきっちりできる、ということです。見積もれるから請け負える。別に見積もれてもあえて準委任契約してもいいけれど。で、気になるのはその次の顧客立場で、となっているけれど、いや、そういうケースもありますね。


でも、別のケースもあるんですよ。それは、見積もりができるほど要件が明確でない場合見積もれないから請け負えません。でも、その曖昧要件プロジェクトの中で一緒に明確にしていく作業を準委任でならやってもいいですよ、という内容の場合が。


このケースは実質人だしと同じですが、プロジェクトチーム受託側が編成して、持ち帰りでできるんですよ(実際、随分やってますよ)。あとですねぇ、


「「ウチは一切の請負はしなくて、業務委託イケてるエンジニアを貸し出します御社事業コミットして、モノも作れますから。毎月XX円お支払ください。」と言われて「なるほど、確かにそれがベストだね!アジャイルにやろう!」 ってなるのかなぁ。 顧客はそれについてこれるのか。 全ての舵取りを顧客に委ねるのが正しいのか。どう説明してご理解を頂くのかイメージが湧かないけど、それしか無いならしょうがないのかな。」


これ、普通の準委任契約じゃないのかな。契約の仕方の見せ方が新鮮に見える人がいるのかもしれないけれど、これ、本質は道幅ビジネスなんですよ。あとは諸条件でアウトプットのうち、ドキュメント成果物にしていなかったりするんじゃないのかな。多分だけれど、内部で必要ドキュメントは内部用に作るんでしょう。そうしないと人の入れ替わりに対応できないから。


さいごに事業会社IT企業に転生とあるけれど、武器にはなるだろうけれど事業会社提供するサービス物理だったら無理なケースもあるだろうねぇ。そういったケースはどう議論が展開されるのか興味があります


関連があるような2つのエントリですが何か関連あったのかなぁ、というのが正直な感じなんだけれど、こうやって自分で2つのエントリを読んで、それぞれで言いたいことはなんだろうと考えてみてわかることもあるんだなぁ。


で、思ったのはシステムエンジニア契約について、いよいよ知っていかないとこうした議論に参加もできないんじゃないか、ということです。はい