読者へ:
ソフトウェア開発の専門家は誰でも、このアーティクルに関心があるであろうが、特にマネージャ、CIO、ソフトウェアアーキテクトは、特に関心をもつであろう。この話題は、多くの人にとって意見がわかれるところであるが、アジャイルのうねりのなかで、大きくなるつつある問題への洞察として、この記事を提供する。
“なぜあなたはここにいるの？ アジャイルではマネージャは不要だ。”
このような言葉を聞いたことがあるだろうか？あなたの地位は存在すべきでない、あたかも、その地位を作るためにマネージャは仕事をしているかのように開発者に思われていると聞いたらどれだけショックか想像してみよう。このような思いは、ほとんどの場合、プロジェクトマネージャが、ともに働く開発チームに初めて会う際にぶつけられる。確かにオリジナルのアジャイルマニフェストはプロジェクトマネジメントに関して一切言及しておらず、その後のアジャイル理論家もその考えを進めて、プロジェクトマネージャの役割はコーチやサポート的な役割であると考えている。
しかしこの見方は、現実を無視している。
小規模なインテグレーションのない独立した開発プロジェクトに、有能で経験を積んで能力のあるチームが取り組むのであれば、確かにどんな種類の管理もほとんど必要ないだろう。しかし、プロジェクトの期間がより長くなり、インテグレーションがより必要なプロジェクトでは、開発がプロジェクトの中心となることは少なくなる。調整やコミュニケーション、全体の作業を率いるためにプロジェクトマネージャがより必要となる。開発の割合が、全予算のわずか10％のプロジェクトでは、スクラムマスターが開発を率いることはできるだろうが、プロジェクトマネージャに報告する必要がある。
さらに開発チームは、予算を管理することを意識していなかったり、得意でなかったりすることが大半だ。ソフトウェアを開発するのに時間が必要なので、その他のことに費やす時間は限られる。これによって、開発者の中には、自分たちが行っていることがプロジェクトであり、その他のすべては些末なうっとうしい事だと信じるものもでてくる。
ここに見られる悪い態度は、他の役割や専門家が価値を持っていることを理解できず、現実に沿った形で柔軟性をもつ必要性を認識せずに、哲学的な解釈に固執することだ。極端に言うと、この態度はすべての場面のすべてのマネージャにまでこの見方をひろげると労働主義者や、新共産主義者とほとんど同じものなのだ。確かにすべての企業文化や組織階層をフラットに無限定にすべきだという考えを採用する人々は急進的である。この見方は表層的ではあるが、このような考え方をもった人が(リーダーのように)権限のある人であるとすると、この人の考えは勢いをまし、開発チームとマネージャの関係を悪化させることもありえる。プロジェクトの完結という目的が、マネジメントと労働者の階級闘争に置き換わってしまうのだ。
“マネージャでなく、チームがプロジェクトを動かしているのだ。何を済ませるかは私たちで決定する。”
この考え方は、マネジメントの役割はもはや必要ないという考えの副産物として生じることが多い。これは真実を無視している。多くの決定には、会社の多くの部門や個人の協調を必要とするのだ。開発チームだけでは決定はできないのだ。ソフトウェアの設計やアーキテクチャでさえ。
このような考えをもつ開発者が単にプロジェクトに別の側面が存在することを認識していないだけの場合もある。さらに悪い場合には、開発者が過去に悪い経験を体験しており、目に見える破綻が起こる前にプロジェクトを「制御」しなけれならないと感じていることもある。
常にではなくても多くの場合、開発チームの上に管理階層を置くことは意味がなく、成果への貢献からすぐに除外すべきだという態度に対して、アジャイルは口実や考え方の基礎となってしまっている。このような態度をそのままにしておくと、私の経験上、終わりのないアーキテクチャの再構築セッションや予算超過、意味を持たない期日、自分たちのミッションに対して幻滅した感情的なチームの崩壊などにつながる。
“アジャイルには締め切りもスケジュールも存在しない”
資本予算や企業会計について深い知識を持っている人であれば、この考えがいかにばかげているかを理解できるであろう。しかし、Ken Schwaber氏のスクラム本を読んだことがあれば、その本がガントチャートを禁止しており、チャートを捨て去るように主張していることに気がつくであろう。実際のところ、チャートを捨て去ることは巧妙でよく考えられた革新的なアイデアなのだが、このことをデリバリのスケジュールが存在しない、つまり予算がつきることはないと解釈する人たちもいるのだ。
これは私にとって痛みのともなう経験だった。実力がありカリスマ的な技術リーダ(チームの全員は彼に報告していた)に率いられたチームが、「仕掛かり中の製品」を顧客に提供するために時間ベースの目標をもつことを禁止するのを目にした。時間の制約がなくなり、チームはめちゃくちゃな方向に暴走した。労働倫理は低下、もしくは全くなくなった。製品を成功させたいと望む人々はモチベーションとやる気を失った。機能や製品変更要求はどこかにいってしまうのに、なぜ種々の技術上のアーキテクチャにこんなに重点が置かれるのか、顧客は途方にくれてしまった。チャートを使わなかったことで、ますます顧客は混乱した。顧客が本当に知りたかったことは、いつ製品が完成するのかということだった。チームは、「スケジュール通りに進んでいない。完成するまで開発し続ける」と回答するだけだった。
現実的なゴールを誰かが設定しようとすると、「反アジャイル」だということで即座に打ちのめされた。プロジェクトが救いのないほど予算超過だとチームが告げられたとき、彼らの目は暗くなり、混乱して見えた。彼らがやってきたことと、時間、究極的にはお金の間の関係は、ホワイトボードに書かれた抽象的なデザインパターンの中に消えてしまったのだ。
現実的には、明示的にであれ、暗黙的にであれ、常に締め切りとスケジュールは存在する。完成することがない開発プロジェクトには誰もお金をださない。さらに現実的にいうと、ガントチャートは、複雑なインテグレーションや開発以外の側面をアジャイルチームとアジャイルを利用しないチームの間で調整するには、非常に有益だと私は感じている。
スケジュールが存在しないという態度は、予算がつきるまでプロジェクトは新規機能を追加しつづけるべきだという考え方がアジャイルのテクニックから生み出されていることに起因するのであろう。この考え方は、空想上のものであり、開発チームが予算内で最低限の機能も実装できずにアプリケーションが役に立たないものになった時に何がおこるかを無視している。この考え方の悪いところは、チームの進捗や責任を監視する新しいテクニックを、製品のデリバリに責任を持たない理由にねじ曲げてしまっていることだ。
“アジャイルのコードは、それ自身がドキュメントである。アーキテクチャダイアグラムや技術仕様書は必要ない。
もしあなたがソフトウェア・アーキテクトか技術マネージャであるならば、この態度はあなたを驚かせるだろう。この薄くベールに包まれた攻撃は、あなたの役割や経験、企業の売り上げの78％を生み出している2800万行のソフトウェアプログラムの技術上の設計を調整する人間の必要性に対して攻撃を仕掛けている。
確かに、この考えは無知に起因することが多い。おそらく、その開発者が最近開発した2000行のWebアプリケーションは、ソースコード以外の成果物をほとんど要求されず、スケールすることが重要だったのだろう。あなたや、あなたのマネージャはこのことがわかっているが、この態度は、スクラムのような今時の開発テクニックではあなたの役割は時代遅れだと決めつけるのだ。主要なソフトウェアシステムは、数人の頭脳が技術上のビジョンを指示、調整し、数百人の手がそれを実装することを要求する。
私の経験からいうと、この態度は、皮肉にもアーキテクチャチームの一員になりたいという開発者から発生することが多い。技術リーダーを批判し、議論することで、自身のアジャイル・テクニックの知識を紹介し、一目おかれて、熱望するアーキテクトの一員となりたいのだ。望みと反して、鬱陶しい、トラブルメーカーと見れらるようになるのだが。さらに、彼のアジャイルの考え方の紹介の仕方に戦略がなかったことにより、シニアな技術リーダがアジャイルといえば何でも印象がよくないものになってしまうのだ。
“アジャイルは変更を迅速に取り入れる。どんな変更でもだ。”
この態度は、私の経験上、開発者ではなくマネージャが取りがちなものだ。変更を迅速に取り入れるという文言をどんな種類の変更でも受け入れることを意味すると読んでしまったことに、この態度は起因する。元々のアジャイルの起案者は業務上の要求に限定していたのにもかかわらずだ。従って、根本的なアーキテクチャ上の変更が普通のものとなり、オープンソース技術を他のオープンソースに入れ替えることがよいことだと考えられるようになる。これらの変更により、チームのスキルセットからかけ離れたものとなり、プロジェクトの完成が数ヶ月遅れるにもかかわらずだ。組織上の実験や急な人の出入りも「迅速に変化を受け入れる」一部となる。その結果は大混乱となる。
明らかに顧客から提示された変更は重要だ。しかし変更を管理する仕組みがなければ、トラブルを求めているだけになるだろう。すべての要求とプロジェクトの完了への影響を管理し続ける必要があり、それをもとに顧客と会話を進めるのだ。これは効率よくプロジェクトでの決定をくだすために必要だ。もしこれを怠れば、顧客は要求すれば、すべての要求が取り入れられるという非現実的な考えを持つようになる。その結果どのような事態になるかはおわかりだろう。
従って、ここでみられる悪い態度とは、管理することなく変更を受け入れることだ。完全にすべてを自由にすることは、希望を打ち砕き、期待に添えない結果となるだろう。変更はよいことだ、しかし乱暴な変更は混沌を生む。
“アジャイルはジェネラリストを利用する。自分のソフトウェアは自身でテストする。品質管理グループは必要ない。”
哲学的な解釈からいうと、この見方も正確だ。しかし私の経験、とくに大規模なソフトウェア開発プロジェクトでの経験からいうと、開発者か開発したもの、およびそれがどのように動作するのかを確認するためにもう一組の目が必要なのだ。作品に対するプライドはすばらしく、促進されるべきものだが、時折、プライドは盲目的な受け入れおよび保身に変わりえる。強くて本当に正直な人が自身の限界に気がつき、それを軽減する方法を発見することになるのだ。
ジェネラリストを利用するという言葉は、複数のスキルをもった個人からなる俊敏なグループが配属されていることを強調する。それを反映すると、ソフトウェア開発は職人技であり、製品の組み立てでないということになる。しかし、ソフトウェア開発のリーダとしては、人が完全であることを想定することや、事実を無視することはできない。リスクとそれに対する計画を用意しておくことが賢明であり、、開発者はすべての自分の間違いを見つけることができないということを歴史が証明している。
私の経験では、この考え方を持つ人は、自分のコードを他のだれかにテストされることを嫌い、建設的な批判にカッとなる人たちだ。もう一つの具体的な理由は、開発者がコーディングが得意でないというものだ。彼はトレーニングを受け、助言をうけて数ヶ月格闘した結果、自身があやまったキャリアパスを選らんだことがはっきりしたのだ。
従って、ジェネラリストを利用することはすばらしい、しかし、哲学的な純粋さに賛同して、数十年の確かな真実を無視すれば、この考え方は腐ったものとなるだろう。
まとめ
結論としては、これらの問題はアジャイル以前の世界にも同じようににみられたものだ。しかし、私の経験からいうと、これらの悪い態度は、隠れ場所と正当化の論拠を、それ自身ではおそらくそのような主張をすることは全くなかった新しいテクニックのなかに見つけるのだ。彼らがアジャイル方法論を牛耳って、よい動きに陰を落とすようになるまでに、ソフトウェア開発リーダとして、これらの見方に対応することは必須である。アジャイルは、すばらしいメッセージをもっている。単純さ、製品開発に顧客を参加させること、オーナーシップをもつこと、そして常につながっていること。これらのメッセージが失われるのを見るのはとても残念だ。あなたはどのように考えるだろうか？あなたの職場では、このような態度は見られるだろうか？どのように、これらに対処するだろうか？皆さんの意見を聞かせてほしい。
著者について
Christopher R. Goldsbury氏は、キャリアのなかで開発者、アーキテクト、スクラムマスタ、開発マネージャ、プロジェクトマネージャ、そして品質管理マネージャの役割を経験したソフトウェア開発の専門家です。Chris氏は、自身の経験やアイデアをブログに書いています。