昨日の @daidara_bo さんのjenkinsおじさんの記事からバトンを受け取りまして、
本記事はCocone Advent Calendar 2022の5日目の記事となります。
とある日のご相談
＜ クローリングのシステム、って作ること出来ますか？
皆様なら、この質問にどう答え、どう仕事を進めて行きますか？
そんなお話です。
記事の概要
- 開発あるあるの小話です。
- ココネには入社して間もないのですが、会社が変わっても役に立ちそうかもと思った小話です。
- Qiitaの思想に背いてはいないつもりの小話です。
- 昔の実話ベースで記載しておりますが、特定の立場、職種、人物を下げる意図は全くございません。
記事の目的
- コミュニケーションを意識することで事業全体の生産性を上げてゆけたら良いなあという思いのアウトプット
- 以前から言語化しようと思っていたやつ
ご相談を受けて考えること
さて、本題です。
＜ クローリングのシステム、って作ること出来ますか？
ここで皆様は何を考えるでしょうか。
...Batch処理で良いのか、画面から設定できるようにするのか
...毎日クローリングするのか、1回限りで良いのか
...Slack通知をするのか、どこかにDBで保存しておくのか
...対象サイトはどこなのだろうか。
...対象サイトはそういう行為をしてOKなところなのだろうか
...そもそもクローリングをするのか、もっと単純なスクレイピングを指しているのか
...いつまでに欲しいのだろうか
「クローリングのシステム」というだけでは、色々と情報が足りませんよね。
まずは、上記、クローリングの中でどんな機能が必要なのかを聞いてゆくでしょうか。
忙しかったら一番最後のスケジュールが気になるかもしれません。
しかし、今回の実例では、それを詳細に考えてしまうこと自体が不正解、ということが伝えたい内容となります。
今回の正解
＜おお、良いですね！ちなみにどんなことに困ってて相談してますか？
と返すのが正解です。
（※笑顔と、最初に肯定で入ることも強くお薦めします）
なぜ？
今回の場合で言うと、そしてよくあることと思っていますが、実は相談者のやりたいことはクローリングシステムの構築では無いからです。つまり、上記の「詳細の仕様を考えようとする」こと自体が、本来の課題解決に対しては不要な時間となります。
「やりたいことに対して機能まで突き詰め」たうえで問うことは、システム開発における要件定義の力を必要とするはずで、思っている以上に難易度が高いです。
まして、もしも相談者がエンジニア職種でなかった場合、なおのこと難しいはずです。
相談者が実際に困っていたこと
会話の続きを見てみましょう。
＜ クローリングのシステム、って作ること出来ますか？
＜おお、良いですね！ちなみにどんなことに困ってて相談してますか？
＜ はい、実は、作成したランディングページの一覧資料に対して、タイトルが正しいか、また、リンク切れをしていないかの確認に工数がかかってしまっており、クローリングのシステムを作ることで、この課題が解決すると考えました
＜(...!)
どうでしょうか。相談者の方の思考プロセス自体も、特に誤っている訳ではありません。
しかし、やりたいことをヒアリングすることで、必要な機能だけがtoo muchになっていることが分かるかと思います。
解決の提案
＜ ちょっとだけお待ちくださいね(その場でググり始める 「スプレッドシート タイトル取得」)
＜ 一覧資料ってスプレッドシートだったりしますよね？であれば、その横にこんな感じで書くと、解決しますよ！
=IMPORTXML(A6,"//title")
これを伝えると、相談者の方はとても喜び、結果、相談者の悩み事は解決しました。
いえ、解決してしまったのです、と言うべきかもしれません。
工数の比較
さて、タイトルを回収するため、クローリングシステムを作ろうとした時の工数を見積もって見ましょう。
傾聴せず仕事を進めた場合
※「相談先エンジニアが手を動かさない」が必須になりそうなので、画面を作ることになると思います。
※組織である以上必然的に、相談者だけのためのシステムではなく汎用的な仕組みになるかと思います。
| No | 項目 | 工数（h) | 備考 |
|---|---|---|---|
| 1 | 必要機能の確認 | 1 | 最低限の機能要件の確認 |
| 2 | アーキテクチャ検討 | 4 | インフラ面の調整、費用算出、DBどうするの面、etc |
| 3 | クローリング周りの実装 | 8 | どこまで作り込むか（エラーの場合の再実行とか）による |
| 4 | 画面の実装 | 8 | 地味にパラメータ多くて面倒だと思われる |
| 5 | テスト | 4 | どこまで作り込むかによる |
| 6 | 検収 | 2 | 使い方の説明、相談者のみでの動作確認など |
課題解決まで、最低でも26時間、3.25人日となりました。
実際には、相談者側だったり、実装者側だったり、お互いの上長とのやりとりとか何だかんだワイワイするので1週間くらいかかるんじゃないでしょうか。
傾聴して進めた例
※ Googleの機能を利用しているので、テストも実施済、と言えます。
| No | 項目 | 工数（h) | 備考 |
|---|---|---|---|
| 1 | 傾聴 | 0.1 | 6分 |
| 2 | Google検索 | 0.02 | 72秒 |
| 3 | 組み込みの解説 | 0.05 | 3分 |
課題解決まで、0.17時間、ようは10分くらいでした。
タイトル回収
これはただの数字遊びですが、コミュニケーションの方法1つで、最大で25時間以上の不要な時間が発生していた可能性があります。150倍、生産性が変わりました。
もちろん、傾聴せず進めた場合でもどこかのタイミングで「本当にやりたかったこと」にたどり着く可能性があります。例えば初回の打ち合わせの途中で、30分くらい話して発覚したとしても、3倍以上の生産性の違いが出ます。
これは極端な例だとしても、日頃のコミュニケーション1つを意識することで、生産性がだいぶ変わるのかも、と思って来ませんか？
善意によって生まれる非効率
誰しも最初からやりたいことを聞けば良いのですが、なぜ「この機能出来ますか？」という問いになるのか、過去、色々な人と話し、また、観察していると下記のようなことが原因かもしれないと思っています。
- 質問はシンプルな方が優れていると考え、色々削ぎ落とした結果、「この機能出来ますか？」になる
- 「結論から話せ」と日頃から怒られているため、「この機能出来ますか？」になる
- 忙しい相手を気遣ってYes/Noで答えられるように、「この機能出来ますか？」になる
つまり、より良くしようと考えたり相手を気遣ったり「善意によって生まれる非効率」であるのかもしれないと思っています。または、心理的安全性が低いと、それを拗らせてこうなるケースもあると思います。
まとめ
- 質問時のやりとり1つで、生産性が変わり得る
- 相談者が何に困っているか、を傾聴すると正解に進めやすい
書いてみた雑感
- 心理的安全性の話も書きましたが、こういうコミュニケーションを気軽に出来る会社でありたいと思ったりもします
- フルリモートだと気軽な傾聴の雰囲気を作るのって結構工夫が必要だろうなぁ、と思っています。
- 効率とか非効率とかの話をしていて冷たいように感じますが、たぶん今回の場合だと効率を求めた方がコミュニケーションとしては暖かくなるはずで、その辺りのねじれもちょっと面白いかなと思っています。
明日は再び、 @daidara_bo さんの記事となります。
是非、ご一読頂ければ幸いです！