はじめに

　こんにちは！NTTドコモ新事業開発部事業アクセラレーション担当の東孝明（@dcm_higashi）です。普段は、hands という内製開発チームにて、新規事業創出を目的とした技術支援や開発業務に携わっています。

　今回は、「Web アプリケーション構築が可能な、React 製フレームワークである Next.js を用いて、部内で利用される新規事業の管理サイトを作った際に、苦労した内容・工夫したこと」を執筆させていただきます。

　本記事は、Web 開発未経験の新入社員目線での気づきや体験をベースとした内容となっており、日々開発業務に取り組む熟練者の方々には、ぜひ少しでも懐かしんでいただければと思っております。また、私と同じく Web 開発未経験の方にも役立てば幸いです！
（本記事は、NTTドコモ R&D Advent Calendar 2023 の 22 日目の記事となります）

完成物

　今回開発した管理サイト（以降、ダッシュボード）は、部内に存在する種々のプロジェクト（以降、PJ）の情報を統合的に閲覧可能なサイトとなっています。大きく分けて、以下のような3種類のページで構成されています。なお、表示されているデータは全てダミーとなります。

メインページ

PJ 一覧ページ

詳細ページ

ダッシュボードの構成技術

　ダッシュボードは、以下のフロントエンド技術で開発されています。

それぞれの役割は下記となり、近年の Web アプリケーション開発でよく利用される技術スタックを採用しています。

