2024.12.19
システムの穴を運用でカバーしようとしてミス多発… バグが大量発生、決算が合わない状態から業務効率化を実現するまで
リンクをコピー
記事をブックマーク
花川直己氏(以下、花川):こんな感じで2日間やってみましたが、「なんだか様子がおかしい。なんかうまくいっていないな。なんでだろうな」と。イマイチ噛み合っていない感覚がありました
「なんかおかしいな」と思ったら、我々は絶対やることがあります。そう、「ふりかえり」です。毎回1日癒着するたびに、「今日どうだったかな?」と振り返ってみました。KPTみたいに、「KeepとProblemをまじめに考えてTryをしよう」といったカッチリしたものではなく、もっとラフに「感想だけでいいよ」「今日思ったこととかをラフに書けばいいよ」くらい。
ふりかえり自体が負担になるのがすごく嫌だったので、簡単に書いてもらって、それを見て僕がどう直していくかを考える意図で、すごくラフにやっていました。
書いてもらったことをベースに、次の日どうやろうかを、僕がやり方を変えて試してみるようなトライアンドエラーをずっと繰り返していました。もちろんこのふりかえりには、当然「これがよかった」のようなことは書いていいよ、と伝えています。
2日やって見えてきた問題。僕はJohnを見ながらやっているので、手が止まったな、John悩んでいるのかな、とか。Johnがけっこうリアクション薄いので、大丈夫かな、と思って僕が話しすぎちゃう問題。
僕がJohnの状況を、うまく把握できていなかった問題がわかってきました。Johnとしては手が止まっているのは、わからないから止まっているんじゃなく、わかっているんだけど「この問題をどう解決しようか」とか、そういったものを考えているステートでした。そこでミスマッチが発生していたり。
実はわかっているんだけど、詳しく説明されているので、言いづらいような。そういった状態でした。Johnとしては、自分が置かれている状況や感想をうまく発信できていない、2020年リモートワークが流行った頃によく出てきた“コミュニケーションのミス”がすごく発生していた、ということが見えてきました。
「ふりかえり」で見えてきたから、修正していこうと。手が止まった、それは実は悩んでいるんじゃなくて、考えているだけだというところでは、Johnは長考タイムというかたちで「今考えているのでちょっと待ってください」みたいなことを宣言する仕組みを導入しました。
Johnがこれを宣言したときは、僕は「じゃあ何分待つね」のような感じで、ちゃんと時間を区切ったうえで、邪魔をしない仕組みを作りました。
あと「リアクションないな、大丈夫かな?」というのは、とりあえずJohnに「今何をしようとしているかを、口に出すことを意識してもらっていいかな?」とお願いしました。これも慣れなので、最初はどうしてもできないんですが。慣れないとどんどんできなくなるので、慣れてもらうという意味でもお願いしました。
一方で、ここはなにか仕組みや方法でうまくできないかなということで、僕が引き続きうまくいくことを考えていくことにしました。できるだけコミュニケーションを重視して、お互い理解していくことを意識するように修正していきました。
変えてみて、またやってみて。さらにまた別の問題が出てきました。このときのやり方は、最初言ったようにJohnがずっとドライバーをやって、僕がサポーターをやるかたちでした。Johnはわかっているんだけど、どう書けばいいか思いつかなくて止まる。
あと実装していくうえでコードを読むと、「ここってどういうふうに動いているんだろう」って疑問が出てきます。僕としては「ここはこんな処理を書けばいいのにな」って横で思ったり、「ここはこういうことやってるんだよ」みたいなことを思って話しますが、Johnは僕が口頭で話しても理解が追いつかないというか。Johnはこのとき「わからない」と教えてくれたんですが、聞いていて「え?」っていう状態が発生してしまいました。
あと、Johnが「ほかの人の仕事の様子が見たかった」という、もともと発信していた知りたいことが、実は解決できていないことに気づきました。
ここで原点に立って、「ちくしょう、こうなったらペアプロだ!」ということで。ペアプロの正しいメソッドを導入しました。ちゃんとドライバー、サポーターを交代して、お互いにコードを書いて開発していきましょう。ただ、ペアプロだとサポーターが指示を出してドライバーは基本的に手を動かすだけですが、そこは少し変えています。
Johnがドライバーをするときは質問オーケー。「naosukeさんどうやっているんですか?」みたいに聞いたりとか。あと、書きながら「ここどう書くかわからない」というのを、できるだけコメントを残してくれとお願いしました。
一方で僕は、「わからない」と書いたコメントに対して一気に解説をしたり、「どう書けばいいのでしょう?」と、できるだけ“指針”というかたちで、コメントベースでコードを書くかたちでドライバーをしていく方法でやっていました。
お互い質問したり、「ここはこうなんだよ」と解説するのはオーケー、というレギュレーションです。もちろん、ふりかえりをしながら少しずつ工夫していきました。やはりペアプロってすごいもので、この形式を採用すると、すごくいい感じに仕事が捗るようになってきました。
最終的には画面共有で全体を見せつつ、LiveShareを使ってエディタはエディタで別途同期する。必要があったら、iPadとかApple Pencilを使って図を描いて解説する。こういうかたちで落ち着いてきました。
少しずつ試行錯誤しながら、無事バグ修正Doneになって、コードもマージされて。癒着完了と、ぴったりくっついた状態になりました。
こういった取り組みを1ヶ月してみて、Johnに「どうだった?」って聞いてみました。まず感想ヒアリングすると、「すごくよかった」と。気軽に質問できたり、ほかの人の仕事の進め方を通して「こう進めればいいんだ」ってわかったり、コメントベースのコードが、道標を出してもらって、長考が減ってスムーズだったと。
一方で、「先輩社員と新入社員の2人分の稼働が使われているので、やはり焦りや不安が生まれてしまう」という感想をもらいました。あとはコミュニケーションの負荷が高いとか、けっこう体力を使うようなことを改善、もうちょっとうまくできたらいいね、と感想をもらいました。
僕的にこういうのを聞きながら考察すると、オンボーディングのペアプロは、うまく空気作りができると感じました。本当はドキュメントに書ききらないといけませんが、書くまではいかない細かいノウハウを口頭で話したりとか。
タスクに関連した周辺知識を、ふと「こういうことなんだよ」とインプットできたり、そういったメリットがすごくありました。
考慮すべき点としては、気合いでどうにかするにしても、やはり体力を使う。あと口数が少ない子はペアプロが合うのかな、と。先輩社員的には、理解度の見極めがかなり難しいとすごく感じました。
そのため、初手でペアプロやって終わりとか、単発でやるというよりは、例えば「最初の時期」「入ってしばらく経った時期」「もうしばらく経った時期」みたいな感じで、定期的にやっていくのがよさそうだと個人的には考えています。
そういうことをしながら、“ぼくのかんがえるさいきょうのペアワークベストプラクティス”。特に今回みたいな新入社員+古い社員という構成でやるにはどうしたらいいかと考えたら、環境としてはやっぱりVSCodeとLiveShareが、同期もなかなか優秀なので、これを使うのがいいかと思います。
一方で、画面全体を共有したうえで、個人の進め方の共有で、 Google Meetなどを使ってやるのがいいのかなと。お互い何をやっているかを、無駄な忖度をできるだけなくしてやったほうが、脳の負荷を下げられる、ペアプロに集中できるようになります。
時間設定としては90分から120分を1回として、終わったらちゃんと休憩して、続くならまた90分から120分というかたちでやるのがいいかなと。けっこう想像以上に、脳の負荷がかかります。90分、120分やってもけっこうヘロヘロなので、これ以上やると絶対集中力が保たない感じです。
Driver timeを非対称にして、新入社員を少し長めにDriver timeを取ります。というのも、ペアプロ中にインプットと高度なアウトプットでけっこう複雑な処理をしなきゃいけない。新入社員は脳の整理をしながらコードを書いてもらうかたちで、少し多めに時間を設定しておいたほうがいいかと感じます。
逆に、古い人たちはさっさと手を動かしちゃうので、新入社員があんまり力を得られなくなります。逆に既存社員は、ちょっとセーブするかたちで、短めに設定したほうがいいです。
これはペアプロによくありますが、やっていることは全部口に出せ、という話があります。同じことですが、オーバーヘッドをなくす。先輩社員はコードを書きすぎない。あくまで新入社員のパワーアップが目的です。「俺強ぇ!」ってやりたいならやりたいでいいから、別のペアプロ、同じ立場の人たちでペアプロやるときにやれと(笑)。
ふりかえりをして初めてわかったことですが、やはりちゃんとふりかえりをして、問題点を明らかにして少しずつ変えていかないと、なかなかうまくいきません。
新入社員としては、困っていることが本当に解決できているかを考えるきっかけになるし、先輩社員としては新入社員が困っていることを知れたり、やり方として合っているかを評価するきっかけになります。
それを踏まえたうえで、いろいろ考えることで、パワーアップを促せるよりいい方法を考えついて、最終的にチーム全体のパワーアップにつながる、すごくいいサイクルが回せます。やはりふりかえりはすごく大事かと思います。
まとめとしては、新入社員に癒着をした結果、なかなかいい感じに進みました。さっきも言いましたが、最初にやって終わりではなく、機会を開けて定期的にやっていきます。
新しい知識のインプットや、やればやるほどわかってくること・わからないことを、少しずつ明らかにしていくチャンスです。このご時世だったので、リモート自体がすごくやりやすくなってきました。
とはいえ、理解度を測っていくのはすごく大変なので、そういう意味で言うと、僕たちは癒着がまだ始まったばかりです。まだスタートラインに立ったばかりなので、これからもどんどんレベルアップしていかなきゃいけないと感じています。
こんな楽しい癒着をしたい人たちは、現在求人中なので、ぜひみなさん応募してきてください。naosukeの発表は以上になります。ご清聴ありがとうございました。
2024.12.12
会議で発言しやすくなる「心理的安全性」を高めるには ファシリテーションがうまい人の3つの条件
2024.12.19
12万通りの「資格の組み合わせ」の中で厳選された60の項目 532の資格を持つ林雄次氏の新刊『資格のかけ算』の見所
2024.12.16
32歳で成績最下位から1年でトップ営業になれた理由 売るテクニックよりも大事な「あり方」
2023.03.21
民間宇宙開発で高まる「飛行機とロケットの衝突」の危機...どうやって回避する?
2024.12.10
メールのラリー回数でわかる「評価されない人」の特徴 職場での評価を下げる行動5選
2024.12.13
ファシリテーターは「しゃべらないほうがいい」理由 入山章栄氏が語る、心理的安全性の高い場を作るポイント
PR | 2024.12.20
モンスター化したExcelが、ある日突然崩壊 昭和のガス工事会社を生まれ変わらせた、起死回生のノーコード活用術
2024.12.18
「社長以外みんな儲かる給与設計」にした理由 経営者たちが語る、優秀な人材集め・会社を発展させるためのヒント
2024.12.12
今までとこれからで、エンジニアに求められる「スキル」の違い AI時代のエンジニアの未来と生存戦略のカギとは
PR | 2024.11.26
なぜ電話営業はなくならない?その要因は「属人化」 通話内容をデータ化するZoomのクラウドサービス活用術
Climbers Startup JAPAN EXPO 2024 - 秋 -
2024.11.20 - 2024.11.21
『主体的なキャリア形成』を考える~資格のかけ算について〜
2024.12.07 - 2024.12.07
Startup CTO of the year 2024
2024.11.19 - 2024.11.19
社員の力を引き出す経営戦略〜ひとり一人が自ら成長する組織づくり〜
2024.11.20 - 2024.11.20
「確率思考」で未来を見通す 事業を成功に導く意思決定 ~エビデンス・ベースド・マーケティング思考の調査分析で事業に有効な予測手法とは~
2024.11.05 - 2024.11.05