チーム開発うまくいかなかった時となんかうまくいった時の差について考えてみる。

技術 日記 ポエム チーム開発

先日、授業で「機械学習を利用したアプリケーションの提案」についてのグループ課題（最終課題）が出たので、提案だけじゃなくてプロトタイプまで作っちゃおうというノリでチームの開発を進めたら、うまくいったのでその時のことをまとめたい。

また、同じメンバーで長すぎた春休み中に開発を行ったら、個々はいいところまで進んだが完成することができなかったので、その時との違いについて考えたい。

作っていたもの

  • うまくいった時

授業の音声をテキスト化し、文章を要約して重要語の補足説明を入れてくれるアプリケーション。

プロトタイプはこちらに公開しています。

https://summary-classes-web.azurewebsites.net/

 

使用言語、フレームワーク
Python,Flask,Azureなど 

  • うまくいかなかったもの

AOJ（会津大学が公開しているオンラインジャッジ）がオフラインでもできるソフトウェア

使用言語、フレームワーク
C#, .NET

うまくいかなかった時


はじめにうまくいかなかった時について振り返りたい。
昨年の12月、「チーム開発でぎっとはぶであじゃいる開発って響き、なんかかっこよくね」ということで始まったプロジェクトであった。

はじめは、GitHubの使い方、プッシュやマージ、プルリクについて学び、（一人でプルリク使うとなんか虚しくなるのでみんなでできてよかった）その後分担して作業を進めていった。
私が思う、うまくいかなかった原因、要因は以下の５つだと思う。

 

  •  機能を細分化しすぎた


まずはじめに、機能を細分化しすぎた点があげられる。今回は、ネットワーク部、エディタ部、コンパイラ部に別れて作業を行った。それぞれ各一人が担当し、全く互換性がないまま個々の技術が実装されていってしまった。これが、一番最後に一つにまとめられない原因を作ることとなるのです。 

  • ビジョンがなかった

次に、作りたいものへのビジョンが明確でなかったのではないかと思う。（図１）のようにしっかりと、要件定義、設計を行ったのですが、機能を細分化しすぎたため、全体を統括するプロジェクトマネージャーみたいな人間がいなかったのが原因だと思う。

f:id:y_a_m_a_y_a:20200724125036p:plain

ログイン画面の設計案

 


３つ目に、アジャイル開発のレポートを書いた直後（ソフトウェア設計論について一通り履修済み）だったため、開発中意識はしていた（形）だったが、実際は小さなリリースを重ねるどころか、全体をまとめることができなかった。Visual Studioがmacがいい感じじゃなかったり、環境依存の問題やいろんな問題がありました。

  • オンラインで繋げた時のみに作業をしていた


オンラインの進捗会議が、進捗の確認ではなく無言の作業時間だった。。。

  • ソフトウェアを作ることより、ソフトウェアに使われていた


タイトルはよくわからないですが、以下のようなことです。
ソフトウェアを作るという目標より、個々のパートのソフトウェアを作ることに集中してソフトウェア全体が見えていなかった。
はじめにも述べたように、ソフトウェア全体を管理するPMがいなかったのも大きな原因ではないかと思います。

  • 使用する言語技術についての理解度がみんな違った


使用する言語はC#を利用しました。理由としては、オブジェクト指向が強めの言語で、個々で開発しやすい。OSに依存せずマルチなプラットフォームで使えるなどの理由から採用しました。しかし、メンバーのうちC#はネイティブでかけるのが一人、自分を含め残りの二人は初めてのC#だったので、はじめのC#の勉強会が少なかったのではないかなと思います（C++かけるからそれの++版と思っていたら意外と違かった）ただ、普通に皆コードはかけるので、新しい技術を使う際はみんなで勉強会を開いて行くべきだなと感じました。

  • デザイナーいなくね？


