LoginSignup
9
3

More than 1 year has passed since last update.

先日、弊社内で開催された@t_wadaさんのセッションを受けて、自分なりに得た実践論を記載します。

前提

こちらとほぼ同じ内容を踏まえた記事になるので、お時間があれば是非ご一読ください。

質とスピード~ソフトウェア開発の典型的な誤解を解く~

乱暴に要約すると「質を落としても、早くはならない」と言う話です。

要点

以下、個人的に解釈した要点を幾つか見ていきます。

要点1:プロジェクトのメンバーとして「できる人」しかアサインさせない

セッションの内容を整理すると、

  • 「できる人」は早く書いても品質が高い
  • 「できない人」は時間をかけても品質が低い

となります。

個人的な感覚と合致します。

ですが、現実的には自分も含め「できない人」の方が多い気がします。

では、「できない人」はどうしたら良いのでしょうか?

要点2:「できない人」は「できる人」になってもらう

当たり前感がありますが、改めて役割を整理すると、

  • 「できる人」
    • プロジェクトを実現する事
  • 「できない人」
    • できる人になる事

ですが、認識はしていても対策されている事は多くありません。

と言う事で、

対策:「できる人」になる工数を計上しましょう

各プロジェクトには必要なスキルセットがあります。

ですが、メンバーがアサインされるタイミングで全て備わってない方が普通です。

特に内部品質に関するスキルセットに関しては条件として明記されている方が稀です。

実践

進め方を整理すると、

  1. プロジェクトに関して必要なスキルセットを明確化する
    1. 内部品質に関しても明確化する
  2. メンバーが持っているスキルセットを明確化する
  3. ギャップを埋める学習時間を工数として計上する

となります。

終わりに

上記を実施する事で、メンバーをアサインする経営側の期待値プロジェクトを実現する現場側の実態を少しでも埋める事ができるのではないかと考えています。

実践するのは結構大変だと思いますが、その際の一助になれば幸いです。

9
3
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
9
3