🏃‍♂️

明日へ前進するための(独断と偏見で選んだ)7つの習慣

に公開

こんにちは。ココナラ募集部のカヤと申します。私は社会人になってから、今のココナラが3社目になります。それまで様々な人たちと出会い、そして色々な事を教えていただきました。まだまだ力量が足りないと感じる日々を過ごしていますが、少なくとも新卒の頃よりは幾分ましになったのかなと思っています。

今回はこれまでの自分の経験上で

  • この習慣を身につけておいてよかった
  • この教えが自分を前へ進めてくれた

等と思った習慣やノウハウ・格言などをまとめてみたいと思います。特にタスクや問題をなんとか前に進めるために有用な習慣が多いと思います。ぜひ参考にしてくださると幸いです。

習慣1:許可を求めるな、謝罪せよ

元々はCOBOLの開発をしたグレース・ホッパーさんという方の言葉だそうです。昔から界隈でも参考にしてる方が多くいるイメージです。

“It's easier to ask forgiveness than it is to get permission.”

「許可を求めるより許しを乞う方が容易い」と訳すのが良いと仰っている方もいます。

この考えは、特に何か新しい物事を始めたり、進めるときに、非常に役に立っています
何か新しい技術やわからないことがあって、前に進めるのが不安な時があると思います。関係各所に質問してみたり、妥当性を上司に相談したりするのも大事なことだとは思います。しかし、変化の激しいこの業界では、その時間がもったいないこともあります。

単純な話ですが、「まずは自分でやってみる!」、「試してみる!」、「ダメだったら、すまん、うまくいかなかった...」。変化のスピードが激しいこの業界で生き残るには、スピード感を落とさずに進めることは結構大事だと思います🏃

誤解しないでほしいのが、危険な作業や実装でも許可なくやってしまえ!ということではないです。「なんかよくわからんけど、動いてるし、リリースしちゃお!....あ、なんか本番がバグって迷惑をかけてしまった...」では目も当てられない。適切にルールは守りつつ、スピード感のある判断・行動に繋げていくためには、関係者全員の合意を待つなどのプロセスが過度に民主主義的になるのは良くない事もあります。

まずは試してみる!というスタンスが私たちを身軽にしてくれると思います。

習慣2:スモールサクセス

類似の主張は多く存在しますが、要は物事やタスクを小さく分解して、小さく完成させて進めることが大事という主張です。

新卒の頃に「一気にやろうとしないで!まずは少しずつ進めてみてよ。途中でもいいから」と教えてもらいました。
おそらくまだ未熟な自分の進捗を都度正す意味と、進捗を確認するためだと思いますが、この考え方は自分が社会人になって10年ほど経った今でも役に立っています。

メリットはたくさんあると思っています。

  • 小さく分解して進めているので、途中で失敗しても軌道修正しやすい。
  • 物事やタスクを細かく区切って情報整理にもなる。
  • 小さく成功を積み重ねられるので、少しずつ確実に周りへの信頼貯金が貯まる。
  • 成功が細かく連続的に体験できるのでモチベーションにつながる。

実装時の具体例に焦点を当てると、この習慣はPRの細分化にも活用できます。たとえば、最近チーム内で「PRの粒度が大きすぎてレビューしづらい」という話があったりしました。Claude CodeなどのLLMの登場で自動レビューが盛んな昨今ですが、それでも最後は人間が妥当性を判断する必要があります。人間が見る範囲も限られているので、PRを小さく区切ってくれるとレビューしやすくなります。他にも問題の早期発見や細かい問題についての議論に繋がったりします。議論ができればもっといいコードや知識が手に入るかも👀。

まず、今やっているお仕事を分けられないか?を考えてみると良いと思います。え?進めてみたら失敗した?...大丈夫です。小さく区切っていたので軌道修正も楽です。さっさと「ごめん。間違えた」と伝えて先に進むことをオススメします。

習慣3:WIP = 1

これは「世界一流エンジニアの思考法」の著者である牛尾 剛さんが書籍やブログでも書かれていた内容で、個人的に気に入っている習慣です。

https://www.kinokuniya.co.jp/f/dsg-01-9784163917689

要は WIP(Work In Progress)= 1 。つまり、今手を付けている仕事を1つに限定するということです。