これが最大の原因です。xmlでデザインすることの難しさについて、技術選定や開発を始めた頃全く考慮していなかったのが一番の問題でした。今回は、ModenUIというフレームワークを調べて採用しましたが、なかなか難しかったです。
そして深刻なデザイナ不足でした。「どのように見せるか」についてはすごく大事ですね。

  • これらの結果


API叩いて、問題文取得や回答を送信するネットワーク部、Tabやインデント、{の自動補間に対応した何気に強いエディタ部、実行を押したらコンパイルしてテストケースのローカル実行のコンパイラ部。３つの機能が個々に完成しました。しかし、デザインや互換性の問題などから一つにまとめられませんでした。
また、この結果がわかったのは4月でした。

 

ここに、どこまでできたかを示しておきます。

・なぜかしれないけどうまくいった例

 

次にうまくいった例についての振り返りをしたいなと。

 

今回作成したのは、授業の音声をテキスト化し、文章を要約して重要語の補足説明を入れてくれるアプリケーションです。
文章要約には、bag-of-wordsで単語のベクトル化をして、２つの文章ごとの関連度を調べています。関連度が高い文同士を繋げて繋がっているものが多いぶんを抽出して実装をしています。（ちょうど授業で理論を習った内容だったのでよかった）

開発期間は一週間ぐらいです。意外とすんなりと作れてしまったのでびっくりです。
今度参加するハッカソンと似たような感じだったので、それの練習として作りました。

・よかった点

  • ビジョンについてすごく話し合った


今回の成功の要因は、作りたいものについてよく話し合ったことなのではないかと思います。チーム内の共有のScrapboxにくだらないものから真面目なものまでアイデアを書き連ねるページがあり、もともとそこにアイデアをだすという習慣がありました。それを元に、アイデア出しを３時間近く話し合い一番欲しくて、授業でやったら面白そうなもの（先生の話した内容をリアルタイムで要約できたら受けそうじゃない？）を選びました。

何のために作りたいか、どんなものを作りたいかを詳しく話し合ったことが今回の成功の要因なんじゃないかなと思います。
ちゃんとは意識していなかったが、要件定義をしっかりやったんだなと思います。

  • 目標、期限があった

締め切り直前はブースト入りますよね。開発のモチベーションになったのではないかと思います。

すでにある手法を元に、どのような流れで作るかを決め、文章を要約する機能を一気に作りました。これで最初のプロダクトとしての形が出来て、この後の流れが明確になったのではないかと思います。その後、重要語検出やデザインの機能が加わり、バージョン名のないバージョンアップで機能が増えていきました。

 

f:id:y_a_m_a_y_a:20200724125905p:plain

はじめの概形（フロントは昔書いたhtmlをそのまま）

 

f:id:y_a_m_a_y_a:20200724130039j:plain

HTML,CSSを書いてくれて神ってなった @jimar884

 Gyazo

f:id:y_a_m_a_y_a:20200724130206p:plain

重要語の検出機能が追加 @tomsoyaN

Gyazo

f:id:y_a_m_a_y_a:20200724130237p:plain

WEBスクレイピングの機能が追加（重いのでβ版)@tomsoyaN

f:id:y_a_m_a_y_a:20200724130409j:plain

!!???

 

 

  • 作業の分業

前回失敗した作業の分業について、今回の開発ではうまく動きました。
ブラウザに表示までやったら、CSSやhtmlを書いてもらって、その後にバックエンドの機能を追加するなど、必要なものが分かったら作業を割り振るという内容が多く、よかったのではないかなと思います。また、使用をはじめに多く決めすぎなかったため、個々が実装したいものを追加で実装することが出来たのかなと思います。言い換えると三人の個性が合わさって出来たのではないかと思います。
しかし、設計をちゃんとやらなかったため、コードに冗長性があったり、プロジェクトの肥大化があったりの問題もありました。

 

  • 同時平行ではない開発

今回は、はじめに大枠を作り、機能を追加していく形だったので、同時に違う作業をすることは少なかったのではないかなと思います。レポートに追われる日々の中、全員の予定が会う機会が少なかったという要因もあります。実際の開発では、効率が悪いので、平行して行える開発を考える必要があると思います。

 

  • 製作会議は進捗確認でメインはプレゼンについて話し合い

