生産性向上について
生産性向上について、よく目にする機会が増えました。
DevOps界隈では、ケイパビリティを向上させるために、どのようにするべきかが体系化されており、ここから学ぶことは多いように思います。
生産性向上について、ソフトウェアのコードだけでなく、コンフィグレーションや構成管理などもコード化しましょう、デプロイの痛みを減らしましょう、等の話はとても理解できます。
しかし一方で、それ以前のもっと手前の話での “躓きどころ” に課題を感じることも多くあります。
なんだか時間を浪費する
ソフトウェア開発において、想定外に時間を浪費して客観的な説明責任を果たすのが難しい場合に遭遇することもあるでしょう。
- 丸一日つかったが、成果を得られなかった
- 手探りですすめているが、打開策が見えない
- 1ヶ月経ったが目立った進捗が出せていない
一方で、マネージャー側の視点としては下記のようなものがあります。
- メンバーの時間だけが消費されている一方、進捗が見えない
- 報告のあった進捗率が当てにならない、日付と正比例に上がっていてた進捗率は嘘で、実は今もほぼ0%ではないかという疑い
- 何が起きているか不明、リモートワークで作業が見えにくいが、仕事に時間を当てているか心配
私はプレイヤーでありマネージャーでもあるため、双方の気持ちが分かります。
プレイヤー目線で
エンジニアリングの仕事は非エンジニアにとっては何をしているかわかりにくいケースがあります。
また、対応が難しい事象に遭遇することも珍しくありません。労力がそのまま成果に繋がらない場合もあります。
その際に、白紙の状態で依頼された目的の進捗は0%です。と、報告するわけにはありません。時間に応じた客観的な説明義務があると考えています。
このため、私の場合、「何を考え、何をしてきて、どういう途中成果物があるの？」と聞かれたときに用意できていることを意識しています。
これは日報かもしれませんし、週報かもしれませんし、定例ミーティングのアジェンダかもしれません。
これらの説明義務をうまく果たせなかった場合には、雇用主や顧客から契約を終了されるかもしれないという気持ちでやってきました。
このため、直接的な解決に至らない場合であっても、下記のように進めることが多いです。
- このような仮説のもと、こう進めていくという道筋を共有
- 道筋の分岐ごとの着地点・結果を共有
- 調査結果や検証用の簡易プログラムなど途中成果物を共有
マネージャー目線で
進捗がないという報告だけを毎日受けないように気をつけています。
本当に “ただ進捗がない” 事実だけしか報告がないとしたら、その時間のコストは一体どこに消えたのだろう。と考えねばなりません。
このため、私がよく伝えるのは「思考の途中式で良いから共有してほしい」と伝えます。
綺麗な体裁になっている必要はありません、単純な箇条書きや独り言のようなもので良いので日報やプロジェクト管理ツールの課題に共有してもらうのです。
思考の途中式は、「途中式で汚れた答案」とも言い換えられます。
途中式を見ることで、「あぁ、ここまで考えてくれているのか、確かに問題の仮説としてこの部分は怪しいのでこのまま検証してもらったらいいな」なのか、「見当違いで答えに辿り着くことができない道を登り始めているな」なのかがわかったりします。
具体例
例1: 印刷すると文字化けするという報告への対応
私が対応する場合、このような思考の順序となります。
- 顧客から報告のあった現象をまずは再現しよう
- 普段の自分の環境（MacのChrome）で再現するか
- 再現しなかったので顧客がおそらくつかっているであろうWindows環境で再度確認
- 再現できた
- 報告のあったページだけの問題なのか、それともサイト全体の話なのか確認
- サイト全体の話だった
- 文字化けしている箇所に一定のルールがあるか確認
- 特定のWebフォントが適用された部分であった
- 該当箇所のWebフォント指定を剥がすとどうか
- 解決した
- Webフォント全般的に問題が生じているのか、特定のフォントのみ確認
- 特定のWebフォントのみであった
- 解決へのパターン出し
- 全般的に問題のWebフォント利用を取りやめる
- 印刷用CSSで、印刷時だけ問題のWebフォント利用を取りやめる
- 問題のWebフォント部分のフォントはどうあるべきか
- その他の部分はどのようなフォント指定になっているか
作業担当者の習熟度によって、この途中式がどこまで出てくるかの個人差があります。
もし、問題を再現出来ていないままで解決策を考えているようであれば、「解決したかどうかの判断を顧客を巻き込まないと出来ないとお互いの労力がとてもかかるので、ひとまず手元で問題を再現しよう。」というアドバイスにつながります。
文字化けする箇所のルールがつかめていないのであれば、「不要な部分を削減して、一番シンプルに問題が再現する状態をつくってみよう。そしてそれが再現しないケースとの差分はどこかを調べよう。」と言えます。
例2: 有料プラグインでの要求への対応
例えば、予約管理システムの実装で有料プラグインや何らかの製品を導入しており、顧客からの要望の実現可否を調査する場合は下記のようになるでしょう。
- Google検索などで同じような要求と対応方法が記録されていないか確認
- 製品の公式リファレンスを確認
- サポートへの問い合わせ
- 製品の実装をコードを読んで確認
- データベースでの情報の持ち方などを確認
人によってはGoogle検索で出てくるはずもない情報をずっと探してしまったり、ChatGPTが回答を持たない内容をChatGPTに聞き続けてしまうこともあるでしょう。
その場合は、「公式の開発者用リファレンスはある？もしあればそちらを見て、必要に応じてサポートに聞いてみよう。返答が来るかわからないから、そのあとコードを軽く読んでみよう。それですぐにわかることもあるから」とアドバイスできます。
まとめ
思考の途中式は、まずは本人に考えてもらうことが重要です。
これが「道筋をたて推進する力」につながるからです。
もし、不足している部分や、その判断はどういうインプットから起きたものか不明瞭であれば担当者とディスカッションすると良いでしょう。
本人に途中式を考えてもらう、深く思考してもらうことを経たうえで「ここは、こういう考え方は矛盾してないかな？」と話をすると、一度しっかりと考えているため、スムーズに「あ、それはそうですね！」と簡単にフィードバックが伝わります。
関連記事
弊社のチームメンバーが書いてくれた記事ですが、ここで書かれている「問題点の細分化」はこの記事で言っている内容と重なる部分があり、こちらのほうが人によってわかりやすいかもしれません。