仕様書やプログラムコードの「ユーザー」のことを常に思いやる
宮下氏が心掛けるプロジェクト・組織マネジメントの極意を一言で言い表すと、「ユーザーを想うのと同じように、開発スタッフのことも想うこと」だという。
例えば、開発プロジェクトにおいて意図通りの実装になっていないような問題が発生した場合に、その一因として仕様書の品質に起因することがあり、これを解決する上でも前記の心掛けが役立つという。
「ソフトウェアの開発者は、常に『製品やサービスがユーザーにどう使ってもらえるか』を考えながら開発を進める。同様に仕様書を作成する際には、仕様書のユーザーである全プロジェクトメンバーにどう使ってもらえるかを強くイメージする必要がある」
仕様書内の表記をきちんと統一し、プロジェクト内の共通言語や共通認識を根付かせることも、こうした取り組みのひとつだ。例えば、エラーを表示させるためのウィンドウのことを、仕様書内で「ウィンドウ」「ポップアップ」「ダイアログ」などとバラバラに表記すると、それを読むプロジェクトメンバーも、おのおので異なった解釈を行う可能性がある。その結果、開発者によって異なる実装を行ってしまい、プログラムコードの品質が著しく低下してしまう。こうしたリスクを回避するためにも、仕様書の記述は全プロジェクトメンバーにとって分かりやすく、かつ内容に一貫性が保たれている必要がある。
また仕様書には必ず、「なぜそれを実現したいのか」を表す「目的」を明記しておくこと重要だ。その仕様の目的が不明確なままだと、仕様書を読んだ開発者ごとの判断にばらつきが生じて、設計者が意図した通りの実装にならないこともある。逆に目的が明確に記されていれば、開発者やデザイナーから「この目的を達成するには、こういうやり方の方がいいのでは？」といった提案を引き出せる可能性も出てくる。
仕様書と同じく、プログラムコードの品質を高める上でも「ユーザーを想うのと同じように、開発スタッフのことも想うこと」が大事だという。
「プログラムコードのユーザーは、プロジェクトの全エンジニア。従って、プログラムコードの作成者は製品やサービスのユーザーのことを想うのと同じように、プロジェクト内のほかのエンジニアのことを想いながらプログラムコードを作成する必要がある」
コードレビューを行う際にも、レビューを行うエンジニアの立場に立ち、より正確で効率のいいレビューを行ってもらえるよう十分な情報を集めて提供する必要がある。単にコードを提供するだけでなく、仕様の情報や実装方法、影響範囲、場合によってはUIの画像情報なども併せて提供する。
エンジニア同士のレビューだけでなく、テストを行うQA部隊とエンジニアとの間のやりとりにおいても、テストの目的やバグの要因、プログラムの変更内容、影響範囲といった詳細な情報を渡すことで、互いの認識の齟齬を避け、正確で効率的なテストが可能になる。もちろん、QA部隊からエンジニアに対してテスト結果や見つかったバグの情報をフィードバックする際も同様だ。
「そのほかにも、チケット駆動開発を行っている現場なら、チケットを渡す相手のことを想って、必要な情報を分かりやすくチケットに記載する必要がある。このように、人に情報を伝えるタスクすべてにおいて、プロダクトのユーザーを想うのと同じように、開発プロジェクト内でもそれぞれのユーザーを想像し、互いの理解を深めてアウトプットの品質を高めることが重要だ。こうしてアウトプットの品質を高めていけば、開発全体の品質が向上し、ひいてはより良い品質でユーザーに届けることができる」
