エンジニアのみなさんの中には、毎日の残業や休日出勤だらけでつらい日々を過ごされている方もいらっしゃるのではないでしょうか。実はちょっとした行動を取るだけで、そのつらい日々がなくなる可能性があります。そのちょっとした行動とは「ふりかえり」です。定期的な「ふりかえり」は、生産性を大きく向上させます。また、チーム力の強化にも大きく貢献します。今回は、そもそも「生産性とは？」の話しからスタートし、「生産性を高める方法」、「生産性を高めるために「ふりかえり」が最も効果的であること」を話していきたいと思います。
1.生産性とは？
1.1 システム開発における生産性
生産性は、主に「労働生産性」と「資本生産性」の２種類に分けられます。文字通り、労働の視点から生産性を測ったものが「労働生産性」、資本の視点から生産性を測ったものが「資本生産性」です。私たちエンジニアのシステム開発の現場で用いられる生産性は「労働生産性」の方です。今回は、「労働生産性」について話していきます。(以降は「労働生産性」のことを単に「生産性」の表現することにします。)
システム開発における生産性とは、生み出された成果物に対して、それを完成させるまでにどれだけの資源(リソース)を投入したかを示す割合のことです。
生産性は、「生産性＝成果物（output）÷投入資源（input）」の式で表すことができます。この式から読み取れることは、生産性を高めるために、少ない「投入資源(INPUT)」で最大限の「成果物(OUTPUT)」を生み出すことです。
1.2 なぜ生産性を高める必要がある？
国レベルのマクロな視点では、その答えは「労働者人口の減少」と「国際的な競争力の強化」のためです。これから日本は、「少子高齢化」と「人口減少」が進みます。つまり、「労働者人口」が少なくなります。つまり、現代の日本の社会保障は、その収入源である労働者が減ることによって、いずれ維持できなくなるということです。そのため、日本政府は、生産性を高めて、何とか社会保障を維持できる取り組みをしようとしています。
しかし、私たちひとりひとりのミクロなの視点からすると、それら理由はあまり重要ではありません。では、私たちが生産性向上を目指す意味がどこにあるのでしょうか。その答えについて、私は「ワークライフバランスを整え個々の生活を豊かにするため」だと考えています。毎日過度な残業や休日出勤が続くとつらいですよね。生産性を高めて毎日定時で帰宅する。これがすべての労働者における理想的な姿だと考えます。
1.3 生産性＝効率×品質
エンジニアの皆さんは、「生産性は作業効率だけで測れるもの」だと思っていませんでしょうか？実は少し違います。生産性は作業効率だけでは測れません。生産性を考える際には、品質についても考慮に入れる必要があります。つまり、システム開発現場における生産性は、以下の関係性が成り立ちます。
生産性＝(作業)効率×(作業・成果物)品質
生産性を高めるため、作業効率だけを高めても、品質が悪ければ作り直しが発生します。いくら成果物を早く仕上げたとしても、作り直しが発生すれば、作り直しの分、作業工数が余分に掛かってしまいます。結果的に生産性が低下します。つまり、生産性を高めるためには(作業)効率と(作業・成果物)品質をバランスよく高めていく必要があります。
2.生産性を高める方法
前章から生産性を高める方法として、「(作業)効率を高める」ことと、「(作業・成果物)品質を高める」ことが必要であることがわかりました。本章では、具体的に生産性を高める手法をご紹介します。
2.1 マクロ・ツール化
効率と品質を高めるための方法として、マクロ・ツール化があります。これは、ドキュメント作成、ソースコード作成、テスト実施のどのフェーズにおいても有効な手段です。仕様書としてエクセルを使用しているのであれば、エクセルのマクロやVBAなどを利用して、機械的に作成している部分について自動化します。また、エクセル(仕様書)を基に、ソースコードの一部を自動で作成することもできます。テスト工程は、マクロ・ツール化がフルに活用できるフェーズです。テストデータを自動で作成できるようにする、テスト準備(SQLによるデータの投入やインプットファイルの準備など)やテスト実行コマンドなどをひとつのツールとして、ボタンひとつで実行できるようにする、など他にもマクロ・ツール化できることがたくさんあります。マクロ・ツール化が優れているところは、効率と品質を同時に高められることです。また、一度作ってしまえば、インプットとアウトプットの内容が変わらない限り、永続的に利用することができます。
一見メリットだらけのマクロ・ツール化ですが、もちろんデメリットも存在します。「マクロ・ツールの作成に時間が掛かる」これはデメリットのひとつです。いくら本作業や本成果物の効率・品質が高まったとしても、マクロ・ツール作成自体に時間を取られているようでは本末転倒です。また、もうひとつのデメリットとして、「マクロ・ツールの品質問題」があげられます。マクロ・ツールも成果物(中間成果物)のひとつです。マクロ・ツールに不具合があれば、アウトプットである本成果物にも不具合が生じます。このように、何がなんでもマクロ・ツール化した方が良いわけでなく、費用対効果をしっかりと見極めて、作成するかどうかの判断が必要となります。
2.2 既製品の積極活用
開発の生産性を上げるツールとして、フレームワークやライブラリがあります。これらを積極的に活用するようにしましょう。例えば、カレーライスを作ることを考えてみてください。カレーライスのレシピがフレームワークに相応します。カレーライスを作るには、レシピ(フレームワーク)通りに作れば、平均的なカレーライスがすんなりと出来上がってしまいます。そのカレーライスのレシピ(フレームワーク)を個人の好みに応じてアレンジ(カスタマイズ)していけば、比較的簡単に美味しく調理することができます。システム開発も同じです。システムもある程度決まった構成で作ります。そのため、フレームワークを活用し、その案件に応じてカスタマイズしなければならないところのみ作るだけで、比較的早く、品質良くプログラム作成することができます。ライブラリも同様です。カレーライスの例に戻ると、カレールーや調味料がライブラリに相応します。カレーライスを作る際に、カレールーをカレー粉の段階から作りはじめる人はほとんどいないと思います。カレールーとしてもう完成している商品がありますので、ほとんどの人はそちらを使用するのではないでしょうか。調味料も同じで、原材料から調味料をイチから作ろうとする人はほとんどいないと思います。システム開発も同じで、実現したい処理について、もう既にライブラリとして提供されているものがあるのであれば、積極的に活用すべきです。イチから部品を作ろうとすると、時間が掛かる上にバグを埋め込んでしまうリスクがあります。生産性を高めるため、使えそうなライブラリに常にアンテナを張り巡らせて、積極的に活用するようにしましょう。
2.3 共通部品化
プログラミングを本格的にはじめる前によく検討設計すべきなのが、同じような処理の共通部品化です。同じような処理をそれぞれの担当で作ってしまうと、冗長なプログラムが多く生み出してしまいます。これは生産性が落ちるどころか保守性に大きく欠けてしまいます。システム開発を進める上では、無駄なプログラムを生み出さないようにコミュニケーションを密に取り、共通化できるところがないか常に意識して作業するようにしましょう。
2.4 再利用
過去に開発したプログラムや、他のプロジェクトのプログラムで、使えそうな処理がありましたら積極的に活用しましょう。過去のプログラムや、他のプロジェクトのプログラムであれば、既に本番で動いている実績があるので、品質としてもある程度担保された状態になっていると思います。生産性を高めるため、簡単にコピペで済むような処理であれば、積極的に再利用するようにしましょう。
2.5 無駄を徹底排除
生産性を阻害する要素があれば徹底して排除します。ダラダラとした会議はその一例です。会議のやり方を見直して、効果的な会議を実施するようにしましょう。むしろ会議をしないという選択肢もアリだと思います。会議の必要性をしっかりと見極めて、必要と判断した会議のみに絞ります。その会議も、効率的に進行できるように事前に準備して臨みましょう。また無駄な管理資料なども徹底的に排除すべきです。管理者になると、状況を詳細に把握したくなり、管理資料を多く作りがちです。管理資料が多すぎると、管理が煩雑になり、そのうち形骸化が進みます。形骸化した管理資料を継続してメンバーに更新させているようでは、メンバーに無駄な作業をさせてしまうことになりかねません。管理資料は必要最低限とし、あまり効果的でないものは思いきってやらないなどの決断をするようにしましょう。
2.6 教育
生産性を高めるために手っ取り早い手法は、豊富な経験やスキルを持ったエンジニアをプロジェクトに参画させることです。経験の浅い若手エンジニアを複数人参画させるより、経験豊富なベテランエンジニアを1人参画させる方が、圧倒的に成果をあげられることはざらにあります。しかし、エンジニアが慢性的に不足している現代においては、有能なエンジニアを採用することはかなり難しいと思われます。そこで、今いるメンバーの教育を徹底して行うようにしましょう。教育は長期的な投資です。生産性向上の即効性は見られませんが、長い目で見れば、生産性を高めることができます。生産性を高めるための未来に向けての投資として、勉強やセミナーでメンバーの育成に積極的に取り組みましょう。
2.7 モチベーション
システム開発における最も重要なのリソースはヒトです。そのため、メンバーのモチベーションは、生産性に大きく作用します。メンバーのモチベーションを高めるための取り組みを積極的に行うようにしましょう。例えば、メンバーがこのプロジェクトに携わっている意味や役割等を明確にし、メンバーが目的を持って作業に当たれるように支援します。メンバーが目的意識を持って作業に当たれば、生産性は飛躍的に向上します。また、メンバーが気持ちよく働けるような環境作りも重要です。作業用のPCが遅くてメンバーがイライラしないように開発環境を見直すことや、ストレスを軽減させるためにテレワークを積極的に採用するなど、メンバーが働きやすい環境になるように常に心がけましょう。
3.必ずふりかえりを実施しよう
これまで生産性を向上させる手法についてお話ししました。最後に最も効果的な方法をお伝えします。それは「ふりかえり」です。定期的に「ふりかえり」を行うこと、つまり、定期的に改善を繰り返すことで、生産性の低い作業が改善され、生産性が段々と上がっていきます。このシンプルな「ふりかえり」による改善効果ですが、案外「ふりかえり」の重要さに気づいていないチームやプロジェクトが多く存在します。「ふりかえり」なくしてチームの成長はありえません。日本を代表するトヨタが世界のトップ企業に成長した背景には「カイゼン」の取り組みが大きく貢献していることは有名な話です。システム開発でも同様です。必ず「ふりかえり」を実施し、無駄な作業などを徹底的に改善し、生産性を高める取り組みをしましょう。
「ふりかえり」の手法は様々ありますが、最もシンプルで効果的な手法はKPT法です。KPT法は、Keep(良かったこと・続けていきたいこと)、Problem（悪かったこと・問題や課題）、Try(問題や課題に対して改善すること)をメンバー同士で話し合い実践することです。１カ月毎、案件の切れ目毎など、定期的に続けることで「ふりかえり」の効果を最大限に発揮できます。ぜひ、今日からでも「ふりかえり」を取り入れるようにしましょう。
4.さいごに
私自身、エンジニアのキャリアを通して、「ふりかえり」の効果を強く感じています。とあるプロジェクトでダラダラと開発を進めていた時期があります。そこでは、慢性的な稼働過多と休日出勤に悩まされていました。そこで思い切ってチームに「ふりかえり」の実施を提案しました。検討の結果、とりあえず１回実施してみることにしました。結果として、たった１回ふりかえり実施しただけなのに、それ以降、チームの稼働が大きく下がりました。また何よりの収穫だったのがチーム力が強化されたことです。メンバーのプロジェクトに取り組む意識が大きく変わり、モチベーション高く業務に取り組むようになりました。このように視点を少し変えて行動することで人生は大きく変わります。エンジニアの皆さんも、「ふりかえり」を導入し、生産性を向上させることで、より良いワークライフバランスを得られることを期待しています。
以上
