Zenn
📝

XP入門3

2024/10/23に公開
アジャイル
xp
エクストリームプログラミング
idea

前回までの振り返り

第1章~第16章は実践的な内容で、XP (エクストリームプログラミング)における開発手法や考え方について学びました。

今回の内容

今回は17~25章を読み進め、XP の哲学や歴史的な背景について学びました。
その中でも印象的だった章についてまとめていきます。

エクストリームプログラミング / ケント・ベック 著

テイラー主義とソフトウェア

  • 世界初の生産技術者である、フレドリック・テイラーという人物について。
    • 工場の生産性を飛躍的に向上させる、科学的管理法を提唱した。
    • これが「テイラー主義」と呼ばれており、技術的、社会的、経済的に影響を与えた。
  • テイラー主義には好ましい効果もあるが、いくつか深刻な欠点もある。これらの欠点は、以下の3つの単純化された仮定によるもの。
    • 通常、物事は計画通りに進む。
    • 局所最適化は、全体最適化につながる。
    • 人はほぼ代替可能であり、何をすべきかを指示する必要がある。
  • テイラー主義によるソーシャルエンジニアリングの手順。
    • その1
      • 計画立案と実行作業の分離。
      • 作業方法や作業期間を決定するのは、教育を受けたエンジニアである。
      • 作業者は、与えられた仕事を、与えられた方法で、与えられた時間内に、忠実に実行しなければいけない。
      • 権限のある人が他人の作業の見積もりを作成したり、変更したりする。
    • その2
      • 独立した品質管理部門の設置。
      • テイラーは品質管理部門を設置することで、作業者に適度なペースかつ規定の方法で作業させるようにして、適切な品質レベルを保った。
      • 多くのソフトウェア開発組織は、品質部門を別に設置しているという意味で、まぎれもなくテイラー主義
      • 品質部門を別にすれば、エンジニアリングにおける品質の重要性が、マーケティングや営業における品質と同等だというメッセージを送ることになる。
      • エンジニアリングで品質に責任を持つ人がいなくなる。
  • テイラー主義は生産性を向上させる一方で、ソフトウェア開発のような複雑で創造性を必要とする分野には適していない。
    • ソフトウェア開発においては、個々のエンジニアの能力を最大限に引き出し、チーム間のコミュニケーションを促進するような柔軟な開発体制が求められる。

トヨタ生産方式

  • トヨタは最も利益性の高い自動車メーカーのひとつ。
    • その理由は無理をしているからではない。
    • 車を製造するプロセスのすべての工程で、無駄な労力を削減しているから。
    • 無駄を十分に排除すれば、単に速く進もうとするよりも、ずっと速く進むことができる。
  • 従来と異なる仕事の社会構造が、トヨタの成功には絶対不可欠。
    • 全ての作業者が、生産ライン全体に責任を持つ。
    • 欠陥を見つけたら、紐を引っ張ってラインを止める。
    • そしてラインの全員で問題の根本原因を発見し、それを修正する。
    • 「ラインの最後」で品質に責任を持つ人がいる大量生産ラインとは異なり、後工程の品質保証が必要ないくらいにラインの品質を保つのが TPS (Toyota Production System)。
  • TPS では、作業者個人が作業のやり方や改善について多くの意見を述べる。
    • 無駄は改善イベントで削減していく。
    • まずは作業者が無駄(品質問題や非効率)の源泉を特定する。
    • そして率先して問題を分析して、実験して、その結果を標準化する。
  • TPS では、テイラー主義の工場で見られた厳格な社会的成層が排除されている。
    • 日常的なメンテナンスはエリート階級の技術者ではなく、普通の作業者が行っている。
    • 独立した品質部門は存在しない。組織全体が品質部門。
  • 最大の無駄は「つくりすぎの無駄」
    • 何かを作り、それが売れないとなると、作った労力の行き場がない。
    • 生産ラインで何かを作り、それをすぐに使わないとなると、情報のバリューが消えてしまう。保管コストもかかってしまう。
  • ソフトウェア開発には「つくりすぎの無駄」が満ち溢れている。
    • すぐに陳腐化する分厚い要求文書。
    • 全く使われない精巧なアーキテクチャ。
    • 数ヶ月も放置され、インテグレーション、テスト、本番環境での実行が全くされないコード。
    • 不適切で誤解を招くようになるまで誰にも読まれないドキュメント。
  • 無駄を排除するためには、アウトプットをすぐに利用する必要がある。
    • 要件収集を改善するには、要件収集のプロセスを念入りに行うのではなく、詳細な要件の作成とソフトウェアのデプロイの間隔を短縮すればいい。
    • すぐに利用するのであれば、要件収集は静的なドキュメントを作成するフェーズではなく、開発で必要になった詳細な情報を作り出す機会になる。
  • TPS の考え方は、ソフトウェア開発にも多くの共通点がある。
    • 特に「無駄の排除」という点で深い繋がりがある

