読者です 読者をやめる 読者になる 読者になる

inayamafumitaka’s official diary

プロジェクトマネージメント/人材育成・研修/執筆/書評・・・執筆・講演をお受けします。Twitter(@inayamafumitaka)のDMでコンタクトしてください  ☆アジャイルジャパン(4月13日)登壇します!!

今ならKindke版が50%OFF!! アプリ開発チームのためのプロジェクトマネジメント チーム駆動開発でいこう!

あら、ポイント還元でじゃなくて半額!

Kindle 価格: ¥ 1,447

¥ 1,447の割引 (50%)

https://www.amazon.co.jp//dp/B014U9J4ZI/

Agile Japan 2017 不確実なプロジェクトに立ち向かう ~未来を占う術~ 事前ミーティング その2

アジャイルジャパン

アジャイルジャパンの登壇者の高柳さんと森實さんとパネルディスカッションの運営やパネルディスカッションのファシリテートについて摺り合わせしたときの2枚目の図です。

侍れっど流とあるようにこのグラフィックは、森實さんが「マネージャの知識レベル観」について述べたことを可視化したものです。

f:id:inayamafumitaka:20170326153544j:plain

図中の「概念で理解し、話せるライン」とは、適用技術などについて専門家のレベルまでの詳細な知識は必要ないが概念については理解し説明できるスキルレベルに到達している必要があるということを示しています。

概念を理解しているからこそ技術の専門家であるチームメンバと意思疎通が可能となり、期待する結果に到達可能な意思決定に結びつけることができるようになります。

概念を理解するためには知識の習得が必要で、体系的にまとめられた知識の習得や習得した知識を実践で使用することで経験値のレベル上げをすることができます。

ただ、経験値は可視化されにくいもので、アウトプット、振る舞い、評判などでしか確かめることができません。そうしたことを第三者の認定で証明するのが資格試験などの認定です。

第三者認定は、それ自体で仕事ができることを認定するものではなく、限定した知識エリアについて保有している知識を認定していると捉えるものです。最低限の保有している知識はプロトコルであり、認定者同士は認定された知識エリアにおいて意思疎通ができることをタイトルとして可視化したものです。

知識を習得したあとに試験により認定を受けることは、自己研鑽の成果の表現方法の1つです。

 

【確定アジャイルジャパン ※パネルディスカッションのみ

~シン・アジャイル~  Agile Japan 2017 アジャイルでつくるミライ
開催日 2017年4月13日(木)
会場 タワーホール船堀 
〒134-0091 東京都江戸川区船堀4-1-1

 

Agile Japan 2017 不確実なプロジェクトに立ち向かう ~未来を占う術~ 事前ミーティング その1

アジャイルジャパン

#画像が暗かったので明るくしてみました。

アジャイルジャパンも後ひと月なので、登壇者の高柳さんと森實さんとパネルディスカッションの運営やパネルディスカッションのファシリテートについて摺り合わせしたのでした。

ちょうどアジャイルジャパンと同じように高柳さんがファシリテーター、森實さんと二人で好き勝手に話をする配役です。

 次の画像がそのときに出てきたテーマの一コマ。

f:id:inayamafumitaka:20170326065637j:plain

普段なら「2度と繰り返したくない経験」と言っているところです。表現の違いはありますが、言っている内容は同じです。

わざわざ、2度と繰り返したくない経験を進んでする必要ありません。というかしない方が健全です。

現実には不幸にも巻き込まれることもありますし、自ら無意識にそれを引き起こしてしまうこともあります。そうなったとき、どこまでやると、若しくは、どこまで放置すると2度と繰り返したくないことを引き起こしてしまうか、その閾値をセンシングできるスキルは身につけておこうね、ということです。それが「リスクを取れるライン」なのです。

 

【確定アジャイルジャパン ※パネルディスカッションのみ

~シン・アジャイル~  Agile Japan 2017 アジャイルでつくるミライ
開催日 2017年4月13日(木)
会場 タワーホール船堀 
〒134-0091 東京都江戸川区船堀4-1-1

 

【更新】2017年の講演活動・イベント予定について ※超技術書典

現時点で確定又は抽選待ちのイベント予定です。

ニコニコ超会議の併催イベントの超技術書典に2daysで参加します!

 

【終了】1月22日 イベント名 ぱんっあ☆ふぉー! 9 Bー17 @東京ビッグサイトhttp://www.editnet-p.jp/submissiondue/eventdetail.phtml?eventcode=Y71711&%20

ガルパン仕事術1巻2巻
ガルパン仕事術トートバッグ(在庫のみ)

 

【終了】2月17日 デベロッパーサミット @目黒雅叙園
下図のdevbooksにサークル参加します。

・カワイイ後輩の育て方1巻2巻3巻

・カワイイ後輩の育て方theComic1巻2巻

ガルパン仕事術1巻2巻

ガルパン仕事術トートバッグ(在庫がある場合)

 

http://image.slidesharecdn.com/developerssummit2017-161201014805/95/2017-devbooks-4-638.jpg?cb=1480668534

