「はじめよう! 要件定義」を読んだ

「はじめよう! 要件定義 ～ビギナーからベテランまで」（技術評論社）を読みました。

プログラミングの技法やフレームワークなどを使って「どうやって作るか」については知見が急激に増加してきている一方、そもそも「何を作るか」については取り残され気味であったとの著者の課題意識から出発している書籍です。
「UI」「機能」「データ」の３つにポイントを絞って平易な文章で書かれており、少しずつ順番に説明が進むため、２〜３時間くらいでスッと読める一冊でした。
特に、準備編と助走編まで（ページ数としては半分くらい）は、システム開発やプログラミングの経験があまりない人にも読んでもらえると、基本的な認識を揃えることができてコミュニケーションが少し円滑になるのではないかと思います。

要件定義や業務設計を一緒に進めるとなると、気後れしてしまう人もいますし、後回しにしてしまう人もいるのが実情です。 本書では要件定義の前にそもそも何が必要か、要件定義が終わった時の成果物は何か、といったことを要所要所で繰り返し列挙してくれますので、組織内で知識の底上げを図り、最低限の作業を担保するには分かりやすい内容です。

印象的だったのが、「機能設計と業務設計の類似性」というコラムです。

プログラミングが得意だと思っているにもかかわらず、業務設計が苦手だと感じるのであれば、それは本当の意味でプログラミングを理解している訳ではなく、ただ単に手癖でたまたま動くプログラムを書けるようになっているだけなのかもしれません。

アプリケーションの特性によって異なる部分はあるにしても、多くのシステム開発は人間がやる仕事をコンピュータに置き換えている側面があります。 このため、業務設計はできないけど機能設計はできます、という発言には自他を問わず気をつけた方が良いなぁと思いました（自戒を込めて）。 背景や目的を理解せずに淡々と作業として開発や改修を繰り返してしまうと、往々にして陥りやすい状況だと言えます。
同様に、業務を遂行できることと、業務を設計できることは違う次元の能力だと言えます。 業務に従事している人が一番詳しい、と目されることがあるかもしれません。しかし、残念ながらその人が業務をきちんと一覧化して構造化して説明できるとは限りません。
時には日常の作業を俯瞰して整理し、たとえば業務フローや業務手順書を見直したり、定型作業をテンプレート化するなど、自己フィードバックを組み込んだ組織設計が重要だと実感しました。

要件定義という切り口で、チーム開発における意思伝達や、小規模なシステム開発の業務委託を円滑に進める上では定期的に振り返りたい本でした。