雇用機会もとい成長機会

Yoshitaka Akashi — Tue, 08 Sep 2026 08:44:46 +0000

IT業界では、雇用機会、成長機会がなく埋もれてしまっている才能が数多にあると思っている。機会がない理由としては様々あると思うが、経済的原因や人口的原因などどうしても贖えないこともある。
しかし、埋もれた才能をそのままにするのも勿体無いが、国内か海外かで状況は変わるもの。言葉の壁や文化の壁。かなり難しいハードルではあるが、わざわざ超える必要も
ないと考えている。今では通訳アプリがあり、言葉のコミュニケーションはほとんど問題ないと言っても良い。もちろん、お互いの尊重し合うことは必須だが。

そこで、国籍や働く場所も関係ない、ネットを通じて求人と求職者をつなげる仕組みを構築したい。もうすでに存在するのであれば、そのサービスに携わりたい。

働けるフィールドが世界中だと実感した時、新たな世界観が見つかるのではないでしょうか？
同じ考えの人と繋がりたい。

I believe there is a great deal of untapped talent in the IT industry that remains hidden due to a lack of employment and growth opportunities. While there are various reasons for this lack of opportunity, some—such as economic and demographic factors—are simply unavoidable.
However, it would be a waste to leave this untapped talent unutilized, though the situation does vary depending on whether one is working domestically or abroad. Language and cultural barriers are significant hurdles, but I don’t think it’s necessary to go out of one’s way to overcome them. Nowadays, with translation apps available, it’s safe to say that language communication is hardly an issue—though, of course, mutual respect is essential.

That’s why I want to build a system that connects job openings with job seekers via the internet, regardless of nationality or location. If such a service already exists, I’d like to be involved in it.

When you realize that the world is your workplace, don’t you think you’ll discover a whole new perspective?
I want to connect with people who share this vision.

Translated with DeepL.com (free version)

About the Project Management Intership

Yoshitaka Akashi — Sun, 28 Jun 2026 06:37:41 +0000

はじめまして。
長いこと一エンジニアとしてキャリアを積んできましたが、
現場の状況からPMをやることになり、感じたこと、自分の至らないと感じてどのようにアプローチしたかをここに記します。

まず、何をすべきか？どのような役割分担にするか？
ここは明確になっていました。しかし、そのためのスキルやコミュニケーションルールが定まっていないが故にプロジェクトはほぼ崩壊していました。
・何を作れば良いのかわからない
・何のために作っているのかわからない
・どのように作れば良いのかわからない
・設計書を読んでも理解できない

そもそも、プロジェクトで想定されいた言語や環境などについて、未経験でアサインされていたこと、詳細設計書でなく、プログラム設計書が作成されていたことなど原因はありますが、一番に課題と感じたのは、ステークホルダー、設計者とエンジニアの橋渡しがいないことだと感じました。
橋渡しがいないが故に、それぞれの要求や思想などが伝わらず、プロジェクトが頓挫したのでは、と。

そのため、私は橋渡しをすることを決めました。
具体的には、
・要求を言語化する
　プログラム設計書だとどのような要求があり、どのように実現するのかが曖昧だったため、要求を言語化し、それを設計書とするよう、設計者に依頼しました
・プログラムを骨組み化する
　プロジェクトに要求されるスキルを満たしていなかったため、骨組みを作成し、それらを真似ることで作成できるようにする。また、難易度の高い機能については私自身が引き取って対応しました。
・現実ベースの報告をする
　当たり前と思われるようですが、ステークホルダー、設計者とエンジニア間での工数のミスマッチもかなり大きかったため、現実ベースの工数を提示してスケジュールを調製しました。

大まかには上記が主にやったことです。
細かいところだと、どのようにメンバーのスキルを上げるか、どのようにコミュニケーションを取れば上手く回せるか、など多岐にわたります。
しかし、前提としてどのポジ

Nice to meet you.
I’ve spent a long time building my career as an engineer,
but due to circumstances on the ground, I ended up taking on the role of project manager. Here, I’ll share my thoughts on the experience, as well as the areas where I felt I fell short and how I addressed them.

First, what needed to be done? How should responsibilities be divided?
These points were clear. However, because the necessary skills and communication guidelines hadn’t been established, the project was on the verge of collapse.
・People didn’t know what to build
・People didn’t know why they were building it
・We didn’t know how to build it
・We couldn’t understand the design documents even after reading them

There were several underlying causes—such as the fact that I had been assigned to the project with no prior experience in the programming language or development environment it required, and that a program design document had been created instead of a detailed design document—but the primary issue I identified was the lack of a bridge between the stakeholders, designers, and engineers.
I suspected that the project had stalled precisely because, without this intermediary, the respective requirements and ideas of each group were not being communicated effectively.

Therefore, I decided to take on the role of that intermediary.
Specifically, I:
・Articulated the requirements
　Since the program design document was vague about what the requirements were and how they would be implemented, I asked the designers to articulate the requirements and use that as the basis for the design document.
・Creating a program framework
　Since the team lacked the skills required for the project, I created a framework so that others could build upon it by following its structure. Additionally, I personally took charge of handling the most challenging features.
・Providing realistic estimates
　While this may seem obvious, there was a significant mismatch in effort estimates between stakeholders, designers, and engineers, so I presented realistic estimates and adjusted the schedule accordingly.

Broadly speaking, these were the main tasks I undertook.
On a more granular level, my responsibilities spanned a wide range of areas, such as how to improve team members’ skills and how to facilitate effective communication to keep the project running smoothly.
However, my overarching priority was to build relationships of trust with everyone in every role.
Even when asked to do something that was beyond our capabilities, instead of simply saying “We can’t do that,” I would say, “We can do this.”
I believe that by promoting “This will work” over “No,” we can move forward to the next step, build trust with stakeholders and designers, and ultimately produce a higher-quality product.

If asked whether this is the best approach, I do have my doubts. After all, we encounter various challenges and face dilemmas as we move the project forward.
While finding the best solution is a given, I also value the overall atmosphere. If I can make everyone feel that being part of this project was worthwhile, there’s nothing better than that.

I’m still a work in progress myself.
There’s still so much I need to learn.
I hope this can serve as a guidepost for others taking their first steps on a similar path.
*I’d be even happier if we could exchange opinions with others in similar situations.

Translated with DeepL.com (free version)

DEV Community: Yoshitaka Akashi

雇用機会もとい成長機会

About the Project Management Intership