長瀬嘉秀のレビュー一覧
-
-
Posted by ブクログ
マーチン・ファウラー氏による業務向けアプリケーションを構築するために使われるパターン集。ってここまで書いてみて思ったんだが、そもそも業務向けアプリケーションってなんだろうね。
ベストプラクティスでもないし、サンプルコード（JavaもしくはC#）がそのまま打てば動くようなものでもない。というわけなので、「明日使えるコーディング例がここに」って感じではない。読み方としては、ここで書かれている内容を読み手の経験をベースにそれぞれ語り合うっていうのがいい気がする。一人で読み進めるのであれば、一旦全部をざっと通して読んでそこから詳細を読んでいく感じかなと思う。
書かれている内容は難解。日本語訳がこなれていないという声もよく聞くけど、元の英文も難解なので、こればっかりはしょうがない。
書かれた時期が時期だけに、内容がちょっと古いという点もあるけど、著者の先見性が所々に垣間見えたりするし、そんなに技術的な流行に流される内容ばかりではない。コーディング技術よりも一歩下のレイヤーの部分が書かれている。その分、分かりにくいところはあるんだけれども、繰り返し読んでいけば分かってくる気がする（自分もそうありたい）。
というわけで、アプリケーションを設計・実装するソフトウェア技術者なら読んでおいて損はないかなと思って星5つ。 -
Posted by ブクログ
SI業態(ウォーターフォール開発を主とする企業)に向けたアジャイル導入本。普段ウォーターフォール型開発に携わっており、プロジェクトを計画・リードするポジションのPM/SEにオススメできる良書。
本書では、日本のSI事情を考慮したウォーターフォール + アジャイル型（ハイブリットアジャイル）がまとめられており、アジャイルプラクティスを取り入れるかは別として、様々な点が参考になる。(TDD/CIの効果など)
前半で開発手法に関する説明が一通り行われ、その後に関西電力の中規模開発(20人月くらい？)における実例が記載されており、実際の運用がイメージしやすい。
全体を通して感じられるのは、アジャイルプラクティスに対する理解と、理解の上で計画/実践することの大切さ。
大規模SIでは契約形態等で問題になることが多いが、ハイブリッドアジャイルの場合、ベンダ側の知識レベルやコントロールの方が重要に思える。
例えばTDDを採用する場合、テストコードの妥当性をチェックする必要があり、また、CIを採用する場合には、CIを実現するための実務経験が必要である。
これまで伝統的なシステム開発を行ってきた会社にとっては、実施の妥当性が大きな壁になるだろう。（そこに投資できるかどうかが、企業体質を改善できるかどうかの差になると思われる） -
-
Posted by ブクログ
大規模システム開発にアジャイルを適用する一例として関西電力の例を挙げ、WFとの融合を図る。
一般的なアジャイルで用いられる手法の紹介もあり。
日本の大企業でよくある、委託開発に対応するため
WFの上流設計以前＆統合テスト以降はWFのまま、
詳細設計～実装～結合テストはアジャイルを適用する
【再認識】
・アジャイルに向いているのは、
上流～下流まで自社開発
スキルのある人材
ツール環境構築
【気づき】
・アジャイルは手段であり、目的ではない
目的はプロセス改善による品質＆生産性向上
・テスト駆動開発を適用すると、単体テストの品質指標が使えない→カバレッジで評価
・アジャイル導入の改善効果を予測する
→改善効果がないなら、適用は無意味
・イテレーション開発時、計画に2日ほど割き
タスク分割を行うが、このタスク管理するには
機能を詳細まで検討しておかなければならない。
とりあえず作り始める、はNGで
計画をしっかり立てることが重要という
アジャイルの一般的な感覚とは異なる
→むしろアジャイルこそ、計画が重要 -
Posted by ブクログ
名著『リファクタリング』でも有名なITエンジニアの巨匠マーチン・ファウラー氏が、エンタープライズアプリケーションの方式について書いた解説書。
ちなみに、エンタープライズアプリケーション≒業務アプリケーションのこと、と理解しています。
日本で業務アプリケーション開発をしているITエンジニアなら、書籍などから得たデザインパターンやテクニックを、結局のところ業務にどう適用すればいいのか、で悩んだ人も多いはず。
そこに踏み込んだ書籍は、自分の記憶にはほとんどなく、これらのいわゆるオブジェクト指向な業務システム開発を売りにして成長する企業もあるくらい、この部分は大事なノウハウだったわけです。
思い返せば、自分が社会人になって間もない10年位前がそんな時代でしょうか。
巨匠マーチン・ファウラー氏が「テクニックは使えてナンボ」と、ノウハウの囲い込みよりも、ITエンジニア発展のためにと踏み込んでくれた書籍が、この解説書だということになるのでしょう。
違ってたらすいません。
で、改めて読ませていただきました。
現在では、各企業に根付いていて、使いにくいと文句を言いながらも使いこなさざるを得ないてあろう「業務アプリケーションフレームワーク」。
これが隠蔽しているアーキテクチャの部分に対する内容がほとんどです。
まあ、そうなりますよね・・・。良いのか悪いのか、今は、アーキテクチャが分かってなくても、プログラム開発ができてしまう時代です。
ただ、解説の内容はとても良かったです。
「なぜ、このアーキテクチャはこうなってるんだろう」とか、漠然とは理解しているけど、まわりを説得させるほど上手くは説明できなかったようなことがしっかりと解説されてますし、何より「マーチン・ファウラーがそう言ってんだから間違いないでしょ」というキラーコメントで周りを説得できたりしますｗ
また、汎用的には決められない（正解がない）ことは、その考え方が示されてますし、ちゃんと読み込んで、中身をちゃんと腹に落とせば、血となり肉となる内容だと思いました。
業務アプリケーションフレームワーク自体を開発していたり、コアな部分の開発に携わっている方は、ぜひお奨めです。
ひとつ注意すべき点は、この書籍は、決してベストプラクティスでは無いということ。
サンプルソースまで付いているので、このままフレームワークとして使えそうな気がしますが、これは、ある条件、ある時点においての解であり、他の開発に当てはめる時は、このアーキテクチャを理解した上で、その条件、その時点の最適解を見つけないといけないということです。
あと最後に。
翻訳版の本書が、その側面で酷評されているのは承知です。そこは否定しません。
自分も置き換えられた日本語に違和感を感じる部分は多数ありました。英語ができるなら原文を読んだ方がいいのでしょうね。
それでも、アーキテクトとしてやっていくなら、ぜひ目を通したい書籍だと思いました。 -
-
-
-
-
-
-
-
-
-
Posted by ブクログ
【目的】 アジャイルの方法論やプラクティスを基にして、基幹システム開発などエンタープライズ領域におけるソフトウェア開発の「プロセス改善」の方法を伝える。
【収穫】 ハイブリッドアジャイルの方法論と、その概要を説明できるだけの理解が得られた。
【概要】 本書は、日本の諸事情を考慮しながら、アジャイルプロセスを導入するための解説と、実際の国内プロジェクトの実践報告の紹介の2部に分かれている。
[解説編のポイント]： 日本での大規模開発への導入においては、変更受け入れのルールや契約の仕方など考慮すべき事項が存在する。例えば、あらかじめ変更要望に対応するためにコストやスケジュールにゆとりを持たせることを合意したり、請負契約に限らず変更分は準委任契約とするなど工夫が必要。アジャイルプロセスの導入検討においては、まず現行プロセスの課題を明確にし、解決策と具体的な改善方法の検討、改善効果の予測、そして事後評価という手順を踏む。実際にプロジェクト計画を策定する場面では、管理方法やどのプラクティスを導入するかを決定する。進捗管理では、WBSとバーンダウンチャートを併用すると効果的。また必要最低限のドキュメントに抑えるなどして作業量を減らすが、アジャイルプロセス特有の作業も発生するため、その分は必ずスケジュールに含める。
[実践編のポイント]： 実際のプロジェクトでは、WFモデルの詳細設計・製造工程をアジャイル化するハイブリッドアジャイル方式を適用。イテレーション毎に発注側含めて仕様確認レビューを行い、変更要望を早期に発見。また、変更要望コストのゆとりを基本設計完了後の20%としてその枠内で完成。プラクティスは、チケット型タスク管理や、CI、TDD、ペアプロなどを導入。実績としては、タスク管理やCIのおかげでリスク低減につながった。また、変更要望を早期に取り入れることで、初回リリースからユーザー満足度の高いシステムを提供。一方課題としては、開発コストの低減と短期リリースの効果があまりあらわれなかった。
【感想】 具体的な大規模開発向けのアジャイル適用事例を知りたくて購入。WFかアジャイルかという単純な区分ではなく、プロジェクトにおいて重視する部分を明確にして、その目的に合った開発手法を取り入れようという考え方が参考になった。一方、本書で紹介されている事例では、複数チームでの開発実績はなく（体制の組み方などは紹介されているが）、オフショア先との分散開発時の管理手法など、個人的に気になる部分までは明確にされていなかったため、そこは今後に期待したい。
