水野シズク、入社一年目のフレッシュプロマネの挑戦 第四話

ランチタイム

シズクが勤務する会社は東京の大手町とお茶の水の中間に位置しており、オフィスは都心の活気に溢れた場所にあった。彼女は仕事の合間にも小さな楽しみを見つけていた。隣のグループの先輩である安藤さんとは、出勤が重なる日は一緒にランチをとることにしていた。

この界隈では、ランチタイムになると多くの飲み屋がお得なランチメニューを提供している。今日は安藤さんと一緒に近くのタイ料理屋のサバイサバイタイ食堂に行き、トムヤムヌードルを注文した。味わい深いスープと麺の絶妙なハーモニーが、忙しい一日の中での一時的な逃避とリラックスの時間を提供してくれた。

シズクにとって、安藤さんとのランチタイムはただの食事以上のものだった。これは仕事のストレスを和らげ、リフレッシュする貴重な機会となっていた。また、安藤さんとの会話は仕事のヒントや気づきを与えてくれることも多く、彼女にとっては仕事の一部としても大切な時間だった。

プログラミング工程

詳細設計の条件が解除され、プロジェクトは全面的にプログラミング工程に移行した。この新たな段階では、チーム構成にも変化があった。メンバーの中で3人が抜け、新たに5人が加わった。残りのメンバーは、詳細設計に関わったメンバーがそのままプログラミングに取り組むことになった。リーダーは引き続き松島と三井で、彼らがこの新たな段階の指揮を執ることになった。

プロジェクトがプログラミング工程に移行した後も、ニシスの日常業務にはそれほど大きな変化はなかった。シズクは毎日の朝会と夕会に参加し、WBSを確認することが日課となった。遅延しているタスクがあれば、そのリカバリ策を各リーダーに確認し、対策を講じる。

シズクは、マイネットワーク社とのQAが滞りなく進行しているかを確認することに時間を割いていた。これによって、プロジェクトの進行が円滑に行われているか、また、問題が生じていないかを常に把握しておくことができる。

QA管理表を丁寧に確認しているうちに、シズクは小さな問題を見つけた。明日が期限なのにステータスが「未対応」のままとなっている案件が2つあった。これらはマイネットワーク社からの質問に対する回答が必要なもので、単なる更新漏れならば良いが、放置されている状態ならば問題だ。

管理表の「玉持ち」欄には2件とも「コウ」という名前が記されていた。この「玉持ち」とは、現在問題に対応している担当者のことを指すルールだった。シズクは以前、QAが滞っている場合は「玉持ち」の人物に直接状況を確認するように指導されていた。

状況を把握するため、シズクはコウにコンタクトを取ることに決めた。オプション選択画面を担当している彼から、なぜQAが停滞しているのか、その背景や解決策について聞くことが重要だった。

シズクはチャットでコウに、「コウさんがご担当のQA 2件について、管理表の更新がありませんが、どのような状況ですか？」と尋ねた。しかし、2時間が経過しても、コウからの返信はなかった。

メンバー表を調べたところ、コウはプログラミング工程から参加した22歳の中国人であることがわかった。お昼休みを過ぎても反応がないため、シズクは直接通話でコンタクトを取ることに決めた。

通話がつながり、コウの返答があった。「コウさん、QAのことで確認したいのですが」とシズクが切り出すと、コウは中国語訛りの日本語で応答した。「未回答の2件ですね。内容がよくわからなくて。フルリモートなので誰に聞けばいいのか分からないんです。」

シズクは、コウとのコミュニケーションが少し難しいと感じたが、彼が直面している問題を理解しようとした。「松島さんに連絡してみましたか？」と彼女は尋ねた。

「彼はいつも忙しそうで、なかなか話す機会がないんです。」とコウが答えた。

シズクは、コウの抱えているQAの内容を理解し、彼をサポートすることに決めた。一つはオプション選択画面で表示順序を変更することに関する影響範囲の調査、もう一つは画面レビューの日程変更の要求だった。

