wikiの書き方

iGEMのアドカレ2です。まともなことを書いて行きます。

はじめに

自己紹介の類を全然していませんでした。UTokyo 2024でチームリーダーをしておりました高橋と申します。よろしくお願いいたします。

さて、iGEMでは一年間の成果をwikiと2本のvideoにまとめる必要があります。今回はwikiの作成方法について記載します。ただ、wikiの実装についてではなく、実際に載せる文章やその構成について書いていこうと思います。wikiの実装については、公式ページやiGEMアドベントカレンダー1の12/5の記事などを参照してください。(私がvideoについての記事を書く予定はありません。)

wikiを書く前に

iGEMのwikiは共同研究の成果であることに加え、educationやhuman practiceといった活動についても記載する必要があり、文章量が膨大になります。それら全てをwiki freeze直前期に全てまとめるのは非現実的です。完成された文章ではないにしろ、活動内容を定期的にまとめることを勧めます。

少し話がそれますが、活動内容をまとめることはwikiだけに効果があるわけではありません。現状を正しく認識し、チームに共有することができます。主要なメンバーだけが理解しているという状態を改善したり、一時期離れていたメンバーなどの理解も促進できます。また、今後研究を行う場合にも成果を定期的にまとめる方がいいと周囲の人が言ってました。

私が2024年のiGEM competitonを経験し、定期的にまとめた方が良いと感じたものを以下に2つ掲載します。

• 実験ノート
  プロトコルだけでなく、実験中に考えたことなどあらゆるものを記載しましょう。いうまでもないですが、結果についても高い頻度でまとめましょう。実験ノートをwikiに載せるチームが多いですが、必須ではありません。ただ、あった方が信頼できます。

• HPのまとめ
  各HPのまとめが存在しているとチーム内での共有に便利です。また、事実ベースで書く必要があるので、時間が経ったことによる記憶の改竄が起こりにくくなります。

すでに行っているチームもあると思いますが、これら2つが存在するだけでprojectの進行もwikiの進行も非常に加速されます。大変だと思いますが、なるべく記憶の新しいうちにこれらをまとめておきましょう。

wikiを書くとき

順番を決める

計画なくwikiを作成することは困難な上に良いものが出来上がる可能性が下がります。まずは過去のwikiを参照し、どのような項目が存在するかを把握しましょう。次にチーム全体で話し合って必要な項目とその部分の原稿担当を割り振りましょう。

必要な項目は公式サイトを適宜参照してください。
最低限必要なものはProject AttributionとProject Descriptionです。前者はチームメンバーやPIやスポンサーなどが行った活動や実際の活動期間について記載する必要があります。忘れやすいので注意が必要です。後者はprojectのあらすじを書く必要があります。
bronze medalには上記の2つに加えてproject contributionが必要になります。ここにはチームがiGEMにどれだけ貢献したかをを書きます。貢献の内容としては、partの登録、education教材の作成、softwareの開発など他のチームや合成生物学に関わる人が今後も使用できるものを記載しましょう。
silver medalには上記3つに加えて、Engineering SuccessとHuman Practicesが必要になります。前者はprojectの進行の様子を記載する必要があり、よくDBTLサイクルを用いてprojectをまとめています。後者はHPの活動を記載する必要があります。projectに対してHPがどのように関わっているのかを書きましょう。
gold medalは選択した3つのspecial prizeについてのページを作成する必要があります。各論になるためこの文章では詳細について触れません。過去のwikiや公式のrubricやhandbookを読むことを勧めます。
(Proof of conceptがmedal要件だと思っていたのですが公式サイトにはありませんでした。ただ、最低限のもので戦うよりかは最大限のもので戦う方がMedalの色も良くなります。なので、過去のwikiを参照し、必要そうなものをリストアップすることを勧めます。)

基本的な情報について理解できたと思うので、ここからは構成を考えます。まず、wikiはHOMEとそれ以外に分けることができます。HOMEはwikiの顔であり、最も魅力的に作成し注意を惹きつける必要があります。私がデザインが得意ではなく、HOMEについて助言することはできません。ただ、イラストやアニメーションとともにprojectを簡潔に紹介しましょう。

HOME以外について、wikiでは項目群ごとに区切りを設けることが多いです。projectの説明をする項目群、wet実験について説明をする項目群、アウトリーチ活動などについて説明する項目群などです。自分たちのprojectを振り返り、どの項目群に若得ることで効果的にprojctを説明できるか考えてください。そしてそれらの項目群に包含される項目を考えてください。例えば、