http://image.slidesharecdn.com/developerssummit2017-161201014805/95/2017-devbooks-5-638.jpg?cb=1480668534

【終了】コミティア119 に15b
日程 : 2017年2月12日(日)11:00~16:00
場所 : 有明東京ビッグサイト東5・6ホール

COMITIA

・アプリ開発チームのためのプロジェクトマネジメント 

・カワイイ後輩の育て方1巻2巻3巻

・カワイイ後輩の育て方theComic1巻2巻

ガルパン仕事術1巻2巻

ガルパン仕事術トートバッグ(在庫がある場合)

 

 

【確定】技術書典2 かー46

日時 2017/4/9 (日)
場所 アキバ・スクエア

 

techbookfest.org

 

【確定アジャイルジャパン ※パネルディスカッションのみ

~シン・アジャイル~  Agile Japan 2017 アジャイルでつくるミライ
開催日 2017年4月13日(木)
会場 タワーホール船堀 
〒134-0091 東京都江戸川区船堀4-1-1

www.agilejapan.org

 

【確定】超技術書典

日時 2017/4/29 (土) 30(日) ※2days連続で参加します!
場所 幕張メッセ

techbookfest.org

 

デブサミ2017(DevBooks)にお立ち寄りありがとうございました

昨日、2017年2月17日(金)のデブサミの番組として初めてDevBooksが組み込まれました。

サークルスペースにお立ち寄りいただきましてありがとうございました。お時間に余裕のあった方とはプロジェクトマネージャの育成の悩みやプロジェクトマネージャの資質、プロジェクトの運営などについても伺うことができ、現場ではまだまだ課題が多いのだと改めて実感したところです。

f:id:inayamafumitaka:20170218102015j:plain

ちょうど、この時期は雛祭りお飾りの時期と重なるため、雅叙園のしつらいが楽しみでもあります。正面玄関には雛山が。

f:id:inayamafumitaka:20170218101857j:plain

会場までの廊下には桃の生け花が。

f:id:inayamafumitaka:20170218101921j:plain

翔泳社のイベントなので、マイナビ本はお留守番です。

「カワイイ後輩の育て方」がスピンオフ作品なので、その説明にノベルティの栞の裏のマイナビ本を説明する必要があるので間接的にはアレですけど。

DevBooksとコミケコミティアとの違いを幾つか気づいたので。

