DFDで見えた技術QA業務の構造と気づき～Challenge Blog～
■はじめに
パートナーブログをお読みいただいている皆様、はじめまして。筆者は、ネットワンパートナーズ株式会社で、技術業務に携わっている2年目メンバーの1人です。
本記事では、筆者が所属するTechDesk（技術QAチーム）において、データフローダイアグラム（DFD）を用いた技術QA業務の可視化ワークに取り組んだ経験についてご紹介します。単なる図の作成にとどまらず、業務を手順ではなく、「いかに全体を捉えて構造を表現するか」という思考への転換、そして新卒メンバー8人で一つの成果物を作り上げる中で感じた難しさや葛藤について率直にお伝えできればと思います。本稿は、”Beyond Challenge” 記事の第8弾です。
■背景
筆者が新卒一年目に技術QA業務を引き継いだときに、この業務を理解する難しさを漠然と感じていました。一つは、「全体像が見えない」というもどかしさです。断片的なメモや口頭説明を頼りに業務を進める中で、自身が業務のどの位置を担当しているのか迷子になることがあり、不安を抱えながら進めていたのを覚えています。
もう一つは、技術QA業務の手順書自体は存在していても、業務を構成するサブタスク間のつながりが見えず、理解しているというより「理解しているつもり」だとの感覚もありました。こうした経験から、業務とは担当者個々の理解や経験に依存するもので、それゆえに「あの人のやり方」、「あの人しかできない」という属人化につながりやすいのだろうと考えました。
そのような中、先輩方より、本業務をDFDを使って可視化する作業の指示を受けました。このワークでは、現状の業務をデータの流れを中心にして整理・可視化すること、出来上がった図を基にして、さらなる業務改善や業務自動化につなげることが目的とされていました。
DFDについては今回初めて知ったのですが、実は1970年代前半に提唱・体系化されたもので、決して新しい技法ではないそうです。作業説明会では、「業務の図示は、JISフローチャートやスイムレーン図で表現されることが多いが、それらによる数珠つなぎの一本棒や役割分担の表現に限界を感じているため、あえてDFDを採用した」と力説されていました。
■エピソード～取り組みと気づきから
筆者は、業務全体の骨組み作成やパート（プロセス）分割、およびQA回答を作成するプロセスの設計、そして全体レビューの作業を分担しました。そして作業を通じて技術QA業務は、「思っていた以上に曖昧な理解の上に成り立っている」ことに気づかされました。これは筆者だけでなく、ほかのメンバーも同じだったと思います。いままで大きなミスがなく仕事ができていたのが不思議なくらいでした。
ここでは、本活動における困難さを幾つかのエピソードとしてご紹介します。
① DFDという考え方への苦戦
最初に全体像を描こうとしたとき、「これは思っていたより難しい」と率直に感じました。通常、業務を整理するときには、「誰が何をするか」という役割で考えることが当たり前になっています。しかしDFDでは、その前提をいったん崩し、「データはどこから来て、どう加工され、どこへ行くのか」という視点に立ち戻る必要がありました。
そういう視点に立ち戻ったつもりでも、何度描いても気づけば作業手順の図になってしまいました。「また違う…」と気づいては描き直すことを何度も繰り返し、なかなか前に進まないもどかしさを感じていました。
②自分の常識は他人の非常識
ペアを組んで作業を進める中で、「自分が当たり前だと思っていたことが相手には伝わっていない」という場面を何度も経験しました。同じ業務を見て、手を動かしているはずなのに、部分の切り取り方やまとめ方が異なることに戸惑いを覚えました。
これは成果物についても同様で、成果物を統合した際、アウトプットの粒度や表現にばらつきがあり、修正に手戻りが多く発生していました。
③ 8人で1つの成果物をまとめ上げる難しさ
そして、チームで成果物をまとめ上げる難しさです。今回の取り組みで特に印象に残っているのは、筆者たちのチームではオンラインでのやり取りが中心であったため、議論における発言のタイミングを取りづらく、かつ発言の量や深さにも差が出やすかったことでした。
そして気づけば、意見を出し合って決めていくというよりも、誰かの案をベースに修正していく進め方になってしまう場面がありました。
④進捗管理は管理のための管理？
本作業で、各自の分担作業は進んでいるようでも、全体としてうまく進んでいるのかどうか不安になる場面がありました。そもそも「進んでいる」という表現は、作業に着手している最中なのか、完了したのかも曖昧です。こういう曖昧さの蓄積が、不安を招いていました。
作業説明会では、ガントチャートによる進捗管理がサブテーマとして指示されていました。こちらを扱うのも初めての経験でした。そして、どこか管理のための管理のような気もしていて、DFDの作成自体の進捗に不安があるのに、工程を細分化して新たな技法で図を描いて管理する作業が加わると、全体の進捗にさらに影響しそうな気配がありました。
図1 修正途中のDFD図
■考察
今回の取り組みでは、「分からなさ」と向き合い続けることに厳しさを感じていました。最初は時間もない中、正解を急ぐあまり焦りを感じていましたが、その焦りこそが理解の浅さに気づくきっかけになりました。「なぜプロセスがこの単位なのか」「なぜこれがデータなのか」と問い続ける過程は、地道ながら自分の思考を少しずつ深めていける実感がありました。
また、チームでの進捗管理や認識合わせを通じて、「可視化すること」の重要性も強く実感しました。頭の中では理解しているつもりでも、相互の認識のズレを正し、構造として表現しようとすると、曖昧な部分が浮き彫りになります。ここが、「理解している」と「理解しているつもり」のギャップなのだと学びました。
特筆すべきはガントチャートによる工程管理です。これによって進捗状況が可視化され、特に「どこで詰まっているのか」が明確になり、チームとしての動きが見えるようになりました。なるほど、ガントチャートが、今回の作業のサブテーマに位置付けられている意義を理解することもできました。
■おわりに
本記事では、DFDを用いた業務可視化の取り組みと、チームで成果物を作る中での経験について述べました。チーム作業で理解や意思疎通に戸惑い、うまくいかないことも多くありましたが、自分にない視点に触れる面白さを感じ、「考え続けること」そのものの重要性を実感することができました。
今後は、この経験を生かし、業務をこなすだけでなく、「構造として捉え、言語化し、共有する」ことに着目して取り組んでいきます。これが、今後の自身の成長のための重要な姿勢の一つになると考えています。まだ試行錯誤、紆余曲折の段階ですが、積み重ねることで、自身の理解を深め、ひいてはチーム全体の価値向上につながっていくものと確信しています。最後までお読みいただき、ありがとうございました。