彼女はコウに対し、サポートする意向を伝えた。「私からサブリーダーの高橋さんに話してみます。結果はコウさんにチャットで連絡しますね」とシズクは言った。そして、すぐにコムテル社のサブリーダーである高橋に状況を説明し、協力を求めた。

高橋は快く協力を申し出てくれ、「私が対応しますよ。管理表の玉持ち欄も私の名前に変えておきます」と返答した。この迅速な対応に、シズクはほっと一息ついた。彼女は自分がプロジェクトの一員として何ができるかを見極め、効果的に行動することができた。

シズクはこの経験から、プロジェクト内でのコミュニケーションの重要性と、適切な人に問題をエスカレーションすることの大切さを学んだ。また、チームメンバー間のサポートがプロジェクトの進行においていかに重要かを再認識した。

委託契約

プログラミング工程が中盤に差し掛かる頃、田中はシズクに開発パートナー2社との重要な開発推進会議の設定を依頼した。会議には事業部長の塚本、部長の佐藤、ニシスのメンバー、そしてパートナー社の開発部長や営業部長、担当営業が出席する予定だった。

シズクはまずコムテル社との会議の準備に取りかかり、迅速にインビテーションを送付した。会議はオンライン形式で行われることになっていた。

会議の主な目的は、結合テスト工程以降の人員計画と発注に関するものだった。シズクの会社は開発パートナーへの発注に関して非常に慎重なアプローチを取っており、最初に大枠予算を決めているが、実際の発注は開発スタートから要件確定まで、基本設計からプログラミングと単体まで、結合テスト以降の3つのフェーズに分けて行っていた。これは大幅な予算超過を防ぐための措置だった。この会議は結合テスト以降の体制と見積を行うための前提条件を決めるためのものである。

コムテル社との会議で、玉川は慣れた営業トークで進めた。「今回も前回と同じ条件でお見積もりいたします。いかがでしょうか？」と彼は明るく提案した。

しかし、田中の反応は異なった。「現在のリーダーの進捗報告や品質報告が不十分で、プロジェクトの全体像が掴めていません」と田中は静かに述べた。「各工程の成果物の粒度が担当者によってまちまちで、手戻りも増えています。前任の後藤さんのときは発注仕様書がずいぶんザックリでしたが、テスト工程は特に品質が重要なので、委託内容をもっと詳細に詰めたいと考えています」

会議中、玉川は田中の要求に応じ、「そうですか、承知しました」と答えたが、その表情にはわずかな陰りが見えた。彼の声には通常の明るさが少し欠けており、田中の指摘に少なからず心配している様子が伺えた。

会議中の田中と玉川のやり取りを聞き、シズクはあることに気がついた。田中がこれまで開発パートナーである松島の仕事について直接的な不満を言わなかった理由が理解できたのだ。契約上、田中は松島に直接指示を出すことができないため、具体的なやり方に関しては言及せず、必要な指摘のみを行っていたのだ。これまでの契約では、作業の詳細に関する記載が不足していたため、そのようなアプローチが取られていた。

田中は、結合テスト工程以降、進捗管理や品質管理を業務委託の範囲として明確にし、不備があれば営業にクレームを出せるようにすることを明示した。これに対して玉川が「その分工数アップにつながりますがよろしいですか？」と問うと、田中は冷静に「御社の進捗管理と品質管理のプロセスに関する手順書を見せてください。内容が十分であれば、御社の手順で管理していただいて結構です」と答えた。「御社のプロセス以上は要求しませんので、追加で費用は掛かりませんよね？」と田中は付け加えた。

シズクはこのやり取りから、プロジェクト管理における契約の重要性、特に品質管理と進捗管理に関する契約の精密さがプロジェクトの成功にどれほど重要であるかを深く理解した。また、田中の柔軟かつ的確な対応が、プロジェクトをより良い方向へ導くための鍵であることを学んだ。

テスト準備

プログラミングの作業と並行してテスト準備の作業も進められた。結合テストと総合テストのテストシナリオおよびテストケースの作成が始まったのだ。これはプロジェクトにおいて非常に重要な段階であり、開発したソフトウェアが設計通りに機能するかを確かめるためのものである。

