こんにちは、あのぶるです。

チームでソフトウェア開発を行うとき、私たちはたくさんのツールを使って仕事をします。
そのツールの中には開発環境やライブラリのような有形(と言えるのか悩ましいところですが……)のものの他に、チームの運営方法や情報のまとめ方、設計手法と言ったある一定の様式を持った活動を指す「無形のツール」が存在します。
それらの必要性やアレンジの是非について定期的にSNS上で論争が起こっているのを見かけますが、今回はそのような意見についてどのように受け止めたらいいのかを一緒に考えていけたらと思います。

さて、個人的な意見を最初に述べてしまうと以下のとおりです。

  • ツールの「様式」を守ることそのものにはあまり意味がないことが多い
  • そのため、自分たちのチームにフィットするようにアレンジするのは全く問題ないと思う
  • ただし、そのツールの「様式」がどのような効果を期待してそうなっているのかを理解しないと、意味を保ったままアレンジすることはとても難しい
  • ツールを使いこなせないままアレンジした結果、効果がなくなってしまい「○○は役に立たない」と感じて・発信してしまうのは誰にとっても不幸でしかない

例えばプロジェクト運営手法の一つである「スクラム」を導入する目的は「チームの問題を明らかにすること」であり、よく解説で見かけるこの運営フローを守ること自体ではありません。


Creative Commons License
This work is licensed under a Creative Commons Attribution-NoDerivs 3.0 Unported License.

スクラムをよく理解している人であれば、もしかしたら一部のイベントを省略したり、よりチームに合ったツールに置き換えた上で正しくチームを運営することが出来るかもしれません。この場合の「正しい運営」とはフローの通り進行出来ていることではなく、先に述べた通りでチームの問題を炙り出せていることを示します。フローが崩れたことで発見出来る問題というのもあるはずなので、フローが守れなかったことが即スクラムの失敗を示す訳ではありません。
しかし、十分な理解に至らないままアレンジしてしまうとどうなるでしょうか。発生したトラブルがスクラムの運用に失敗しているからなのか、チームの課題を見つけることが出来たからなのか、区別が出来ないかもしれません。あるいは無意識的にチームの課題を庇うように運用を変えてしまい、何も進展がないままプロジェクトが終了してしまうかもしれません(これは課題を認識した上で一時的な対応として運用を変えるのとは全く別の意味を持ちます)。残念ながらこの場合はどちらもスクラムの運用に失敗していると言わざるを得ないでしょう。「型破り」と「形無し」とも表現される「技術を自分のものとした上で昇華出来ているかどうか」の差がまさにこれです。

一方、「何も考えずただその形に従う」というのはある意味とても楽なことですが、過去の記事でも述べてきた通り、それだけで良いのならコンピュータの方がずっと速く正確にこなせる分野でもあります。形に従うのは「いつもと違う」の違和感を受け取るアンテナを麻痺させないための対策であり、使うべきところでしっかり冴えた頭を使えるように、情報に溺れないための手段なのです。

ソフトウェア開発の歴史は短いですが、そのツールについての解説だけで1冊の分厚い本が出来るくらい「様式」として確立されているのであれば、相応に多くの人が実践と検証を繰り返して現在の形に到達しているはずです。一見無駄に見えても初めはそのまま実践してみることで、何がどのように作用して目的を達成しているのかが少しずつ見えてくるでしょう。基本をしっかり使いこなした先でよりよい形を見いだすことが出来たなら、そのときはぜひ胸を張って自分たちの成果を自慢して欲しいなと思います。

The following two tabs change content below.
Twitter のプロフィール

あのぶる

Software Engineer
杜の都で育ち、赤べこの街でコンピュータのいろはを学んだソフトウェアエンジニア。今はスマホゲームのためのWebAPIを作るお仕事をしています。最近はすっかりガルパンおじさん化。