aritomi.log

チーム運営で考えていること、試していること、失敗したことを書いています。

新規事業開発での技術選定

はじめに

今、新規事業の部署でEMをやっています。新規事業開発で技術選定するとき、何を基準に選べばいいのか...いつも悩ましいなーと思うことが多いです。

新しい技術を試したい気持ちと、事業を成功させたい気持ち。この2つのバランスをどう取るべきかで、ずっと悩んでました。

最近この辺りについて考える機会があったので、自分なりに整理したことをメモしておこうと思います。

新規事業の難しさ

そもそも新規事業開発は、常に不確実性との戦いです。「そのサービスが市場に受け入れられるのか?」がわからないので、基本的に不安定な状況が続きます。

既存事業だとある程度需要が見えている状態ですが、新規事業だとそうはいかない。そのため、仮説を立て、作り、提供し、検証、を繰り返すしかないです。

しかも時間もお金も無尽蔵にあるわけではないので、できるだけ早く市場の反応を見たい...。そうなると技術面で余計な不確実性は持ちたくないというのは、自然な考えかと思います。

技術選定の観点

で、ここが本題なんですが、新規事業での技術選定では「不確実性が高くないもの」を選ぶのがベストだと思ってます。

ビジネス側で既に高い不確実性を抱えているのに、技術面でも不確実性があると、リスクが積み重なってしまう。早く市場検証したいのに、慣れない技術で開発が遅れてしまったら本末転倒です。

具体的には、社内やメンバー内で利用実績がある技術を選ぶのが良いと思っています。慣れてる技術なら開発スピードも出せるし、何かトラブルが起きても対処方法がわかる。新しい技術だと「あれ、これどうやるんだっけ?」って調べる時間が必要になったり、そもそも想定通りに動かないケースも考えられます。

技術面では確実性を重視して、その分のリソースをビジネス仮説の検証に回す。これが事業成功の確率を高めることに繋がると思います。

また、運用コストも重要な観点です。新規事業だとメンバーが少ないケースが多いので、チーム内でなるべく運用する技術を増やさないようにする。そのため、会社内で既に運用されているインフラやサービスに相乗りできるなら、それを利用するのがベターだと思います。

技術的探究心とビジネスリスクとのジレンマ

ただ、エンジニアとしては「新しい技術試せないのは違和感ある」というのも正直なところです。

技術的な成長を求めるのは自然なことだし、新しい技術に触れることで視野も広がる。でも新規事業開発の現場では、それがビジネスリスクになってしまう。これは結構つらいジレンマです。

この解決策として、新しい技術を試す場を別で用意するのが良いと思ってます。Googleの20% ルールやR&Dプロジェクトのようなもので新技術を学び、実績を積んでから本番投入する。会社やチームとしても、そういう仕組みがあるとこのジレンマは解消できると思ってます(*1)。

正直、新規事業開発は「技術だけ試したい」という人にはつらい環境になると思います。事業が当たるかの検証が最優先になるので、技術的な自由度は制限される場面が多い。でもそれは仕方ないことかなと。

おわりに

新規事業開発では、エンジニアの技術的探究心と事業のリスク管理のバランスを取るのが重要だと思います。

本番では確実性重視の技術選定をして、新技術への挑戦は別の場所で。そんな使い分けができると、事業成功の確率も上がるし、エンジニアとしての成長も両立できそうです。

一旦の結論として、こんな感じで考えてます。引き続き試行錯誤していこうと思います。


*1: 弊社だとゴキゲンチャレンジという仕組みがあります。

良いチームにするためにやること

今日も今日とて、ウェットな記事を書いていきます。良いチームにどうやったらなるのかしらというテーマ。

「なんかこのチーム居心地悪いな」とか「みんなもうちょっと協力的だったらいいのに」って思うことがある。一方で、「このチームにいると仕事が楽しい」「みんなで頑張ってる感がある」みたいなこともある。後者にしていくためにはどうしたら良いんだろうと考えていたんだけど、結局やること 2 つしかないんじゃないかと思ってる。

信頼関係の構築

