Agile Japan 2017 不確実なプロジェクトに立ち向かう ～未来を占う術～ 事前ミーティング その3
アジャイルジャパンの登壇者の高柳さんと森實さんとパネルディスカッションの運営やパネルディスカッションのファシリテートについて摺り合わせしたときの3枚目の図です。
その2に続いて、この写真も侍れっど流とあるようにIPAの資格をほぼ網羅している森實さんの「資格」についての考え方を可視化したものです。
森實さんは、「資格とは自分のやったことの証である」と言っていますが、それは知識を習得し、その成果をただの暗黙知のままにすることなく、形あるものに変換する連続した学習を実践することで上司や他者が認識可能な資格として表現しているのでしょう。
ところで、こういった認定資格は形式知を習得した結果を可視化する以外に別の捉え方で利用することができます。
それは、資格を持っていることでそのエリアでの最低限の会話ができる知識を有していることを示す役割です。
もしPMPの認定を受けているのであれば、PMBOKに書かれているプロジェクトマネジメントに関する用語や考え方などについては説明が不要とすることができます。
それを踏まえ、例えばプロジェクトマネージャを担いたいが、経験不足でプロジェクトマネージャにアサインされないとしたら、プロジェクトマネジメントに関する書籍を読みPMPをパス（合格）することで、プロジェクトマネージャのcertifyに必要な知識と見識を持っているということができます。
このPMPを持つことで上司を安心させてプロジェクトマネージャに任命するように働きかけることができます。
今ならKindke版が50%OFF!! アプリ開発チームのためのプロジェクトマネジメント チーム駆動開発でいこう！
あら、ポイント還元でじゃなくて半額！
| 紙の本の価格： | ￥ 2,894 |
| Kindle 価格: | ￥ 1,447
￥ 1,447の割引 (50%) |
Agile Japan 2017 不確実なプロジェクトに立ち向かう ～未来を占う術～ 事前ミーティング その２
アジャイルジャパンの登壇者の高柳さんと森實さんとパネルディスカッションの運営やパネルディスカッションのファシリテートについて摺り合わせしたときの２枚目の図です。
侍れっど流とあるようにこのグラフィックは、森實さんが「マネージャの知識レベル観」について述べたことを可視化したものです。
図中の「概念で理解し、話せるライン」とは、適用技術などについて専門家のレベルまでの詳細な知識は必要ないが概念については理解し説明できるスキルレベルに到達している必要があるということを示しています。
概念を理解しているからこそ技術の専門家であるチームメンバと意思疎通が可能となり、期待する結果に到達可能な意思決定に結びつけることができるようになります。
概念を理解するためには知識の習得が必要で、体系的にまとめられた知識の習得や習得した知識を実践で使用することで経験値のレベル上げをすることができます。
ただ、経験値は可視化されにくいもので、アウトプット、振る舞い、評判などでしか確かめることができません。そうしたことを第三者の認定で証明するのが資格試験などの認定です。
第三者認定は、それ自体で仕事ができることを認定するものではなく、限定した知識エリアについて保有している知識を認定していると捉えるものです。最低限の保有している知識はプロトコルであり、認定者同士は認定された知識エリアにおいて意思疎通ができることをタイトルとして可視化したものです。
知識を習得したあとに試験により認定を受けることは、自己研鑽の成果の表現方法の1つです。
【確定】アジャイルジャパン ※パネルディスカッションのみ
～シン・アジャイル～ Agile Japan 2017 アジャイルでつくるミライ
開催日 2017年4月13日（木）
会場 タワーホール船堀
〒134-0091 東京都江戸川区船堀4-1-1
Agile Japan 2017 不確実なプロジェクトに立ち向かう ～未来を占う術～ 事前ミーティング その１
＃画像が暗かったので明るくしてみました。
アジャイルジャパンも後ひと月なので、登壇者の高柳さんと森實さんとパネルディスカッションの運営やパネルディスカッションのファシリテートについて摺り合わせしたのでした。
ちょうどアジャイルジャパンと同じように高柳さんがファシリテーター、森實さんと二人で好き勝手に話をする配役です。
次の画像がそのときに出てきたテーマの一コマ。
普段なら「２度と繰り返したくない経験」と言っているところです。表現の違いはありますが、言っている内容は同じです。
わざわざ、２度と繰り返したくない経験を進んでする必要ありません。というかしない方が健全です。
現実には不幸にも巻き込まれることもありますし、自ら無意識にそれを引き起こしてしまうこともあります。そうなったとき、どこまでやると、若しくは、どこまで放置すると２度と繰り返したくないことを引き起こしてしまうか、その閾値をセンシングできるスキルは身につけておこうね、ということです。それが「リスクを取れるライン」なのです。
【確定】アジャイルジャパン ※パネルディスカッションのみ
～シン・アジャイル～ Agile Japan 2017 アジャイルでつくるミライ
開催日 2017年4月13日（木）
会場 タワーホール船堀
〒134-0091 東京都江戸川区船堀4-1-1
【更新】2017年の講演活動・イベント予定について ※超技術書典
現時点で確定又は抽選待ちのイベント予定です。
ニコニコ超会議の併催イベントの超技術書典に2daysで参加します！
【終了】１月２２日 イベント名 ぱんっあ☆ふぉー! 9 Bー１７ ＠東京ビッグサイトhttp://www.editnet-p.jp/submissiondue/eventdetail.phtml?eventcode=Y71711&%20
・ガルパン仕事術１巻２巻
・ガルパン仕事術トートバッグ（在庫のみ）
【終了】２月１７日 デベロッパーサミット ＠目黒雅叙園
下図のdevbooksにサークル参加します。
・カワイイ後輩の育て方１巻２巻３巻
・カワイイ後輩の育て方theComic１巻２巻
・ガルパン仕事術１巻２巻
・ガルパン仕事術トートバッグ（在庫がある場合）
【終了】コミティア１１９ に１５b
日程 ： 2017年2月12日（日）11:00～16:00
場所 ： 有明・東京ビッグサイト東5・6ホール
・アプリ開発チームのためのプロジェクトマネジメント
・カワイイ後輩の育て方１巻２巻３巻
・カワイイ後輩の育て方theComic１巻２巻
・ガルパン仕事術１巻２巻
・ガルパン仕事術トートバッグ（在庫がある場合）
【確定】技術書典２ かー４６
日時 2017/4/9 (日)
場所 アキバ・スクエア
【確定】アジャイルジャパン ※パネルディスカッションのみ
～シン・アジャイル～ Agile Japan 2017 アジャイルでつくるミライ
開催日 2017年4月13日（木）
会場 タワーホール船堀
〒134-0091 東京都江戸川区船堀4-1-1
【確定】超技術書典
日時 2017/4/29 (土) 30(日) ※2days連続で参加します！
場所 幕張メッセ
デブサミ2017（DevBooks）にお立ち寄りありがとうございました
昨日、2017年2月17日（金）のデブサミの番組として初めてDevBooksが組み込まれました。
サークルスペースにお立ち寄りいただきましてありがとうございました。お時間に余裕のあった方とはプロジェクトマネージャの育成の悩みやプロジェクトマネージャの資質、プロジェクトの運営などについても伺うことができ、現場ではまだまだ課題が多いのだと改めて実感したところです。
ちょうど、この時期は雛祭りお飾りの時期と重なるため、雅叙園のしつらいが楽しみでもあります。正面玄関には雛山が。
会場までの廊下には桃の生け花が。
「カワイイ後輩の育て方」がスピンオフ作品なので、その説明にノベルティの栞の裏のマイナビ本を説明する必要があるので間接的にはアレですけど。
DevBooksとコミケやコミティアとの違いを幾つか気づいたので。
・時間 DevBooks（10:00〜18:00） コミケ（10:00〜16:00）ティア（11:00〜16:00）
・電源 DevBooks 有 コミケ 無 ティア 無
・環境 DevBooks 宴会場 コミケ イベント会場 ティア イベント会場
・机 DevBooks 余裕あり コミケ びっちり ティア びっちり
・需給 DevBooks 一致 コミケ 不一致 ティア 不一致
開催時間が長いのは機会創出につながるので良いですね。ただ、最終セミナーと終わる時間が同じなので、DevBooksはもう30分くらい長い方が良いかもしれません。会場撤収の制限はありそうですが。
環境が良いのは助かります。昨日は気候のせいもありましたが、熱いくらいでした。
環境面では、電源があるのは助かります。さすが、エンジニア向けイベントとしての配慮だと思います。
会場が宴会場のため、終日居座る参加者にとっては、体力面で助かります。
机が１テーブルごとに通路が確保されているのでこれも移動が楽です。もう少し参加サークルが増えるとどうなるか。
技術書典と同じように技術者向け同人販売イベント（コーナー）になるので、需給が一致しているのは大きいです。コミティアのように一致しておらず、コミケのようなスケールもない場合、マーケティング的な活動から必要になりますから。その分、パイの奪い合いになるのは必須で、最大のコンペティタは主催者とオライリーになりますが。
そこで差別化できるコンテンツを供給できるかがポイントになりますね。
帰る際も綺麗にして。
次は、アジャイルジャパンでの講演（パネルディスカッション）となります。
サークルとしての参加は技術書典（4月9日＠アキバスクエア）となります。
システム開発に契約知識を
良い問題提起のエントリなので勝手ではありますが、ちょっとフォローを。
最初の引用。ベンダは一括請負で赤字プロジェクトの対策として契約を分割するようになった、その後です。
ここで問題になるのが、準委任契約のあり方である。一般に、IT開発の最初の要件定義と、最後の総合テストないし運用テストは、準委任契約で行われることが多くなった。最後のテストでは、かかる工数が発注者側の運用環境に依存するし、また既存のレガシーシステムとのインタフェース・テストなども含まれることが多い。だからここを準委任でやること自体は一見、適正なことに思われる。ところが、ここで交わされる準委任契約が、ともするとITベンダー側に非常に都合のいいようにできているという。
←要件定義（準委任）→←基本設計〜総合テスト（請負）→←受入テスト（準委任）→
と契約分割するようになった、とあります。これは経産省からも研究会のレポートが出ていますね。
「情報システムの信頼性向上のための取引慣行・契約に関する研究会」
ところが、ここで交わされる準委任契約が、ともするとITベンダー側に非常に都合のいいようにできているという。
ここで、そうかなぁ、と思うのです、はい。
で、読み進めると、
たとえば、瑕疵担保責任の所在である。実装は一括請負だが、ユーザにとって納品物を受け入れるかどうかは、最後のテストの結果を見て判断することになる。ところがそこは準委任契約だから、成果物に責任はありません、というケースがあるらしい。何かバグが見つかって直す必要があったら、ユーザがお金を払わなければならない。これでは実装の品質が低ければ低いほど、ITベンダーは収入が増えるというおかしなことになる。それに、納期の問題だ。準委任だから、完成義務はない、納期は保証しません、という。
「というケース」とあるのでそういうケースもあるようです。ただ、これは２社間での契約の問題、という感じが一見しますが、実はエンドユーザ側のプロジェクトマネジメント力の問題を提起しているのではないか、と見ることもできます。
先の、工程別契約を見やすいように分割します。
要件定義（準委任）
基本設計〜総合テスト（請負）
受入テスト（準委任）
エントリのケースを当てはめると
要件定義（準委任）
基本設計〜総合テスト（請負）
受入テスト（準委任） ←ここでバグが出る
受入テストでバグが出ても準委任だから成果物に責任がない、とケースに出てくるベンダは主張されてエンドユーザは困っている、と。
それ、受入テストでのバグの起因となった工程を特定するなどの品質管理の中でコントロールをエンドユーザ側ができていない、ということなのでしょう。
要件定義（準委任）
基本設計〜総合テスト（請負）
受入テスト（準委任） ←ここでバグが出る ←バグの起因はどこか
バグの起因が基本設計〜総合テスト（請負）の中であれば、修正する義務が発生します。これが要件から漏れていたのであれば、エンドユーザ側に起因することになります。
ただ、プロジェクトマネジメント力があるベンダであれば、基本設計〜総合テスト（請負）の各工程の中で、要件からの抜け漏れがないかを次工程に突入する前のcriteriaとしてゲートを設けているはずなので、ある意味、受入テストまで進んでから機能漏れとならないように防止する歯止めをプロセスとしてかけているものです。
もうひとつ。準委任における責任に曖昧さが生じるか、です。
もう一つ問題の所在となるのは、System Engineering Service（略称SES）とよばれる契約形態である。これはIT会社の元請けから、下請け会社にSEを配員してもらうために発注するサービスだが、準委任契約の業務委託になっている。しかし、その実態は派遣契約にきわめて近い。IT業界は知っての通り多重下請け構造なので、SESの再委託もある。準委任の準委任という訳だ。どこの誰に責任があるのかさっぱり分からなくなる。
なんとなく、解は書かれているように思えるのですが、
ところが、海外企業との実費償還契約というのは厳しいのだ。まず、プロジェクトへの配員は、顧客が経歴書を審査し、きちんとした経験・能力が認めることが条件だ。勝手に協力会社の人間をアサインするなど、もってのほか。また一旦、配員されても、仕事ぶりの質が低いと、欠格として解任（Disqualify）されてしまう。働いた時間に応じて対価が払われるが、毎週タイムシートを顧客に提出し、チェックと承認を受ける必要がある。出張も外出も、顧客の事前の承認がいる。
法律との兼ね合いでどこまでできるかは別として、エンドユーザ側は、プロジェクトとして必要なスキルセットとスキルレベルを満たすリソースを契約条件に示せばいいのではないか、と。
請負なら、ベンダは契約を履行するためにそうするでしょう。請負での曖昧さはベンダとサブコン間のリスクです。
＃そうしないと赤字になるので。
ただ遠回りにはプロジェクト全体としてはエンドユーザに影響はしますが、それで履行されてないのであれば、ベンダが問われるだけでは、と。
では、準委任でどうするか、ですが、ここはエンドユーザ側が主体の工程になるので、工程に必要なスキルセットとスキルレベルを持つリソースを提供することをベンダに求めるのかと。
その上で、プロジェクトの工程管理をするだけではないかと思うのです。それをベンダに丸投げしてはいけないという教訓かと。
契約関連は、この本の付録を参照していただけると幸いです。
アプリ開発チームのためのプロジェクトマネジメント チーム駆動開発でいこう！
- 作者: 稲山文孝
- 出版社/メーカー: マイナビ出版
- 発売日: 2015/04/28
- メディア: Kindle版
- この商品を含むブログを見る