時を超えたプログラミングの道

  • クリストファー・アレグザンダーという建築家について。
    • アレグザンダーは、建築家の自己中心的な関心事は、施主の関心事と一致していないと指摘した。
    • 建築家は仕事をすぐに終わらせて、賞を獲得したいと思っているが、重要な情報を見逃している。
    • それは、施主がどのような生活をしたいかという情報。
    • ソフトウェア開発においても、エンジニアの利益や技術的な興味事項ばかりに注目し、ユーザーのニーズを見落としてしまうことがある。
  • 筆者が育ったシリコンバレーではエンジニアリングが王様だった。
    • 「あなたに必要なものを与えよう。必要かどうかは知らなくても構わない」がモットーだった。
    • このようにして作られたソフトウェアは、技術的には優れていたが、役に立たないものが多かった。
  • 経験を積んでいくと、正反対の不均衡を目にするようになった。
    • ビジネスの関心ごとが開発を支配する世界。
    • ビジネス上の理由だけで期日やスコープを設定すると、チームの誠実性を維持できない。
  • 高みに到達することが目的であれば、ソフトウェア開発は「プログラマーとその他大勢」で成立するものではない。
    • 関係者全員の関心事のバランスがとれていなければ、開発に貢献できない人が出てくる。
  • XP の成功は、信頼できるソフトウェアのすばやい見積もり、実装、デプロイができる優秀なプログラマーの増加にかかっている。
    • このようなプログラマーがいれば、チームのビジネス担当者に意思決定を任せることができるはず。
  • ツールや技法は何度も変化するが、大きく変化するわけではない。
    • 一方、人はゆっくりとだが、深く変化する。
    • XP の課題は、このような深い変化を促し、個人の価値と相互の人間関係を新しいものにして、ソフトウェア業界に次の50年間の居場所を用意すること。

コミュニティーと XP

  • サポートしてくれるコミュニティーの存在は、ソフトウェア開発の偉大な資産である。
    • 自分に共感してくれる人を見つけたり、誰かの声に自分の耳を傾けたりする絶好の場。
    • 人と人との関係は、安全に実験ができる安定した場を提供してくれる。
  • コミュニティーでは、自分から話すよりも耳を傾けるスキルの方が重要。
  • コミュニティーは一緒に勉強する場にもなる。
    • XP には、練習が必要なスキルも数多く含まれている。
  • コミュニティーは説明責任の場でもある。
    • コミュニティーでは、自分の発言に責任を持たなければいけない。
    • 説明責任を果たすためにも、コミュニティーには安全性が必要である。
    • 相手の秘密を大切にしたり、求められたときにだけアドバイスしたり、よく考えてから判断したりすることは、すべてが安全性につながっている。
  • コミュニティーは質問や疑問を投げかける場でもある。
    • コミュニティーには、個人の意見が重要である。
    • 衝突や意見の不一致は、共に学習するための下地となる。
    • 衝突を抑え込んでしまうのは、コミュニティーが弱い証拠。
    • 本当に重要なアイデアならば、そのようなことで重要性が失われることはない。
    • 常に意見を一致させる必要はない。お互いをリスペクトしながら、意見の不一致に対応すればいい。

今回のまとめ

  • テイラー主義
    • 専門化することで作業時間を短縮し、生産性を向上させ、品質の安定化を図る
    • 管理者と労働者を明確に分離する
  • トヨタ生産方式
    • 過剰生産や加工の「無駄」を排除することで、生産性を向上させる
    • すべての作業者が品質管理に責任を持つ
  • XP
    • 顧客と密なコミュニケーションをとることで、期待とのズレを生じにくくし、生産性を向上させる
    • ペアプログラミングを行いコードの品質向上や知識共有を行う
    • 信頼関係を重要視し、チーム全体で協力して問題を解決する

例えば XP のペアプログラミングは、一人当たりの労働時間を短縮し、生産性を向上させようとするテイラー主義では考えられない手法だと思います。
チーム全体で取り組む点と、管理者と労働者を明確に分離する点も対照的です。

また XP とトヨタ生産方式を比較すると、どちらもチームワークを重要視し、個人の能力を超えた成果を目指している点は共通しているように思います。

まとめると、工場生産が中心だった産業革命時代から、コンピューターの発明とインターネットの普及により、ソフトウェア開発が登場した時代に合わせて、生産性を向上させるための手法が変化してきたと言えそうです。
そしてその手法は徐々に、人間性やコミュニケーションを重要視するようになってきており、XP はその流れの中で生まれたものだと感じました。
どの手法も無駄を排除することで生産性を向上させようという点では共通しているように思いますが、歴史的背景を知ることで、何を重視して現在のプラクティスが生まれたのか理解し、より効果的な取り組みを行えそうです。

本書を読み終えて

今回で「エクストリームプログラミング」を読み終えました。
ソフトウェア開発は、単なる技術的な作業ではなく、人々が協力して行う創造的な活動であるということを改めて感じました。
本書でも触れられていたのですが、XP は問題解決に取り組むための新しい文脈であり、それ自体では問題を解決するものではありません。
アジャイルが健全に回るように、これからも継続的な学習・改善を行っていきたいと思います。

Discussion