基本設計と詳細設計の段階で洗い出されたテスト項目に基づいて、テストシナリオのパターンが組み立てられた。シズクとチームは、各テストケースに必要なマスタデータや、画面から入力する値を準備し、例外パターンや代替パターンも検討した。また、データ移行とそのデータを使ったテストの計画も進められた。

この段階では、テストを実施する前に数多くの準備が必要で、シズクはその複雑さと重要性を痛感していた。テストケースの作成には、仕様の理解だけでなく、システムの全体像を見る能力が求められる。それは、ソフトウェアが実際の環境でどのように機能するかを予測し、可能な限り多くの問題を事前に特定し解決するためである。

結合テストの段階では、SIMナンバー管理サブシステム、決済管理サブシステム、与信情報システムなど、外部システムとのインタフェースが確認されることが重要であった。シズクは、これらのシステム間の連携がスムーズに行われるかどうかに注目していた。マイネットワーク社が以前のオーナーシップのもとで使っていたシステムのテストパターンは変わっておらず、新しいインタフェースのテストケースを既存のテストに追加するだけで済んだ。

しかし、契約システムと請求システムの扱いはより複雑であった。プランの種類が多岐にわたり、学割や家族割りのような割引プランも組み込まれており、さらにキャンペーンの管理も求められていた。料金パターンを整理し、それに基づいてテストを行うことの難しさをシズクは痛感していた。

テストパターンを決めるテスト調整会では、各分野の有識者が集まってディシジョンテーブルを作成し、効率的にテストパターンを決定していった。シズクはこのプロセスに参加し、専門家たちがどのように複雑なデータを分析し、どのようにテストケースを洗い出していくかを学び、その手際の良さに感銘を受けた。

結合テストの準備が進む中、テストシナリオの作成において特に重点を置かれたのは契約のライフサイクルであった。シズクは、契約プロセスの各ステージを詳細に検証することの重要性を認識し、その複雑さに圧倒されながらも、一つ一つのステップに対する理解を深めていった。

テストシナリオには、新規契約の作成から始まり、契約内容の変更、未払いによる契約の一時停止、その後の契約再開、契約の譲渡、複数回線契約の管理、解約などの個々のテストケースを組み合わせて、一連のライフサイクルの流れが表現されていた。そして、マイネットワーク社の前進となる通信会社から何百万という契約が移行されるため、移行されたユーザーがマイネットワーク社のサービスを利用できるかというテストシナリオも作成された。更に、これらの基本シナリオを組み合わせて、さらに複雑なケースを想定したシナリオも定義された。

シズクはこれらのシナリオを通じて、契約関連の操作がシステムに与える影響を全体的に把握し、どのようにそれぞれのテストケースを設計し、実行するかについて学んだ。各テストシナリオは、実際の業務フローを反映したものであり、実際の運用環境で発生する可能性のある問題を事前に特定し、対処するためのものだった。

このテストの段階を通じて、シズクはテスト設計の重要性と、プロジェクト全体の品質保証プロセスへの貢献について、さらに深い洞察を得ることができた。テストシナリオの各ステップが具体的なビジネスのニーズにどのように対応しているかを理解することで、彼女はより効果的なテストプランナーとなり、プロジェクトチーム内での役割を果たす自信を強化した。

テスト手法

シズクは、結合テストの準備を進める中で、新人教育時に学んだ「ディシジョンテーブル」というテスト手法を思い出した。当時、彼女はセクションテストの準備のため、多くの専門用語とその内容を一生懸命覚えたものの、実際にそれらがどのように適用されるのかについては具体的なイメージが持てなかった。

しかし、今、実際のプロジェクトでテスト手法がどのように使われ、それがどれだけ重要な役割を果たしているかを目の当たりにして、シズクはテスト手法の重要性を改めて実感していた。彼女は、これらの手法がテストの精度を高め、より効率的で信頼性の高いソフトウェア開発に寄与していることを理解した。