言語：TypeScript (https://www.typescriptlang.org/ja/)
スタイリング：Tailwind (https://tailwindcss.com/)
フレームワーク: Next.js (https://nextjs.org/)
コンポーネント：tremor (https://www.tremor.so/)

なお、コンポーネントとして用いられる tremor は他と比べると有名なライブラリではありませんので、少し紹介させていただきます。

tremor とは

　主にダッシュボードの構築で利用される React 用のオープンソースライブラリ。Tailwind をベースに作られており、表やグラフデザインの美しいコンポーネントが多数用意されています。Web サイト内で、多用される表やグラフデザインの調整に特化しており、サイト全体の UI デザインは、tremor で統一しています。

メリット

グラフや表の描画に優れており、デザインまでこれ一つで完結する点
公式 Slack や GitHub などのサポートサポートも手厚く、疑問点を質問しやすい点

デメリット

新しいライブラリのため、できないこともしばしば存在する点（グラフの軸ラベルが表示できない、など）
非対応のグラフなど細かい UI 調整はできず、カバーしきれない UI は Taiwind で調整する必要がある点

ダッシュボード公開までの道のり・苦労

　「部内に存在する様々な新規事業プロジェクトのデータを一元管理するツールが欲しい」との要望を、部の方針を決める部長の方々からいただいたことが全ての始まりです。私の所属チームは、内製開発が活発であり、新入社員として配属された私もすぐに今回の開発に加わることとなりました。　

　前節でも述べましたが、本開発では主に Next.js をフレームワークとして用いています。しかし実は私、Next.js はもちろん、JavaScript はおろか、学生時代には Python しか書いていなかったため、開発はトライアンドエラーの連続でした。

　そんな新入社員が、どんなことにつまずき、工夫して困難を乗り越えたか、ぜひご紹介させていただければと思います。

チームへの加入直後

新たに学ぶことがたくさん

　前述したダッシュボードに用いられている技術の理解・Docker などの環境構築方法・Git の作法など、早急に理解すべきことがたくさんあり、かなり大変でした。特に、開発対象の技術構成を理解しているかどうかで、コーディングのスピードってかなり変わると思っています。特に、各種フレームワークの役割や、バックエンドやインフラ周りに関する知識がほとんどなかったため、よく先輩に相談していました。今も、まだまだ学ぶネタが尽きることはなく、勉強の日々を送っています。

工夫した点 ①：積極的に先輩が働いているところを見にいった

　これは、新たな技術の使い方を学ぶという点以外にも、自分がどういう方向に成長していけば良いのか指標を定めるという点でも重要だと考えています。実際に、先輩社員が働いている様子から学べるものはたくさんあると思いますし、そういったコミュニケーションを取れる場は大切だと思います。

　私の例で言えば、チーム加入後すぐに Flutter という別フレームワークの技術イベント（東京 Flutter ハッカソン）への参加を希望し、先輩方と一緒に開発を行いました。結果はなんと 23 チーム中 2 位で準優勝 !! このイベントは、Flutter 以外の技術も使って良いルールだったので、自分も Python 記述や生成 AI 活用を担当しましたが、比べて先輩方の Flutter を用いた開発力は計り知れないものでした...

　特に、先輩方のアイデア力・コーディング力・マネジメント力には舌を巻きました。数年後、自分がここまで成長しないといけないのかという良い意味での焦りにも繋がり、モチベーションも高まったのですごく良かったと思っています。また、こういった限られた時間で開発を行うイベントでは、スピードが求められます。効率化の観点からも、Miro や Figma のようなツールを利用することが望ましく、これらに明るくなったことも収穫の一つですね。

工夫した点 ②：ドキュメントにまとめた

　月並みですが、メモって大切ですよね。新たに学んだ会社のルール、Git コマンドなど、次も必ず使う内容に関しては、ドキュメントにまとめています。また、抱えた疑問点は常に先輩社員に相談できるわけではないので、これもどこかに溜め込んでおくと役立ちます。もしかすると、自分が後輩を持つことになった時にも役立つかもしれません。

初学者（新入社員）の感想　〜 Git って難しい〜

　突然ですが、みなさん Git 毎日使ってますか？私は、このチームに入ってから使い始めた「 Git 一年生」です。研究室時代にプログラムは書いていたものの、そのコードを GitHub などでしっかりと管理していなかったので、キャッチアップに苦労しました。ある程度理解はしましたが、まだ Git 管理の恩恵を十分には享受できていない気がしています。というのも、チーム開発とはいえ、少人数でプロジェクトを回しているためです。ブランチ運用はかなり便利ですが、そこまでコンフリクトとかは起こっていないんですよね。きっと、一年後には Git しか使えない人間になっている気もしますが...

開発開始〜完了まで

UIデザインとの戦い

　「実用性を備えた綺麗なサイト」を作るのって難しいですよね。そのために、tremor という表や図に特化したライブラリを導入しましたが、意外とできることが限られてしまうというのが 1 つのデメリットです。その可能な範囲を調査するのには、ある程度の労力を要します。

工夫した点 ①：公式ドキュメントに限らない調査を行う

　前述の通り、tremor はグラフや表のデザインに優れている一方、細かな UI 調整や改良は tremor 単一では完結しません。当初は、公式ドキュメントばかり読んでおり、一向に UI 周りの問題が解決しなかったのですが、公式質問箱（Slack）を活用することで一気に進展するということがありました。

　例えば、開発項目に以下のような「横スクロール時に、表の最左部の項目を固定する」という処理があったとします。

この件について Slack で投げかけたところ、tremor と Tailwind は相性が良いこと・Tailwind の overflow クラスが使えることなどを助言してもらえました。実際に、これらを反映したことで、スクロール時の問題は解消することができました。逆に、これはできませんというのも tremor 開発者の方が返答してくれるため、ドキュメントのみに頼らず、もっとコミュニティに頼ればよかったと感じています。

工夫した点 ②：先輩へ質問しやすい環境を整備する

　日々、Slackで困っていることや逆に学んだことをまとめる質問箱チャンネルを作成し、ノウハウを溜め込んでいます。特に、高い技術力を持つ先輩方にもチャンネルに入ってもらい、必要に応じてコメントいただく形式を取ったことで、開発スピードなどにかなり良い影響を及ぼしています。対応してくださる先輩方には本当に感謝しかありません...

　ちなみにこの質問箱チャンネルですが、私のもう一人の同期がきっかけで始まりました😁 本人（@dcm-satou）も 21 日に記事を執筆してますので、もしよければ読んでみてください。

初学者（新入社員）の感想　〜英語で質問できれば... 〜

　「自由に質問できる」って素敵ですよね。課題を開発者コミュニティでのコミュニケーションで解決できるのは、コスト的に見ても望ましい状況だと感じています。こと、プログラミングに関していえば、Slack やメール、Stack Overflow のような質問箱など手段は多岐に渡っていますし、日本国内に限らないという質問環境はスピーディな開発に一役買っているんだろうと。これからは積極的に使いたい...が、言語は「英語」なんですよね😅 毎回、翻訳・校正ツールのお世話になっていますが、やはり英語をある程度自由に使えた方が可能性は広がりそうだなと常々思ってます。未来の自分に期待です。

TypeScript と Python って全然違う

　今回の開発の中で、たくさんのバグと対峙してきましたが、特に多かったのは「TypeScript の型定義」です。これは、Python との違いで中々苦しみました。元々 Python が持つ動的な型付けに慣れており、TypeScript 含め他言語が持つ静的な型付けにあまり馴染みがなかったためです。

　簡単な例ですが、変数を定義する際に、TypeScript と Python では以下のような違いがあります。

一番ハマったのが、tremor のとあるアイコンの色を条件によって変更する関数を作った時でした。該当箇所に、String 型で「gray」と入れても受け付けてもらえず、悩んでいたのは忘れられません。結局、以下のような独自の型定義が必要でした。

初学者（新入社員）の感想　〜これからも TypeScript を〜

　Web 開発未経験だった私にとっては、まだまだ Python の方が得意です💪 元々、私の研究内容が「画像・生体データ等のマルチメディア信号 × 機械学習」だったこともあり、大学時代はどちらともある程度相性の良い Python で事足りていました（MATLAB は少し使ったかも...?）。

　一方、Web 開発含め、ユーザー向けのアプリケーション開発では他言語の方が向いている場合もあるということに、すごく納得しました。Python の次に触る言語としては、TypeScript が正解だったのかなと感じています。というのも、Stack Overflow が毎年出している調査の中の "Most popular technologies" では、Python が 4 位、TypeScript が 5 位（サブセットの JavaScript は 1 位）と報告されています。利用者が多いということは、これから活かしていく機会も多いでしょうし、自己研鑽に励もうと思います。

初期リリース

ステークホルダーへの周知

　本案件のステークホルダーには、ダッシュボードを元に部の方針を決める方々、実際にデータを投入する各 PJ の担当者の方々が存在しています。それぞれ、境遇や求める機能などバックグラウンドが異なるため、周知方法を一様とすることはできません。それぞれのステークホルダーが求めている機能や利用時の負担など、ポジティブ・ネガティブな面を考えた上でプレゼン用のスライドを作成していきました。最終的に、部の運営方針を決める会議、そして各 PJ の担当者も参加する部全体のキックオフにて、予定通り公開することができ、なんとか一段落させることができました。とはいえ、たくさん改良案をいただいているので、これからも良いプロダクトを目指していければと思います。

初学者（新入社員）の感想　〜プレゼン経験値が足りない〜

　今回、先輩方とスライド作成を行いましたが、やはり難しいですね。相手が「何を聞きたがっているのか」、「利用に際してどんなところが負担になるのか」などを意識しないといけません。特に、会社という単位で見ると、学生の頃とは違った目線を求められるので、自分の考え方をアップデートしていく必要があると前向きに捉えてます。「練習あるのみ」ですね。

　今回開発したダッシュボードの周知は、普段は参加しない会議で実施しました。その名も「担当部長会議」です。そもそも年次の離れた担当部長や部長のみ参加する会議にて、お時間を取っていただくということは初めてだったので、かなり緊張しました。今回は、先輩と共にその場に望みましたが、いつか自分主導で行う機会が来るかもしれないので、慣れていければと思います。

こうしておけば良かった点

　最後に、今後に活かせそうなポイントを列挙して締めさせていただきます。

わからないことは、臆せず質問すべき。媒体が英語であっても敬遠しない意識が大切。もし英語で説明しきれない場合は、図など作って説明すると良い。
いきなり実装するのではなく、そのプログラミング言語のチュートリアル、あるいは書籍などを一読しておくと良い。時間がない場合でも、そういった学習環境が存在することをあらかじめ知っておくと、後々役立つ。
開発段階から、こまめにステークホルダーへのインタビューをすべき。可能なら、依頼主・依頼主以外のサービス利用者の両方とコミュニケーションできると良い。