Software engineering from east direction

六本木一丁目で働くソフトウェアエンジニアのブログ

アジャイル開発におけるメンタルヘルス 〜駆け出しアジャイル記録〜

TL;DR

  • アジャイル開発における「あるあるの失敗」は、コミュニケーションを一瞬でも取り逃すと発生しうる
  • どういうときに流れに飲み込まれ、メンタルの追い込みが発生しうるかを考えた
  • 何を主眼としているかを何度もコミュニケーションし、発生させてしまいかねない副作用を避ける、流れに飲み込まれないための施策が必要だろう

背景

所属企業で、かつてからのチーム開発の課題や、WORK FROM HOME な事情もあり、アジャイルムーブメントをに取り組んでいます。そのなかで、現職での取り組みを始めてざっと3ヶ月弱となり、教科書どおりには決していかない、自分たちにとって最適なものは何かを日々レトロスペクティブなどで探っている日々。そんな発展途上な段階の思考をdumpしてしまおうという記事。

上記資料については、プロジェクトをどう進めるかについては、説明していないが、チームの取り組み方を変えた後に、プロジェクトの取り組み方自体に対して、漸進的にリズムを作っていっている最中という状況。

以下、取り除いたほうが良さそうだと感じたリスクを感覚レベルの粗末な文章で書き連ねていく。

生産性を気にしていないか?それを主眼にしていなくても視界にはいることのリスク

前提:ストーリーポイントでの見積もり、消化ポイントをメトリクスに取ることによるベロシティ計測

見積もりの手法として、いくつか他PJでも採用されている「ストーリーポイント」を使用している。これは、だいたい3日でできるといった差込なしの作業に対する見積もり(理想日による見積もりとよく表現される)のではなく、それぞれのissueを相対評価大きさで図るもの。

たとえば、「注文完了時にメールを送信する」を1ptとしたら、「注文情報を表示する」は相対的にメール送信するよりもやること多いし、技術的にも触れるバリエーションが多いから3ptくらいかしら、的な形で相対評価で、そのタスクがはいるばけつはど〜れ?って考えるやり方といえる(と認識している)。

そして、それを1週間など一定期間でどれだけの大きささばけたか、を計測していくことで、自分たちが見積もりに対してどれだけの速度でさばけるかを、ベロシティとして認識する。平均速度のようなものなので、何らかそのメトリクスに下降傾向とかがあったら「あれ?どうしたのかな?体調が悪い?」といった形で図れるといった効果も期待される。

チームのメトリクスと見ても、個々人の生産性に"感じる"リスク

個人としてチームのメトリクス内で「どれだけの大きさ」できた?みたいなのが、意識内に入ってしまうところはある、だってにんげんだもの

これに対して、小さい組織の分にはコミュニケーションの中で「なぜいまこれをしているのか」について会話をすることで何らか対策が取れるだろうが、人数が増えると大変そう。やり方をフレームワークと捉えてしまうと、即座にフレームワークの罠に陥ってしまうだろう。「前職でやってたけどつらかった」といった話はこういった経験から生まれるのかもしれないですね。

今のところ考えること: 成果(WHAT)と取り組み(HOW)の振り返りは分離する

極端なことを言うと、たくさんストーリーポイントを消化しようがしまいが、成果(WHAT)がでてフィードバックがもらえてっていうループが回せるか、が重要と心得る。

プロジェクトの成果を振り返る場では、プロダクトに対して純粋に「こうしたほうが良い?」・「ここはこう治そう」と向き合うことが出来るが、チームでの取り組みを振り返る(レトロスペクティブとよんでいる)場で仮にWHATを図ろうとした場合にできることは「消化ポイントがどれくらいだったか」になる。これがよくない。明確にWHATとHOWの振り返りを分離することで、ベロシティを上げることから視線を外す事が必要なのではないか。

また、想定した成果が出なかったよぉっていうときには、それはプロジェクトの成果として考えると良いのだろう。たとえばプロジェクトにどれだけ時間を費やしたか、といった占有率、とかそういうことが分析として考えられる。

ある種、PJ単位にすることは逃げ道を用意できる側面もあるだろう。いろいろ他のこともしていたので〜だったり。逃げるは恥だが役に立つ

そんなことを思っているので、スプリントレビュー(PJの成果レビュー)とレトロスペクティブ(チームでの取り組み振り返り)を分けることにしている。

適度なプレッシャーを保てるか

1週間っていう期間をおいて、毎週成果を出しましょうっていうのは、リリースが毎週繰り返されるみたいなお気持ちに近いところがあるので、それなりのプレッシャーは精神にかかることにはなる。だからこそメンタリング装置が各所に仕込まれているっつう話なんだろうが、このプレッシャーが適度なものになっているかは、気にしないといけない。

自分なりの努力を重ねることを元プロ野球選手のイチローが言っていたが、ゆうて自分なりに馴染む温度で仕事をすれば良いのであって、過プレッシャーはよくない。

個人にとってのHOWとWHAT

プログラマ個人にとって、HOWの理解→WHATへの焦点といった段階があるのか、とか早朝朝5時思い立ったのは、たとえば、いまからBASEの中でAPI作ってくださいねってときに、何が焦点になるかというと人によって異なっていて、3びきのこぶたのテンションでいうと、

  1. PHPを書くぞ
  2. ブラウザからアクセスされるAPIを書くぞ
  3. BASEのサービスを作るぞ