今回の課題の内容は、「プロトタイプを作る」ことではなく「プロジェクトの提案」だったのでプロトタイプはおまけでした。（簡単に示せたらいいなと思っていたらいい感じのものが出来てしまって少し驚いています。）
そのため、どのようなプレゼンを行うかが製作会議の主な内容でした。前回のように、製作会議が実装の時間ではなく簡単な進捗の確認や方向性の確認だけだったので、アプリケーション自体、プロジェクト自体を話す時間が確保できたのが大きいのではないかと思います。

 

  • 前回と今回の違い、今回の反省

前回と今回の最大の違いは、プロジェクト自体について話会う時間が多く、プロジェクトのビジョンが明確に共有されていたことだと思います。
今回はプロトタイプを作ることではなく、プロジェクトの提案がメインだったので、自分はコードを書く時間は会議の時間と同じぐらいだったと思います。

また、設計を明確に行わず個々のアイデアの出しあいでプロジェクトを作れたことはすごくよかったと思います。実際の開発では、確実に空中分解すると思いますが、ハッカソンなどの短期間のプロジェクトの場合は面白いアイデアが出てきて、仕様書を超えた良いものができるかなと思います。

一方反省点は、一人が開発をある程度まで進めそれに後から機能を追加していくものであったため、ロスの時間が生まれてしまったことです。
時間は有限ではあるので、より複雑なプロジェクトの時に時間的に間に合わない可能性があるのではないかと思います。
また、設計をしっかり行わなかったため、少し変更した同じコードを違う関数で定義することや、動作確認のjupyter Notebookファイルが大量発生してしまうなど、コードの冗長性やプロジェクトの肥大化が起きてしまいました。
同時に作業を進めていれば、競合が起きるのでフィードバックがしやすいのですが、完成した後に気がつくので、手をつけられないという問題がありました。
ここは、プロジェクトの大きさによって一長一短な気がします。

 

 

感想

なんかうまくいったのでヨシ←

f:id:y_a_m_a_y_a:20200724131111p:plain

発表後のメンバーの様子（よし）

 

ハッカソン出ようぜってラインで行ったら２分後にはOKが帰ってくるようなノリのメンバーなのでハッカソンもこんな感じで頑張りたいと思います。
以前からだいぶ感じているところではありますが、クリエーションって楽しいなと思います。

でもチーム開発って難しい！！（三人寄ればなんとかをうまく使いこなしたい）

 

 

 

----------------------------------------------

こっからは今回作ったやつを使って要約した結果です（半分の文章量にしています。）

summary-classes-web.azurewebsites.net

 

 

---------------------------------------------

先日、授業で「機械学習を利用したアプリケーションの提案」についてのグループ課題（最終課題）が出たので、提案だけじゃなくてプロトタイプまで作っちゃおうというノリでチームの開発を進めたら、うまくいったのでその時のことをまとめたい。   今回作成したのは、授業の音声をテキスト化し、文章を要約して重要語の補足説明を入れてくれるアプリケーションです。 文章要約には、bag-of-wordsで単語のベクトル化をして、２つの文章ごとの関連度を調べています。関連度が高い文同士を繋げて繋がっているものが多いぶんを抽出して実装をしています。（ちょうど授業で理論を習った内容だったのでよかった） 開発期間は一週間ぐらいです。意外とすんなりと作れてしまったのでびっくりです。 今度参加するハッカソンと似たような感じだったので、それの練習として作りました。

