【ITニュース解説】They Praised the Same Thing They Warned You About

システムエンジニアを目指す上で、個人の特性がどのように評価され、それをどう管理していくべきかについて、非常に示唆に富む考え方が示されている。この記事が伝える核となるメッセージは、「特性は美徳でも欠点でもなく、単なる設定である」ということだ。

私たちは日々の業務の中で、自分自身の行動や性格に対して様々な評価を受ける。例えば、「徹底的だ」と褒められる一方で、「仕事が遅い」と指摘されることがあるかもしれない。「決断力がある」と言われる一方で、「周りの意見を聞かない」と見なされることもある。「慎重だ」と評価される一方で、「なかなか決断できない」と批判されることもあるだろう。これらは一見すると矛盾する二つの評価のように思えるが、実は同じ一つの特性を、異なる状況や視点から見た結果に過ぎない。

システムエンジニアの仕事に置き換えて考えてみよう。例えば、コードを書く際に非常に「徹底的」な特性を持つエンジニアがいるとする。このエンジニアは、バグの可能性を徹底的に検証し、あらゆるエッジケースを考慮した上でコードを記述する。その結果、彼の書いたコードは非常に堅牢で、リリース後の不具合が極めて少ないかもしれない。プロジェクトマネージャーや品質保証担当者からは「信頼できる」「品質が高い」と高く評価されるだろう。しかし、その徹底さが度を超すと、開発に時間がかかり、「リリースが遅れる」「開発スピードが遅い」という評価につながる可能性もある。これは、同じ「徹底的である」という特性が、見る人や状況によって「強み」にも「弱み」にもなり得ることを示している。

記事では、このような評価を受けた際に、多くの人が「指摘された悪い面をなくそうとする」と述べている。例えば、「仕事が遅い」と指摘されれば、「徹底的にチェックするのをやめよう」「もっと早く決断しよう」と考え、自身の特性そのものを変えようと試みる。チェックを減らし、決断を早め、十分な確認をせずに成果物をリリースするようになるかもしれない。その結果、確かに「遅い」という批判はなくなるかもしれないが、同時に「信頼性」や「品質の高さ」といった元々持っていた強みも失われてしまう。人々が頼りにしていた、目には見えない「丁寧さ」や「堅実さ」が失われたとき、誰も何が変化したのかを正確に指摘できないまま、いつの間にかチーム全体の信頼性が低下してしまう、といった事態に陥る可能性もあるのだ。

このような事態を避けるために、記事は「特性を取り除こうとするのではなく、それを調整（Meter）しよう」と提案している。特性は、私たちのダイヤルのようなものだ。そのダイヤルの目盛りをどこに合わせるかによって、結果として生み出されるものが変わる。重要なのは、その特性が「週にどのくらいのコストを払っているか」「どの状況で最大の価値を発揮するか」を理解し、適切に管理することだ。

具体的には、特性を最大限に活かすべき状況と、その影響を制限すべき状況を区別し、調整していく。例えば、「徹底的である」という特性を考える場合、システムの根幹に関わる設計や、セキュリティ上重要なモジュール開発など、本当に「徹底的であること」が不可欠な場面では、その特性を全開にする。一方で、プロトタイプ開発や、比較的重要度の低い機能の改修など、スピードが求められる場面では、その特性が過度に出過ぎないように意識的に制限を設けるのだ。

この「調整」のために、いくつかの具体的な手法が提示されている。

一つは「タイムボックス」だ。これは、特定の作業に費やす時間をあらかじめ区切ることで、たとえ徹底的な特性を持つ人でも、その時間内で最善を尽くし、それ以上深入りしないように管理する方法だ。例えば、コードレビューに30分と時間を区切ることで、与えられた時間の中で効率的に問題を発見し、過剰なチェックによる時間超過を防ぐことができる。アジャイル開発のスプリントやタスク管理において、このタイムボックスの考え方は非常に重要となる。

二つ目は「セカンドリーダー」、つまり別の目を通すことだ。自分の特性が偏りすぎていないか、あるいは見落としがないかを確認するために、他のメンバーにレビューを依頼する。システムエンジニアの現場では、コードレビュー、設計レビュー、テスト計画レビューなど、様々な段階で複数人によるチェックが行われる。これは、個人の特性が持つ強みを活かしつつ、弱点を補完するための非常に効果的な仕組みと言える。

三つ目は「動かせない期日」を設定することだ。明確な納期やマイルストーンを設けることで、どんなに徹底的な特性を持っていても、その期限内で成果を出すことを意識せざるを得なくなる。これは、徹底さとスピードのバランスを取る上で、外部からの強制力として機能する。プロジェクト管理において、リリース日や機能完了日を固定することは、チーム全体の生産性を高める上で欠かせない要素である。

これらの手法を用いることで、特性そのものをなくすことなく、その運用方法を「管理下」に置くことができる。特性は依然として機能し続けるが、もはや無秩序に暴走することはない。これにより、以前は矛盾しているように見えた「徹底的だが遅い」という評価が、それぞれの状況における「ダイヤルの目盛りの位置」を示すレポートとして理解できるようになる。それは、個人の資質に対する「判決」ではなく、自身の行動と周囲の状況がどのように相互作用したかを示す客観的なデータとして捉えることができるのだ。

さらに、この記事は、他人の習慣に苛立ちを感じたときにも役立つ視点を提供している。もしチームメンバーの行動にイライラする場面があったら、その行動の裏にある「強み」を探してみるべきだと示唆している。例えば、あるメンバーが会議で発言が少なく、なかなか意見を言わないことに苛立ちを感じるとする。しかし、その裏には「他者の意見をじっくり聞く」「軽はずみな発言をしない」という慎重さや思慮深さの特性が隠れているかもしれない。システム開発の複雑な問題を解決する際には、このような特性が後々大きな価値を発揮することもあるだろう。他者の特性の二面性を理解することは、チーム全体の多様性を尊重し、より協力的な開発環境を築く上でも極めて重要だ。

システムエンジニアとして成長していく上で、自分の特性を深く理解し、それを状況に応じて適切に「調整」する能力は不可欠である。自分の強みを最大限に活かしつつ、それが弱点とならないように管理する。そして、他者の特性を理解し、互いの強みを引き出し合うことで、個人だけでなくチーム全体のパフォーマンスも向上させることができるだろう。特性は変えるものではなく、磨き、使いこなすものなのだ。