こんにちは、入社3年目となりましたR.Fです。 それは、忙しさそのものが問題なのではない、ということです。 最初に気づいたのは、「忙しい」という言葉が原因として使われすぎている、ということでした。 確かに手は動いています。でも、なぜか物事が前に進まない。 立ち止まって問い直してみると、忙しさの奥には構造的な欠如がありました。 誰が何をしているか、どこで意思決定がなされているか、今どのくらい余裕があるか 「知っている人に聞かないとわからない」が日常になっているチームは、ここに当てはまります。 全員が常にフル稼働している状態です。 余白がないと、予期せぬことが起きたときに吸収できません。 知識・判断・作業が、特定の人に集中している状態、俗にいう「属人化」です。 ここが、この問題の一番厄介なところです。 3つの欠如は、それぞれ別々の問題ではありません。 何が起きているか見えないから、問題への対応が遅れる。 これがまさに、自分たちのプロジェクトで起きていたことでした。 ひとつだけ直しても、ループは止まりません。
この視点を持つと、チームの詰まり方の見え方が変わります。 「なんか最近うまくいってないな」という感覚の裏には、
品質のばらつき、見えないコスト、崩れるスケジュールが複合的に積み重なっています。 問題が起きたとき、現象だけを見るのか、構造を見るのか。 3つの欠如を一気に解消しようとすると、それ自体が大きなタスクになってしまいます。 「なんかうちのチームも詰まってる気がする」と感じている方の、課題を整理するきっかけになれば嬉しいです。 ecbeingではAIに関する記事も公開しております！
普段はプロジェクト運営改善の活動に取り組んでいます。
この活動を続けていく中で、ずっと気になっていることがありました。
「なぜチームメンバーの全員が頑張っているのに前に進んでいる感覚がしないのか」という問いです。
全員が動いていました。でも、プロジェクトは止まっていました。
不思議なことに、誰かを責めることもできない。
ただ、何かがうまく噛み合っていない感覚だけがありました。
この"詰まり感"の正体を追いかけていくうちに、忙しさの奥にある構造的な問題が少しずつ見えてきました。
「忙しい」は原因ではなく、症状だった
この状態を「人が足りない」「時間が足りない」で片付けてしまうと、本当の問題を見逃します。
そして、重要なのは次の3点だと気づきました。
3つの「欠如」が根っこにある
可視化の欠如
——こういった情報が見えていない状態です。
そしてそういうチームでは、判断が必要な場面で誰かを探すことになります。
実際に、進捗を把握しているのが実質一人だけ、という状況がありました。
その人がお休みをとったとき、進捗の確認ができず、「あれ、今このプロジェクトって大丈夫なんだっけ？」という状況になってしまいました。余白の欠如
改善のための時間も、ふり返りのための時間も生まれない。
忙しさが、忙しさを生み続けます。
突発的な対応に追われて計画が崩れ、結果として残業や期限遅延が繰り返し発生していました。形式知化の欠如（属人化）
「あの人がいないと決められない」という状況は、一見するとその人への信頼のように見えます。
でもチームとしては、脆さのサインです。
知識がその人の頭の中にしかなかったために、
急ぎの対応が必要な場面で他のメンバーではうまく進められず、対応が遅れてしまったこともありました。3つは独立していない──「負のループ」という視点
互いが互いを悪化させる構造になっています。 可視化の欠如
↓ 問題への気づきが遅れ、対応が積み重なっていく
余白の欠如
↓ 対応できる人が限られ、頼れる人に負荷が集中していく
形式知化の欠如（属人化）
↓ その人しか知らない情報が増え、全体が見えなくなっていく
↓（最初に戻る）
遅れた対応は、動ける人・判断できる人に集まっていく。
その人の余白がなくなると、情報を整理したり誰かに伝えたりする時間が消える。
——気づいたときには、また「何も見えない状態」に戻っている。
「なんで改善しようとしても続かないんだろう」と感じていたのは、ループの一部だけを直そうとしていたからだったのだと、あとから気づきました。
「ドキュメントを書こう」と決めても、余白がなければ続かない。
「作業を分散しよう」と決めても、知識が属人化していれば移管できない。
これがなぜ改善が根付かないのか、の答えだと思っています。
大事なのは「構造ごと見る」こと
そしてその根っこを辿ると、たいてい3つの欠如のどれかに行き着きます。
この違いが、改善が続くかどうかを決める分岐点だと感じています。
ループを断ち切る「最初の一手」
正直なところ、自分たちも最初はどこから手をつければいいか全くわかりませんでした。
私の場合は配属当初からすでにこの状態だったため、どこがループの起点なのかを特定する余裕もなかったのです。
たとえば、こんなことが実際に起きていました。
進捗を把握しているのが特定の一人だけで、その人がお休みをとった途端に状況が見えなくなる（可視化の欠如）。
復帰後は確認が集中し、その人への負荷がさらに増す（属人化の強化）。
余白がなくなり、ドキュメントを書くなど知識を共有する時間も消えていく（余白の欠如）。
——そしてまた、誰も状況を把握できない状態に戻る（可視化の欠如に戻る）。
どこか一点だけを直そうとしても、ループは止まりません。
それでも何かを変えなければと思ったとき、まず可視化から手をつけることにしました。
3つを同時に解決しようとするのではなく、まず土台として可視化を整えることが、
他の2つへの前提になると判断したからです。
「何が起きているかわからない状態では、何も改善できない」
——形式知化の欠如も余白の欠如も、そもそも問題として認識できていなければ手が打てません。
まず見えるようにすることが、すべての改善の出発点になると考えました。
具体的な内容は機会があればまた別の記事で書きたいと思っていますが、チームの状況に合わせたタスク管理の仕組みの構築や、会議内容の記録・共有といった取り組みを少しずつ進めています。
まだ道半ばではありますが、以前よりも状況が見えるようになってきた実感があり、少しずつ良くなってきている気がしています。
余白の欠如と形式知化の欠如の解消にも、引き続き向き合っていきたいと考えています。
まとめ
お知らせ
ecbeingでは新進気鋭なエンジニアを募集しております！
2つの視点で見るecbeing開発 ──製品開発と案件対応を経験して学んだこと
こんにちは。入社3年目のHです。
私はECパッケージ「ecbeing」の製品開発部門に配属されたのですが、案件対応にも携わる機会がありました。 製品開発は汎用的なパッケージを作る仕事、案件対応はそれをベースにお客様ごとにカスタマイズする仕事です。 同じECシステムでも求められる視点は大きく異なり、その両方を経験する中で、開発において大切なことが少しずつ見えてきました。
本記事では、それぞれの経験で印象に残っているエピソードをもとに、「標準パッケージの機能を理解すること」と「お客様の運用を理解すること」の大切さをお伝えできればと思います。
続きを読む迷わない仕事術──AI時代に「道筋を作れる人」は本当に強い
アイマス20周年の怒涛の供給で心は潤い、財布はカラカラになっている新卒7年目のPです。
最近は、生成AIに自分の考えをぶつけて思考を言語化し、その内容を教育や育成に応用できないかを試し続けています。
その過程で「これは多くの人に共有したい」と感じた気づきがあったため、今回こうして書かせていただきました。
パッケージ開発×AIエージェント導入記
こんにちは！入社2年目のYです。普段は、ECパッケージ「ecbeing」の製品開発を行っています。
パッケージ開発では、コードベースが大きいため既存コードの読み解き・影響調査に時間がかかります。そこで業務効率化のために、部署としてAIエージェントを試験導入してきました。具体的には、GitHub Copilot → Claude Code → Codex の順に、各種AIエージェントツールを使いこみました。
本記事は、各エージェント活用時の所感とポイントをまとめたものです。あくまで私の環境での実感値ですが、これからAIエージェントを導入する方の参考になれば嬉しいです。
続きを読む「勘で改善するな、まず計測せよ」──SQLチューニングで40秒が1秒になった奮闘記──
こんにちは。入社2年目でSEをやっているT・Sです。
ECサイトで改修をした際に、「カート処理が異常に遅い」という報告が舞い込んできました。 通常なら1秒程度の処理が、特定の条件下で40秒以上もかかってしまう。ECサイトにとって、これは致命的な問題です。
この記事では、その問題をどう分析し、どう解決したのか。その一連のプロセスを、ストーリー形式でサンプルコードと比喩を交えながらご紹介します。
単なるテクニックの羅列ではなく、「勘で改善するな、まず計測せよ」という原則に基づいた、パフォーマンスチューニングの思考プロセスをお伝えできればと思います。
続きを読む
スクラムとウォーターフォール開発を経験してみて
はじめに
こんにちは。入社4年目のバッキーです。
今回は、私が経験した開発手法の大転換についてお話しします。
これまで担当していたスマホアプリ開発では、1週間単位で進めるアジャイル（スクラム）開発が中心でした。
しかし、3年目の夏から主力製品である「ecbeing」の開発チームに異動し、全く異なるウォーターフォール開発の現場に飛び込むことになりました。
このブログでは、私が感じたこの環境変化のリアルをお届けします。
続きを読む