ここもちろぐ

生産性志向のSEが、IT業界での奮闘記や仕事や生活で学んだことをはきだします。

「前回こうだったから今回もそうしよう」病の危険性

pocket-watch-3156771_640 こんにちは。もちです。

みなさんは「前回こうだったから今回もそうしよう」というセリフを聞いたことがありますでしょうか。

確かに、前と全く同じ状況で、同じことをするのであれば、サクッと検討が進み、良い手かと思います。

ただ、前回と状況が違う場合、同じでいいはずがない!と思うのです。

なぜなら、「人も社会も変化する」からです。

変化する状況

たとえば、以下のようなものは、日々変化しています。

  • 社会
  • 技術
  • 法律
  • 文化
  • 経済
  • メンバー
  • 所有スキルの変化
  • お客様
  • 競合
  • 会社制度
  • 場所
  • スケジュール
  • 予算
  • 季節
  • 天気
  • etc

そんな中、ノータイムで前回策を今回策に採用するのは、一度、立ち止まって考えたいです。

振り返ってみると、
「あの時は仕方なくああしたけど、今なら他のあの方法のほうが効率いいな」
という発見があるかもしれません。

毎回、今の案件の目的を考え、目的からブレークダウンしながら方法を考えたいです!

わたしが体験したこと

システム開発プロジェクトの件

いくつかわたしの体験を例に挙げます。

悪いプロジェクトを真似る

1つめは、「スケジュールが厳しい見積もり」です。
とある悪いプロジェクトで、残業前提や、スキルの高いエンジニアが作業する前提で組まれたスケジュールがありました。

当時は、国から残業のことをうるさく言われることもなかったので、残業を駆使し、スケジュールを短縮していたのだと思います。

時が経ったことで、
昔話は「前回もこうだったから、今回も短納期でイケる」という美談に変わり、前回プロジェクトを参考に、新たな悪しきプロジェクトを立ち上げている方がおりました。

しかし、近年、働き方改革が進み、残業は悪だというのが最近の日本の共通認識かと思います。
(悪だとわかっていても改善しない企業もあるが・・・)

また、セキュリティや品質の要求も昔に比べ高まっており、ますます対応日数が欲しい状況にも関わらず、 スケジュール感やリソースを改善せずに真似て、「とりあえず残業でカバー」していきます。

2つめは、「人のアサイン」です。
「前回と同じくらいの規模だから参画人数も同じでいいや」みたいなパターンです。
システム開発のマネジメントは単に作業量と納期から人の数を決められるものではありません。

たとえば、

  • クラウド系のインフラスキルが高いメンバーが必要だったり、
  • お客さまの業界に詳しい人が最低でも3人は欲しかったり、

といった具合で、プロジェクトの特性に合わせ調整するものだと思いますが、
わたしの出会ったマネージャは、過去のプロジェクトの数字しか見ておらず
「前回こうだったから今回もそうしよう」病を患っておりました。

3つめは、「毎日の長時間全員ミーティング」です。 納期まで余裕があり、個人間でのコミュニケーションも活発であれば、
わざわざ毎日全員で決まった時間に長時間ミーティングをする必要はないかもしれません。
必要な時だけでいいとわたしは思います。

なのに、以前参画していた炎上案件を引き合いにして、
「毎日、すべての進捗を聞かないと不安でしょうがなかったので、今回もやるべき」みたいな自己満足だけの悪しき文化を持ち寄るマネージャがおりました。
ミーティングだけで工数の20%くらい持ってかれます。
少なくとも、話すテーマを絞り、目的ある5分ミーティングの方が良いです。

心配であれば進捗を把握しやすいツールを導入するなど仕組みでカバーしたいです。

他にも、昔のプロジェクトの成功体験が抜けず、プロジェクトの特性に合わない悪しき文化

  • レビューシート
  • 実績入力シート
  • プログラムの修正エビデンス取得

を無理やり持ち寄る方もいました。

プロジェクトの特性と案件の目的を考え
「参考にすべき部分は参考にする」、「捨てるべき部分は捨てる」を実施したいです。

わたし自身も、「楽だからなるべく流用できないか」と視野が狭くならないよう、時々立ち止まって考えるようにしています。

技術は進化しているけど人や会社が進化していない。

「5年前に似た画面を3日で作った気がする。今の技術なら1日で行けるやろ」みたいなパターンです。
実際に対応するメンバーのスキルセットも時代に合わせ進化していれば良いですが、残念ながら、そうじゃないパターンがあります。

また、スキルセットも揃っているにも関わらず、

  • 無駄な社内作業が多い、
  • 開発PCのスペックが低い、
  • 要件定義や設計が甘くて、QAを連発しなければならない、

などが要因で、残念ながら、メンバーの力が発揮できない場合もあります。

社内行事の件

わたしが体験したのは「去年資料の使いまわし」です。 その行事では、参加者への依頼や後日アンケートがあるのですが、観測した当時テーマが少し変わりました。

本来、テーマが変われば、資料も変わるはずです。
なのに、依頼方法やアンケートにとどまらず、運営方法も前年度のモノをコピペしている運営がそこにはありました。

前年度の運営がテーマや運営方法の振り返りを行ったはずなのに、それを活かすことなく、
今年度の運営が前年度のものを「とりあえずコピペしてしまう」のはもったいないなと感じました。

運営委員の方に、「そこに、あなたの想いはありますか?」と問うてみたい...苦笑。

まとめ

「前回こうだったから」は、今回案を選択する際の理由にならないと思ってます。
変化した状況を鑑みて、毎度、今回の方法を決定していきたいです。

同じにしていいのは、
新たに検討した際に「前回と同じ方法が良い」という結論が導き出された時だけだと、わたしは考えています。

  • そもそも何が目的か
  • 前回との変化は何か
  • 今なら、もっといい方法はないか
  • 時代の変化を認めず、思考停止していないか
  • 今回の案件で本当に最適か

こんなようなことを確認しながら、
わたしも早く、時代の進化と共に進化したい!


スポンサーリンク