みたいな感じでそれぞれどこに焦点があたっているかで、なんとなくその人の仕事感みたいなところが出るのかな、とかおもう。

1がわりとHOWよりで、3がWHAT寄りだが、1が焦点の状態で1に取り組むと、HOWに対するプレッシャー、つまり、「PHP難しそうだけど頑張るぞぉ...」っていうプレッシャーがのってくる。

さて、そのうえでイテレーションで動くものをつくりましょう、なり、なんらか明確な言葉で成果を定義されると、その焦点は自然と2以降にずらされる。

結果的に、これまでHOWのプレッシャーが掛かっている状態で、さらにWHATのプレッシャー、つまり「今週中に自分がやりきらないといけないのはこのAPIを...」とか、「ユーザーが待っているし問い合わせも日々見るから早くリリースを...早く...」と、上乗せされる。

この事象に対して、HOWのプレッシャーに戦略的に鈍感になることで、すぐにWHATを実現しよう、みたいな話が技術的負債のあれこれに、つながっていったりするのだろう

無意識的にHOWのプレッシャーに鈍感であることは、「プロとしてレベルの低い仕事をしていることに気が付かない」可能性を含んでいるので危険だろうけども。

今のところ考えていること その人にとってのプレッシャーがどこにのっているかによって計画の立て方を変えるのが良いのかもしれない

たとえば、オンボーディング期間とかの状態で、即座に明日リリースだからシュッと全部実装してデプロイしてください、みたいなことをいうと、極端にHOW/WHAT両方のプレッシャーが押し寄せて、震度7大震災ですいやーんこわーい、って話。

そういう期間であることを加味した設計が必要なのだろう。ペアオペなどで知識を同化していく〜みたいな話も、精神の余裕があってこそ。

個人が職能横断的であることが求められる昨今

個人が職能横断的にであることが求められる昨今ホンコン。これ自分は麻痺してるんだけど、けっこう大変なんですねっていうことをおもい。

組織重力の3つの法則というみんなでアジャイルの中で語られている話だと、組織の個人は自分のサイロの中で簡単な仕事を優先する、みたいな話があるので、別に自分たちが自立してだいたいのものはカバー範囲にありコントロール下にある「簡単な仕事」にしていくことは、プロダクトの課題解決にあたってはなくては厳しいと思うが、あくまでそれはチームの話

思っていること 個人が職能横断的ではなくてもいいことは改めて言語化しないといけないのだろう。

アジャイルチームのメンバー構成の要件にはプロフェッショナルがいることを上げているが、特化した専門性は必ず必要になる。 チーム状況によっては、ある程度、専門外のことをやる必要があるが、それが強いられることはない。

専門的組織との関わり方

職能でレイヤーの切られた組織において、職能横断的であることが求められた場合、その人の志向性とミスマッチする可能性がある

PHPで世界をとりたい、みたいな人に「今からTerraform書いてAWSのインフラ作ってくれ」って言うのはその人にとって不幸せな余分な時間になるだろう。

あるいはデザインやML的な文脈でも違う専門性なので、そこに対して職能横断的であることを強いるのは精神衛生上良くない。

おもうこと プロジェクトの関係者 != チーム

チームであることを強いると、上記のミスマッチを発生させてしまう可能性がある。プロジェクトの捉え方について認識をすり合わせることは、仕事をしていく上で大事だが、それとはまた別の話。

What are you doing? 何をいましているのか・どうやっているのかをプロジェクトとしたら、チームであることを強いるのは「どこにいるのか」を規定してしまう。

たとえば、突然あなたは明日からメイドカフェのチームとして振る舞ってもらわないといけないので、猫耳をつけてくださいって言われたら、とりあえず退職届を書くことになると思うのね。 メイドカフェを立ち上げるPJをやるからそのPJにJOINしてもらいます、その中ではこういうふうに考えてやっていくの、さぁ猫耳をつけてって言われたら、いやそれでも退職届を書くことに...

例が悪かった。いい例が思いつかないが、具体的な話に戻ると、スプリントレビューに入ってもらう人と、レトロスペクティブに入ってもらう人は、明確に違う風にしていいと思っているということ。

これは、1PJ=1TEAMの1-1の関係であれば両方入るカバレッジが100%だし、社前提がアジャイルな文化です、っていうならそれもカバレッジ100%だが、世界は多種多様でよくわからないので、自身がどういう状況にいるのかを考えた上で、!= であることを改めて確認したほうが良いのだろう。

これは、組織学習の過程とも言えるかもしれない

上記の怪文書は、ある種これまで潜在的に課題だったものが発見される過程なのかもしれない。

アジャイル開発は組織学習をプロセスに取り込んでいます。アジャイルなチームとなっている組織とそうでない組織を比較して、個々のメンバーを眺めてみると、確かにアジャイルなチームのほうが優秀なメンバーが揃っているように見えるでしょう。しかし、初めから優秀なメンバーを揃えないとできないというわけではありません。おそらく、アジャイルな方法論を取り入れることができないほど優秀でないメンバーであれば、他のプロセスを採用したとしてもうまくいく可能性はありません。

広木 大地. エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング (Japanese Edition) (Kindle Locations 3144-3149). Kindle Edition.