経験備忘録_チーム開発_2022年
こんにちは。お久しぶりです。
今回は、これまでのチーム開発について学んだこと、これからについて、備忘録も兼ねて共有します。
ウォーターフォール型開発(WF型)
Javaを使ってソフトウェア工学について学ぶ講義の締めくくりとして、ウォーターフォール型でチーム開発(4名)を行いました。この講義の趣旨は、構造的要求分析とUMLの書き方ができるようになることです。要件定義から開発まで８時間ほどです。時間外作業(残業)はしていません。
開発環境はEclipseを使い、話し合い(対面)のときは口話と手話を用いました。コードや成果の共有は講義で使用しているTeamsチャンネルで行いました。
チーム開発では、ウォーターフォール型(以下WF型と表記)での開発ということで、
①要件定義
まず作るものについて話し合い、だいたいの要件が決まったらシナリオ(ユーザーがどういう風に使うか。実装したい機能)として書き出し、
②外部設計
画面構成や画面遷移などのUIをOnenoteを使って文章と図にまとめました。
③内部設計
①、②をもとにUML(クラス図、ユースケース図、アクティビティ図、シーケンス図)をチームメンバーで分担して作りました。図は4人で分担して作成し、作成次第他メンバーに共有、確認を受け、必要に応じて修正を行いました。
④コーディング＆単体テスト
その後、作成するクラスを分担し、作成したUMLに従って各々で開発を進めました。(ソロプロ)また、各々で単体テストを行いクラス内の処理が問題なく実行されることを確認しました。
⑤結合テスト
講義が終わる直前(20～30分前)に、各々で書いたプログラムを合わせて、各クラス間の値の受け渡し、処理に問題がないか確認しました。
⑥運用テスト
中間発表と最終発表の直前に、他のチームメンバーに使っていただきフィードバックを受けました。
⑦リリース
最終発表で、作成したもののタイトル、開発理由、内容、UMLについて説明を行い、その後デモとして実際にユーザーが使う流れを実演しました。
ここまでがWF型を採用したチーム開発の流れです。
振り返り
ここからは振り返りになります。
私はチームの責任者としてコーディング以外に以下の4点を行いました。
①話し合い、開発の司会・進捗管理
②UMLの確認
③メンバーからの開発に関する相談への対応
④その日の成果まとめと次回やることのチームへの共有
ちなみに開発中は、自分の担当部分を書くより相談に応じる時間の方が長かったです。また、説明がうまく通らず自分が書いてしまった部分もありました。感覚で言うと3対7ぐらいで、もう少し自分の担当部分に時間をかけたかったです…プログラムの担当割合を見ても80%以上書いていたようです。(今振り返ると属人化が起きていました…)
-ポジションについて
チーム決めの際に、受講者の中で比較的Javaが使える人・自信がある人をリーダーとして決めてからメンバーが割り振られました。(各チームの実力がなるべく均等になるように。)
ただ技術レベルとしては、Javaを使って構造化プログラミングが出来る、与えられた課題に対して自力で取り組める程度として自覚していました。
チーム決めのあと、何を作るか話し合いを行うことになり、上記の①～③では、自分が中心に議論を進めていました。
>今考えると司会やテックリードとしての役割への負担を重く感じていました。一応、OneNoteの導入やUML、クラスの担当割振りによってなるべく自分の負担が軽減するよう努めてはいました。
また、チーム全体の雰囲気としてチーム開発への意欲、興味は高かったですが、技術力への不安が大きいと自覚しているメンバーがほとんどでした。(私自身もテックリードとして動けるほど自信は無かったです…
そのためか、アイデアを出す際もさほど盛り上がらず、静かな印象を受けました。ひとまず自分の意見を出してから、意見を促したりその意見を掘り下げるようにしました。それから、コミュニケーション方法としては口話と手話(どちらかというと手話寄り)を併用していたのですが、なかなか意見の共有がうまく出来ず、考えを伝えるのに苦労していました。
そのため、途中からOneNoteを使いチームで一つの操作画面を見ながら議論をすることに。この工夫の導入により、メンバーが自発的に意見をまとめたり(視覚化)、画面構成をイラストで描いたりするように。
口頭だけだと議論状況が不明瞭になり、何が決まり、今どこで悩んでいるのかがわからず、また作成する画面の様子がメンバーによって想像しているものが違っていました。
-相談への対応について
Javaの書き方については講義で課題等を通して使えるように全員がしていたはずですが、実装したい機能をどう書けばいいのかわからない、或いはうまく実行できないという相談が多かったです。
開発中は、定期的にメンバーへ進捗状況を確認し、何をしているか、どこで詰まっているのか把握するようにしていました。
開発に使える時間が限られており決して多くはないことと、その講義時間内で何かしらの機能を動かせるようにするためです。
その際、困ったことがあれば自分や他のメンバーに相談するように伝えてはいたのですが、他人(主に私)が声をかけるまで、自分で調べたりあれこれと見直したりとしていたものの状況は変わらずただただ時間を費やしてしまっていました。(私が対応してみたらすぐに解決した内容が多く、初歩的な内容で詰まっていました。)
後から話を聞いてみると、各々コーディングに集中しているため話しかけにくい、技術的に頼りにくいといった理由があったようです。
前者はソロプロのデメリットで、後者は当初から全員が抱えていた不安でした。上記への解決策として進捗状況の確認を行うスパンを短めにしました。
しかし、その結果、メンバーの担当部分の進捗は良くなったものの自分の担当部分に使える時間が減ることに。
私はチーム内で最も技術力があることから、作成システムの基幹部分を担当することになり、書く量やその中身の複雑さも他より大変で思うように進まずだいぶ焦っていました。
そのためチームの資源として、だいぶ大きな損失が生まれていたと思います。
ちなみに、モブプロやペアプロを導入しなかった理由はそもそもその存在を知らず、また講義でチーム開発を行う上でのルールとして一人一クラス以上担当することになっていたため、必然と各々の担当を各々で行うことになっりました。ペアプロやモブプロで進めていたらもう少し進捗が良くなったかもしれませんが、知識や技術面で不安がある人が4人中3人では、うまくいったかどうか…ワンマンプレー(属人化)になっていたのではと思います。
-WF型について
講義の目的として、要求分析を行ったりUMLの作成は一応果たすことができましたが、①～③までの流れの中で、よりアイデア出しが活発になるような環境を作ることができなかったのが残念でした。(Onenoteを使ったことで、議論の可視化はできましたが、意見出しが活発になったわけではないです。)
また、あれこれと気づき自ら動けたものの、そのせいでどんどんチーム内での負担が重くなっていました。他人への仕事の割振りも考えましたが、議論の様子などを踏まえるとメンバーを十分に信頼できず、求める作業が重いのではと考えてしまい、結局自分でやってしまいました。(チームへ相談はしていましたが、相談した上でその仕事をやって貰える、割り振れるような環境を十分につくることができなかったのが原因の一つだと思います。)
そもそも、チームのマネジメントができなかった自分に原因があるのですが。
マネジメントを担当する自分が困ったときのサポート役を決めていなかったことや、チームマネジメントの改善を気軽に提案できるような雰囲気づくり、すぐにメンバーへ相談できる環境づくりが十分に出来ていなかったです。
そこまで余裕が無かったと言うとただの言い訳になってしまいますが。
ということで、以上が1回目のチーム開発についてでした。
自分がどのようにチームに貢献するか考えるきっかけや、チーム開発の経験を積みたいと考えたきっかけになります。
この経験から、学内学外を問わずチーム開発の機会を探っていました。
以前から、技育祭への参加などでハッカソンの存在は知っており、「いつか出てみたい！」「チームで画期的なアプリを作りたい！！」と憧れがありました。
そこで、同期を誘いハッカソンに参加することに。
それが次の内容になります。
ハッカソン(技育CAMP8月.vol7)
夏休みに入ったところで、遂にハッカソンに参加することに。参加する前提として、同期と自分が同じチームにいること、それから交流の機会を作るためにメンバーを募集して3人以上で開発を行うことにしました。(チーム作成は運営の方に調整していただきました)
チーム結成がハッカソン数日前だったので、作成物の相談等はほとんどありませんでした。
とりあえず、自分たちで作りたいものを軽く説明してみたらそれを開発することに。
チームは自分と同期、もう一人を加えて3名でした。技術的には、彼がサーバーサイドも一応書けるレベルだったと思います。
今回の記事では例によって作った物に関する技術的な話は置いときます。
情報保障手法としての音声認識
で、懸念していたことが自分たちは聴覚障害があり、相手の言っていることが言葉として捉えられないことでした。自分は以前の記事で伝音性難聴であることは共有していたと思います。伝音は簡単に言うと、音が小さく聴こえる状態です。(耳穴を塞いで音を聴いてみると似たような状況が再現できると思います。結構聴こえなくて困りますよね？)
オンラインで作業するときは、以前記事でも共有していた骨伝導イヤホン（現Shokz,旧AfterShokzのAeropex）を使用しているため、一応音声でのコミュニケーションは問題ありません。
で、同期が感音性難聴で音が明瞭に聴こえない状態です。
そのままでは、コミュニケーションが取れないので、情報保障の手段として音声認識を用いて、自動で文字起こしを行いました。
細かい手法については、ここでは控えますが、GoogleドキュメントやWordなどを使って文字起こしができます。
そして、チーム開発に入る前に、上記について軽く説明して文字起こしの状況を見ながら話すようにお願いしました。
結論から言うと、この手法は失敗でした。
というのも…
音声認識により、自動で文字起こしができるのですが、その精度は発話状況や入力環境、音声認識エンジンの性能によって変わり、必ずすべての発話が奇麗に文字になるわけではありません。(勿論、すべて文字になるのが理想ですが。)
チーム開発中は、主に音声のみでコミュニケーションを行い、音声認識により自動文字起こしを行っていました。自分も同期も声で会話に参加してはいたのですが、徐々に同期の彼が静かになってしまい…
なんでかというと、文字起こし結果が汚く、何を言っているのか、今何について話しているのかがわからない状態でした。脱字や誤字が目立ち、文章として成り立っていない残骸がずっと続くばかり…
こうなることは予想できていたので、直せるときは自分が直したり、個人チャットで状況共有はしていましたが、すべての情報を共有できていたわけではありませんでした。
というのも、音声によるコミュニケーションの流れは早く、文字起こしが間に合っていなかったり、文字起こしのためのラグが生じ、リアルタイムでのコミュニケーションができていませんでした。
普段、大学では十分な情報保障環境の中で講義を受けているため、情報保障者と呼ばれる方達に文字起こしをしていただいたり、講師は手話と口話を併用し、音声認識を用いる場合にはとくに明瞭にゆっくりと話していました。
でも、チーム開発ではいわゆる普通の速度でばーーーっと話すため、こちらの想定以上にコミュニケーションが難しい状況でした。
開始早々、そのことに気づいてはいたもののそのときはどうしようもなく、とりあえず自分ともう一人の参加者とで音声コミュニケーションを行いながら、コーディングを行い、自分が手が空いたときに同期に状況の説明、詰まったところの相談をしていました。
これでは、まともなチーム開発とは言えません。チーム内の資源としても、同期の能力が十分に発揮できる環境ではなかったため、大きな損失でした。
結果的に、作りたいもののコアとなる部分は実装することができデプロイできました。
反省点
ただ、コミュニケーションにおける情報保障について大きな反省点がありました。
①自分たちの文字起こしや聴覚障害に関する説明が不十分だったこと
②自分たち自身が情報保障を行うことで、開発に専念できなかったこと
③参加者が文字起こしの存在を忘れてしまい、文字起こしが出来ていなかったり逐一確認するなどができていなかったこと
①・③について、どこまで説明したらいいか、また相手に過剰な負担とならないためにはどうすればいいかわからず、出来る限りの説明はしたのですが、開発が進むと、進捗状況が停滞したり雰囲気がお通夜になったりと、文字起こしのことに意識を向けるよう声掛けをすることも憚れる状況に。
②について、3人という決して多いとは言えないチームでは自分たちで情報保障のすべてを全うすることは難しいことがよくわかりました。
理想を言うならば、対面でもオンラインでもその場にいる全員が同じ情報を受け取れる環境が気軽に、そして質(ここではその情報の精度と伝達速度のこと)が高くあってほしいのですが…
音声認識を使う際には、誤字脱字などが起きるため、それを修正する人が必要ですが、開発者当事者はいつでも、ずっとそのことに手を動かす暇はないですよね…
対応としては、
・チームメンバーに必要なことを理解してもらえるよう説明すること
・逐次、必要に応じて情報保障手法の調整を行える環境を構築すること
・情報保障を受ける側が情報保障について正しく適切な理解を持つこと
以上の3点があると思います。
いずれも実践していましたが、不足していた部分があったため今回の結果になったのだと考えています。
障害への理解について
また、自分自身、大学に入学してから情報保障について学び、気が付いたことなのですが、いわゆる聴者と呼んでいる方々（聴こえにくい人、聴こえない人という意味での「聴覚障害者、ろう者」に対して「聴こえる人」を指します。）は、聴覚障害に限りませんが「障害」に対して正しい知識、理解があまり進んでいないことが多いです。
私も、今でこそ、ある程度は勉強したおかげで多少の知識はつきましたが以前はそうでありませんでした。それは、自分自身に障害があっても、他に障害がある方と触れ合ったことがなければ、障害や社会における障害との関わりについて体系的に学べる環境も知らなかったからです。
また、聾学校や特別支援学校などに在籍した経験があっても、完璧に情報保障について理解し実践できている人は少ないと思います。
社会の中でも割合として小さい障害者当事者でも、自らの障害に対して正しく理解できていないことがあるのですから、関係者でもない一般人にとっては、障害について十分な理解が無いのが当たり前のことだと思います。それだけ、まだ少なくとも日本では聴覚障害について普及していないということでしょう。
これ以上は、本記事の趣旨から逸れるので一旦横に置いておきますが、とにかくここで伝えたいのは、その場で障害や情報保障について説明したとしても、いきなり順応できるとは限らないし、難しいということです。
ちなみに、また脇道に逸れますが、上記に関連して、障害やそれに関する情報を他人にわかりやすく伝えるサポートができるツール、アプリを開発しようと、現在は要件定義を(亀のごとく遅い進捗状況であるものの)行っているところです。
個人それぞれで、知っている知識の範囲で紙に書いたり文書として印刷するのも良いのですが、テンプレート・フォーマットとしてユーザーが必要な情報を入力しやすく、また配布・共有しやすくしたいと考えています。
なぜなら、不足している情報、当事者自身が知らない情報があり、そのことを他の人に共有していないことで不利益を被る・或いは必要な配慮が受けられないかもしれないからです。
ユーザー目線で言うと、自分の障害状況を伝えたい・知ってもらいたい人に手短にかつわかりやすく伝えられる・共有できるアプリです。
アプリでなくとも何らかの形で上記を満たすようなものを公開予定です。(いつになるかわかりませんが…)
で、話を戻しまして。
ここまでがハッカソンに参加したお話でした。残念ながら今回は受賞はできませんでしたが、いずれ再挑戦したい。そして受賞する。学内でメンバー募ってチーム作りたい..デフエンジニアで構成されたデフエンジニアのためのツール開発とかしてみたい。(只今、準備中。)
次は、3回目のチーム開発になります
Agile開発
夏休みが終わるころ、とある集中講義を受講することに。内容は他大学で行っているenPiTのAgile開発で、チーム開発におけるフレームワークの一つを勉強して実践するものでした。
ちなみに、受講理由は
・チーム開発の経験を積みたい
・他大学、他学年との交流がしたい
からでした。
チーム開発は、前述の通り今回で３回目です。
受講理由①チーム開発の経験を積みたい
1つ目の経験を積むという話ですが、具体的に、チームに対して今の自分がどう貢献できるか、振る舞おうとしたかを俯瞰するためでした。
というのも、WF型開発ではリーダーとしてチームをまとめる立場にありましたが、うまく盛り上げて進めることができず。。
そこで、リーダーとしてどう振る舞えばチームがワイワイと動くか分析したいと考えました。
やった結果、チームをリードして進めるのではなく、それをサポートする、本筋に関する話以外で気が付いたこと、状況を踏まえて、何かよりチームとして利益になるようなことを提案する立場が得意なんじゃないかなーと気が付きました。
本筋というのは、開発でどういったことを作って～ということで、それ以外というのは、チームの雰囲気だとか、発言の様子だとか、開発とは直接関係が無いけど、改善することでより開発速度を促進するなどチームの動きが良くなるようにということです。
例えば、今回の開発では、モブプロの形で進めていたのですが、ドライバーとナビゲーターがいて、ドライバーは当然自分で(ナビゲーターにあーでもないこーでもないと言われながら)考えながらプログラミングしますが、ナビゲーターが５人もいるとどっかのタイミングで誰かが暇になってしまうことがありました。
それを見て、チーム全体の生産性をあげるような工夫ができるのではと考え、自分が何をしているのか作業の可視化を行ってはどうかと提案しました。
結果的に、それは付箋のようなものを使って、今やっているタスクに対して自分がやっている、或いは誰がこのタスクをやっているのかパッとわかるようになりました。
なので、やっているタスクが無いのであれば、スクラムマスターが状況を見てタスクをやるように指示を出したり、何かナビゲーターとして検索しておくように指示するなどできるように。
その成果として、開発初日と比べ作業量が２倍以上に増えたと実感できました。
このように、チームを活性化させるように動くという役割について経験を積むことができました。それはスクラムマスターの仕事内容であったわけですが。全行程４日間の内２日目のスクラムマスターを自分が担当したことで、それ以降「自分がスクラムマスターならこうするだろう」と考えて、俯瞰した立場から提案できるようになりました。
チーム開発において、貢献する形としては、
①技術的につよつよでガシガシコーディングする
②アイデアを出しまくったり、意見の発散<->収束を繰り返す
③状況を踏まえ指示を出す(スクラムマスター)(戦国時代で言うなら軍師)
と、３つに分けられる…？と思います。まだ分別ができるかもしれませんが、ひとまず上記の３つ。
今回は、③についてとくに学べました。単に時間を管理したり、進捗状況を確認するだけではなく、よりチームがチームとして動けるようにその場その場でカイゼンしていくのがスクラムマスターの役目だと理解しました。
スクラムマスターの動きについては、他にできることややるべきことがないか次に勉強したいところです。今後、チーム開発することがあればその時に改めて勉強してみます。
以上、1つ目の受講理由とその成果でした。
次は、２つ目。
受講理由②他大学・他学年と交流がしたい
普段、同期との交流しかなく、サークル以外に先輩後輩との交流が無くもっといろんな人とお喋りしたい！と思っていました。
また、他の大学とも絡めたら…とも。ハッカソンではそれは叶ったのですが、３人チームだったのでそこまで交流できたわけでもなく、また前述の通り余裕もありませんでした…
他大学とはチャット上ではありますが、少し交流できました。もっとガッツリ絡みたかったですが…
今回、受講して一番驚いたのが、想定以上に盛り上がってワイワイやってたことです。これまでの経験から、開発が進むだろうか、楽しめるだろうか..とあれこれ考えてたのですが杞憂でした。
開発前にあれこれやったワークでも積極的に発言し、誰かがボケればツッコんだりととにかくずっと笑いが自然発生していたように思います。
私たちのチームは、全員が聴覚障害があり、手話を第一言語とする人もいれば口話で生活してきた人もいます。
チーム開発中は、対面で手話と口話を併用したり、チャットツールを使って文字でやりとりしたり様々。
おそらく、他のチームと違うのは、我々が何をやっているのか、どんな会話をしたのかということが文字として残っており、あとから見返しやすいことでしょう。実際、あとからチャットログを見ても、他チームより圧倒的に情報量が多く、盛り上がっていたことがわかりました。
この点で、我々チーム以外の人がそのチャットを見たときに、どんな雰囲気で開発が進んでいったのか、困ったところはどこでどう解決したのかみたいなことがわかるということは他とは違う特徴だと思います。
通話しながらあーでもないこーでもないと開発を進めるのが一般的だとは思いますが、それでは一時的にその場にいる全員が音声による情報を享受するだけで後には残らない。メリットとしてはリアルタイムでポンポンっとコミュニケーションが交わされること。ただ、一方でデメリットとして、言った言わない、いつ何をしたのかわかりにくい、この２点が挙げられます。
自分たちが、そういう特性があるからこそできた工夫だったと思います。
で、先輩後輩を感じさせず、一人の人間として相手を尊重しながら気軽に話しかけられる空間が出来上がっていました。
開発が終了した今でも、たまーに集まり、とあるイベントの準備をしたりご飯に行ったりと交流が続いています。
そんな空間ができた理由、きっかけを考えてみると、
アイスブレイクによる発言しやすい環境づくり
各々の受講への熱意
お互いを否定しない
以上の３点がパッと思い浮かびました。
１つ目について、アイスブレイクの定義としては雑談等をしてチームの硬い雰囲気を壊し、発言しやすい状況を作ったり緊張をほぐしたりする技術、手法だと捉えています。
その意味で、今回の講義でアイスブレイクとなる要素がいくつかあって、とくに印象的だったのは、一つは講義内でのクイズ大会(事前に学んだことの復習の場)、もう一つは受講時間より一時間ほど早めに集まって雑談したことです。
クイズ大会では、制限時間内にチームで相談してクイズに答える場面で、回答者が「どれかな？？」と周りに聞いたならば、他の人達は予習したことを一生懸命思い出し「これじゃない？こうだったはず」みたいに発言していました。結果、なんといくつかチームがあったなかで1位。まさか１位になるとは。
それだけ皆がこの講義に対して熱意があり予習をしてきたんだろうと思います。またその成果を積極的に言えるような、クイズ大会の仕組みもうまく作用したと思われます。時間制限だったり、正解時の得点とは別で回答の先着順によって点数が加算されたりなど。
雑談について。「2.各々の受講への熱意」と箇条書きしましたが、毎日１時間ほど早く集まり、ある者は開発で使うであろう技術について他の人と確認したり、(残業ではありません)お菓子食べながらゆっくりしていました。
あとは、受講環境の用意。モニターの準備だとかテーブル、椅子の位置調整だとか。
で、３日目の振り返りのあと、帰宅後にふと気になることがありメンバーに相談したところ、最終日となる４日目の朝にとあるテーマについて雑談することに。
気になったことというのは、皆がなぜこの講義を受講したのか、何を成し遂げたいのかということです。私の受講理由は前述した２点ですが、他の方々はどんなきっかけで受講したんだろう、と気になりました。
全員一旦作業を止め、このテーマについて雑談すると、各々熱意をもって参加していたことがわかりました。皆、明確に参加する理由を言語化できるからこそクイズ大会でも優勝できたし、コミュニケーションも活発になったのだと思います。
「3.お互いを否定しない」
これは、最初からチーム内のルールとして決めていたのか、講義でそのように説明があったのか思い出せていないのですが、まあとにかく、このことを全員が共有していたことで、自分の発言がいきなり「ダメだ！」とか「ほんとにそうかな？違うと思う。」などと言われないことの安心感から、発言の質を気にせずあれこれ言えるような心理的安全性が確保されたのだと思います。
残業について
以下、本記事ではさほど重要ではない内容ですが自分のために残しておきます。
残業。それはチーム開発のために設けられた時間外で作業することと認識しています。
自分の記憶上、１回目のチーム開発でも２回目のチーム開発でも残業はしていません。時間外で作業しても生産性が高いわけではないので、いたずらに考える羽目になることはわかっていたためです。
ただ、ハッカソンでは深夜残業してオールして翌日に臨むチームもあったようですが…
今回のチーム開発でも残業はしていません。講義開始より早く集まってはいましたが、開発に関わるコーディングや議論等はしていなかったはずです。
まとめ-学んだこととこれから
これまでのチーム開発から学んだことをまとめてみます。
協力することで一人一人の負担が軽減される
視野が広がり、刺激を得られる
技術力の不足
思ったより開発は進まない
1.協力することで一人一人の負担が軽減される
大規模なシステムも複数人で取り組むことで、作業の分担及び並列化が出来るため、一人でやるより生産性が高く、またプロダクトの質も上がりやすいとわかりました。
2.視野が広がり刺激を得られる
自分には思いつかなかった発想や誰かのチームへの貢献や活躍を目の当たりにして、「すごい！」「自分もこうなりたい！」と羨望し、次の行動へのきっかけになることがわかりました。
3.技術力不足
これは、エンジニアとして活動するにあたりずっと抱える課題でしょう。常に新たな技術が確立されたり、研究が進んだりするため、最先端の技術を学び、開発に活かすことが多いことでしょう。
基本的には、随時調べて書けばいいとは思いますが、基礎的内容が無いとそもそも調べても何のことかわからず開発の手が進まないことがわかりました。
4.思ったより開発は進まない
３回チーム開発をやってみると、思った以上に時間は早く過ぎ、進捗は進まないことがわかりました。
進まない理由は、プロダクトについての議論が停滞したり、自分たちの技術では解決できないエラーを抱えたりと様々です。
WF型やアジャイル型について勉強すると、短期間でサクッと素晴らしいプロダクトを生み出すことができると思ってしまっていたのですが、最初の内からそうはいきませんでした。
とは言え、３回目の開発についてはもう５，6回程スプリントを重ねると最初に定義していた内容のほとんどは出来そうな気がします。
ということで、もうちょっと長期間で、１週間或いは２週間、１か月、半年をかけてチーム開発してみたいなと思いました。
卒業するまで何度かその機会は設けられそうなので、またこの記事の続きを書く予定です。
これから
これからは、チーム開発だけではなくて、個人開発として作りたいツールを作る過程で技術の練習をしたり、ユーザー目線でのUI/UXの改善など試みる予定です。
ツールについては、やりかけのものがいくつかあるので、要件について整理してから開発に臨む予定です。
また、Repl.it以外での開発環境も使いながらGithub等でのバージョン管理を行ったり、タスクの可視化としてmiroを使ったりする予定です。
ある程度完成したら使ってもらってフィードバックを受けたり、やったこととツールの説明を何かnoteとかスライドにまとめます。
ということで、以上、これまで行ってきたチーム開発について書いてみました。ここまで読んでくださりありがとうございました。
もしよければ他の記事もご覧ください。
あとがき-独り言
いずれ書こうと思っていた「チーム開発」。今回の経験である程度知見がたまったので書くことに。書き始めてから２週間。やっとまとめ終わった…
３回目のチーム開発については、まだまだ書きたいことはたーっくさんあるのですが、ここでは省略。
さて、次回は何を書こうか…最近勉強してる音声学とか、随分前に出した色彩学のこととか、勉強に使った本をまとめてみようかな。
あとは最近買ったオーディオテクニカの軟骨伝導ヘッドホンのこととか。
そういや、この記事、自分史上一番文字量が多いアウトプットなのでは？12500字弱とか…文字だけだと読むのキツイなあ..
登壇だとか発表のネタには丁度良い分量なのかもしれないけど。
以上.
2022年10月18日 フジえもん
もしよかったらサポートお願いします！ いただいたサポートは読書費用に充てます！