はじめに
仕事でよく言われる「期限厳守」という言葉。
全員、頭では大事とわかっている。
だけど、実際の仕事では遅れてしまうこともある（なぜ？）
（自分もたまにあります🙇♂️🙇♂️）
「期限を守れ」とは言うが、その具体的な方法を教えてくれる人って意外と少ないはず。
そうして結果的に根性論になってしまう
根性で乗り切る時も勿論ありますが、ずっと続けていたらメンバーが徐々に疲弊してしまうサイクルが生まれてしまう
ではどうすれば1人1人がより着実に期限に間に合わせられるようになるのでしょうか？
自分なりに期限を超過してしまう要因を分析・言語化してみました。
- 今回の発信は私なりの仮説です。実際はプロジェクト内容やメンバーの立場の違いなどによって結果が変わる場合があります。
- これで全然守れなかったら自分にブーメラン返ってきそうですが、個人の反省も兼ねて投稿しています
遅延してしまう要因と対策
遅延が発生してしまうであろう要因を大きく分けて7つに洗い出しました。
1. 要件定義の曖昧さ
要因:
- 顧客やステークホルダーの要求が不明確、または変更が多い
- 要件の優先順位が定まっていない
- 開発チームと顧客間のコミュニケーション不足
対策:
- 要件定義の初期段階で、顧客やステークホルダーと密なコミュニケーションを取り、要求を明確化する
- 要件の優先順位を決定し、スコープを明確にする（=何をどこまで実現するか）
- ドキュメントやプロトタイプを用いて、要件の可視化を図る
- 要件変更管理プロセスを導入し、変更の影響を評価する
2. 不適切な計画と見積もり
要因:
- 開発期間や工数の見積もりが甘い
- リスクや依存関係の考慮が不足している（具体例を別途記載します）
- 計画の変更に柔軟に対応できない
対策:
- 過去の類似プロジェクトのデータや専門家の意見を参考に、現実的な計画を立てる
- WBS（Work Breakdown Structure）を用いて、タスクを細分化し、責任者を明確にする
- マイルストーンを設定し、進捗状況を定期的に確認する
- リスク管理計画を策定し、発生時の対応策を準備する
3. 開発チームのスキル不足
要因:
- 必要な技術スキルを持つメンバーが不足している
- チームメンバー間の連携が不足している
- 新しい技術やツールへの適応が遅れている
対策:
- チームメンバーのスキルアップのための研修やOJTを実施する
- 経験豊富なメンターを配置し、若手メンバーを育成する
- チームビルディングを行い、コミュニケーションを促進する
- 最新の技術やツールに関する情報を共有し、学習機会を提供する
4. コミュニケーション不足
要因:
- チームメンバー間、または顧客やステークホルダーとのコミュニケーションが不足している
- 情報共有が遅れたり、誤解が生じたりする
- 問題や課題が早期に発見されない
- メンバーのモチベーションが低下し、生産性が上がらない
対策:
- 定期的なミーティングや進捗報告会を開催する
- チャットツールやプロジェクト管理ツールを活用し、情報共有を促進する
- オープンなコミュニケーション文化を醸成する
- 問題や課題が発生した場合は、速やかに共有し、対応策を検討する
5. 技術的な問題
要因:
- 開発中に予期せぬ技術的な問題が発生する
- 使用する技術やツールが適切でない
- 技術的な負債が蓄積している
対策:
- 技術的なリスクを早期に洗い出し、対応策を検討する
- 適切な技術やツールを選択し、開発前に十分な検証を行う
- コードレビューやテストを徹底し、品質を確保する
- 技術的な負債を解消するための時間を確保する
6. 外部要因
要因:
- 外部の依存関係（APIやライブラリなど）に問題が発生する
- 法規制や業界標準（デファクトスタンダード）の変更
- 自然災害や疫病などの不測の事態
対策:
- 外部の依存関係について、常に最新情報を収集し、リスクを評価する
- 法規制や業界標準（デファクトスタンダード）の変更に迅速に対応できる体制を整える
- 不測の事態に備え、事業継続計画（BCP）を策定する
7. その他
要因
- 人的資源の不足（離職率の増加、経験者の不足など）
- 予算不足
- 品質管理の不備
- 開発プロセスの非効率性
リスクや依存関係とは
2. 不適切な計画と見積もりでも書いた、リスクと依存関係について深掘りします。
1. 技術的なリスク
例:
- 新しい技術を採用したが、開発チームのスキルが不足している
- 使用するライブラリやフレームワークに脆弱性が見つかった
- 開発環境が不安定で、頻繁にエラーが発生する
対策:
- 技術調査やPoC（Proof of Concept）を事前に行い、リスクを評価する
- 開発チームのスキルアップのための研修やOJTを実施する
- セキュリティ対策を講じ、脆弱性情報を収集する
- 安定した開発環境を構築し、バックアップ体制を整える
2. スケジュールリスク
例:
- タスクの依存関係を考慮せずにスケジュールを組んだため、後工程が遅延した
- 開発期間の見積もりが甘く、途中で手戻りが多発した
- 外部の協力会社との連携がうまくいかず、スケジュールに影響が出た
対策:
- WBS（Work Breakdown Structure）を用いてタスクを細分化し、依存関係を明確にする
- 過去の類似プロジェクトのデータや専門家の意見を参考に、現実的なスケジュールを立てる
- 定期的に進捗状況を確認し、遅延が発生した場合は早急に対応する
- 外部の協力会社との連携を密にし、情報共有や進捗確認を定期的に行う
3. 人的リスク
例:
- 開発チームのメンバーが突然退職してしまった
- チームメンバー間のコミュニケーションが不足し、意思疎通がうまくいかない
- 開発チームのモチベーションが低く、生産性が上がらない
対策:
- チームメンバーの増員や教育を行い、人員体制を強化する
- チームビルディングを行い、コミュニケーションを促進する
- チームメンバーの意見を聞き、働きやすい環境を作る
4. 外部依存リスク
例:
- 外部のAPIやサービスに依存しているが、そのAPIの仕様が変更された
- 外部のライブラリにバグがあり、開発が滞ってしまった
- 外部の協力会社の都合により、必要な成果物が期日までに納品されない
対策:
- 外部のAPIやサービスに関する情報を常に収集し、変更に備える
- 外部のライブラリの選定は慎重に行い、十分なテストを実施する
- 外部の協力会社との契約内容を明確にし、連携体制を強化する
遅延におけるボトルネックは？
ボトルネックとは、プロジェクトの進行を妨げる、または遅延させる最も重要な要因を指します。
上記の要因は複合的に絡み合って、プロジェクトに影響を与える可能性があります。
そのため、「ボトルネックはこれだ」と言い切るのは正直難しいと思います。
しかし、個人のタスクに焦点を当てて考えた場合なら、問題の特定と改善はしやすいと思います。
個人の期限遅延におけるボトルネックは何か？
これは私が思うに、
個人のタスクにおける期限超過のボトルネックは、
総じて「ゴール（目標）からの逆算不足」にあるのではないか？と仮定します。
※要件定義の曖昧さなどの外部要因は除いた場合
これを沖縄旅行に例えてみます。
旅行計画の例
あなたは1週間後に沖縄旅行に行くことになりました。
ゴール（目標）: 1週間後の沖縄旅行を楽しむ
逆算できている場合
出発日: 1週間後
沖縄での活動:
3日目：美ら海水族館に行く
2日目：マリンスポーツを楽しむ
1日目：那覇市内を観光する
移動手段: 航空券、レンタカーを手配
宿泊先: ホテルを予約
持ち物: 旅行に必要なものを準備
予算: 旅行に必要な費用を計算
逆算できていない場合
あなたは「沖縄旅行に行く」ことだけを決めましたが、具体的な計画を立てていません。
- 航空券やホテルは直前になってから予約しよう
- 沖縄で何をしたいかは現地で考えよう
- 持ち物は当日になってから詰めればいいや
このような状態だと、出発日が近づくにつれて焦り、
- 航空券やホテルが予約できない
- 沖縄で何をすればいいか分からない
- 持ち物を忘れてしまう
航空券が取れず、そもそも行けないかもしれない（それとも泳いで行きますか？🌊🏊🏊♀️）
ホテルは取れず、ネカフェ。それもなければ最悪野宿かもしれない⛰️
そんなグダグダな旅行は嫌ですね🫠
逆算ができていない要因とは？
例えば以下のような要因が考えられます。
計画の具体性不足
- タスクの洗い出しが不十分：必要なタスクを網羅できていないと、後になって予期せぬタスクが発生し、遅延につながります
- タスクの順序が不明確：タスク間の依存関係を考慮せずに計画を立てると、後工程で手戻りが生じる可能性があります
- マイルストーン設定の欠如：中間目標を設定しないと、進捗状況を把握しづらく、遅延に気づきにくくなります
時間管理の欠如
- 時間配分の偏り：特定のタスクに時間を使いすぎてしまい、他のタスクの時間が足りなくなる
- 集中力の維持不足：集中力が続かず、タスクに時間がかかってしまう
- 割り込みへの対応：予期せぬ割り込みに時間を取られ、予定していたタスクが遅れる
モチベーションの維持不足
- 目標の不明確さ：目標が曖昧だと、モチベーションを維持しづらく、タスクへの着手が遅れる
- 達成感の欠如：タスクを達成しても達成感が得られないと、次のタスクへのモチベーションが上がらない
- ストレスの蓄積：ストレスが蓄積すると、集中力が低下し、タスクの遅延につながる
知識・スキル不足
- 必要な知識・スキルが不足していると、タスクに時間がかかったり、途中で行き詰まってしまったりする
- 新しい技術やツールへの適応が遅れると、タスクの効率が低下する
逆にポジティブに捉えると、これらを一つずつ改善していけたら、仕事もできるようになっていく可能性があるとも捉えられますね💡
技術・経験不足の問題にはどう立ち向かうか？
例をいくつか挙げましたが、実際のプロジェクトで行動に移すのは難しいと思います。
（実践で活かせないとただの綺麗事や理想論になってしまう。。）
特に、IT業界における未経験エンジニアの技術力・経験不足の問題。
（今も駆け出しですが）駆け出し1~2年目の頃は自分も単細胞（?）だったので、
「せや、技術を完璧にマスターすればええんや」と無茶な目標設定をしていました。
「とりあえず技術力だけ磨けば、仕事ができるようになる！（＝期限に遅れなくなるはず）」
といった偏った思想です。
だから誰にも負けないという競争意識で猛勉強してたのですが、今振り返ると他人と比較してばかりで精神衛生上はあまり良くなかったと思いました（そういう時期を乗り越える経験も重要ですが、、）
（本記事の最後におまけで「何がわからないかをわかるようになるためには？」に関する記載を載せています）
技術をひたすらに磨けば、期限に遅れなくなるのか？
「技術があればタスクをこなすスピードが上がる！」
「プロジェクトを熟知すれば、やるべきことがわかる！」
＝期限内にタスクを全て終わらせられる！
確かに、実装力があれば生産性が上がるし、
プロジェクトを理解している方がタスクを進めやすいと思う。
しかしその考え方は、全てのプロジェクトに対して100%当てはまるのか？
実際、過去に経験した類似プロジェクトで実装を進めていても、要件が定まっていない、開発環境などの外部要因の違いで苦戦する場面はあった
（生意気ですが、RailsのERBでフロントを書くから簡単と舐めていた時もありました）
ただでさえ、経験したプロジェクトでもそういうことが起こりうるのに、
「もし言語・FWが変わったら？」
「全く新しいプロジェクトにアサインされることになったら？」
自分1人で考えてもわからないことだって出てくるはず。
そうした時に技術力だけではなく、既存のプロジェクトメンバーから知りたい情報を引き出すためのコミュニケーション力なども必要になってくるはず（自分もこの辺頑張ります）
明日ではなく、今改善する
出典：ジョジョの奇妙な冒険 荒木飛呂彦
「技術力が上がれば、明日はもっと良くなる（？）」
そんないつ訪れるかもわからない将来の自分に期待するのではなく、今改善できることは改善する。
今の自分が他人や会社に求められていることを面倒くさがらずコツコツやる。
（ということを1〜2年前の自分に言い聞かせたいです）
何がわからないかをわかるようになるためには？
こちらはおまけです。
例えば、全く知らない技術（言語など）と向き合う時、どうやってタスクをこなしていけば良いか？
（例えば、今まで学ばなかったVue.jsやReactなどのフロント周りのFWやライブラリをキャッチアップする場合など）
（種類多すぎ笑）
イントロダクション
その対処法として今回は、著書「独学大全」を参考に考えてみます。
まずは下の図をご覧ください。
不明型「わからない」は最も重度なもので、よくいう「何がわからないかもわからない」状態です。
例えばまったく知らない外国語を前にした時、この状態になります。
この場合に取ることのできる対応は、その分からないものを
（1）部分に分けて、（2）部分ごとの解釈を仮にでも決めることです。
知らない外国語の例で言うと、
（1）単語らしきものに分けて（分かち書きしない言語ではこれ自体難事業ですが）、
（2）その意味を仮に決めることになります。辞書がある場合は、辞書を引いて訳語のひとつを当てはめることがこれにあたります。
（全部記載すると長くなるので、続きはこちらをご覧ください）
フロントエンド技術のキャッチアップに置き換えて考えた場合
以下のステップで進めていきます。
※エンジニアに限らず、全ての職種に応用できると思います。
あくまでも一個人の見解です。
-
現状の「わからない」を認識する
まず、自分が何がわからないのかを明確にします。漠然とした不安ではなく、具体的な疑問をリストアップする。- React（Vue.js）の基本的な概念がわからない
- React（Vue.js）のコンポーネントの仕組みがわからない
- 最新のフロントエンド開発のトレンドがわからない
- そもそも、どの技術を学ぶべきかわからない
-
「わからない」を部分に分解する
次に、リストアップした「わからない」をより小さな要素に分解します。- ReactのJSX構文がわからない
- Vue.jsのデータバインディングの仕組みがわからない
- Webpackの設定方法がわからない
- JavaScriptのES6構文がわからない
-
各部分に対する仮の解釈を定める
分解した要素に対して、仮の解釈を定めます。この段階では、正確な理解は二の次で構いません。- JSXはHTMLに似た構文で、ReactでUIを記述するために使うものらしい
- データバインディングは、データとUIを紐付ける仕組みらしい
- Webpackは、JavaScriptのファイルをまとめてくれるツールらしい
- ES6は、JavaScriptの新しい文法らしい
-
仮解釈をもとに調査・学習を進める
仮解釈をもとに、具体的な情報を収集します。公式ドキュメント、技術ブログ、書籍など、様々なリソースを活用しましょう。- JSXの構文規則を調べてみる
- データバインディングの仕組みを図解で理解する
- Webpackの基本的な設定方法を試してみる
- ES6の新しい文法を実際にコードで書いてみる
-
理解度に応じて解釈を修正する
調査・学習の結果を踏まえ、仮解釈を修正します。必要に応じて、さらに深い情報を収集したり、経験者の方に質問したりするのも良いでしょう。 -
1〜5を繰り返す
上記のプロセスを繰り返し行うことで、「わからない」を徐々に解消していくことができます。焦らず、一つずつ丁寧に理解を深めていくことが重要です。
まとめ
タスク期限の超過には様々な要因が複雑に絡み合っているため、他の要因も考慮した上で、総合的な対策を講じることが重要です。
途中で私情を挟んだりして粗雑な文章でしたが、最後まで読んで頂きありがとうございました🙇♂️
参考記事
ビジネスにおける【ボトルネック】とは？意味や問題点、解決法を解説
独学の達人が実践する「何がわからないかもわからない」を解決する一つのツール