アイキューブドシステムズで CLOMO や CLOMO MDM for Android のプロジェクトリーダー (PL) をしている id:oda-i3 です。前回の記事を寄稿してから約一年が過ぎました。またも、失敗の多い生涯を送って来ました。私には、失敗のない生活というものが、見当つかないのです。
このような事を書くと「ネガティブだな」と思われるかもしれませんが、失敗についてはネガティブに捉える必要はないと考えています。本稿では失敗をネガティブに捉えないよう失敗学を参考にして、自分の失敗をふり返りたいと思います。
前回同様、私の体験談が皆さんのプロジェクトマネージメントの一助となれば幸いです。
失敗学とは
失敗学（しっぱいがく）または失敗工学とは、事故や失敗が発生した原因を解明し、（将来）経済的な打撃をもたらしたり人命に関わるような重大な事故や失敗が起きることを未然に防ぐための方策を追求する学問。
Wikipedia - 失敗学 より引用
失敗学は主に「人命に直結しやすい業務（例：鉄道、航空、医療 etc）に携わる方たちが実際にしてしまった失敗の蓄積」という印象を個人的にもっています。
私たちが携わる IT 業界は人命に直結する機会が少ないかもしれませんが、先人たちの蓄積した知識を応用できないものかと考え、私なりにまとめてみました。
失敗をネガティブにとらえない
失敗はとかくマイナスに見られがちですが、じつは新たな想像の種となる貴重な体験なのです。
畑村洋太郎著 失敗学のすすめより引用
落ち込む/落ち込まないは個人差があるとしても、私の場合は失敗やミスをすると気分が落ち込みます。が、「まぁ、やってしまったものは仕方がない」と切り替え、失敗やミスの原因を分析し再発防止策を考え実施します。
失敗原因の分類
失敗の原因は大まかに 10 種類に分類されます。
未知
世の中の誰もが知らない/経験したことがない現象が原因である失敗です。JR 羽越本線脱線事故がこれに分類され、このケースのみ事前に防御策をとりようがありません。貴重な経験として徹底的に原因を分析し、再発防止策を検討/実施し、さらに社内外とわず広くその知識を共有する必要があります。
逆に言えば、この未知以外の失敗は事前に対応策を練って回避することが可能です。
無知
失敗の回避策、解決方法が世に広く知られているが、本人もしくは組織が知らなかったゆえに引き起こされる失敗です。
不注意
体調不良や多忙、またはずっと心に引っかかっていることを気にし続けてしまような気がかりなどが原因となる失敗です。「体調管理も仕事のうち」とよく耳にしますが、体調不良による失敗やヒヤリハットは多いのではないでしょうか。
当事者の理解が表面的で本質を理解できていない場合や、当事者に知識もあり本質も理解しているにも関わらず多忙などを理由に注意を払わないケースもこれに分類されます。
手順の不遵守
決められているルールや広く知られている習慣を踏襲しなかったことが原因となる失敗です。決まった手順を守らないことは当然ながら、行うべき連絡を怠ったりしたケースもこれにあたります。
誤判断
状況を正しくとらえられなかったり、状況は把握していたもののその後の判断を誤ってしまうような失敗です。
調査/検討の不足
決定にいたるまで十分な調査/検討が実施されなかったことが原因となる失敗です。シミュレーションや事前検討、環境の調査不足も含まれます。
制約条件の変化
ある条件下でスタートした企画だったのに、時の経過とともに前提条件が変わってしまい、その変化に対応できなかったために起きる失敗です。
企画不良
企画自体そのものが問題を抱えていることが起因する失敗です。そもそもで実現不可能な戦略をたてたり、組織構成の変更が既に抱えている問題と合致していない場合に発生することがあります。
価値観不良
価値観の共有ができていないために起きる失敗です。生活習慣や心情の違いなど価値観が周囲と異なり、自分との差異を理解/対応できない場合に起きやすいです。また、組織内のルールを最優先にし、一般的なルールから逸脱した場合もこれに該当します。
組織運営不良
組織自体が正常に運営されていないことが原因である失敗です。決定権の承認のフローが長すぎたり、トップの指示が正しく現場に伝わらない（その逆も然り）ケースがこれにあたります。
一年を振り返って
実際に何をやったのか？
前回の記事では特に言及していませんでしたが、私が携わるプロジェクトはスクラムを採用しています。スクラムとはざっくり以下のようにまとめてあります。
www.ryuzee.com - 5分で分かるスクラム用語集 より転載
Ⓒ@ryuzee / Ryutaro Yoshiba 2021/07/30 www.ryuzee.com - 3分でざっくりわかるスクラム（スクラム用語を使わないスクラムの説明） より転載。転載元と同じく CC BY-SA 4.0 ライセンスに準拠。
各用語について、私の携わったプロジェクトの実情はどうだったのかを大まかにまとめます。
- プロダクトオーナー
→「これは私？それとも CEO？」程度の認識1。 - プロダクトバックログ
→スプリントバックログとの違いを分かっていない。よって、常に最新の状態に保てていない。 - デベロッパー（開発チーム）
→チームメンバーと等価。 - スプリント
→2 週間固定で運用している。 - スプリントプランニング
→スプリント開始時に実施している。 - スプリントバックログ
→プロダクトバックログとの違いを分かっていない。 - インクリメント
→スプリント内の実装という認識。ただし、社内ルールで「スプリントレビュー（もしくはこれに類する説明会）で関係者に設計内容の合意をもらわないと実装に着手できない」というものがあり容易に実施できない現状がある。 - デイリースクラム
→いわゆる朝会。毎日は実施していない。 - スプリントレビュー
→スプリントでやったりやらなかったりでまちまちだった。 - スプリントレトロスペクティブ
→いわゆるふり返り。当初は実施していたが、次スプリントに活かせるアクションが出てこなくなったので廃止した。 - スクラムマスター
→資格を所有する社員はいる（≠チームメンバー）2。が、自発的に相談をしていなかった。
このように見返すと無知/手順の不遵守/誤判断が目立って見えます。
改善すると思って実施したこと
前回のブログを公開後、取り組むことにした課題は以下になります。分類的には誤判断になります。
- 1 プロジェクト 2 プロダクトなのに一つのユーザーストーリーで管理していた
- スプリントレビュー後で指摘されてから作成すべきユーザーストーリーを、スプリントレビュー前から作成していた
1 プロジェクト 2 プロダクトなのに一つのユーザーストーリーで管理していた
私のチームではカンバンを利用できるチケット管理システムを採用しています（※下の画像はイメージです）。
PANEL(CLOMO MDM) と Agent(CLOMO MDM for Android) がそれぞれプロダクトになっています。AER2021-393 というユーザーストーリーには両プロダクトのタスクが含まれていますが、プロダクトが異なるためタスクを取れるエンジニアが限定されます。
つまり、1 プロダクトのタスクは完了していてももう一つのプロダクトのタスクが完了していないため、このユーザーストーリーを完了できずにスプリントが終わってしまいます。
スプリント内で完了できるよう現在はプロダクトごとでユーザーストーリーを分けています。
スプリントレビュー後で指摘されてから作成すべきユーザーストーリーを、スプリントレビュー前から作成していた
「最初に見積もった工数は、追加工数を発生しないよう努力すべき」と考えていますが、この考えを曲解したものが本項になります。
スプリントレビューで指摘され設計をやり直す必要がある
↓
後から見積もっていないタスクが増えてくる
↓
最初からタスク作っておけばいいのでは！？（俺って天才？）
「終わらせることから始める」必要があるのに、「終わるかどうか分からないタスクを作る」ことをしていました。結果、不要なユーザーストーリー/タスクが氾濫し、不要な管理工数が発生しました。
現在は、不要なユーザーストーリーは作成せず、必要に応じて作成するようにしています。
本当は基本に忠実にやることが望ましいが、逸脱せざるをえなかったこと
以下の事象は手順の不遵守となります。ただし、「本当にこれは失敗なのか？」と私自身まだ迷いがある事象でもあります。
- デイリースクラムをデイリーでやっていない
- スプリントレトロスペクティブをやっていない
- スプリントレビューは動かない成果物からフィードバックをもらう
デイリースクラムをデイリーでやっていない
私のチームでは週 2 回の実施としています。毎日実施しない理由は「チームメンバーが緊急度の高い調査依頼など割り込みタスクが頻発する」ためです。
毎日実施したとしても「昨日は外的要因で進捗 0 です」という状況が頻発するため、15 分といえど毎日メンバー全員の時間をロックする必然性を感じなかったので実施しませんでした。
これは現在も継続しています。
スプリントレトロスペクティブをやっていない
当初は KPT 法で取り組んでいたのですが、課題ばかり積もり、課題に対する解決策やアクション事項も実施されないままとなりました。アクション事項は朝会で確認するも、各メンバーの時間的リソースも逼迫した状態であったため、思い切って実施自体をやめました。
これは現在も継続しています。が、やった方が良いとは思っています。
スプリントレビューで、動かない成果物からフィードバックをもらっている
本来であれば、スプリントレビューは動作する成果物をデモしてフィードバックをもらうことが目的です。しかし、従来行っていたウォーターフォールの名残りとして「関係者（他部署を含む）から設計内容のレビューをしてもらい合意を得なければ実装に着手できない」というものがありました。
この名残りがまだ根深く残っており、スクラム手法を完全に取り入れきれていない過渡期の状態にあると考えています。
これは現在も継続していますが、絶賛改善中です。
明らかに用途を間違っていた、もしくは誤解していたこと
以下の事象は無知だったことが起因しています。
- スプリント内で完了しないタスクを設定していた
- ストーリーポイントは人時と同等のものと錯覚していた
スプリント内で完了しないタスクを設定していた
再度このボードを例にすると、スプリントが終わる時には各レーンのタスクは一番右の完了レーンにいなければなりません。それを理解しておらず、気づけば 3〜4 スプリントをまたがっているユーザーストーリーがいることに違和感を感じなくなっていました。
また複数のスプリントにまたがっているユーザーストーリーをどうしたら完了させることができるかをスプリントレトロスペクティブで十分に考え切れていませんでした。
その結果、第三者からは「このプロジェクトは成果を出し切れていない」と判断せざるを得ないスプリントを設定していました。
現在は抽象的であいまいなユーザーストーリーは作成せず、1 スプリント内で完了できる粒度までユーザーストーリーを細分化するようにしています。
ストーリーポイントは人時と同等のものと錯覚していた
私が初めて実践的にスクラムを使ったプロジェクトは、一週間単位で解決できそうな不具合を随時改修していくものでした。そのプロジェクトは小規模であったため、ストーリーポイントと工数が正比例ではない状態で運用していました（例： 1SP = 1 人日としているが 2SP = 1.5 人日と設定している）。小規模なプロジェクトであれば運用可能だったのですが、プロジェクトの規模が大きくなるとその誤差は大変大きなものとなりました。
また「ストーリーポイントは規模を表すもの」と頭で理解していたつもりでしたが、いつしか「ストーリーポイントは人時と同等のもの」と錯覚していました。結果、規模を出したいのに稼働工数の見積もりをやっていることと大差ないことをしていました。
現在はユーザーストーリーを可能な限り細分化（ベロシティ内で確実に完了できるレベルの粒度）し、その中で最小のユーザーストーリーを 1 SP と定義し、その他のユーザーストーリーの規模感をスプリントプランニングで決定しています。
まとめ
スクラムをやっているつもりで、スクラムではない何かを生み出してしまった
本記事で挙げたミスはスクラムを始めたばかりの人ならば誰しもやってしまうものではないかと思います。1 スプリント内だけであればリカバリーも十分可能です。しかし、2 スプリント以上またがり、さらに改善案という名のもとにスクラムのお作法には存在しない独自ルールを追加していってしまい、結果この世に存在せず汎用性のない開発手法を生み出してしまいました。
今回のケースでは、開発の手を止め、再度「自分たちが何をすべきか」を確認するため、スクラムマスターに指示を仰ぎました。結果、独自の開発手法からスクラム開発になるよう軌道修正することができました。
スケジュールの相談をすることは大事。ただし、誰に相談するかも大事
三人よれば文殊の知恵な場合もありますが、三人よってもダメな時はダメです。ちゃんとスクラムマスターに相談しましょう。
同じ失敗を繰り返さない
前回のブログから今までを見直すと「これって結局この前の失敗と本質的には同じだよね」というものが散見されました。
人間は誰しもミスはするものですし、そういう生き物なので仕方ありません。未知との遭遇による「良い失敗」はやっても構わないと考えていますが、再発など怠慢による「悪い失敗」は繰り返さないようにしなければなりません。その為にはスプリントレトロスペクティブレベルで小さなやらかしの原因究明と再発防止策の考案と実施、そしてナレッジの共有が大事です（この記事もナレッジの共有のつもりです）。
手を止めてでも行いを見つめ直そう
進捗が遅れている時、人間誰しも焦りが生まれます。その焦りは「早く開発を完了させなければ」という気持ちを生み出します。同時に、ここまで書いてきたように「自分たちのやり方に違和感がある」という感覚が、いつしか頭をもたげるようになっていました。焦りが生まれ手法にも違和感を感じた時こそ、一度開発の手を止めて自分たちのやっていることを見直すタイミングでした。このように複数の悩みに苛まれたときこそ立ち止まり、一度手を止める勇気を持つようにしましょう。