世の中にはキャッチアップしないといけないことがたくさんあるし、タスクも溢れかえっていてどれを優先すれば良いのかわからなくなることが多々あります。いくらAIが進歩して並列実行したLLMが色々やってくれたとしても、最終的な判断等はまだまだ人間がやることが多いと思います。一人の人間が同時にできることには限界があります。

**マルチタスクで色々やってもクオリティもスピードも上がらないので、思い切って目の前のことだけに集中しよう!**ということです。

多忙な方の場合、なかなか難しいことかもしれませんが、

  • TODOアプリで「実施中」のレーンやカテゴリを用意して、それだけに集中する。
  • 絶対それ以外やらない時間を設ける。カレンダーにも自分だけの予定を入れる。

といったことから始めてみると良いかもしれません。ちなみに僕はTODOアプリの方法を実践しています。最近だったらGeminiやChatGPTなどにタスク管理してもらうのが良いかもしれないですね。

これを意識したとしても「どうしてもWIP=1ではうまく行かない...」という場面があるかもしれません。僕の経験上ではあるのですが、そういう場合は大抵優先度がうまく付けられていない場合が多いです(ベンチャー企業で立ち上げ一人エンジニア!とかなら話は別かもしれませんが)。

自分のタスクマネジメントという意味でも、この考え方は有用だと思います。

習慣4:未来の生産性を重要視する

これも世界一流エンジニアの思考法に書かれています。「未来の生産性」と呼んでいます。「木こりのジレンマ」というのも似た話かと思います。

早く、そして後先考えずにまず価値を提供すること。これは企業にとって大事なことです。

とはいえ、その代償として負債化したプロダクトというものが生まれます[1]。この負債を放置したまま矢継ぎ早な対応を続けると、開発生産性はどんどん落ちてしまいます。こうした状況を、少しずつでも解消していかなければなりません。

「こんな生産性向上ツールがあるけど、どうだろう?」、「このライブラリが最近ホットだ!うちの問題も解決しているかもしれない!」。
たまにエンジニアは勉強し続けないといけない職種だ!ということを聞いたりしますが、その本質は自分たちの未来の生産性を高めて、楽して、生きがいのあるエンジニアライフのためなのだろうと、僕は勝手に思っています。

未来の生産性に繋がる具体例として「時間がないときこそ、一度立ち止まってテストコードを書く」ということが挙げられます。これについては、弊社のKさんの最高の記事を再掲しておきます。ぜひご一読ください!!
https://zenn.dev/coconala/articles/write-tests-in-parallel

習慣5:質問する人が偉い

「かやさんは、よく質問をしてくれるよね😊」

そんな評価を何度かいただいたことがあります。わからないことがあるとそれが頭の中いっぱいになってしまう性分なので、早いうちに疑問を解消してしまいたい気持ちが先行してしまうからです。

出自は忘れてしまったのですが、

「質問は恥ずかしいこと」という誤ったメンタルモデルを破壊し、質問を「チーム全体の知識を増やすための素晴らしい貢献」というメリットにつながる

という説明をされているのを見て、より自信を持って質問することができるようになった気がします。学生の時はみんなの前で質問するなんて恥ずかしいという心理がありましたが、今は聞かない方が後々の不利益に繋がります。

https://togetter.com/li/1603943

ただこの言葉を鵜呑みにして、わからないからすぐ聞くというのは少し違うかなと思います。

これは質問の仕方のスキルにも依存しますが、ただただ「わかりません!」では質問された方も答えづらいことも多くあります。AIも一緒。雑な質問でも結構良い感じに回答をしてくれますが、それでも丁寧に論理立てた質問の方がより適切な回答をしてくれることが多いです。

例えば、「自分はここまで調べてみたけど、この部分で詰まっています。次に〜をすればいいと推測していますが、どうすればいいでしょうか?」というように質問すれば、自分の思考プロセスの整理の練習にもなるし、受ける側も理解しやすくなって良い方向に繋がりやすいと思います[2]

slackスレ

5~10分考えてわからなければ聞け!みたいな有名企業の社内ルールも有名でしょうか。とにもかくにも、まずは質問しまくってみることから始めてみるといいかもしれません💪

習慣6:成功の犠牲者(たち)

