はじめに スクラムのルールブックであるスクラムガイドにある通り、スクラムは「経験主義」と「リーン思考」に基づいています。また、この経験主義は「透明性」、「検査」、および「適応」により実現されているということはご存知かと思います。 この「透明性」、「検査」、および「適応」が可能な状態にするためには、チームメンバが互いに臆する事なく発言し合える状況がとても大切です。スクラムで定義されたイベントを効果的に進めるためにはチームメンバの発言が不可欠です。一方で、たとえチームメンバの前であっても、人前で話をする、意見をするということが苦手な人は多いのではないでしょうか。このような状況を打破するた

はじめに ビジネスdアプリ開発チームの徳原です。 私は地元の金融機関で12年間営業職として勤務した後、IT業界へキャリア転換しました。 本記事では、これまで私が転職で経験したことやキャリアの自律に向けた取り組みについて紹介します。 目次 はじめに これまでのキャリア 金融機関からIT業界へ 前職(外資コンサル)でのSE業務 キャリアを動かしたきっかけ 継続的な学習 前職のインフラ運用業務で苦戦したこと 前職のアプリ開発で苦戦したこと 現職へ転職することになったきっかけ 現職の業務とキャリアの広がり 学習の支援 外部発表の機会 現職のアプリ開発について これまでの経験から感じたキャリアの自律 おわりに これまでのキャリア これまでの私の経験を簡単にまとめました。 地元金融機関で営業12年 外資コンサルにSE転職 営業資料作成（希望外の業務）→インフラ運用→アプリ開発(入社時に希望した業務) ドコモビジネス入社 ビジネスdアプリ開発 金融機関からIT業界へ 金融機関では、主に個人のお客さま向けに金融サービスの営業を担当していました。 定期貯金の契約、年金の請求手続き、保険の契約、相続に関する相談など、生活に関わるさまざまな手続きをサポートしていました。 担当するお客さまは常時数百世帯にのぼり、多くの相談に対応する中で大変な場面もありましたが、「相談して良かった」「以前提案してもらった保険が役に立った」といった言葉をいただけたときは大きなやりがいを感じました。 一方で、日々の業務では申込書や稟議書など紙を中心とした手続きが多く、関係部署とのやり取りに時間がかかることに課題を感じていました。 そうした経験から、テクノロジーによってこれらの手続きを効率化できれば、より多くの価値を提供できるのではないかと考えるようになりました。 ちょうど世の中でDXという言葉が広まり始めた頃でもあり、「デジタルの力で世の中の非効率な業務を改善したい」と思うようになりました。 そしてエンジニアという仕事に興味を持ち、思い切ってIT業界へ転職することを決意しました。 前職(外資コンサル)でのSE業務 転職直後に担当したのは開発ではなく営業資料の作成業務でした。 希望していた職種ではなかったためとても残念でしたが、転職当時ITスキルがほとんどなかった自分を採用してくれたことを考え、まずは目の前の仕事をやり切ろうと決めました。 キャリアを動かしたきっかけ きっかけは小さな行動からでした。 上長が行政DXのプロジェクトを兼任していることを知り、「そちらも手伝わせてください」とお願いしました。 当時はすぐに参画できませんでしたが、前向きに検討してもらうことができました。 そこで諦めず、引き続き交渉を続けていきました。その結果、半年後にはそのプロジェクトのクラウドインフラ運用を兼務できることになりました。 しかし、私が本当にしたいのは開発業務でした。このプロジェクトにはアプリ開発チームがあると知り、また希望を出し続けることにしました。最初は少しずつ関わらせてもらうところからでしたが、最終的にはそれまでの業務との兼務という形ではなく、専従でアプリ開発業務を担当しました。 開発業務ではプログラミングだけではなく資料作成やインフラ環境の構築もあり、振り返ると一見バラバラに見える経験が、後々全て必要なスキルとなりました。 当時は無駄に思っていた仕事でも、後々経験となって活きてくると感じました。 継続的な学習 転職前や転職後、さらに新しい業務に踏み出す際には、自主的に学習を進めることを意識していました。 挑戦の機会に合わせて学習を継続したことが、新しい領域へのチャレンジを後押ししてくれたと感じています。 前職のインフラ運用業務で苦戦したこと インフラ運用では、デプロイ作業やインフラ構築を担当しました。 ステージング環境の構築手順を1つ飛ばしてしまい、検証用サーバへログインできなくなるトラブルを経験したことがあります。 この出来事をきっかけに、手順書の整備と手順を1つ1つ確認しながら進めることが安定した運用につながると強く意識するようになりました。 前職のアプリ開発で苦戦したこと 前職で初めてJavaによるウォーターフォール型の開発に参画した際、Railsでの開発との違いに戸惑いました。 Railsは規約が強く、ある程度のレールに沿って実装を進めることができますが、Javaでは設計書を読み込み、クラス構成やレイヤー構造を理解しなければ実装に着手できません。 特に、インターフェース設計や影響範囲を考慮した修正対応など、「動かす前に考える」文化への適応に苦戦しました。 一方で、この経験を通じて設計の重要性とレビューの重要さを学ぶことができました。 現職へ転職することになったきっかけ 開発エンジニアとして業務に携わる中で、次第に「企画に近い立場でサービスを作りたい」と思うようになりました。 単に要件に沿って実装するだけではなく、ユーザーの視点やこれまでの経験を活かしてサービスの価値そのものに関わりたいと考えるようになったためです。 そうした中で、ドコモビジネスではサービスの企画・開発・セールスまでを自社で一貫して担う体制に大きな魅力を感じました。 自分もそのような環境で、サービスに近い立場から開発に関わりたいと考え、応募しました。 現職の業務とキャリアの広がり 現在は、スクラムをベースとしたアジャイル開発でビジネスdアプリの開発に従事しています。 開発と企画が一体となり、ユーザー価値を短期間で届ける開発スタイルを実践しています。 前職では受託開発として要件に沿った実装する立場でしたが、現職では企画段階から議論に参加し、サービスの方向性を検討する立場で業務に関わっています。 営業時代に経験した業務理解をもとに、実際の利用シーンを踏まえた改善提案を意識しています。 たとえば社内報のPCブラウザ版開発では、中小企業の利用実態を踏まえたPC導線の必要性について意見を出し、検討の一要素として取り入れていただきました。 単に実装するだけでなく、「なぜこの機能が必要か」を議論できる環境にあることは、前職との大きな違いです。 転職後に経験した営業資料作成・インフラ運用・開発経験といった一見異なる業務が、現在の職務でも活かされていると感じます。 現在は、企画〜実装〜改善まで一貫して関われる環境であり、想定していたよりもサービスに近い立場で仕事ができていると感じています。 学習の支援 これまでは自主的に学習を進めてきましたが、現職では資格取得の支援制度が整っており、明確な目標を持ってスキルアップに取り組める環境があります。 上長に取得したい資格を申告し承認を得ることで、受験費用・外部研修の費用を会社側で負担してもらえます。 資格取得が単なる自己満足ではなく、組織として推奨される目標の1つになっている点は、非常にありがたいと感じています。 外部発表の機会 社内外への発信も推奨されており、テックランチやエンジニアブログでの発信機会があります。 また、Google Cloud Next Tokyoでの登壇、Google Cloudとドコモグループ共催イベントでのハッカソン優勝された方など、社外イベントで活躍されているチームメンバーもおり、外部発表が1つの目標として位置づけられています。 自分自身もテックランチやエンジニアブログ執筆を通じて、これまで経験したことや学んだことを発信する機会をいただいており、アウトプットしながら学ぶことを実践できています。 現職のアプリ開発について React開発では、型定義や状態管理の理解に苦労しました。 特にTypeScriptの型設計や、状態の責務分離については、実務を通じて学ぶことが多くありました。 コードレビューでは、パフォーマンスを意識した設計、再利用性を高めるコンポーネント設計、可読性を意識した実装といった観点でフィードバックをいただき、改善を重ねています。 またペアプロ・ペアレビューや生成AIを活用しながら理解を深め、品質向上を意識した開発に取り組んでいます。 モバイルアプリ開発に限らず、1つの機能をフロントエンドからサーバ、分析基盤まで横断して担当できることも大きな特徴です。 サーバレスを前提とした構成のため、インフラ構築の負担が比較的少なく、機能開発や継続的な改善に集中できる点も魅力の1つです。 ビジネスdアプリについては過去の記事をご覧ください。 サーバレスをフル活用したビジネスdアプリのアーキテクチャ [前編] [後編] ビジネスdアプリの社内報PCブラウザ版リリース：レスポンシブ対応とGTM導入で実現した開発効率化 これまでの経験から感じたキャリアの自律 終身雇用が前提ではない今の時代、「会社が面倒を見てくれる」前提でキャリアを考えるのは難しいときもあります。 だからこそ、学び続けることと、行動の積み重ねがキャリアの自律につながるのだと思っています。 おわりに 金融営業からIT業界へのキャリア転換は、業務内容や求められるスキルが大きく変わる挑戦でした。 不安や戸惑いを感じる場面も多くありましたが、実務を通して学び続けることで少しずつ役割を広げていくことができました。 キャリアは一度の異動や抜擢で大きく変わるものではなく、日々の業務への向き合い方と学習の積み重ねによって形づくられていくものだと感じています。 本事例が、今後のキャリア形成や新しい分野への挑戦を考える方にとって、1つのヒントになれば幸いです。

