説明が必要なのはアジャイルじゃなくて、従来の開発手法の方じゃないだろうか

Agile Japan 2017の社内サテライトイベントに参加しました。そこで考えたことを書きます。これは僕の認知と想像（創造）を書いていることで、検証された事実というわけではないことを先に断っておきます。

• 組織には長くに渡って執り行ってきた開発手法・ルールがある
• 知見が蓄積されている
• ただし全体的に古い傾向
• 開発実働は外注することが多かったので、外注管理的なマネジメントの知見に偏っている傾向がある
• 計画通りでないことを発見して、なんとかしてくださいよと注文する、ということはできる
• 新しいツールや技法をうまく使いこなすための知見があまり含まれていない
• 理解して実践できるようになるための情報が弱い
• チェックリストのような形で、形式的には文書化されている
• だがパターンのような形で、背景や理由まで書き残されているわけではない

• ウォーターフォールと、それを失敗させないための工夫に関する知見は、よくて組織、たいていは個人に暗黙知として蓄積している
• それらの共同化、表出化はあまり行われていない
• 対してアジャイル手法については、解説書やWeb記事などの情報が（少なくともウォーターフォールより）多くある
• コミュニティーイベントや勉強会などで、経験者と対話して学ぶことも可能

• 新しいメンバーにとっては、ウォーターフォールはよくわからなくて、アジャイルは（実戦経験はないか少ないにしてもまだ）わかる
• 中堅メンバーにとっては、ウォーターフォールベースの社内開発手法・ルールは、それなりに共通言語ではあるし使うことはやぶさかではないが、よくわからないところ、冗長だったりもはや古くて無駄に思えるところがあったり、いろいろやりにくいと感じることが多々ある
• アジャイルで行う方が自然と思われるけれど、会社ではウォーターフォール
• 社内のアジャイルカンファレンス（講演や事例紹介など）に参加した
• 社内開発手法・ルールの要件にアジャイルを合わせる方法が、苦労した点やポイントとして語られる
• 質疑応答で、「この説明を聞いてもなぜアジャイルで品質（あるいは別のなにか）が確保できるのかわからない。ウォーターフォールでよいじゃないか」という（多分古参の人の）発言がでる
• よくわからなくなる

• 説明と共有が必要なのは、従来のウォーターフォール型手法とルールなのではないか
• なんのため、前提や制約はなに、今でも有効なのか、問題点
• それなしには、続けることだってできない（やりにくい）のではないか