アジャイル宣言を思索と思考の順番

以前から
特にQA系の勉強会に出ると
アジャイル思想やフレームワークについて
触れたり考えたりする勉強会が多かったんですが(私が参加していた勉強会がたまたまだったのかもしれませんが。)
最近はどこの勉強会行っても「アジャイル」について考えよう・実践してみよう
みたいな流れがありますね。

ちなみにうちの会社内でも同様です。

アジャイル宣言については以前ブログエントリを書いたので、概要についてははしょりますが、
最近は「アジャイル」よりも「スクラム」の方が一人歩きしてバズってる雰囲気を感じます。
以外とスクラムフレームワークについては理解めっちゃ深くても、
いざ「アジャイル」となると特に信念ない、ばっくりスクラムと混同した思想をもっていて、
会話していると「あれ?私今アジャイル宣言のこの部分ってどうお考えですか?」とディベートスタートさせたはずなのにこの人スクラムの話してるな・・・
とか
あるわけです。
アジャイルの勉強会に行っても。

たしかにアジャイル宣言に書かれている内容はとても簡素で、シンプルで、短い。
それだけでは曖昧な部分が多すぎて、実際に開発を進めるには大変な 難がある。
というかアジャイル宣言だけでは開発チームを動かすことができない。
だからアジャイルフレームワークと呼ばれるスクラムやリーンやkanban(ツールとしてのかんばんと区別するためにここではkanbanと表記することにしますね!)
が存在し、
各フレームワークの中でもう少しブレイクダウンした規約やルールを用意しています。
各フレームワークの中で定められたルールは当然正しく守られる必要があり、
さらにいうと実際に5人10人とチーム規模が拡大すればするほどフレームワークで定められた哲学だけではルールが不足したり破綻したりするものなので、
各プロジェクトに合わせたフレームワークのチューニングやルールの再定義が必要になるのだと思います。
アジャイル宣言もアジャイルフレームワークも、
こういったフレームワークチューニングやルールの再定義については特に言及されていませんので
「チーム全員の中できちんと協議が行われ、合意がとれているのであれば」
推進されるものなのだ、と思っています。

私個人的には、

アジャイル宣言の中でもっとも大事なことは

  • 誰か一人の専制政治(独裁政治の場合もあるかもしれません)的な合意で決まったルールチューニングでは絶対に動かない(運用しきれない)
  • アジャイルチーム 内すべてのメンバーが「対等」に「お互いの立場を尊重して」疑問や不信に思ったことを協議へ運ぶこと・協議の場をチームとして確保すること
  • 言葉の定義もしくは規約の定義に疑問がある場合は徹底的にチームで意識のすり合わせを行うこと

なんじゃないかなと思っています。
都度協議を挟むことでアジャイルの醍醐味である短期納期を達成できないではないか、
と思うかもしれませんが、
そもそも疑問や合意が取れていないチームで「自己組織化」を目指すアジャイルシステムを採用できるのでしょうか。
私の意見としてはNoです。
もし言葉の定義の揃わない団体にアジャイルを導入するのであれば、

  1. まずはプロジェクト人数を減らし
  2. チーム内の合意や都度協議を「しやすく」する

環境を作ること、協議や疑問を持つことはタスク消化を妨げるものではないことを習慣づけることの方が優先です。
個人的な意見としては、
アジャイル宣言もしくはアジャイルフレームワークを取り入れる場合は「とにかくアジャイルと呼ばれる定義をがむしゃらにすべて取り入れてみる」ことよりも
「段階的にできることから、取り入れ、できていないことは順番に思想から思考から浸透させていく」ことが先決だと学びました。
これは社内のチームにスクラムを取り入れてみようとした時に得た実教訓です。
人数が増えるほど、「とりあえずやってみる」の前に「まずは全体合意と明示」が必要なのだと思っています。
まずは漠然でもよいので「全体合意」と「明示」を行ってから、「とりあえずやってみる」をしてみたほうが意外にうまくいく場合もあるということです。