・よかった点 ビジョンについてすごく話し合った 今回の成功の要因は、作りたいものについてよく話し合ったことなのではないかと思います。チーム内の共有のScrapboxにくだらないものから真面目なものまでアイデアを書き連ねるページがあり、もともとそこにアイデアをだすという習慣がありました。それを元に、アイデア出しを３時間近く話し合い一番欲しくて、授業でやったら面白そうなもの（先生の話した内容をリアルタイムで要約できたら受けそうじゃない？）を選びました。 何のために作りたいか、どんなものを作りたいかを詳しく話し合ったことが今回の成功の要因なんじゃないかなと思います。 ちゃんとは意識していなかったが、要件定義をしっかりやったんだなと思います。 目標、期限があった 締め切り直前はブースト入りますよね。開発のモチベーションになったのではないかと思います。

アジャイル開発（とよんでいいものか） すでにある手法を元に、どのような流れで作るかを決め、文章を要約する機能を一気に作りました。これで最初のプロダクトとしての形が出来て、この後の流れが明確になったのではないかと思います。その後、重要語検出やデザインの機能が加わり、バージョン名のないバージョンアップで機能が増えていきました。   はじめの概形（フロントは昔書いたhtmlをそのまま）   HTML,CSSを書いてくれて神ってなった @jimar884   重要語の検出機能が追加 @tomsoyaN WEBスクレイピングの機能が追加（重いのでβ版)@tomsoyaN !!???     作業の分業 前回失敗した作業の分業について、今回の開発ではうまく動きました。 ブラウザに表示までやったら、CSSやhtmlを書いてもらって、その後にバックエンドの機能を追加するなど、必要なものが分かったら作業を割り振るという内容が多く、よかったのではないかなと思います。また、使用をはじめに多く決めすぎなかったため、個々が実装したいものを追加で実装することが出来たのかなと思います。言い換えると三人の個性が合わさって出来たのではないかと思います。 しかし、設計をちゃんとやらなかったため、コードに冗長性があったり、プロジェクトの肥大化があったりの問題もありました。  

同時平行ではない開発 今回は、はじめに大枠を作り、機能を追加していく形だったので、同時に違う作業をすることは少なかったのではないかなと思います。レポートに追われる日々の中、全員の予定が会う機会が少なかったという要因もあります。実際の開発では、効率が悪いので、平行して行える開発を考える必要があると思います。  製作会議は進捗確認でメインはプレゼンについて話し合い 今回の課題の内容は、「プロトタイプを作る」ことではなく「プロジェクトの提案」だったのでプロトタイプはおまけでした。（簡単に示せたらいいなと思っていたらいい感じのものが出来てしまって少し驚いています。） そのため、どのようなプレゼンを行うかが製作会議の主な内容でした。前回のように、製作会議が実装の時間ではなく簡単な進捗の確認や方向性の確認だけだったので、アプリケーション自体、プロジェクト自体を話す時間が確保できたのが大きいのではないかと思います。   前回と今回の違い、今回の反省 前回と今回の最大の違いは、プロジェクト自体について話会う時間が多く、プロジェクトのビジョンが明確に共有されていたことだと思います。 今回はプロトタイプを作ることではなく、プロジェクトの提案がメインだったので、自分はコードを書く時間は会議の時間と同じぐらいだったと思います。 また、設計を明確に行わず個々のアイデアの出しあいでプロジェクトを作れたことはすごくよかったと思います。実際の開発では、確実に空中分解すると思いますが、ハッカソンなどの短期間のプロジェクトの場合は面白いアイデアが出てきて、仕様書を超えた良いものができるかなと思います。 一方反省点は、一人が開発をある程度まで進めそれに後から機能を追加していくものであったため、ロスの時間が生まれてしまったことです。 時間は有限ではあるので、より複雑なプロジェクトの時に時間的に間に合わない可能性があるのではないかと思います。 また、設計をしっかり行わなかったため、少し変更した同じコードを違う関数で定義することや、動作確認のjupyter Notebookファイルが大量発生してしまうなど、コードの冗長性やプロジェクトの肥大化が起きてしまいました。 同時に作業を進めていれば、競合が起きるのでフィードバックがしやすいのですが、完成した後に気がつくので、手をつけられないという問題がありました。 ここは、プロジェクトの大きさによって一長一短な気がします。