• Project

  • Description

  • Proposed Implementation

  • Proof of Concept

  • Contribution

  • Engineering

  • Safety & Security

• Wet Lab

  • Experiments

  • Results

  • Parts

  • Notebook

• Human Practice

  • Education

  • Integrated Human Practice

  • Entrepreneurship

このような感じで、項目を分類していきましょう。
次に、原稿を作る順番を決めます。Medalに関わる部分を最も早く作成したり、projectで一番力を入れた箇所を作成するなど色々な順番が考えられます。ここでは、私が考える最も見通しのよい優先順位を以下に記述します。

まず、Description→Proposed Implementationを作成しましょう。
この2つはprojectを他者にしてもらう上で最も重要になります。多くの人がwikiを読む際にdescriptionを参照し、そこで興味が湧いたら他の部分を読むことが殆どです。この部分で何を行っているのかをわかりやすく伝える必要があり、そのためには推敲を重ねなければなりません。最も早く作成し、何度も手直しすることで誰が読んでもわかるprojectの紹介をしましょう。

次にEngineeringを作成しましょう。
一年間の成果なので分量が膨大になりがちです。早めに手をつけておくことを勧めます。また、Engineeringで状況を整理することでwet labやdry labの流れを考えやすくなります。DBTLサイクルを用いてprojectをまとめましょう。

そして、Human practiceを作成しましょう。
iGEMではHPが重視されています。チーム内だけではなく、社会との関係を意識したprojectが望まれています。また、HPをまとめることでも一年の活動のまとめにつながるので状況を整理できます。

上記の3つを優先的に作成することで、projectを簡潔に伝え、状況をまとめることができます。それ以外の項目は自由に作成しても問題はありません。

メンバーに割り振る

書く順番が決まったのでメンバーを割り振っていきます。
descriptionなどprojectを簡潔に紹介する部分は、projectに一番詳しい人が担当する方がいいです。一番見えている人が骨子を作成し、多少専門的な部分を他の人に委託することで効率的かつ効果的に文章を作成できます。Engineeringもdescription同様ですが、WetリーダーとDryリーダーも共同することが望ましいです。実際の実験の進行について記載する必要があるので、一番詳しい人が書きましょう。
HPはHP班の人が書きましょう。

Wet Lab、Dry Lab、Educationはそれぞれの担当者が作成することが望ましいです。では、Proof of ConceptやContributionは誰が書くべきでしょうか。これらの部分もdescription同様にprojectが見えている人が書くべきだと思っています。ただ、全てを書いていると時間が足りなくなる可能性があるので、全体の大まかなあらすじを立てて、中身については適切な人に割り振っていきましょう。最終的にできたものをもう一度チェックし、手直しすることが最良です。ここまででわかるようにprojectが見えている人がたくさん必要です。理想的には全員がチームリーダーくらい全体を把握していて欲しいです。その状況に少しでも近づけるため、成果物を定期的にまとめましょう。

また、メンバーに割り振ると同時に期限を設けましょう。1回目の原稿の締め切りを設定し、遅れた場合にも対処できるようなbuffer期間も設けます。一番最悪なパターンは担当者が何も書いていないという状態です。wiki freeze直前は全員が忙しく、人の仕事を見ている暇はほとんどありません。蓋を開けてみるとMedal要件の項目が埋まっていなかったという事態を避けるために、早め早めの期限を設けましょう。また、間に合わない場合は別の人に仕事を投げるなど柔軟に対応しましょう。

書き始める

実際に書く始めるときに最も困ることは、一番最初です。書きたいことはあるにもかかわらず、どのようにしてwikiに落とし込めばいいかわからないという状態です。そう言ったときには過去のwikiを参照しましょう。wikiには書き出しであったり項目内の構成であったり学びが非常に多いです。

また、科学において伝える行為は非常に重要です。どれだけ素晴らしい成果であっても、当事者しか理解できない難しい概念や思考の過程がわからない文章は誰にも理解してもらえません。加えて文章として読みにくければ途中で文脈がわからなくなり、読み手に理解されません。そういった事態を避けるためにアカデミックライティングのスキルを身につけましょう。wiki freeze前に身につけるよりはもっと早い段階から学び始めることを勧めます。有名どころとして「まったく新しいアカデミック・ライティングの教科書」阿部幸大 (著) があります。自分たちの成果を余すことなく理解してもらうためには読み手に理解してもらうよう寄りそう必要があります。

修正する