これは人と人が関係をもって円滑にやっていくために基礎の基礎となることだと思ってる。信頼関係がないと適切なコミュニケーションは生まれないし、一緒に頑張って仕事したいと思わないし、それが人間。 信頼関係なくとも自分がやりたいことができて、お金がもらえれば良いという考えの方もいるかもしれないが、自分はそう思っていない。自分のために仕事を続けていると、顧客の価値なんて生まれないと思っている(過激思想)。伸び悩みもするしね。不満も増えるしね。

じゃあどうやって信頼関係を構築していくか。新しく入った環境であれば、仕事ぶりでまず見せる。昭和根性なので自分の場合は、最初の3ヶ月くらいは稼働多めでめちゃくちゃ時間かける。「あーこの人ちゃんと一生懸命取り組む人なんだな」とか「頑張ってくれてるなー」って思ってもらう。ここがスタート。それが前提で日々のミーティングや1on1、雑談等で、会話を増やし、段々と深い話ができる間柄になる。ここにあまりテクニックはないように思っていて、真摯に時間をかけて相手とちゃんと向き合うってことだと思う。

顧客と会社とチームと個人との利害関係を一致させる

ピープルマネジメントと聞くと、人に寄り添って、その人の成長や抱えている課題の解決について、協力していけるかって発想になりがちだった。ある意味正しくて、ある意味正しくないということに気づいてきた。その人のことを真剣に考えて協力していくってのは正しいけど、その人のことだけにフォーカスして判断していくのは正しくない。なぜなら仕事だから。

仕事は、会社が提供するサービスに対して顧客が価値を感じて対価としてお金をいただく。そのお金が会社の運転資金となり、我々の給料となっている。ということは、個人だけでマネジメントしていってもうまくいくわけがないということだ。顧客のためになることを、仕事としてはしないといけない。そうなると大事なのは、顧客と会社とチームと個人の利害関係を一致させることだと思う。

利害関係ってどう一致させるの?って話なんだけど、まずはどういう利害があるのかを明確にしないといけない。顧客や会社の部分は経営層や上司と会話することで知る。それをもってチーム・個人に求められていることを考える。そこまでわかれば、あとは個々人と会話。メンバーが求めていることっていうのを聞き出して、すり合わせる。その時、メンバーの求めていることがすべて満たせないケースってのが出てくると思う。これはしかたない。会話を重ねて、いい塩梅を見つけるしかない。どうしようもなければ会社が合わなかったねって話でしかない。曖昧にしても良いことないからね。

おわりに

偉そうに語ったけど、実践は全然まだまだできていない。そういう考えでチームメンバーと接したい。顧客も会社もチームも個人も、みんなハッピーな状態でやっていけると良いね。頑張ろう。

小さなチームでのコードレビューについて考えていること

最近、開発のリードを任されるようになりました。まだまだ小さいチーム(正社員2名と副業メンバー2名)ですが、頑張っております。

そのチーム運営をやっていくうえで、コードレビューが果たす役割とかウェイトは大きいよなぁと再認識したので、忘れないうちに書いておこうと思う。

レビューは「知識共有の場」

自分は、コードレビューをチーム内の「知識共有の場」として位置づけている。メインの目的は、どういう変更がシステムに加わったのかを全員が把握すること。

もちろん、コードの品質向上やセキュリティ観点でのチェック機能としても重要。 しかし、これらは知識共有に付随して各メンバーのプロフェッショナルな部分で自然に加わってくる要素だと思う。 まずは「全員が変更内容を把握する」ことに軸を置き、その上で各自の専門性を活かしてより良いコードに仕上げていくという形をつくっていきたいと思っている。

この考え方により、レビューが単なるチェック作業ではなく、チーム全体の学習と成長の場になる。 新しい技術的判断や設計思想も、レビューを通じてチーム内に浸透していると思っている。信じてる。

※チーム構成によっては、レビューの位置づけは変えるべきだとは思う。あくまでも一例として🙏

レビュー速度が開発体験を変える

「レビューの初期反応は早いほうが良い」という話は知識としても感覚的にも正しいと思っていたが、実際に体験してその威力を実感したのは結構最近。

