コードをコピーします。エディタ上に貼り付けて、保存します。挿入部分に貼り付けてください。戻り、「メンバー情報」というシートを作成してください。ここはユニットランチに参加しうるメンバーの情報を保存します。列を作成してください。1から順に割り振ってください。次に「履歴」というシートを作成してください。ここには今までのユニットランチで誰がどのチームだったかを記録します。順に左詰めで名前を入力してください。番号と列数が同じになるようにしてください。最後に「参加者」というシートを作成してください。いちいちIDを調べるのは面倒だと思いますので、IDの列には以下の数式を入力すると良いでしょう。必要ない関数はグループ分けを実行する前に削除して下さい。ボタンを押して実行してください。実行すると承認を求められると思うので、許可してください。見ると、参加者IDがグループごとにまとめられています!最後に履歴シートに誰が同じグループだったかを入力します。2行目が1回目のユニットランチの履歴で、以降は下の行に追記していきます。誰が同じグループだったかがわかればいいので、私は適当にアルファベットを入力しています。Product)ということもあり、まだまだ手動で操作しなければならない作業が多いです。今後改善していく部分としては、グループ分けの結果をIDではなく、名前で表示するようにするグループ分けの結果を履歴に自動で入力する必要なシートをワンクリックで自動生成できるようにするなどが挙げられます。使って開発を行なっています。書き方がよくないため、上長に余計なコストをかけてしまっていました。読み手に伝わりにくい原因を知ることができました。プログラミングスキルが伸び悩んでいる原因にも共通する部分があることに気づきました。見る私が感じた「文書作成」と「プログラミング」の共通点についてまとめようと思います。伝わりやすい文書を書くためには、実際に書き始める前に文書の「構成」を考えなければならないと書かれていました。その構成を考える際に、文書全体を階層構造にしておくことで、読みやすく、理解しやすい文書を作成できるということです。作成に限らず、日報やドキュメントを書くときも、構成を全く考えずに書いていることに気がつきました。書いている途中で何を書いているのか分からなくなることが多いです。プログラミングの場合これはプログラミングでも同じだなと、本を読んでいて気がつきました。私は仕様がある程度固まってくると、まだあまり整理できていないのに、すぐにプログラムを書き始めます。すると文書作成と同様、書いている途中で何を実装しているのか分からなくなります。仕様を整理したわけではないので、仕様の考慮漏れがあるなどして、手戻りが発生してしまっています。まとめると...文書作成にしても、プログラミングにしても、全体を階層構造にすることで複雑な事柄を細分化し、簡潔にまとめることが大切だと感じました。読み手が理解しやすい文章を書くには、長い歴史を経て作り上げられたパターンを使うことが勧められていました。「起承転結」という展開パターンです。長い歴史から確立されたこのパターンは、人間が順を追って事象を把握、理解する際の思考の流れに合ったものであり、理解の仕組みを反映したもの考えられています。このパターンの沿って書けば、自然と読み手が理解しやすい文章をかけるということです。プログラミングの場合これはプログラミングでも同じだなと思いました。私が使用しているオブジェクト指向言語にも、デザインパターンと呼ばれるパターンがあります。これも上記と同様に私よりもはるかに優れたエンジニアたちが長い歴史を経て確立した設計パターンです。システム設計で困った時に、デザインパターンを使うことで解決する問題も多いでしょう。まとめると...文書作成にしても、プログラミングにしても、すでに確立されているパターンを使うことで、目標を達成しやすくなるということです。巨人の肩の上に立つというのは本当に大切だなと再確認しました。文書作成で抱えていた課題とプログラミングスキルの伸び悩みの原因に共通する部分があったことに驚きました。今回の学びは汎用的なもので、他にも活かせる部分があるはずです。一つの学びをより広い範囲で活用できるようになりたいものです。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。