エンジニア未経験からのチーム開発挑戦記：36歳の新米、文系出身者の成長と感謝の軌跡
Prologue Pizzazz - はじめに-
これは、
- エンジニア未経験の36歳
- 文系大学出身（高校数学赤点ギリギリ）
- 非効率で無駄なことが大好き
そんな一人の男が、1ヶ月半のプログラミング学習を通して得た知識と技術で、初めてのチーム開発に挑んだ軌跡（ブログ）である。
*Programing Languages* - 開発に使用したプログラミング言語とツール-
学習のため、フレームワーク等は使用せずに開発に当たった。
フロントエンド技術
- HTML
- CSS
- JavaScript
- Ajax (JavaScriptの一部)
バックエンド技術
- Ruby
- WEBrick (RubyのWebサーバーライブラリ)
データベース管理
- MySQL
クッキー管理
- Cookie (ログイン機能を実装するため)
打合せで使用したツール
- Canva (ホワイトボードを活用して、リアルタイムで情報を共有・可視化)
- Adobe XD (ワイヤーフレームやデザインプロトタイプの作成で使用)
- Discord
第1章 *Serendipity Symphony* - きっかけ-
1. Serendipity Symphony - きっかけ-
近年、AIやITの発達により、様々な分野で変化が起きている。
- 業務効率の向上（DX）
- モバイルテクノロジーの進化
- 無くなる仕事・生まれる仕事、など
そのような変化の目覚ましい時代の中で、日本の社会人の平均勉強時間は13分/日だそうだ。（「令和3年社会生活基本調査結果」（総務省統計局より）もちろん、私もここに含まれる。
「若い人は使いこなすのが早いなあ」「最近のものは全然分からないなあ」などと言っている場合ではない。かつてないほどのスピードで、未来に向けた変化が、身の回りで毎日起きているのである。
と、ここまで偉そうに述べたのは、全てYoutubeの影響である。
- 「ふ～ん」
- 「へぇ～、すごいな」
- 「たしかに、そうかもしれない」
観始めたら止まらなくなり、書籍の購入にまで至ったのが、この私。単純な思考しか持ち合わせていない36歳。この年になっても周りからの影響を大きく受けやすい、自分という軸のない男。こんなおじさんになるのはイヤだと思うのならば、「日々をこなす」だけではなく、「学び続けよう」とする気持ちを大切にして欲しい。
さて。興味をもってからの行動も早かったのは、評価できる点である。次はプログラミング学習を扱ったYoutubeチャンネルを観るようになった。
さらに、Progateというサイトにも登録して、手探りながらコンテンツを進めていくようにもなった。
- 言語がいっぱいあるけれど、どれから勉強したらいいのだろう
- そもそも、なんでこんなにいっぱい言語があるのだろう
そんな「分からない」を抱えながら、Youtubeを観てProgateに取り組んで…を繰り返していた時に、「だれでもエンジニアチャンネル」で
「未経験からエンジニアを本気で目指している人を募集します」
と呼びかけられたのだから、このタイミングに運命を感じずにはいられなかった。こうして私は、アプレンティス生として、エンジニアを目指す道を歩み始めたのだ。
第2章 *Random Rendezvous* - チームの結成 -
2. Random Rendezvous - チームの結成 -
アプレンティスシップが始まると同時に、チームが割り振られた。約20人の同期が3～4人/チームに分かれている状態だ。
同期といっても、オンラインで1度だけしか顔を合わせたことはなく、ほぼ初対面の状態でzoomのルームに分けられた。
（…誰が回す？）
zoom越しでも分かるこの雰囲気。微妙な間…。
新しい一歩を踏み出すために来たのだ、いけ、私。口火を切れ。
- 私「こんにちはー！」
- 全「こんにちはー」
- 私「いや～、なに話します？みなさん、おいくつですか？」 ←
-幕間-
私「あ、私以外全員20歳…！？」
私「なんか、ごめんね…！ 私抜きで集まって、仲良くなっちゃって全然いいからね！」
干支ひと回り以上も離れたメンバーと、初めてのチーム開発が上手く実現できるのか！？
その前に、そもそもこのチームに溶け込むことができるのか！？さぁ、いよいよ本編突入だ！(無駄な前置きが好き)
第3章 *Collaborative Crescendo* - チーム会 -
3. Collaborative Crescendo - チーム会 -
チーム開発の流れは以下の通りだ。
アイディア決め（2W）
発表用スライド作成・要件定義（2W）
設計・タスク整理・環境構築（2W）
実装・プレゼン準備（1W）
1ヶ月後から開発が本格的に始まるスケジュールだ。それまでは、カリキュラムにある課題を各自で解いて学習を進めることになっている。
初回のチーム会で決めたことは次の内容だ。
- 毎週月・木 18:00～18:30にチーム会を実施
- 課題の進捗状況の共有
- 他に困っていることや気になっていることなど、自由交流
- （私抜きで集まるのもOK！）
そもそも全員が「エンジニア未経験」で集まっているため、この時点では、開発スケジュールに書いてある単語の意味すら、まだ正確に理解していない状態である。
ただ、この時「チームとしてあまりやることがない」状態ではあったが、毎週決まった時刻に顔を合わせてコミュニケーションを取ってきたことは、後々になって大きな財産となった。あの日、口火を切って本当に良かった…。
第4章 *Incsption of Ideas* - アイディア決め -
4. Incsption of Ideas - アイディア決め -
進行役をする経験も貴重だと思い、チーム開発の流れがある程度整ったら、進行役を各週で交代していくことにした。
さて。このチームで一体どのようなアプリを作っていくのか。
与えられたテーマは 「自分たちに役に立つものを開発せよ」 だ。
そこで、各自アイディア集めに1週間かけ、その翌週にアイディアを出し合い決定していくことにした。
-1週間後-
まだお互いの距離感がつかめ切れない雰囲気もあるチーム会だが、アイディアはたくさん集まった。
問題だったのは、チーム全員が開発未経験のため、「果たしてそのアプリを現実的に作ることができるのか？」 という点も、考慮しなければならなかったことだ。（この時点では、全員がまだバックエンドの処理しか学習していない状態）
そうはいっても、初めから制限を設けてしまったら、せっかくのアイディアが生まれる前に消えてしまう。
現実離れしたアイディアでも、何かと合わさったときにものすごく光るものに変わるかもしれない。
今の自分には作れなくても、いつかの自分が「創ろう」と思えるかもしれない。
チームの全員がこの感覚を共有していたからこそ、次のようなわくわくするアイディアがたくさん出たのだと思う。
【学習記録アプリ】（決定！）
・X(Twitter)のようなイメージ。使う人と使う目的をより限定的にしたもの
・特に、日々の学習記録やコードの共有などを自由にできるようにする
・作るうえでも、今後機能を拡張しやすい。（基本となるCRUD処理）
＜決定理由＞
・アプリを初めて開発する上で、全員のイメージが共有しやすかったため
・期日までの技術力で、実装可能と思われるアプリであるため
今回は「技術的に難しい」「既存のアプリで充分まかなえる」といった理由から採用しなかったが、メンバーで出し合ったアイディアについても一部紹介。（後半2つは、私が出したアイディア）
【スポーツマッチングアプリ】
・例えば「野球したい」と思っても、すぐに実現させることは難しい
・「グラウンドを借りる」「メンバーを集める」「対戦相手を募集する」「日程を決める」
などの手間を、このアプリで完結できるようにする
【勉強＆ストレッチアプリ】
・コードについて勉強していると、身体が硬くなって運動不足になりがち
・「集中して勉強する時間」と「休憩してストレッチする時間」というサイクルを管理し、
健康的な学習を実現するアプリ
【楽しく目覚ましアプリ】
・「朝起きる」という誰もが毎日繰り返す行為を楽しくしたい
・特に「朝が苦手」「なかなか目が覚めない」と消極的になっている人たちの
気持ちを励ましたい
・自分の朝のルーティンを登録し、それらを制限時間内にクリアしていくようにする
・過去のタイムも見ることができて、「朝起きる」ことに自信がもてるようになるアプリ
【映った人をちょっとだけ太らせる鏡アプリ】
・鏡を見て「最近太ってきたかなあ」と気付いた時には、もう遅い
・そこで、あえて今の自分よりもちょっとだけリアルに太った姿を映すことで、
「これはまずい！すぐに改善しなきゃ！」という気持ちを呼び覚ます
・生活習慣の見直しや適度な運動を取り入れて健康へと向かわせるアプリ
第5章 *Requirements definition Rhapsody* - 要件定義 -
5. Requirements definition Rhapsody - 要件定義 -
「そもそも、要件定義って何だ…？」
全員がそのような状態からのスタートだった。簡単に言えば、「システムとして、どんな要件が必要かを定義していく」 のが要件定義だ。
(1) ニーズ調査
例えば、料理で言えば、
- お腹を空かせてやって来た人がいたとする
- この人がが求めている料理を提供することを目標にする
- この目標を達成するために、まず、やるべきことは、
- この人が、そもそも何を食べたいのか
- 好き嫌いや、アレルギーはあるか
- 今の気分はどんな感じか
などを聞いて、抽象的だったイメージを具体化していくフェーズがニーズ調査だ。
今回は、対象となるユーザーが自分たちなので、このフェーズはそこまで難しくなかったように感じる。
話し合った結果、私たちのニーズは、
- 日々の頑張った学習を記録していきたい
- 他のメンバーが、どのように学習を頑張っているのかを知りたい
- (可能であれば)書いたコードなども共有して、勉強したい
の3つに絞られた。このニーズに応えるべく、私たちが初めて開発するアプリは、エンジニア初学者のための学習記録アプリ。その名も
Study Record.
アプリ名が決まっただけだが、気持ちが高揚したのを覚えている。「文化祭の出し物が決まった」というような感覚だ。
(2) 機能要件の抽出
次に行ったのは、「どんな機能をもたせるか」についてだ。これについて考えるときに、「ワイヤーフレーム」があるとイメージしやすいというナイスな意見が出た。ただ、(それを、誰が作るの…？)というような消極的な雰囲気を、同時に感じた。(←勘違いの可能性もあり)
(メンバーがためらいがちな仕事こそ、最年長の私が率先して挑戦するべきじゃないか！)という気持ちと同時に、「私が次回のチーム会までに仕上げて共有しますよ！」と、言葉が口から出ていた。どうやって作るのか等は、この時点の私は知らないのだが…、やはり最年長として、チームにしっかりと貢献していきたいという気持ちが勝っていた。
ワイヤーフレームの作り方は色々とあることが分かり悩んだが、今回はAdobe XDを使用することにした。作成している段階で、「あ、この機能も必要だなあ」「ここは、もしかしたら人によって意見が分かれるかも」などといった視点をもつことができ、結果として自分の学びにつながった。また、この時点では気付かなかったのだが、私が作成したものは「ワイヤーフレーム」というよりは、「試作品」に近い状態であった。(具体的にイメージできた方が良いだろうと思って作っていたら、楽しくなってきてしまって、つい…)
- 次のチーム会にて -
全員でワイヤーフレームを見ながら、システムに必要な機能をCanvaのホワイトボードに書き出していった。
- 青色の付箋 「良いところ」
- 赤色の付箋 「気になるところ」
- 緑色の付箋 「改善案」
この「試作品」を見ながら考えることで、普段よりも活発に意見が出たし、相手の意見をしっかりとキャッチで来た。だからこそ、メンバー間の距離も、ここで一気に縮まったような気がした。
赤や緑の付箋で出た意見を基に、「ワイヤーフレーム(試作品)を修正して共有→意見を付箋に出し合う」を3回ほど繰り返した。こうすることで、アプリの完成図の細かな点まですり合わせることができ、みんなで目指すべきゴールがピタッと一致したような気持ちになった。
この日以降、週2回だったチーム会の回数を週3回に増やした。アプリについてどんどん話し合っていく時間はとても楽しく有意義で、メンバーとも自然と、何でも話せる関係になれた気がする。
第6章 *Priority Ponderance* - 開発の優先順位 -
6. Priority Ponderance - 開発の優先順位 -
チーム会が盛り上がり必要な機能も出そろい始めたときに、ふと気づいた。
期日内に実装可能なボリュームになっているだろうか
修正を重ねてまとめられた試作品は、次のような状態になっていた。
- 遷移する画面が、全部で13個ある
- ログイン機能を搭載する
- 学習記録の投稿・編集・削除を可能にする
- データベースに、情報を保管する
- ファイルのアップロード・ダウンロードを可能にする
初めてアプリを作る私たちにとっては、このボリュームが果たして「不十分」「最適」「無謀」のどれなのか、判断ができないのである。
そこで、開発の優先順位を付けて実装していくことにした。優先順位は、ニーズの高いものから順番に付け、ユーザーの要望にしっかりと応えられるアプリに仕上げていこうという方針で一致した。具体的には
- (1) 学習記録機能
- (2) ログイン機能
- (3) コード共有機能
という順番で実装していくことで、完成したら次の機能を足していく…という流れだ。
結果的に、私たちは期日内に(2)までの機能を実装し、アプリを仕上げることができた。
終わってみてから思うのは、この時点で「優先順位」を決めずに「全部やってみよう！」と走り出していたとしたら、途中で「息切れ」「リタイア」の連続になっていたかもしれない…ということだ。
第7章 *Task Tessellation* - タスク分解 -
7. Task Tessellation - タスク分解 -
この「タスク分解」が、アプリ開発未経験の私たちにとって鬼門だった。なぜなら全員、
- 分解するといっても、このタスクをどこまで分解できるのか分からない
- フロントエンド・バックエンド・データベースの3つを、どのように連動させるのか分からない
- タスクの実装にどれだけの時間を要するのかが分からない
- そもそも、タスクを全て洗い出せているのかすら分からない
という状態だったからだ。どこまで話し合っても、「確証」が持てないのである。
「分からない」ことをずっと考えていても先に進めないので、ひとまず
-
フロントエンド
- ヘッダー作成
- 各ページの作成
-
バックエンド＆データベース ← 私の担当はこちら
- ユーザー登録及びログイン/ログアウト処理の実装
- 学習記録の投稿・編集・削除の実装
という大きなくくりで2人ずつに分かれて、実装を開始することにした。
第8章 *Implementation Impression* - コード実装 -
8. Implementation Impression - コード実装 -
第7章を読んでくださった方ならば、大方の予想はついているだろう…。そう。この「コード実装」がとにかく大変だったのだ…。「これ、本当に完成できるのか」という不安とも戦いながら、費やせる時間を全部つぎ込んだ1週間だった。
まず、良かった点から整理していく。
- 予定より早く、実装に着手できたこと
- データベース設計を、前回のチーム会で完成させていたこと
- ディレクトリ構造を、全員で統一していたこと
- Canvaでガントチャートのようなものを作り、進捗を共有したこと
- チーム会を毎日開き、修正や調整を行ったこと
- フロントエンドチームが、予定よりも早く画面を仕上げてくれたこと ←これに1番助けられた
次に、実装していく上での「壁」となったことを整理していく。
- フロントエンド・バックエンド・データベースをどうやって連動させるのだろう？
- フレームワークを使わずに、どうやってローカル上で動かすのだろう？
- URLが必要になるみたいだが、URLってどこから手に入れるのだろう？
- ログイン処理って、どうやってコードで書くのだろう？
- 編集画面で編集前のデータを初期値としてもたせるには、どうすればいいのだろう？
- エラーがいっぱい出てきたが、上手く処理されていないのはなぜなのだろう？
ほとんどが「壁」だらけである。つけ足すならば、「まだ見えていない壁も存在しているに違いない」といった不安が、最大の壁だったかもしれない。これらをどのように乗り越えたかについては、以下に1つずつ書いていくことにする。
第8章 突破編 - 「フロントエンド・バックエンド・データベース連動」の壁 -
「壁」と感じる原因
ここまで、各領域を個別に学習はしてきたのだが、これらをどうやって連動させるのかは全く見えていなかった。「もしかして、自分がまだ知らない【連動させるためのツール】のようなものが必要になってくるのでは…！？」と、不安も大きくなっていった。
突破の鍵 - 「URLが全て管理している」 -
ネットのブログ記事を読んだりProgateのスライドを見直したりして、どうやらこれらを連動させるのには、「パス」が必要になるという漠然としたことはつかめた。メンターの方に聞くと、「全ての処理の連動は、URL(path)が管理している」と教えていただけたので、大きな不安が1つ解消された。
第8章 突破編 - 「フレームワーク不使用」の壁 -
「壁」と感じる原因
私が今回バックエンド処理を学ぶ上で選択したプログラミング言語は、Rubyである。どうやらRubyは、単体ではWebサービスを作ることはできず、Ruby on Railsというフレームワークを使用することで、最大の効果を発揮するらしい。
その1番の装備を封じられた状態で、果たして開発ができるのだろうか…。
突破の鍵 - 「あると便利だが、なくても作れる」 -
「Ruby 3.2 リファレンスマニュアル」によればWEBrickというRubyのライブラリを使することで、単純なHTTPWebサーバの機能を作ることができると分かった。つまり、WEBrickライブラリを読み込み、連動させるためのURLを設定しさえすれば、フレームワークがなくても、Webアプリが作れるのである。
第8章 突破編 - 「URL設定」の壁 -
「壁」と感じる原因
「URL」で全て連動できるという理屈は分かったのだが、私の認識では「URL」とはWebサイトのページの場所を示す「住所」のようなものである。ページが切り替わる際にURLが変わるというのは理解できるが、バックエンドやデータベースにもURL（パス）が必要とは、どういうことなのだろう…。
突破の鍵 - 「目に見えないURLが存在している」 -
Webサイト上での処理（ログインや生地の編集・削除など）をRubyと連動させるためには、「このURLにアクセスがあった場合には」といった要領でコードを書いていくと良いことが、分かった。
特に私にとって大事だったのは、「削除するためだけのURL」や「データベースから情報を取得するためのURL」など、Webページ上では見えないURLでの処理が存在しているということだった。
この仕組みを知っていれば、きっとタスク分解(第7章)のときに、もっと上手く分解することができたかもしれない。
第8章 突破編 - 「ログイン処理」の壁 -
「壁」と感じる原因
ユーザー登録の処理については、まる1日かかったが何とか実装することができた。usersテーブルにデータが入ったときは、踊り出しそうなほど嬉しかった。
ただし、私の書いたコードはSQLインジェクション対策(後から知る)が全く考慮されていない作りとなっていて、「このコードのまま実務で実装したら大変なことになる」とご指導をいただき、冷静さを取り戻した。
同じ要領でログイン処理についてもいけるだろうと考えていたが、この時の私は知らなかったのだ。「HTTPは通信が完了すると、クライアント（ブラウザ）とサーバーとの間でのやりとりが終了し、ページ遷移が発生すると次のリクエストとレスポンスは新しいものとして扱われる」というブラウザの仕組みに…
突破の鍵 - 「Cookieを使うことで一意の識別子を保持できる」 -
セキュリティ上の観点からだと、セッションを使用した方が良いということは後から知った。何しろ、実装期間1週間のうち、半分以上を費やしてしまっている状態だったからだ。ログイン処理について調べて、多く出てきた「Cookie」を使って、今回は挑むことにした。
CookieにユーザーIDを保存することで、特定のURLにアクセスしたとき、「Cookieにある現在のIDが、データベースに登録されているユーザーIDと一致するか」という条件分岐をコードに書くことで、ユーザーを特定し、個別の情報をWebサイト上で更新することが可能になった。
# ログイン処理（仕上げる前の半分は、メンターさんやChatGPTにもお世話になった）
server.mount_proc('/login') do |req, res| #form actionに対応
if req.request_method == 'POST'
# リクエストボディからパラメータを解析
params = req.body.split('&').map { |pair| pair.split('=') }.to_h
username = params['username']
password = params['password']
# MySQL2に接続
client = Mysql2::Client.new(
host: 'localhost',
username: 'root',
password: '自分が設定したパスワード',
database: '自分が作ったデータベース名'
)
# データベースからユーザーを検索 クエリをバインド変数を使用して構築
stmt = client.prepare("SELECT * FROM users WHERE username = ?")
result = stmt.execute(username)
if result.count == 1
# ログイン成功時の処理
user = result.first
# パスワードが一致するか確認（BCrypt gemを使用）
if BCrypt::Password.new(user['password']) == password
# CookieにユーザーIDを保存
res.cookies << WEBrick::Cookie.new("user_id", user['user_id'].to_s)
res.set_redirect(WEBrick::HTTPStatus::SeeOther, '/home.html')
else
# パスワードが一致しない場合の処理
res.set_redirect(WEBrick::HTTPStatus::SeeOther, '/login.html')
end
else
# ログイン失敗時の処理
res.set_redirect(WEBrick::HTTPStatus::SeeOther, '/top.html')
end
else
res.status = 400
res.body = 'Bad Request'
end
end
第8章 突破編 - 「編集情報取得」の壁 -
「壁」と感じる原因
「『ログイン処理』の壁」でも触れたように、私は「HTTPは通信が完了すると、クライアント（ブラウザ）とサーバーとの間でのやりとりが終了し、ページ遷移が発生すると次のリクエストとレスポンスは新しいものとして扱われる」ということを知らなかった。だから、次のように考えていた。
- 私「掲載されている記事のreport_idと一致するデータを取得すれば、編集画面にもそのデータが反映できるはずだ！」
このとき、まだCookieによるログイン処理を実装していなかったので、この発想では上手くいかないのは一目瞭然だ。だが、ブラウザの仕組みを理解していない私は、「なぜページが変わると、report_idが0(またはnull)になってしまうのだ…。いったいどのコードが間違っているのだーー」と、ひどく落ち込むことに。
突破の鍵 - 「上手くいかないのは、ブラウザの仕組み上当然のこと」 -
ログイン処理が完成するまでは、次のようなことも試してみた。
- 私「そうだ！report_idと同じ値を編集ページのURL末尾に設定して、そのURL末尾の番号と一致するreport_idの情報を取得できるようにすれば…！」
たしか、この方法だとページを切り替えたときに上手く表示された気がする。ただ、セキュリティの観点など全く考慮されていない危険な発想である。「情報をこのページに表示させるのだ」という目的以外に、余裕などなかった頃だった。
その後、ログイン処理が完成し、その仕組みをチームでも共有したお陰で、事なきを得ることができた。
# 「編集」が押されたときの処理
server.mount_proc '/get_edit_report' do |req, res|
cookie_data = req.cookies.find { |cookie| cookie.name == 'user_id' }
if cookie_data && cookie_data.value != ""
# ログインしているユーザーのIDを取得
user_id = cookie_data.value.to_i
# クエリパラメータからreport_idを取得
report_id_to_edit = req.query['report_id']&.to_i
# 以下省略
第8章 突破編 - 「エラー祭り」の壁 -
「壁」と感じる原因
- 私「うわ…。なんかターミナルにいっぱい表示された。なんだこれは…」
- 私「修正したら、今度は別のエラーが出てきたぞ…。ツライ…」
書いたコードがすんなりと期待通りの処理を実行してくれないことを、一人でけっこう嘆いていた。「○○でエラーが出たので調査中です」という進捗報告にかこつけて、ちょっとdiscordでもつぶやいてみたら、「自分も同じ感じですーーー」「時間があったら見ておきます！」など、チームのメンバーからの共感やサポートのメッセージが返ってきて、とても励みになった。
エラーに対処するための知識・技術・経験不足は仕方なしと割り切って、メンターさんにも相談をさせていただいた。このときにいただいたご指導が、この後の実装速度を大きく加速させてくれるものとなった。
突破の鍵 - 「何らかの処理を行っている場所に、puts!puts!!puts!!!」 -
「開発をしていると、エラーどころか何も出てこないときの方が、もやもやするんですよー」と、メンターさんは言う。つまり、「表示されたエラーを積極的に解読し、原因を突き止めて解決しよう」とすれば、コードは必ず期待通りに動いてくれるというのだ。
「処理を行っているコード付近に、puts "aaaa"などで良いので、ターミナル上に出力されるかやってみるのも良いですよ。エラーがある場合は、出力されない箇所が必ず出ますから」
この言葉で、目から鱗が落ちた。これまでの私にとって、Rubyのputsは「ターミナル上にこれまでの処理を出力させるために、最後に書くためだけのもの」だったからだ。
これを始めてからのエラー対応は、とても楽しかった。
- 私「puts "bbbb"まで出力されているから、怪しいのはputs "cccc"付近の処理だな」
- 私「たしかに、エラーの内容も同じ場所を示しているな」
- 私「 この処理をこっちにもってきたら、動きそうだな」
- 私「やった！エラーの種類が変わったぞ！！！」
というような言葉をつぶやきながら、エラー祭りを楽しむことができるようになったのだ。
第9章 *Soliloquy Sonata* - 個人の振り返り -
9. Soliloquy Sonata - 個人の振り返り -
最後に、自分自身の振り返りをして、「初めてのチーム開発」を終えたいと思う。
今回自分が頑張ったこと
-
「最年長」という点に気を付けつつ、とにかくたくさんコミュニケーションを取った(良好な人間関係の構築)
- 開発のことだけでなく、雑談なども楽しくできた
- これは、私が「頑張った」というよりも、自然とそういう関係になれた、という感じだった
- ここまで年の離れた人たちと対等に話せる機会もそうはないので、貴重な機会となった
-
チーム会の進行だけでなく、記録やレジュメを作成し、事前に話し合う内容を伝えた(見通しをもつ)
- 自分の頭の整理にもつながった
- プライベートの都合もあるので、とにかく全員が集まれる時間を無駄にしないように努めた
- 終了時刻も決めて、会議の時間がダラダラと伸びないように管理した
-
進捗状況や困っていることをCanvaとdiscordで発信した(進捗状況の可視化)
- 「そんな小さなことでも発信していいんだ」と思える雰囲気も、作りたかったため
- 発信された内容をキャッチできれば、次のチーム会に生かすことができるため
チームメンバーからもらった「もっとこうすれば良くなる」というアドバイス
- 「遠慮せずに、もっと自信をもって引っ張っていくときがあっても良いです！」
- 「もっと簡単なコードで書いてもいいんじゃないかなと思いました！」
- 「コードの修正に時間がかかっていたので、経験を積めばいいエンジニアになれると思いました！」
私自身が感じていた部分をしっかりと見抜いて伝えてくれるなんて…、本当にメンバーに恵まれていたなあと感じた。
これらを踏まえて、
今後私が努力することと、その方法
- 時には、自信をもって引っ張っていけるようにする
- コードの実装(技術面)にまだ課題があるので、それを解消させることで「周りを引っ張る」タイミングやスキルを身に着けるようにする
- コードの簡潔化・迅速な修正
- Paizaのレベルアップ問題に取り組み、「最小単位の処理」に分けてコードを組める力を身に着ける
- 他チームが開発に使用したコードを共有してもらい、コードをたくさん読むことで理解力を高める
以上のことを念頭に置き、今日からは主に「技術面」の向上に特化して、精進していくことにする。
Epilogue Eclat - おわりに -
今回の経験を美化するつもりはないが、このアプリは、チームの一人でも欠いていたら完成はしなかっただろう。
これが「実務現場で」と考えたら、欠員が出たら完成しないという時点で仕事として破綻している、と思われるかもしれない。
だからこそ、初めてチームでアプリを開発するという経験を、この「誰一人欠かせない大事なメンバーたち」と一緒にできたことが、大きかった。そう思える関係を築けたことが、嬉しかった。
これもまた、私自身の「影響の受けやすさ」から来るものなのかもしれないが、「みんなと一緒に何かを作り上げる楽しさ」を味わったこのチーム開発。ここが間違いなく、私が「作り手としてのエンジニア」にハマった瞬間であった。
Discussion