以前からなかなかレビューされない問題というものがあり、少し前に意図的にレビュー速度を上げようという話をチーム内でした。 具体的には、PR が出たら Slack 通知、通知がきたらどのタスクよりも優先順位を上げて(障害対応除く)何らかの反応をする、詳細なレビューは後でも構わないから「見ています」という意思表示をする、ということを徹底した。

その結果、開発体験が著しく改善した。 実装→レビュー→実装のサイクルが地続きになっているような感覚になり、コードを書くリズムが途切れなくなった(個人談メンバー談両方)。 さらに驚いたのは、「あれもやろう、これもやろう」という、システムに対する改善モチベーションまで上がったことだ。

コンテキストが保たれ、モチベーションが継続

レビューの待ち時間が短いと、開発者の集中状態やコンテキストが保たれ、結果として、次の改善点も思いつきやすくなり、継続的な改善のサイクルが生まれる。 これは、単にレビュー効率の問題を超えて、チームの開発力全体を底上げする効果があると感じる。全チームでやってほしい。

AIコーディング時代のレビュー運営

Claude Code 等の AI ツールの台頭により、弊チームでも AI が書いたコードの割合が急激に増加している。これにより、思っても見なかった課題が出てきた。

まず、短期間に大量コード(≒ PR)をレビューする必要性が出てきており、レビュアーの負荷増。さらに深刻だったのは、AI が書いたコードをちゃんと把握できていない or 精査できていない状態で PR を出してくるケースが発生したことだ。

この問題に対して、チーム内ですぐに対話を行い、AI コーディングの考え方のすり合わせを行った。考え方の核となるのは「AI は開発者の能力を拡張するもの。最終的な判断は必ず人が行う」という点。

具体的には以下ルールを定めました

  • AI 生成コードの内容は必ず理解しており、説明できること
  • 動作確認やテスト、lint 等を通じて何らかの形で品質が担保された状態であること
  • AI による提案を鵜呑みにせず、チームの設計方針や既存コードとの整合性が考慮されていること

※弊チームではこのくらいの認識合わせで終えたが、その後、弊社の技術責任者からしっかりとした AI コーディングのポリシーも出てきた。流石、頼りになる。

また、技術的な対策として、リポジトリ内に Claude Code のカスタムスラッシュコマンドを定義し、AI によるセルフレビューの仕組みを構築した。これをローカルで実行してもらうことで、PR 提出前にある程度の指摘はしてもらえる状態になった。

AI による開発生産性向上はなくてはならないものになってきている。恩恵を受けつつ、それによって生じた課題も解消しつつ。これは継続的な取り組みになると思ってる。

「わからない」と言える大切さ

コードレビュー時に意図的に「わからないところをわからない」と素直に表明することをしている。

チームの大小にかかわらず、「こんなことを聞いたら恥ずかしい」「わからないと言ったら能力を疑われる」といった心理的な壁が人にはあると思っている。 しかし、レビューというコミュニケーションをする以上、疑問点をそのままにしておくのは絶対ダメだと思う。

チーム内に「わからないところをわからない」と素直に表明する文化を作っていければと思っている。個人の成長にもつながっていくとも思うしね。

おわりに

コードレビュー運営について考えていることを書き連ねた。完璧な仕組みがあるわけではないので、今も試行錯誤の連続だ。

でも、チームで何か問題が起きたとき、チームメンバーときちんと対話し、自分たちの環境は自分たちで改善していこうという意識は大切にしている。ちょっとずつでも前へ進んでいければそれでいい。

この記事が、少しでも、同じようなポジションの方や悩んでいる方の参考になれば幸いです。

トイレは会社の縮図である

◆ はじめに

会社にはトイレがある。

トイレを観察すれば、その会社のマネジメントレベルがわかるし、所属している社員のモチベーションもわかる。逆に、どうすれば改善できるのもわかる。信憑度は占いレベルだ。だがしかし、「トイレは会社の縮図」である。

