概要
システム間データ連携の改修。
連携するデータの種類を増やすという内容。
悪かった点
以下の2点に時間がかかってしまった。
・改修内容の明確化
・他チームとのコミュニケーション
改修内容の明確化
改修内容の明確化には、対象システムについての理解が必要。
そうでないと、どのシステムのどの部分をどのように改修するのかが見えてこない。
システムの理解に時間がかかったのが根本原因。
ドキュメントが整備されていない、レクチャーが特にないという外部要因は色々あるが、今回は内部要因のみにフォーカスする。
内部要因を一言でいうと、システム理解という作業のゴールと道筋が明確でなかったこと。
どこまで理解すればいいのか、そのためにどのように調査をすればいいのか、
と言ったコンセプトがなく、漫然と調査にあたってしまった。
他チームとのコミュニケーション
他チームとのコミュニケーションは基本的に時間がかかるもの。
即時で連絡が来るわけでもないし、ものによっては調査が必要だったりする。
また、狭間の領域はたらいまわしになって、結局自分で調べるハメになるということもある。
このコミュニケーションコストを甘く見積もっていたことも反省点。
ここを踏まえて早め早めに進めておくべきだった。
改善方法
上記を踏まえ、次回以降どのように進めればいいか。
まずは、進め方をデザインすることが挙げられる。
これをすることで、なんとなく取り掛かって、どこが終わりなのかわからない作業をはじめないで済む。
進め方のデザインは、以下の3つのフェーズに分けられる。
・ゴールの明確化
・WBSの作成
・不確定要素の解消方法の検討
ゴールの明確化
ゴールとは目的の個所に適切な修正を入れること。
つまり、何のシステムの、どこを、どのように修正するのか、ということ。
この明確化を一番最初に実施しないといけない。
そして、そのためにはシステムの理解が必要。
まず、調査する範囲をタスク化して明確化する。
これをすることで際限なく調査するということを回避できる。
知る必要があるのは、改修に関わる部分のみ。
また、調査の過程で当初の範囲よりも調査範囲が増えることもあり得る。
その場合は、増えた範囲の分のタスクを追加することを忘れないようにする。
これを怠ると、調査作業の管理ができなくなり、終わりの不明確な作業に時間を浪費してしまうことになる。
また、不明点を極力残さないということも重要。
ここで曖昧な部分を残すと、後々の作業に取り返しのつかない影響を及ぼす可能性があるため。
次に、実際の調査に取り掛かる。
システムを理解するには、まず概要、その後詳細を調査すればいい。
概要を見て、今回の改修に関わる部分のあたりをつける。
その後、その部分の詳細を見ていけばいい。
概要は、ドキュメントを見るのがいい。
当然ドキュメントだけではすべてを理解することはできない。
その部分を解消するために、ドキュメントから理解できない部分を明確化する。
これが難しい場合は、絵を描いてみるといい。
書けない部分が不明な点ということになる。
不明点を解消する方法としては、推理するということが挙げられる。
これは、わかっていることから可能性の高いものを考えるということ。
周りが埋まっていれば、このピースしか当てはまらない、と言うような考え方。
「A→？→C」であるならば「？=B」みたいな感じ。
何の要素が確定すれば、その要素が明らかになるかという逆のアプローチ。
ただ、これでは限界があるので、その場合は人に聞くのが良い。
その場合、質問はなるべく具体的、ピンポイントなものがいい。
そうしないと具体的な情報が引き出せず、結局役に立たないことが多い。
質問が具体的でないと、教える側も何を教えていいのかわからず、(聞き手にとって)有益な情報が提供できない。
また、概略的な情報だと、教える側は些細なことだと思っていても、聞き手にとって重要な部分が抜ける可能性がある。
WBSの作成
改修内容が明確化されたら、それをもとにWBSを作成する。
その際に、不明点、不安要素、懸念点などがあると思う。
それらは、仮置きの状態でつくってしまう。
ただし、それらを解消するというタスクは作っておく。
不確定要素の解消方法の検討
WBSの虫食いの部分の解消方法を考える。
「どうすれば解消できるのか」と「いつまでに解決しないといけないのか」を考える。
