知識労働とソフトウェア開発

技術者としての考え方を養うための本も読まないと、といいつつ、相変わらずサボっていますが、ようやく1冊読みました。

カバーの煽りはともかく(^^; 書名が目に留まって、図書館で借りました。

知識労働とソフトウェア開発 (技評SE選書)

書名の「知識労働とソフトウェア開発」は、この本の第一部です。第二部「UMLは手段」、第三部「アーキテクトに未来を賭けた」、そして、第四部「上流工程で成功する人、つまずく人」という構成になっています。もともと第二部と第四部は、それぞれ一冊の本だったそうです。各部は、独立したパートになっています。

知識労働とソフトウェア開発

第一部は、知識労働としてのソフトウェア開発を行うには、一人の開発者としてどのような振る舞いをすればよいかが書かれています。

ソフトウェア開発は、知識労働にも肉体労働にもなり得ます。しかし、プロジェクトが肉体労働に比重を置いていたとしても、プロジェクトメンバーであるあなたが、知識労働者であり続けることは可能です。

その条件は、次のようなものです。

• 計画性がある
• 知識と技術をバランスよく持つ
• 現場主義である
• クリエイティブである
• プロ意識がある

荒井玲子：『知識労働とソフトウェア開発』，技術評論社，p.60，2010.10

他責の態度を捨てて、知識を使わないとね、ということを思い出させてくれる言葉です。

多くのソフトウェア技術者は、技術の習得には熱心ですが、知識の習得にはあまり熱心ではありません。知識は実務には関係ない、理論的なことだ、と考えているのでしょうか。

（中略）How toをいくら集めても、その技術の限界点は把握できません。それは、その技術の存在意義、つまり本質をつかんでいないからです。

知識を得て、本質を理解していると、次にどんな技術が開発されるのか予想できるようになります。

荒井玲子：『知識労働とソフトウェア開発』，技術評論社，pp.68-69，2010.10

すぐに移ろう表層の技術よりも、本質である知識を学べ、という警句ですね。

この本では、そうして次の技術を予想することで、たとえば「現在開発中のシステムに、将来に提供されうる解決策を見越した仕掛けを施しておく」といった、実利的な「知識の活かし方」も解説されています。上の主張が、ただの精神論ではないと分かります。

UMLは手段

第二部には、目的と手段を取り違えると失敗するよという話が書かれています。

著者の方がUMLの専門家なので、UMLにフォーカスした内容ではあるのですが、「UML」を他のバズワードに置き換えても、共通する部分があると思いました。

たとえば、「これからはビッグデータ解析だ」と叫んで飛びついたプロジェクトが上手くいかない現象や、Hadoopの講習を受けたからといってデータ解析ができるようになるわけでも、データ解析に適したアーキテクチャを組めるようになるわけでもないことなどが、ダブって見えました。（この例は一般論です、ハイ）

アーキテクトに未来を賭けた

第三部には、人材をアーキテクトに育てるにはどうすればよいかが書かれています。といっても、育てる側だけでなく、育ちたい本人が読むとよいと思います。

• なりたい姿を描いて、方向性にズレがないか確認しつつ、足りないものを身に着けていくこと
• 学習サイクルを自分で作って回すこと

この2つは、エンジニアとして成長するために重要なこととして、師匠から自分が刷り込まれてきたことです。まさに同じことが書いてあり、ちょっと驚きました。

上流工程で成功する人、つまずく人

第四部には、俗に超上流といわれる、要求を仕様化するよりも前の工程のやり方のコツが書かれています。

このパートの内容は、自分にとって難解で、すべては理解できませんでした。特に、この本の表現でいうところの「要望の収集」から「要望のフィルタリング」までの部分の話が、抽象的で難しかったです。どう難しいかというと、課題ではなく問題を見つけましょう、と書いてある箇所で、両者の定義が不明だったり(^^; …と書くとアレですが、この本は全体的に分かりやすい文章で書かれていると思うので、このパートだけを難しいと感じたのは、単純に読む側の問題という気がします。

言わんとする方針は、何とか理解できました。要望を収集する前に、要望を入れる型をトップダウンで準備して、収集した要望を分類せよ、という話でした。

・・・と、そんな感じの1冊でした。