成功を導くために
不連続ドラマ：とあるオフショアプロジェクト 3
Y君は自社内システムの新規開発のためオフショア開発のプロジェクトに参加することになった。
会社が選んだマネジメントの担当者は誰よりも血の気が多く、開発部内の喧嘩屋S主任だった。
その人選に目眩を覚えるY君。。。
プロジェクトの体制が決まった時、Y君はS主任に挨拶に行った。
その時のS主任はいつもの「面倒なことに巻き込みやがって」という表情ではあったものの、数日後のキックオフのミーティングではメンバーのみんなと握手をするなど意外に”まともな”振る舞いを見せた。
その後プロジェクトのタスクを洗い出しスケジュールを決め、部内での承認ももらった。
タスクの洗い出しでは、S主任は周囲の予想を裏切るやり方で誰もを驚かせた。
基本的な要件をまとめた資料だけを事前に配布、あとはメンバー全員を集めてブレインストーミングを行ったのだ。
メンバー各自が想定するタスクを上げていく。
S主任はそれをひとつひとつ大きな付箋に書いてホワイトボードに貼っていく。
発言が出尽くしたところで付箋を手早くグルーピングしていくのはS主任が自ら行うのだが、発言者に「これはこのグルーピングで意図はあってるかな」と確認する。
そこには喧嘩屋の面影はなく、Y君はS主任のことをちょっと誤解してたかもと思った。
海外発注に際しての契約面での交渉ごとについて発言したメンバーもいたが、そのあたりは普段のプロジェクトではエンジニアがスルーするところなので、なるほどオフショアではそういうところも視野に入ってくるかなという新鮮な驚きがメンバーにはあった。
また、終始発言のないメンバーもいて、気になったのでY君はなぜ黙っているのかと訊いてみた。
そうすると、オフショアであろうが何であろうが、開発でやることは同じ筈なので、特段発言すべきようなことが見当たらないという。
それは誰もが暗中模索な中尤もな話ではあるが、イマジネーションの有無はプロジェクトをすすめる上では重要だ。
成長という観点でいえば、その彼にはむしろ最前線に立ってベンダーとやり取りさせたりする方がいいかもしれないと思った。
そしてブレインストーミングの産物であるタスクのグループは補填され収束され大線表となり、いよいよ最初のフェーズである設計の作業に入った。
今回のシステムの元となる現行のシステムに関しては、現状の仕様にあった設計書というものが存在しない。
過去に多々の改変改変を繰り返しているが、当初の設計書に反映されることはなく、差分の仕様のみが管理されている。
つまり、今まさに動いている仕様を把握するためには、過去からの仕様変更差分の履歴を時系列にたどるしかない。
この現行仕様をどうやってベンダーに伝えることができるだろう。
そのやり方をどうするかについての議論のさなかにS主任の喧嘩屋の本性が現れる時がいよいよやってきてしまった。
Y君は現行の仕様を差分の状態からまとまった仕様書にし、それを元に新しい設計を起こすことを提案した。
ところが、S主任はそれは不要で、現行システムにゲストログインして遠隔からでも制限付きで使えるようにし、仕様の細かいところはQ&Aでこなせばいいというのだった。
前者は設計書のまとめの時間がかかるし、実装の立ち上がりまでに間に合わせるのは大変だが、できないことでもない。
何しろ決定版の設計書が残ることは後々メリットがある。
後者はドキュメントの作成など最小限にするため、プロジェクトのパフォーマンス優先である。
しかし、Q&Aで対応するのにも夫々時間を必要とするため、その負担は仕様がどれだけ明快かという程度にもよる。
「とうとう面倒くさがり屋が本心を出したな」と思ったY君は少々ムキになって反論したが、S主任は当然きかない。
逆にS主任のきつい言葉を集中的に浴びせられて反対派は一人一人と陥落、結局はどうみても負担の軽い方法であるS主任の主張にプロジェクトの方針は決まった。
「まったくお前の話は古いよ、何時代の話だよ」というS主任の罵倒の言葉に打ちのめされてしまったY君は、すっかり意気消沈してしまった。
早くもこのプロジェクトに暗雲が立ち込めていた。
（続く といいが）
ブレインストーミング
方向性を探るとき、問題点の整理をするときなど複数人でブレインストーミングを行うと効果的だ。
漠然したテーマで、そのテーマに関する各人の意見を出してもらう。
原則的にはどんな発言でもいいが、ルールはただ一つ、批判をしないことである。
意見を出す上で公平であることで、多様な意見を出させ、あとでそれを分類・分析する。
上記の例ではブレインストーミングとKJ法を部分的に取り入れているが、これはどのような形にしてもよいと思う。
ここでは誰もが経験したことのないプロジェクトで、どんなことをするかという目測に使っているが、こういう場合には最適ではないかという思いがあったのでこのフェーズでブレインストーミングの手法を入れてみた。
Y君とS主任の意見の相違
既存のシステムの仕様に関する議論については、まだここで決着はつけない。
後の話が続けばいずれその良し悪しについては触れるつもりではいる。
この場合、主張をぶつけあっている両者の意見はそれぞれに切実な理由がある。
それは決して相手を罵倒して自分の意見を通すことが正しい方法ではないことは明白なので、この場合Sさんのやり方には賛成しかねる点はある。
この場合、Sさんが「古い」といったのはあくまでY君の提案した方法のことである。
設計書をとりまとめるという作業には文書化という重要な意味があり、それがまずプロジェクトを動かす前提となっている場合も多々あるということは事実だ。
この足場にあたる部分をまずしっかりさせようというのがY君の意見。
設計書とはいっても、もしもその存在意義があまりない文書だとしたら、パフォーマンスを犠牲にしてコストをかけてまでやる必要がないという判断が出てくるのも当然である。
それならパフォーマンス優先で設計が理解できる他の方策で代用し先へ進もうというのがS主任の意見。
どちらが正しいかは一概には判断できず、Sさんのいうような新しいか古いかの価値観の問題でもないが、S主任はY君のやり方は古いと感じているのは確かだ。
果たしてそうなのか。。。これも重要な問題である。
不連続ドラマ：とあるオフショアプロジェクト 3
Y君は自社内システムの新規開発のためオフショア開発のプロジェクトに参加することになった。
会社が選んだマネジメントの担当者は誰よりも血の気が多く、開発部内の喧嘩屋S主任だった。
その人選に目眩を覚えるY君。。。
プロジェクトの体制が決まった時、Y君はS主任に挨拶に行った。
その時のS主任はいつもの「面倒なことに巻き込みやがって」という表情ではあったものの、数日後のキックオフのミーティングではメンバーのみんなと握手をするなど意外に”まともな”振る舞いを見せた。
その後プロジェクトのタスクを洗い出しスケジュールを決め、部内での承認ももらった。
タスクの洗い出しでは、S主任は周囲の予想を裏切るやり方で誰もを驚かせた。
基本的な要件をまとめた資料だけを事前に配布、あとはメンバー全員を集めてブレインストーミングを行ったのだ。
メンバー各自が想定するタスクを上げていく。
S主任はそれをひとつひとつ大きな付箋に書いてホワイトボードに貼っていく。
発言が出尽くしたところで付箋を手早くグルーピングしていくのはS主任が自ら行うのだが、発言者に「これはこのグルーピングで意図はあってるかな」と確認する。
そこには喧嘩屋の面影はなく、Y君はS主任のことをちょっと誤解してたかもと思った。
海外発注に際しての契約面での交渉ごとについて発言したメンバーもいたが、そのあたりは普段のプロジェクトではエンジニアがスルーするところなので、なるほどオフショアではそういうところも視野に入ってくるかなという新鮮な驚きがメンバーにはあった。
また、終始発言のないメンバーもいて、気になったのでY君はなぜ黙っているのかと訊いてみた。
そうすると、オフショアであろうが何であろうが、開発でやることは同じ筈なので、特段発言すべきようなことが見当たらないという。
それは誰もが暗中模索な中尤もな話ではあるが、イマジネーションの有無はプロジェクトをすすめる上では重要だ。
成長という観点でいえば、その彼にはむしろ最前線に立ってベンダーとやり取りさせたりする方がいいかもしれないと思った。
そしてブレインストーミングの産物であるタスクのグループは補填され収束され大線表となり、いよいよ最初のフェーズである設計の作業に入った。
今回のシステムの元となる現行のシステムに関しては、現状の仕様にあった設計書というものが存在しない。
過去に多々の改変改変を繰り返しているが、当初の設計書に反映されることはなく、差分の仕様のみが管理されている。
つまり、今まさに動いている仕様を把握するためには、過去からの仕様変更差分の履歴を時系列にたどるしかない。
この現行仕様をどうやってベンダーに伝えることができるだろう。
そのやり方をどうするかについての議論のさなかにS主任の喧嘩屋の本性が現れる時がいよいよやってきてしまった。
Y君は現行の仕様を差分の状態からまとまった仕様書にし、それを元に新しい設計を起こすことを提案した。
ところが、S主任はそれは不要で、現行システムにゲストログインして遠隔からでも制限付きで使えるようにし、仕様の細かいところはQ&Aでこなせばいいというのだった。
前者は設計書のまとめの時間がかかるし、実装の立ち上がりまでに間に合わせるのは大変だが、できないことでもない。
何しろ決定版の設計書が残ることは後々メリットがある。
後者はドキュメントの作成など最小限にするため、プロジェクトのパフォーマンス優先である。
しかし、Q&Aで対応するのにも夫々時間を必要とするため、その負担は仕様がどれだけ明快かという程度にもよる。
「とうとう面倒くさがり屋が本心を出したな」と思ったY君は少々ムキになって反論したが、S主任は当然きかない。
逆にS主任のきつい言葉を集中的に浴びせられて反対派は一人一人と陥落、結局はどうみても負担の軽い方法であるS主任の主張にプロジェクトの方針は決まった。
「まったくお前の話は古いよ、何時代の話だよ」というS主任の罵倒の言葉に打ちのめされてしまったY君は、すっかり意気消沈してしまった。
早くもこのプロジェクトに暗雲が立ち込めていた。
（続く といいが）
ブレインストーミング
方向性を探るとき、問題点の整理をするときなど複数人でブレインストーミングを行うと効果的だ。
漠然したテーマで、そのテーマに関する各人の意見を出してもらう。
原則的にはどんな発言でもいいが、ルールはただ一つ、批判をしないことである。
意見を出す上で公平であることで、多様な意見を出させ、あとでそれを分類・分析する。
上記の例ではブレインストーミングとKJ法を部分的に取り入れているが、これはどのような形にしてもよいと思う。
ここでは誰もが経験したことのないプロジェクトで、どんなことをするかという目測に使っているが、こういう場合には最適ではないかという思いがあったのでこのフェーズでブレインストーミングの手法を入れてみた。
Y君とS主任の意見の相違
既存のシステムの仕様に関する議論については、まだここで決着はつけない。
後の話が続けばいずれその良し悪しについては触れるつもりではいる。
この場合、主張をぶつけあっている両者の意見はそれぞれに切実な理由がある。
それは決して相手を罵倒して自分の意見を通すことが正しい方法ではないことは明白なので、この場合Sさんのやり方には賛成しかねる点はある。
この場合、Sさんが「古い」といったのはあくまでY君の提案した方法のことである。
設計書をとりまとめるという作業には文書化という重要な意味があり、それがまずプロジェクトを動かす前提となっている場合も多々あるということは事実だ。
この足場にあたる部分をまずしっかりさせようというのがY君の意見。
設計書とはいっても、もしもその存在意義があまりない文書だとしたら、パフォーマンスを犠牲にしてコストをかけてまでやる必要がないという判断が出てくるのも当然である。
それならパフォーマンス優先で設計が理解できる他の方策で代用し先へ進もうというのがS主任の意見。
どちらが正しいかは一概には判断できず、Sさんのいうような新しいか古いかの価値観の問題でもないが、S主任はY君のやり方は古いと感じているのは確かだ。
果たしてそうなのか。。。これも重要な問題である。