NTTドコモビジネス イノベーションセンター テクノロジー部門 MetemcyberPJでの経験を通じ、私は「自分でやり切ること」と「チームとして成果を出すこと」のバランスの重要性を学びました。若手社員でも幅広い業務に挑戦できる環境の中で、責任感を持ちながらも周囲と協力することで、個人の成長とチーム成果の両立が可能であると実感しています。この記事では、その経験から得た学びと実践のポイントを紹介します。 はじめに 若手でも幅広く挑戦できる環境 スクラムという前提 私が経験した「抱え込み」 タスクの優先順位のつけ方 最後に はじめに こんにちは。イノベーションセンター テクノロジー部門 MetemcyberPJの2年目社員、千坂知也です。 私は1年目の8月からMetemcyberPJに参画し、OSSコントリビューターとして開発業務に携わってきました。 はじめのころは主に開発コードを書くことに注力していましたが、2年目になってからは、他メンバーのコードレビューやマージ、デプロイ作業など、開発プロセス全体に関わる業務も任されるようになりました。また開発以外の案件支援業務にも携わる機会をいただきました。 こうした経験を通じて、単なる技術力のみならずチームで成果を出すための働き方や考え方についても多くの学びがありました。 そして、自分の成長を大きく感じた一方で、「自分でやり切ること」と「チームとして成果を出すこと」のバランスの難しさも同時に実感する経験をいたしました。 そこで、「自分でやり切ること」だけでチームは強くならないということを本稿にて述べたいと思います。 若手でも幅広く挑戦できる環境 MetemcyberPJでは若手社員であってもコード実装だけにとどまらず、他メンバーのコードレビューやデプロイ、また開発以外の案件支援など、幅広く経験できます。こうした経験を通じて技術的な知識のみならず、チームとしての開発体制のあり方なども学ぶことができます。 また、学ぶだけではなく、改善につながる意見があれば、若手社員であっても発言できます。そして、その意見がチームにとって有益だと判断されれば、柔軟に取り入れてもらえる文化があります。 私自身も、2年目でこうした役割を担当するようになり、自分の視野が大きく広がったと感じています。単にコードを書く力だけではなく、次の観点の視野を持つことが出来ました。 ユーザーにとって必要なものは何か 今チームとして開発は順調に進んでいるか 若手社員の意見も柔軟に取り込んでもらえる環境のおかげで、先輩任せにするのではなく、自分自身の責任感も強まり、成長につながっていると感じています。 一方で、私自身がその責任感を持ちすぎたあまり、うまく動けなかった経験もしました。 若手社員の場合、次のような考え方に陥りがちなこともあります。 自分の担当業務だから最後まで自分の力でやろう！ せっかく任せてくれたのだから最後までやり切りたい！ こうした意気込みは大切ですが、行き過ぎると周りが見えなくなることもあります。 さて、私自身のこのような経験について少し話してみたいと思います。 スクラムという前提 MetemcyberPJでは、スクラムというアジャイル開発手法を用いて開発を進めています。 スクラムではタスクを細かく分解し、チームメンバーで分担しながら開発を進めます。タスクを適切に分担することで、チーム全体の生産性を高めることを目的としています。 そのため、「特定の誰か一人が最後まで抱えなければならない仕事」はほとんどありません。 この前提があるからこそ、状況に応じて役割や優先順位を見直しやすく、若手社員も周囲と相談しながらチャレンジできる環境になっていると感じています。 私が経験した「抱え込み」 1月某日、案件支援業務の資料作成の期日が近づいていた一方で、並行して任されていた開発タスクにも注力しすぎてしまい、資料作成を後回しにしてしまったことがあります。その結果、期日直前まで資料が完成せず、最終的には先輩社員にサポートしていただきながら、なんとか完了させることになりました。 振り返ると、このとき任されていた開発タスクは必ずしも自分一人で最後まで担当しなければならない仕事ではありませんでした。「任された仕事を自分でやり切ろう」という思いが強すぎた結果、タスク全体の優先順位を見失っていたのだと思います。 この経験から学んだのは、「自分でやり切ろう」という責任感を持つことは大切であるが、同じくらいチームとしての成果を出すことも大切であるということです。 個人として頑張ることに意識が向きすぎると、かえってチーム全体の進行や成果に影響を与えてしまうことがあります。 チーム開発では「自分がやり切ること」も大事ではありますが、「今どの進め方がチームにとって最適か」も考えることが重要なわけです。 このとき、もし開発タスクを他メンバーに任せ自分は案件支援業務を優先していれば、資料の品質もより高く担保され先輩社員のサポートも必要になかったかもしれません。結果として複合的にチーム全体への良い影響につながったはずです。 タスクの優先順位のつけ方 このときの経験を通じて、私は自分でやりきることを意識するよりも前に、タスクの優先順位を冷静に見直すことを心がけるようになりました。 タスクの優先順位において、私が意識しだしたのは「工数」と「専門性」の2軸で整理することです。 工数が小さく、専門性の低いタスク 他メンバーに任せやすい仕事 工数は大きいが専門性の低いタスク 上記と同様に他メンバーに任せやすい仕事。特に経験のあるメンバーにお願いすることで、工数を削減されることが期待できる。 専門性が高いタスク タスクを細分化することで協力して進められることもある このように、「他のメンバーが担うことで効率的に進行させられる仕事」を整理したうえで、自分の担当する範囲を決めていくことで、結果としてチーム全体の最適化につながると感じています。 また、若手社員のうちは、任された仕事がどれも同じくらい重要に見えたり、どこまでを自分で持つべきか判断が難しいこともあります。そのようなときこそ、一人で抱え込まず、優先順位や役割分担を周囲と相談しながら決めることが大切だと学びました。そうすることで個人の成果もチームの成果も両立できることに気づきました。 こうして、チーム全体の成果が最大化されるように仕事を整理し、自分の担当範囲を決めることが重要です。 MetemcyberPJ、そしてNTTドコモビジネスでは、個人の成果だけでなくチームとして成果を出すことも同じくらい大切にしています。 「この仕事のこの部分はお願いしたい」「こちらを優先したい」といった相談は、勇気が要るものかもしれません。 特に若手のうちは、「頼りなく見えないだろうか」「忙しい先輩に負担をかけてしまうのではないか」と考えてしまいがちです。 しかし、チームとして成果を重視する環境であれば、そうした相談は前向きな行動として受け止められます。 繰り返しにはなりますが、個人の頑張りは大切であり、それをチーム全体の成果につなげることの方も同じくらい重要です。上記の経験談でもタスクを適切に分担していれば、資料の品質を保ちつつ、自分も開発タスクで価値を出すことができたはずです。 上述した通り、NTTドコモビジネスは若手社員の意見を柔軟に取り込んでもらえます。だからこそ、「自分でやりきること」のみを最優先で考えるのではなく、チームとしてより良い成果を出すための行動をおこしてみましょう！ 最後に 今回の経験から学んだのは、「自分一人でやり切ること」だけを目指すのではなく、チームとして成果を最大化することを意識することで、自分の成果もより価値のある形で発揮できるということです。 若手のうちは、目の前の仕事に真剣に向き合うほど、一人で抱え込んでしまうことがあります。しかし、チーム開発で本当に重要なのは、誰か一人が無理をしてやり切ることではなく、チームとしてより良い成果を出すことです。 私自身もこの経験を通して、「個人の成果を追いかけるだけ」から「チームの成果と自分の成果を両立させる視点」へと意識を変えることができました。 これからも、この環境の中でより良い開発の進め方を学びながら、自身の成長につなげていきたいと考えています。 チームとともに成長しながら開発に取り組みたい方は、ぜひNTTドコモビジネスに興味を持っていただけると嬉しいです。 最後までお読みいただき、ありがとうございました。