「ソフテックだより」では、ソフトウェア開発に関する情報や開発現場における社員の取り組みなどを定期的にお知らせしています。
さまざまなテーマを取り上げていますので、他のソフテックだよりも、ぜひご覧下さい。
ソフテックだより(発行日順)のページへ
ソフテックだより 技術レポート(技術分野別)のページへ
ソフテックだより 現場の声(シーン別)のページへ
筆者は本社事業所勤務の入社10年超になる30代後半の中堅社員です。筆者の入社直後から開発に携わっている業務支援システムがあります。この業務支援システムに関して、一年間に及ぶ大型の開発案件がありました。筆者が主担当としてこの案件を進める上で、担当者に合わせて成果物をチェックすることの大切さについて再認識しましたので、紹介させて頂きます。
今回の案件の目的は新しい業務で業務支援システムを使用できるようにすることとなります。
具体的な作業内容はExcelの帳票を業務支援システムから出力することになります。
業務支援システムにはExcelの帳票を出力する仕組みが既に組み込まれており、この仕組みに新しいExcelの帳票を追加します。
追加するExcelのファイルは20ファイル、シート数で数えると約200シートとなります。
また、帳票の追加に伴い、既存システムへ機能追加も行っています。
開発の主なメンバーは担当者A、担当者B、筆者となります。
担当者Cは案件が佳境に入った時にヘルプとして作業してもらいました。
この中で、担当者Aと筆者が業務支援システムの経験者となります。
はじめに筆者が基本的な設計を先行して行い、担当者Aへ検討結果を連絡していました。その後、担当者Aに外部設計を行ってもらい、それを基にしたお客様とのお打ち合わせにも参加してもらいました。
しかし、開発作業に移るタイミングで、担当者Aから「ソフトウェアをどう作成すればよいか、イメージができない」と相談がありました。
筆者はこのタイミングでこの相談が来ることを想定できていませんでした。
その結果、作業スケジュールの見直しを迫られる事態となりました。
この件に関する筆者の反省点の一つに「担当者Aの理解度の確認が不十分だった」というものがあります。
はじめは筆者が作成した資料をベースに筆者が口頭で説明して理解度を確認していました。
そのとき、担当者Aは経験者なので、その説明で十分通じていると考えておりました。
しかし、筆者が伝えて理解してもらえたと考えている内容と、実際に理解していた内容に大きな開きができていました。
その状況を改善するため、筆者の指示等をもとに担当者Aに一覧表を作成してもらい、 その内容から理解度を判断するように変えています。この後、理解度をより正確に判断することができ、認識のズレも少なくすることができました。その結果、手戻りも少なくなり、元の方法よりは効率も良くなったと考えています。
案件開始時、担当者Bは本案件で必要なスキルを十分には身に着けてはいませんでした。
長期案件ということもあり、この案件を通じて必要なスキルを身に着けてもらう予定で作業開始をしています。
はじめのうちは1回に指示する作業量を少なくして、ソースコードのチェックを毎日行っておりました。
ある程度の目途が立ち始めてから、大きな機能の開発作業に入ってもらいました。
ただし、スケジュールの見直しが必要になったころから、ソースコードをチェックする時間と頻度は少なくなっていきました。その結果、問題の発覚が遅れて後から手直しが必要になってしまい、非効率的になってしまったという反省点があります。
もともとのスケジュールでもチェックの時間は考えていましが、スケジュールを見直ししたタイミングで余力がなくなり、その部分を少なくしてしまっておりました。しかし、これが間違いでした。 担当者の力量が十分であれば、チェックの時間や回数を減らすことはできたと思いますが、その判断がどんぶり勘定になってしまっていたと思います。そもそも、チェックすることは必ず必要なことであり、余力で行うことではないということでもあります。
上記の改善のため、「チェックに必要な工数を初めからスケジュールに織り込む」こととしました。
担当者Bとはこの案件完了後、同じ業務支援システムに関する追加案件の作業を開始していますが、この反省をもとにスケジュールを作成しています。
スケジュールの遅れに対応するため、スポット的に開発と試験をしてもらいました。
対象の機能は業務支援システム本体から出力されるExcel帳票のみとしました。
作業内容を業務支援システム本体から切り離したことにより、他の作業に影響される事なく作業してもらうことができました。結果として、成果物のチェックに関する労力を必要最低限にすることができたと考えています。
ケース1、ケース2それぞれで反省点を挙げていますが、成果物のチェック方法を明確にしていなかったことが問題として共通していると考えています。
ケース1では担当者の理解度を成果物として可視化できなかったことが問題となります。
ケース2ではソースコードのチェックをスケジュールの見直しで怠ってしまったことが問題となります。
逆に、ケース3の場合は独立した機能ということもあり、成果物のイメージが明確になっていたことが成功した理由と考えています。
ただし、あまり細かくチェックをしていくと担当者に「自分は信頼されてないな」と感じさせてしまい、意欲を削ぐことになる場合もあります。このことについて「成果物のチェックのタイミングは何時にしていますか?」と先輩社員へ質問したことがありますが、「これが正解というものはなく、担当者に合わせて変えている。ただし、自分で案件の立て直しができるタイミングを見定めてその前にはチェックをしている。」と回答をもらっています。筆者としては「確かにその通り」と感じており、実践していこうと考えていますが、同時に難しいとも感じています。
ISO9001に基づくソフテックの品質マニュアルでは開発計画書を作成する時に各段階のレビューの実施を明記することが義務付けられています。具体的な改善案としては、この開発計画書に成果物のチェックをレビューとして記載することでチェック方法とチェックのタイミングを明確にすることができます。また、開発計画書は上司の審査・承認を得る必要がありますので、計画の妥当性を上司にも確認してもらうことで、クロスチェックすることもできるようになります。さきほど、「難しいと感じている」と記載しましたが、力が不足しているのであれば、上司やまわりの協力も得て進めることが大切と考えています。
以上のような経験から、案件を複数人で担当する場合には、成果物チェック方法を明確にしていることと、チェック方法について担当者と認識を合わせることが大切と考えています。ただし、チェック方法は担当者の力量、経験、性格に合わせて柔軟に変えていく必要があります。それができていれば、問題があっても早期に発見し、傷が浅いうちに対処できるようになると考えています。
今回は筆者の立場から成果物をチェックすることを紹介させて頂きました。しかし、筆者もまた管理される側であり、管理者へ成果物を出す立場となります。案件進行中の成果物とはなにかと考えると、日々の報連相がそれにあたると考えています。この場合、管理者が必要とする成果物(報連相)を適切なタイミングで出すことが必要になっていくのだと思います。
本文から逸れますが、本案件を進める上で社内の様々な協力を得られたことが大きかったです。
担当者となっていただいたメンバーはもちろんのこと、上司をはじめ社内の人達から多くのアドバイスを頂きました。社内の協力に対する感謝の気持ちを忘れず、今回の経験を今後につなげていきたいと思います。
(K.S.)
関連ページへのリンク
関連するソフテックだより