「業務に近い工程を設計している人は何を考えているか」に関しての考えをまとめました。

目次

先日から、自分の担当する工程が変化した。これまでは、基本設計書ベースでのPG・半SE（SEの定義がわからない）が主だったが、最近は、プロジェクトマネジメントを求められている。設計書の作成に加えて、顧客折衝やアサイン管理、要件の整理、作業依頼などといった具合。 コーディングベースの視野のまま、マネジメント「そこって今大事じゃないと思うよ」という視線を受けまくった。

幸い周りに要件定義・基本設計、顧客折衝を任されている人は、自分と何が違うのかわからないため、周囲の優秀な人がどういう考え方をしているか雑多にメモる

抽象的な課題と、具体的な課題を意識的にコントロールよう求められることが増えている

実装ベース

業務定義と、システム定義を合致させている。例えば、ユーザーは何のテーブルのどこの値を使用しているか→。勘所を理解しているように感じる。権限（管理者かゲストか…）・状態（通常、休会中か、退会中か）、それらはどのテーブルのどのカラムを参照しているか。入力する場合禁則事項はあるか、といった具合。ここはPG経験が長い人にとって強い部分でもありそう。詳細に書きすぎると、それにがんじがらめになったり、マイクロマネジメントに陥りかねない。あえて書いていないこともありそう。

課題に向き合い続ける

最近抽象的な問題の解決方法に悩んでいたら、「頭がおかしくなるくらい、ああでもないこうでもないと考える」と言われた。頭をかきむしるくらい、様々なケースを想定し続ける。コードだったり議事録だったりを眺めて「これって本当にそうか？」と疑っていくそう。「その結果、いろいろ考えたことは起きず、すんなり進むことも多いけどね」と笑っていた。強い・・・。

業務の何を解決するか

作る理由を明確にしている。なぜやるのか、それをどのように実現するのかがはっきりしており、尋ねられたら即答している。巻き取った時など、そこが曖昧な場合は、すぐ顧客またはほかの人に尋ねている。これで思い出すのは、最近経験した炎上案件。この部分が曖昧でメンバー全体に浸透させられなかったのが原因。機能ごとに整合性が取れていなかったり、不要な制限・機能に工数をかけてしまい遅れが生じた。炎上を納めてくれた優れたマネージャーは、まず目的を明確にし、要望・バグの温床になる不要な機能をを削り続けていた。

上流工程は業務ベースの抽象的な思考で実装は詳細設計以降に任せる・・・という単純な話ではなく、実装のことを考え、わからない部分は他人に尋ね未知の部分を減らしていくのが大切な勘所だと思う。

関連しそうな本 Big Thing 「ソフトウェア開発現場の「失敗」集めてみた」