誤解しないでいただきたいことは、
あくまでアジャイル思想を取り入れる時に重要なのは
「今取り入れようとしているチームにアジャイルを導入するためにはどの順番で取り入れるべきなのか」
という採用順番から考える必要がある、ということであり、
「まず手をうごかしてみよう!」というthe エンジニア的なやり方を否定するものではありません。

私自身が今困っていることとしては
日々割り込みタスクが膨大に発生する”運用”というチームにおいて、

  • 何かうまく採用できるフレームワークはないものか
  • フレームワークが相性悪いのであれば、アジャイル宣言をどのようにして達成するべきなのか、プランと方針を決めるのか

ということを決められるほどフレームワークについて種類数と本質を理解できていないということです。
スクラムについては社内ですでに運用しているチームもあり、スクラムマスターの称号を持っている先輩たちもいるので情報がありますが、他のフレームワークについての知見や知識がスクラムに対して圧倒的に少ないことも起因しているのかもしれません。

現在私が働いているチームでは、正直な所「アジャイルフレームワーク」は導入できていません。
これはうまく運用できそうなフレームワークにまだ出会えていないから、という理由です。
ただし、少しでも「アジャイル宣言」の思想に近づけるよう、
かなりのローカルルールではありますが、
都度チームで合意を取りつつアジャイル思想に則った運営をするべく日々奮闘中です。
スクラムももちろんですが、その他のフレームワークの知見を持ってる方や、良い本を知ってる方がいらっしゃればぜひぜひ!おしえてやってください!!

こっからは超個人的な話ですが、
こういう、「アジャイル宣言」そのものの読み解きや思想解釈、
「アジャイルフレームワーク」の中でどのルールがどのアジャイル宣言に対応しているのか、
そのフレームワークの思想はどんなプロジェクトを対象としているのか、など
パンっっと明示された文章に対しての咀嚼や思想協議、ディベートをしてある程度の方向性をつかんでいく、
というこの作業が今までの社会人史上一番楽しい命題かもしれない、とか思ってる今日この頃。
答えがない世界で、ワザと合意ではなく反対意見へたってディベートを始める瞬間ほど恍惚なものはないわけです。
だって
その分今のチームで持ってなかった視野の方向性を得られるかもしれないんですから。
どんなにイラつかれようと、文脈に疑問をもったり、単語の定義に差異を感じたら、きちんと質問して疑問を払拭するべきだと思います。
でないといつまでも平行線で、互いの思想の理解などできません。

逆をいえば、「質問できない」「差異に気づかない」「知らないこと知らない」まま一人で解決しようとすると、大事件になった時点で”どうしてこんなのもわかならいの”となってしまうのです。
そう・・・わたしが・・・それ・・・
毎度都度反省の波に襲われますが、
そもそも「知らないことに気づいていない」のですから、これを自分自身で気づいて対処するのはほぼ無理ゲーです。
これを解消するために事前に日頃から
「どんなくだらないことでも嘲笑されることなく、イラつかれることなく、呆れられることなく質問できる人間関係を構築しておく」ということは、人間社会で、特に大事なことだと思いました。
これはここ1年位のわたしの最大の課題です。
チームやはたまた会社全体を動かさなければ解消できない課題ですから、動かなくてはならないことは細かく膨大です。
それでもやり遂げなければ上記のような環境を得ることは、ずっとずっとないでしょう。
コミュ障なわたしの一大プロジェクトです。

長々と書きましたが、
以下まとめ。

  • アジャイルフレームワークも大事だけど、その前にアジャイル宣言について語ろうぜ。
  • アジャイルフレームワークって万能じゃないけど柔軟で優秀なんだぜ。
  • アジャイルフレームワークに詳しい方、各種フレームワークについて、まあやさんに教えてやってください!おねがいします!
  • みんなで「知らないことに気づかない」という最大の命題を軽減できるような人間関係作っていこうぜ!(職場環境ではなく人間関係なのがポイントです)

そのための助言ください!おねがいします!

広告

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中