この新たな理解を深めるために、シズクは新人教育のときに使用したテキストを引っ張り出して見返してみた。テキストを開くと、当時は難しく感じた概念や手法が、現在の経験を通じてよりクリアに理解できるようになっていた。彼女はディシジョンテーブルの作成方法、それを使ったテストケースの洗い出し方についての説明を丁寧に読み直し、これまでのテスト計画にどのように組み込むかを考えた。

シズクは、テスト手法の復習を深めることに決めた。彼女は特に、同値分割、境界値分析、状態遷移テストなどの手法に焦点を当てた。これらのテスト技法は、ソフトウェアの異なる入力値に対する振る舞いを効率的にチェックするためのもので、各テストがカバーすべき範囲と精度を高めるのに非常に役立つ。

ディシジョンテーブルは、複雑なビジネスルールやプログラムのロジックを明確に表現するために使用されるテスト手法の一つで、複数の条件とそれに対するアクションを整理して理解しやすくします。

同値分割は入力データを同じ期待結果をもたらす効果的なテストケースグループに分割する技法で、テストの労力を減らしながらもカバレッジを維持するのに適している。

境界値分析は、入力データの境界近くでのエラーを捉えやすいため、シズクは特にエッジケースに対するテストの強化を図ることができた。

状態遷移テストは、システムやアプリケーションが異なる状態間で遷移する際の振る舞いを詳細に調べることを可能にする。

この過程を通じて、シズクはテスト技術だけでなく、学んだ知識を実務に活かすスキルを身につけていくことの重要性を再認識した。彼女は、理論と実践のギャップを埋める努力を続けながら、プロジェクトにおける役割をより効果的に果たしていく自信をつけていった。

プログラミング工程の遅延

ある日の朝会で松島から「成果物の一部のレビューが遅れていますが、来週中になんとかリカバリします」との報告があった。田中が「どの部分が遅れているのですか？」と聞くと「管理者画面です」と松本が返した。詳細設計の成果物レビューで設計漏れを指摘した時に「設計漏れをプログラミング中にカバーする」と松島が言っていた箇所だ。もともと松島が利用者画面に力を入れて設計を進めた結果、管理者画面の設計粒度が荒く、プログラミング工程で解決すべき課題が数多くあったのだ。

コムテル社では、プログラマーが設計の漏れを補いながらコーディングを進めていたが、これが予想外の遅延を招いていた。プログラム作成担当者が設計も行いつつプログラミングするため、本来の作業計画よりもはるかに時間がかかってしまっているのだった。

さらに、詳細設計の完了後すぐにプログラミング作業に取り掛かっていたため、設計レビューが行われておらず一部の設計漏れが見落とされていた。実際にプログラムを組み立てる過程で、これらの漏れが矛盾として顕在化し、結果的に設計を何度もやり直す事態になっていた。このことが、効率的な開発フローを妨げ、プロジェクト全体のスケジュールに影響を与えていた。

田中はコムテル社の松島に対して、遅延している部分のリカバリ計画について尋ねた。「松島さん、来週中にリカバリするとおっしゃっていましたが、具体的なリカバリ策はありますか？」田中の声には、状況を把握し解決へ導くための緊急性が込められていた。

松島は少し迷ってから答えた。「利用者画面の担当者にも一部作業を割り当てます」と彼は言った。しかし、その答えは田中にとっては問題の解決にはならなかった。田中はすぐに指摘した。「それでは、せっかくスケジュール通りに進んでいる利用者画面が遅延するリスクがありますが、その点はどう考えていますか？」

松島はその質問に対し黙り込んでしまった。彼の答えのない反応は、計画されたリカバリ策が全体のプロジェクト進行にさらなる影響を与える可能性があることを示唆していた。シズクはこのやり取りを聞いて、プロジェクト管理におけるリソースの配分とその決定がいかに繊細で、計画通りに進めることが重要であるかを痛感した。

この経験を通じて、シズクはプロジェクト管理における適切なプロセスの設計とチーム間のコミュニケーションの重要性を学んだ。また、彼女は問題が発生した際の迅速な対応と適切な問題解決スキルを身につけることが、プロジェクト成功の鍵であることを実感した。