これはオライリー本のエンジニアリングマネージャーのしごとという本に書かれていた言葉です。これは習慣というには不適切だと思ったのですが、個人的に好きな言葉なので紹介。

https://www.oreilly.co.jp/books/9784873119946/

誤解を恐れずに内容を説明すると、スピードや価値提供のためにプロダクトの複雑性に目を瞑って突き進み、結果一定の成果を得られたが、その後の運用などを任されたメンバーは複雑な環境で苦労することになる、という状態を表す言葉です。本の中では、Individual Contributor(IC)がマネージャーに昇格した結果、マネージャーとしての役割に苦戦する文脈で書かれていますが、別にマネージャーじゃなくてもプロダクトが進んだ後の環境では誰にでも言える呼称なのかなと思いました。

ネガティブな表現に見えますが、「自分たちの今の状況を正しく顧みて、その上でチーム全体を成長させるにはどうすればいいのか?」ということに何度も立ち返ることを思い出させてくれる言葉として、僕の頭の中に強く残っています。

正直に今の自分の気持ちを言うと、ココナラもたくさんの技術的負債がある中で多くの新規事業などを立ち上げないといけない第2創業期のムーブを求められるのはなかなかに大変です。

犠牲者という表現はちょっと良くない気もしますが、ここまでの状況を前提に「僕らは犠牲者として次に何ができるのか?」、「チーム全体として何をしなければいけないのか?」ということを、一度立ち止まってより高い視座と広い視野、複数の視点[3]を持って見つめ直すきっかけになるのではないかと思っています。

習慣7:結果よりも過程(成長)に目を向ける

ここまで色々書いてきましたが...まあ、僕たち人間だし。気分の浮き沈みもあると思います。なかなか気乗りしない時もあります。

以下の書籍で紹介している成長マインドセットというのを持つように暗示すると、気乗りしないタスクも進められるかもしれません。

https://www.kinokuniya.co.jp/f/dsg-01-9784794221780

色々書いてあるのですが、特に報酬や結果に対して喜びや達成感を得るというマインドをやめて、努力した過程に価値があるというマインドを持つという説明が非常に有益だと思っています。

自分が通ってこなかった分野でどうしたらよいかわからなくて気乗りしない時や、あまり成果が見込めないタスクでも、何か自分のスキルや知識に繋がるなどのメリットを、それらに取り組む"過程"に対して見込むということです。

自分に暗示をかけるのです。暗示をかけて解決するなら苦労しない...なかなか実践するのは大変だと思います。

とはいえ、少し遠い結果を眺めているよりも、目の前の過程(成長)に目を向けながら進む方が手軽だし楽しいことが多いのではないかと自分は思います。

まとめ:習慣は大事

長くなりましたが、僕がこれまで物事を進めていく上で大事だと思った習慣やメンタルモデルを独断と偏見でまとめてみました。

今回、このような記事を書くきっかけになったのは、ココナラに素晴らしいカルチャーやバリューはあるものの、より現場のエンジニア・デザイナー・その他の職種の方々が現場で実践できる習慣やメンタルモデルが具体化されておらず、加えてメンバーの増加で考え方や取り組み方にばらつきが出ているように見えました。多様な考えがあることは非常に良いことですが、一つのチームとして働く以上、共通的なマインドセットや文化が根付くと、より強固なOne Team For Missionに繋がるのではと僕は考えています。そのためにもまずは自分が大事にしてる習慣・考えを晒してみることにした次第です。


ココナラでは積極的にエンジニアを採用しています。一緒にココナラに良い習慣・文化を根付かせませんか?

採用情報はこちら
https://coconala.co.jp/recruit/engineer/

カジュアル面談をご希望の方はこちら カジュアルにココナラの魅力やキャリアパスについて詳しく聞いてみませんか?
https://open.talentio.com/r/1/c/coconala/pages/70417


脚注
  1. ここでいう負債とは技術的な負債のことを主に指しています。負債という言葉の定義も難しいと思うので、使い方として適していないかもしれませんが、本題ではないので割愛させてもらいます ↩︎

  2. 質問をしやすくする環境も大事ですね。これはまた話が広がってしまうので割愛 ↩︎

  3. 余談ですが、視座・視野・視点については、僕はこちらのドリコムさんの記事が大好きです。https://tech.drecom.co.jp/viewpoint-of-being-leader/ ↩︎

Discussion