wikiの原稿が書き上がった後はチーム内で修正作業をします。一度目の原稿で完璧なものができれば問題ないですが、複数の目を通すことで誤りや漏れを防ぎ、また文章としての質も高めることができます。内容だけでなく文法的におかしなところや、図表の修正点も指摘すると良いものになります。

修正作業では内容自体の修正のほかに、iGEMに合わせにいくという作業もあります。competitonという性質上、iGEMには評価基準があります。Judgeが判断するため細かい部分まで統一的ではないものの、公開されている評価基準は変わりません。そこでrubricやhandbookを参照し、iGEMが求めているもの、評価されるものに調整していく作業を行うとMedalやSpecial Prizeの獲得につながります。

修正作業が終わればwikiを実装しましょう。ここまでの作業にかなりの時間がかかります。原稿作成を開始してから修正作業が終わるまで1ヶ月程度かかることを見越してwikiを書き始めてください。また、wikiの実装班以外の人は実装班の人のこともちゃんと考えてあげてください。膨大な原稿を一日で全て実装することは不可能に近いです。実装班のために余裕を持ってスケジュール管理をしてください。

wikiを書き終わった後

wikiを書き終わった後はひたすら修正作業をします。引用が正しく行えているかどうか、ハイパーリンクが機能しているかどうか、画像が正しく読み込めているかどうかなどです。その前にMedal要件を満たしているかどうか確認してください。attributionは存在しますか？contributionはちゃんと書けていますか？これらを落とすとbronze medalの獲得すらかないません。メンバー全員で確認するようにしましょう。

Tips

ここからはtips兼おふざけゾーンです。時間があれば読んでください。

• 時短集

  • Contributionをproject開始時から書く
    partは書きにくいですが、educationで使った資料や完成したsoftwareなどはその時点でcontributionを書くことができます。先に書いておけば時短になります。

  • member一覧を先に作っておく
    実装班は原稿が上がってくるまでにwikiのデザインなどを行っていると思いますが、memberページはprojectとは関係ないので先にできることは先に済ませてしまいましょう。

  • 引用の形式を整えておく
    なんだかんだ参考文献を書くのは大変です。APAスタイルをコピペして貼り付けるだけですが、版が異なったり、コピペできない論文もあります。後で困るので先に参考文献のリストアップをしましょう。そのときに採用する版を決めておくと便利です。

  • Safety & Securityはコピペで済ます
    これはspecial prizeを狙っているところにはお勧めできませんが、ラボの安全規則や一般的な装置の扱いなどは自分たちのチームの過去のwikiや他のチームのwikiからコピペできます。別のチームのwikiをコピペをするのは権利的に良くない可能性がありますが、どちらにせよ装置の扱いについては部分的に被ってしまいます。

  • Experimentsは先に書く
    実験で使用するプロトコルを時間があるときに英訳し、そのまま原稿にしましょう。wiki freeze前の重要な時期にプロトコルの英訳に時間を取られないようにしたいです。またSafety & Securityと同じように過年度のものをコピペするのも手です。

• Contributionの限界に挑む
  以前読んだwikiの中でContributionが5, 6行のものがありました。そのチームはbronze medal以上を獲得していました。チキンレース目的でContributionを4行で済ませてみてもいいかもしれません。

• 徹夜しすぎない
  実装班は結構大変です。私はフロントエンドに詳しくはないのですが、実装できる環境を持っていたので原稿をコピペして実装していました。UTokyo 2024は文章量が多く(削減するべきだった)原稿の実装を2, 3人で行なっていたですが、ほとんど6徹しました。カフェインは効かない代わりにずっと興奮状態でした。ウキー。その時からずっと眠いです。

• 埋め込みにたよる
  W & M 2023は非常に興味深いprojectでありながらwikiの量は少ないです。代わりに100-200ページに渡る文章をwikiに埋め込んでいました。実装が間に合わなさそうであれば埋め込むのも手かもしれません。

• おしゃれなページにしすぎない
  これは個人の見解ですが、HOME以外のページであまりにも動きがあると読みにくいです。評価する側からしたら好印象かもしれませんが、私はスクロールするたびに文章が現れるタイプが苦手です。大体が環境のせいか微妙に切れており読みにくいです。

• 直接飛べるようにする
  wikiを作成しているうちにwikiの各ページへ飛ぶリンクを覚えてきます。検索画面でチーム名や年度を打って検索し読みたいページを見にくいレイアウトから探すよりもダイレクトに飛べる方がかっこいいです。

終わりに

こんな感じでこの文章を終わります。皆さんがwiki freezeに間に合うことを祈っております。