臨時開発推進会議

遅延によるプロジェクトの危機感を感じた田中は、コムテル社の営業担当である玉川に連絡を取り、急きょ開発推進会議の開催を決定した。彼は玉川に対し、営業の立場からの参加を依頼した。彼の声には、緊急を要する事態の重さが感じられた。

会議の当日、田中は部屋に入るとすぐに本題に入った。「コムテル社の開発遅延は、リカバリが難しい段階にきています」と彼は重く口にした。その言葉にはプロジェクトの未来への深刻な懸念が込められていた。

「現在の予定では、プログラミングと単体テストは8月に完了する予定ですが、これが遅れると、後続の結合テスト、さらには総合テストのスケジュールに大きな影響を及ぼします」と田中は続けた。彼の言葉は、テスト工程の遅延がプロジェクトの成否に直結することを明確に示していた。

シズクはその場にいて、プロジェクトリーダーが直面している厳しい現実と、その重圧を目の当たりにした。彼女は、営業担当と開発側の間での交渉がどれだけ緊迫したものかを感じ取り、プロジェクト管理の複雑さを改めて実感した。

玉川は状況を真摯に受け止め、「私たちも全力でサポートします」と応じたが、その表情からは解決に向けた道のりが容易ではないことの認識が伝わってきた。会議はプロジェクトの命運を左右する可能性を持つ重要な議論で続けられた。

会議室の緊張感が高まる中、田中は玉川への期待を込めて声を強めた。「遅延をリカバリするには限られた選択肢しかありません。人を増やす、稼働を上げる、作業を効率化する、または機能をドロップする。機能の削減は最後の手段です。私たちの前にあるのは厳しい選択ですが、具体的な施策を示してください。」

玉川は深く息を吸い、一瞬の静寂の後で、答えを出さなければならないことを理解した。彼はコムテル社として、プロジェクトを救うための実行可能な提案を考えなくてはならない重責を感じていた。

シズクは、その場に居合わせたことで、プロジェクト管理における遅延のリカバリがどのように交渉と戦略的な意思決定を必要とするかを目の当たりにしていた。彼女は、プロジェクトの成功を保証するためには、時に困難な決断が必要になることを理解し、田中のリーダーシップを見て学ぶことが多かった。

会議は玉川の返答を待ちながら、全員が緊張した表情で次の言葉を待っていた。シズクはこの重要な瞬間を通して、プロジェクト管理の実際の挑戦と、それに伴う判断力の重要性について深く学び取る機会を得ていた。

会議室での緊迫した沈黙を破って、玉川は意を決して答えた。「追加の人員を投入します。もちろん、遅延を起こしたのは弊社の責任ですから、新たな費用負担はありません。」彼の言葉には、責任を認める真摯さと状況を正す決意が込められていた。

田中は頷きつつも、さらに深く突っ込んだ。「人員を増やすと言っても、未経験者が加わると、教育や慣れるまでの時間を考えると、結果的には遅延を拡大する可能性もあります。詳細設計を離れたメンバーを戻すことは可能でしょうか？」田中の提案は、既にプロジェクトに精通している人材を再び動員するという、実用的かつ効果的なアプローチを指していた。

玉川はしばし思案した後、頭を上げて「承知いたしました」と静かに言った。彼にとって、詳細設計を抜けたメンバーを再度コムテル社のプロジェクトに引き戻すのは、他社のプロジェクトに関わっている彼らの業務を再調整するという難題を意味していた。それでも、玉川はこの困難を乗り越え、田中の要求を満たすことを約束した。

シズクはこの交渉を通じて、プロジェクト管理が単に計画を立てる以上のことであること、そして困難な状況の中で実現可能な解決策を見つけるための対話の重要性を学んだ。彼女はまた、経験豊かなリソースの重要性と、柔軟な対応の重要性を理解し、それがプロジェクトのリカバリーと成功に不可欠であることを実感した。

つづく