では、前回に引き続きフォリピンのソフトウェア開発の現場で英語のどのようなスキルが必要かについてお話ししたいと思います。

５）開発タスクをメンバーへ依頼

作成したタスクやスケジュールをメンバーに説明して開発を進めてもらいます。メンバーの数はプロジェクトの規模に応じて変わることが一般的ですが、人数に関わらず対面での説明がおすすめです。開発に関わるメンバー全員を会議室に集めてプレゼンテーションをするようなこともあり、キックオフミーティングなどとも呼んだりします。メンバーは現地のスタッフであることがほとんどですので基本的には英語を使います。

対面で説明するメリットはおおよそ以下のような感じになると思います。

・ドキュメントの中の読み手が気づきにくいような箇所も伝えることができる（開発のきっかけとなった背景や前提とする業務などを含む）

・質疑応答によってドキュメントの抜け漏れに気づいたり、さらに理解を深めてもらうことができる

・役割分担や優先順位なども話し合うことでチームプレーを促進できる

・メンバー同士のコミュニケーションが生まれるので一体感が増し協調して仕事ができる

６）質問対応

開発をしている間、ドキュメントの内容について質問を受けることがあります。質問が出る理由としてはドキュメントの記述に曖昧な箇所があり、どのように作ればいいか判断に迷う部分がある場合だったりします。質問のパターンとしては大まかに以下の２種類に分類され、質問の仕方によって答え方も変わってくると思います。

１）Yes/Noで回答できない質問

例：ここはどういう設計か詳しく教えてください。

２）Yes/Noで回答できる質問

例：ここはこういう設計にした方がいいと思いますが、いかがでしょうか？

１はどうしたらいいかがわからない時に出てくる時のパターンになります。この場合はどのような設計になるかをいったん口頭で説明し、後ほどドキュメントにも反映させておきます。

一方で２はこうしたらいいというアイデアを持っているパターンになり、提案内容に問題なければそのまま承認します。もし提案内容に違和感を感じた場合はこちらから別のアイデアを説明します。

どちらの場合にも言えることですが、その場で判断できるものとクライアントなどへの確認が必要なものがありますので、即答できなさそうな場合は後ほど連絡しますという形で一旦回答を留保する場合もあります。

また、ドキュメントの修正によって他の機能や、テスト設計など他の工程にも影響が出る場合は、関係者へ周知するようにします。例えばテーブル設計の変更であればそのテーブルを使用している全ての箇所、APIのインターフェース設計の変更であればそのAPIを使用している全ての画面といった具合になります。
もしドキュメントの修正範囲が広かったり重要な変更がある場合は、関係者とミーティングを開いて説明をし、認識に相違が出ないようにします。

７）メンバーの作業進捗の確認

プロジェクトは短いもので数日、長いもので数ヶ月におよぶ場合があります。一般的にはプロジェクトの開始段階でスケジュールを作成しますので、作業の進み具合とスケジュールとの乖離を日々チェックすることで、どこに遅れが出ていて、どのような問題を抱えているかがわかるようになります。

確認方法としては、定例の進捗確認ミーティングを行うようなのもあれば、スケジュールに進捗を書き込んでいく方法などもあります。

進捗確認に限らずミーティングをすることはメンバーと情報や課題をシェアし、改善策を検討するためのいい機会ですので、必要に応じて行うにします。

８）成果物の確認

成果物の確認はソフトウェアの品質を左右する重要なプロセスになります。確認をした結果、品質に満足いくものであればそのままクライアントの受入テストに回し、もしそうでなければ開発者や品質管理担当者にフィードバックを行います。誰が担当するかはプロジェクトの規模やメンバー構成、役割分担にもよりますが、品質が担保されていることを確信するためにもプロジェクトマネージャーやプロジェクトリーダーと呼ばれる人もこれらを行えることが望ましいです。
成果物には主に以下のようなものがあります。

１）単体テスト設計

テストは開発の重要なプロセスのひとつで、このやり方次第で品質が大きく変わってきます。単体テストは最初に行うもので、一度にテストする機能が限定される代わりに粒度が細かいものになります。UIや各項目の入力チェック、振る舞い、ロジックの網羅性、出力されたデータ、各種OSやWebブラウザへの対応などが主な観点になり、テストケースとして操作内容や入力値、期待値などを記載します。
テストケースに誤りや抜け漏れがある場合は修正をしてもらうようにします。また不必要なテストケースを作ってしまう場合もあるので、そういったものは削除してもらうようにします。

２）ソースコード

ソースコードの確認のことをコードレビューと呼び、ロジックが適切か、共通化が適切に行われているか、性能やセキュリティに問題はないかなどをチェックします。
もし何か指摘事項があればバージョン管理システムにコメントとして残します。

３）単体テスト結果
テストの結果が期待値通りであるかを確認します。もし手違いなどあれば指摘し、再テストを行うようにしてもらいます。

４）結合テスト設計
業務フローを元に機能間の関連性を失わない程度のサイズに分割し、それに沿って行うテストが結合テストになりますので、フローの網羅性が重要な観点になります。
一般的なものでは管理機能とフロント機能を交互に操作したり、バッチ処理を混ぜるような感じになります。

５）結合テスト結果
こちらも単体テストと同様に、テストの結果が期待値通りであるかを確認します。もし手違いなどあれば指摘し、再テストを行うようにしてもらいます。

いかがでしたでしょうか？ソフトウェア開発である以上は特定領域の技術やソフトウェア工学、プロジェクトマネジメントなどの専門的な知識は不可欠になりますので、英語も勉強しつつ技術の向上にも励みましょう。

ではまた次回をお楽しみに。