知識労働とソフトウェア開発 の商品レビュー

荒井玲子【著】

2021/07/13

以前に買って、そのままだったが、改めてよみなおしてみた。UMLの適用は今、業界としてどうなっているかはよくわからんが。。。要所要所にあるあるが書いていて面白い。
一応はだいたいは理解していることで、改めて字面で読ませてもらったという感じ。

2015/01/12

ソフトウェア開発が高度な知識を必要とする創造的な活動であることを説き、それとは反する現状を著者のコンサルタントとしての経験をもとに記してある本です。

労働集約的な考え方を持っている人を論破したいときの材料として読んだり、日本のエンタープライズ向けシステム開発がコンサルタントからどう見えているかを知るために読むのが良いと思います。

UMLとオブジェクト指向の導入に失敗するエピソードや、アーキテクトの立場を勘違いしているエピソードは、身に覚えのある方にとっては耳の痛い話かと思います。そして、それゆえに興味深いでしょう。

2012/03/13

120312
１～５章まであり、ドラッカーの言葉を使いながらソフトウェア開発者の業務内容や進め方のパターンを解説している。元ＳＥ系プロマネとしては非常に興味深く勉強にある。また著者が語るように、ソフトウェア開発業務に限らずすべての業務について参考になると思う。

2010/09/30

帯に「IT開発の知恵はドラッカーに学べ」と書いてあり、ソフトウェア開発もマインドマップからドラッカーへシフトしたのか（トレンドの変遷で）と思って買ってみました。
読み出してみると専門用語が整理されていなくてよく解らない単語が多数出てきました。
読みづらく途中でやめてしまったが、改めて最初から専門用語は気にせず読み進めました。

なるほど。
気になる箇所はいくつかあったが、これは複数の本を再構成・改題を行ったことで、少々のつじつまの合わなさが出ただけだったようです。
前書きに「本書は第1部から第4部のどこから読んでも構いません。」と書いてある。

大企業のSIに携わってきた著者だけに昨今のオープンシステム化・オープンソースソフトウェア化に対処できない現在の大企業の体制をいかにして現実にあわせるかという視点で楽しく且つ目から鱗ともいうべき指摘とともに楽しく読めました。

特にメインフレームとオープンシステムのアーキテクチャの違いの分析は秀逸であり、「なるほど。だからか！」と納得のいく内容でした。

しかしながら著者は自身でコードを書いたことがないんだろーなーと思える箇所が多数あり、型に嵌める（型に嵌らなければならない）事に終始しており、当たり前と思える事の指摘がだらだらあったり、現行のインターネットサービスを行う事業者の開発手法（すなわちトレンド）やOSSプロジェクトの開発手法を理解していればこんな回りくどい事しなくてもといったような記述が多数ありました。

今私が、受託・企画・設計・開発・実装・運用・保守・拡張を行っているプロセスの中で、参考になることは勉強させてもらい、違うと思うことは自身の手法で行えば良いと総括します。

ただ自分のスキルが変遷した際に読み返すとまた違った感想が出てくるような本でした。

ドラッカーの記述はあまりありませんでしたけど。

参考
メインフレームは「守られた開発」
メインフレームはハードウェアからミドルウェアまでがセットでベンダーから提供される。
トランザクションからアプリケーションのインターフェース制御まで全てを網羅している。
制御の主体はメインフレーム。接続されている全ての端末の状態を知っており、全ての端末を制御できる。接続されている端末に何かあった場合、メインフレーム側で他の端末に対して制御をかけ、トランザクションを保護することが可能。

分散システム（オープンシステム）
守られているのはハードウェアとOSのみ。
トランザクション制御やセッション制御はミドルウェアもしくはアプリケーションフレームワーク或いは開発者の独自実装で実現する。
制御の主体はクライアントにあり、サーバはクライアントで何が起きているか知る術は持たない。
あるクライアントが強制終了したとしても他のクライアントを制御する術を持たない。
分散システムを開発する場合、アプリケーション機能のみを設計実装するだけでなく、ミドルウェア層の設計、アプリケーションフレームワークの設計・実装・チューニングが開発範囲（保守範囲）となりDBを使用するのであればDBサーバと通信制御も別に設計・実装・チューニングが必要となる。
分散システムではこれらミドルウェア、フレームワークの開発範囲を網羅した上で、他のシステムとのインターフェースの設計も開発範囲となる。
メインフレームと比較して自由度が高い反面、開発範囲（保守範囲）が圧倒的に広くなる。
「守られていない」事を理解した上で開発・実装を行わないと、

システムの突然のダウン
トランザクションの一定量の超過から突然パフォーマンスが落ちる。
アプリケーション機能のデバッグだけで不具合が解消されない
システム間・サブシステム間でのインターフェースに不整合が多い
アプリケーションのコードが冗長で重複が多い

等の不具合に見舞われる。

2010/09/20

ソフトウェア開発を、労働集約的な肉体労働から知識労働へ転換しようと啓蒙している書籍です。
著者は、UMLやオブジェクト指向導入の教育・コンサルテーションで著名な荒井玲子さん。
この本自体は、過去に出版した書籍をまとめてリライトしたものだそうです。

私が特に興味をもったのが、UMLの導入に成功する企業の特徴を書いている章。
成功する企業の特徴は、新しい技術を導入する目的がはっきりしていて、自分のビジネスの強みを活かすために活用している企業だといいます。
その逆の場合、何でもいいからできたらいいという姿勢で望むと、目的がはっきりせず、現状に対して適切な対応ができず、効果が得られないという事例が多くなるといいます。

これは企業の話ですが、著者が言っている知識労働を行うべき一技術者に対しても同じことが言えるんだろうなと思います。
時間は有限である以上、目的をもって物事に取り組むことがなにより重要だと言えます。