僕はトイレ掃除が好きだ。学生時、掃除時間に「どれだけトイレを綺麗にできるか」を真剣に考え、掃除をしていた記憶がある。そのため、友人から「トイレマスター」の称号を頂戴した。ジェダイナイトならぬトイレナイトである。だからこそ、トイレに残る些細な情報(汚れ)にも意味を見出してしまうのだ。

ちなみに、ただのネタであり、愚痴である。注意いただきたい。意見の偏りは凄い。

◆ 悪い兆候

トイレを観察すれば、その会社のことがわかると書いた。では、どのようなことがわかるのか、悪い兆候を例に挙げながら説明していきたい。

* トイレ掃除当番が明確に決まっていない

トイレ掃除当番が決まっていないということは、誰かが自主的に掃除をしなければ、掃除がされない状況である。掃除は新入社員がやるものだろ、とか、早く出社した人がやればよくない、とか、掃除好きはほっといてもやるだろとか。どのケースにしろ、昔からの通例、暗黙の了解、自主性依存といった、"やるやらない"を現場の"誰か"に丸投げしてしまっている。

こういった場合、仕事においてもマネジメントがうまく機能していないことが多い。そもそも会社の時間内に掃除時間がある以上、掃除=業務である。その認識においていえば、"誰か"に丸投げしている時点で、業務におけるマネジメントを放棄していることになる。いやいや掃除は業務じゃないから、ということであれば社員がやらなくて済むように業者を頼むなりする必要がある。やはり放棄している。

* 汚したまま放置する

トイレを使用するとき、意図せず汚してしまうことはあるだろう。問題は、汚してしまった後どういう行動が取られているか、ということだ。

1) 汚した本人が掃除している

素晴らしい。僕が無駄なネタブログポストをする必要がなくなる、優しい世界。チームメンバー間の信頼関係も築けており、社員のモチベーションも高い。

2) 汚れを放置しだす

心に余裕がなくなっている、もしくは傲り高ぶっている。社員のモチベーションは低く、卑屈な状態だろう。

3) わざと汚す

わりとまじでやめて。

* トイレが汚い

行き着く先である。誰かが改善アクションをとらないとどうしようもないレベルになっている。マネジメント?モチベーション?そんな話ではない。

◆ どう改善していくか

* 仕組み化

人は弱い生き物であり、変化を嫌う。なので、外部的に無理やりやらざるを得ない環境にし、それを継続、習慣化してしまうのが改善の近道だと思っている。いわゆる仕組み化だ。

トイレ掃除だと、掃除当番表を作成し、やるだけ。あら、簡単。

* 明確化

仕組み化と似た話にはなるが、以下2点を明確に定義するのが良いと思っている。

1) 責任者

誰が、どういうミッションを担っているか、ということ。任された当人としてはミッションを達成する責任感が増し、推進もしやすい。皆、問題意識はあるが、誰も手をつけないみたいな状況を回避できる。

トイレ掃除のミッションは、トイレを清潔に保ち、気持ちよくトイレができる環境を社員に提供することである。このミッションを誰が担うかを決めれば良い。

2) 評価指標

1だけだと弱いので、ミッションに対してどうなったら良いのか、の指標もあると良いと思う。できているのか、いないのか、判断できるし、PDCAも回しやすい。

トイレ掃除でいうと、以下が指標かと思う。 - 毎日トイレ掃除ができている - トイレから嫌な匂いがしない - 汚したら自分で掃除する文化になっているか

* 戦う意思を持つ

トイレ掃除がちゃんとできない会社の文化と戦う意思を持つのも重要。会社の文化はそこに所属する社員によって構築されるものなのである。よって、戦う相手は「社員」である。うまくいっていない原因は、「社員」のどういう振る舞いからなのか、発言からなのか、よく見極めて、意見や改善指摘をしてく必要がある。それをすることで、会社に居づらくなる一方なら、多分会社と自分がFitしていないということなんだと思う。新天地を探せば良い。

◆ まとめ

改めて書くが、ネタである。ネタ的に書いてみたが、それっぽくなったので満足している。社員がトイレ掃除をすべきといった精神論ではない。ネタだ。僕が掃除が好きなだけだ。

「トイレは会社の縮図である」。ネタであることを祈る。