・時間 DevBooks(10:00〜18:00) コミケ(10:00〜16:00)ティア(11:00〜16:00
・電源 DevBooks 有 コミケ 無 ティア 無
・環境 DevBooks 宴会場 コミケ イベント会場 ティア イベント会場
・机  DevBooks 余裕あり コミケ びっちり ティア びっちり
・需給 DevBooks 一致 コミケ 不一致 ティア 不一致

開催時間が長いのは機会創出につながるので良いですね。ただ、最終セミナーと終わる時間が同じなので、DevBooksはもう30分くらい長い方が良いかもしれません。会場撤収の制限はありそうですが。

環境が良いのは助かります。昨日は気候のせいもありましたが、熱いくらいでした。

環境面では、電源があるのは助かります。さすが、エンジニア向けイベントとしての配慮だと思います。

会場が宴会場のため、終日居座る参加者にとっては、体力面で助かります。

机が1テーブルごとに通路が確保されているのでこれも移動が楽です。もう少し参加サークルが増えるとどうなるか。

技術書典と同じように技術者向け同人販売イベント(コーナー)になるので、需給が一致しているのは大きいです。コミティアのように一致しておらず、コミケのようなスケールもない場合、マーケティング的な活動から必要になりますから。その分、パイの奪い合いになるのは必須で、最大のコンペティタは主催者とオライリーになりますが。

そこで差別化できるコンテンツを供給できるかがポイントになりますね。

f:id:inayamafumitaka:20170218101946j:plain

帰る際も綺麗にして。

f:id:inayamafumitaka:20170218102101j:plain

次は、アジャイルジャパンでの講演(パネルディスカッション)となります。

www.agilejapan.org

 

サークルとしての参加は技術書典(4月9日@アキバスクエア)となります。

techbookfest.org

システム開発に契約知識を

良い問題提起のエントリなので勝手ではありますが、ちょっとフォローを。

 

brevis.exblog.jp

最初の引用。ベンダは一括請負で赤字プロジェクトの対策として契約を分割するようになった、その後です。

ここで問題になるのが、準委任契約のあり方である。一般に、IT開発の最初の要件定義と、最後の総合テストないし運用テストは、準委任契約で行われることが多くなった。最後のテストでは、かかる工数が発注者側の運用環境に依存するし、また既存のレガシーシステムとのインタフェース・テストなども含まれることが多い。だからここを準委任でやること自体は一見、適正なことに思われる。ところが、ここで交わされる準委任契約が、ともするとITベンダー側に非常に都合のいいようにできているという。 

 ←要件定義(準委任)→←基本設計〜総合テスト(請負)→←受入テスト(準委任)→

と契約分割するようになった、とあります。これは経産省からも研究会のレポートが出ていますね。

「情報システムの信頼性向上のための取引慣行・契約に関する研究会」

ところが、ここで交わされる準委任契約が、ともするとITベンダー側に非常に都合のいいようにできているという。 

 ここで、そうかなぁ、と思うのです、はい。

で、読み進めると、

 

たとえば、瑕疵担保責任の所在である。実装は一括請負だが、ユーザにとって納品物を受け入れるかどうかは、最後のテストの結果を見て判断することになる。ところがそこは準委任契約だから、成果物に責任はありません、というケースがあるらしい。何かバグが見つかって直す必要があったら、ユーザがお金を払わなければならない。これでは実装の品質が低ければ低いほど、ITベンダーは収入が増えるというおかしなことになる。それに、納期の問題だ。準委任だから、完成義務はない、納期は保証しません、という。 

「というケース」とあるのでそういうケースもあるようです。ただ、これは2社間での契約の問題、という感じが一見しますが、実はエンドユーザ側のプロジェクトマネジメント力の問題を提起しているのではないか、と見ることもできます。

 

先の、工程別契約を見やすいように分割します。

要件定義(準委任)
基本設計〜総合テスト(請負)
受入テスト(準委任)

 エントリのケースを当てはめると

要件定義(準委任)
基本設計〜総合テスト(請負)
受入テスト(準委任) ←ここでバグが出る

受入テストでバグが出ても準委任だから成果物に責任がない、とケースに出てくるベンダは主張されてエンドユーザは困っている、と。

それ、受入テストでのバグの起因となった工程を特定するなどの品質管理の中でコントロールをエンドユーザ側ができていない、ということなのでしょう。

要件定義(準委任)
基本設計〜総合テスト(請負)
受入テスト(準委任) ←ここでバグが出る ←バグの起因はどこか

バグの起因が基本設計〜総合テスト(請負)の中であれば、修正する義務が発生します。これが要件から漏れていたのであれば、エンドユーザ側に起因することになります。

ただ、プロジェクトマネジメント力があるベンダであれば、基本設計〜総合テスト(請負)の各工程の中で、要件からの抜け漏れがないかを次工程に突入する前のcriteriaとしてゲートを設けているはずなので、ある意味、受入テストまで進んでから機能漏れとならないように防止する歯止めをプロセスとしてかけているものです。

 

もうひとつ。準委任における責任に曖昧さが生じるか、です。

もう一つ問題の所在となるのは、System Engineering Service(略称SES)とよばれる契約形態である。これはIT会社の元請けから、下請け会社にSEを配員してもらうために発注するサービスだが、準委任契約の業務委託になっている。しかし、その実態は派遣契約にきわめて近い。IT業界は知っての通り多重下請け構造なので、SESの再委託もある。準委任の準委任という訳だ。どこの誰に責任があるのかさっぱり分からなくなる。

なんとなく、解は書かれているように思えるのですが、

 

ところが、海外企業との実費償還契約というのは厳しいのだ。まず、プロジェクトへの配員は、顧客が経歴書を審査し、きちんとした経験・能力が認めることが条件だ。勝手に協力会社の人間をアサインするなど、もってのほか。また一旦、配員されても、仕事ぶりの質が低いと、欠格として解任(Disqualify)されてしまう。働いた時間に応じて対価が払われるが、毎週タイムシートを顧客に提出し、チェックと承認を受ける必要がある。出張も外出も、顧客の事前の承認がいる。

法律との兼ね合いでどこまでできるかは別として、エンドユーザ側は、プロジェクトとして必要なスキルセットとスキルレベルを満たすリソースを契約条件に示せばいいのではないか、と。

請負なら、ベンダは契約を履行するためにそうするでしょう。請負での曖昧さはベンダとサブコン間のリスクです。
#そうしないと赤字になるので。

ただ遠回りにはプロジェクト全体としてはエンドユーザに影響はしますが、それで履行されてないのであれば、ベンダが問われるだけでは、と。

では、準委任でどうするか、ですが、ここはエンドユーザ側が主体の工程になるので、工程に必要なスキルセットとスキルレベルを持つリソースを提供することをベンダに求めるのかと。

その上で、プロジェクトの工程管理をするだけではないかと思うのです。それをベンダに丸投げしてはいけないという教訓かと。

 

 契約関連は、この本の付録を参照していただけると幸いです。

 

 

Comitia119お立ち寄りありがとうございました

技術書の典型的なデザインはもちろん、内容もしっかりとしたチームの運営のプラクティスを取り上げたガルパン仕事術をはじめ、「カワイイ後輩の育て方」などオールラインナップで望んだComitia119のサークルスペースにお立ち寄りいただきありがとうございました。

f:id:inayamafumitaka:20170212231615j:plain

冬コミガルパンオンリーに続き、頒布の際にノベルティとして栞をおつけしました。ぜひ、アユちゃんの栞をご活用ください。

f:id:inayamafumitaka:20170212231616j:plain

次のイベント参加は、今週金曜日のDevelopers Summitの2日目、DevBooksとなります。翔泳社主催となりますので、頒布予定は、同人誌のみ、となります。

Comitiaのご都合が合わなかった方は、ぜひ、DevBooksでお会いしましょう。