電子書籍

2019/01/11

GitHubが無料でプライベートリポジトリも使えることで小説家にもGitが必須になってきたのではないか

GitHubが無料でプライベートリポジトリも使えるニュースが届いた。
とても素晴らしい。
このニュースは、小説家にもGitが必須になってきた事実を示唆していると思う。
以下、ラフなメモ書き。

【参考】
GitHub、無料ユーザーもプライベートリポジトリを使い放題に - ITmedia NEWS

【1】GitHubが無料でプライベートリポジトリも使える最大のメリットは、プライベートなドキュメントは全てGitHubで管理できることだ。
僕は、この恩恵は計り知れない、と思う。

たとえば、ブログの元ネタのメモ、Excelで作った家計簿、執筆原稿用のWord、プレゼン資料のパワポなど、全てGitHubに入れてしまえばいい。
そうすれば、日々更新するファイルは全てGitHubの履歴として管理でき、いつでもどこでも復元できるようになる。
よって、「yyyyMMdd_ファイル名」みたいなExcelファイルを一時的に作ったり、他の共有ファイルサーバーに逐一手動でバックアップしたりする作業は不要になる。

また、GitHubにはIssue管理(チケット管理と呼ばないんだね笑)、Wikiの機能も付いているので、日々のタスクをIssueにメモしたり、常に参照すべき共有情報はWikiにまとめることができる。

つまり、個人のドキュメント管理と情報管理は、今後、GitHub中心に回るようになるだろう、と思う。
プライベートPCを切り替えても、GitHubにドキュメントがあるなら、いつでも自分だけの環境を復元できるわけだ。

【2】最近の最先端の小説家は、どうやら、GitHubを使っているらしい、という記事を見かけるようになった。
文系の人達も、プログラミングしない人達も、Gitが必須になってきたように思える。

「Githubで小説? そんな時代なの?」そうなのだ。 - 景虎日記

GitHubをコーディング以外で活用する7つの方法 | readwrite.jp

世の中の小説作家と編集者は今すぐ Word や G Suite を窓から投げ捨てて Git と GitHub の使い方を覚えるべきだ - Qiita

Web小説のリリース自動化 - Qiita

【1】小説家がGitHubを使うメリットは2つあると思う。
一つは、小説というドキュメントがGitHubの構成管理の配下になることで、成果物の履歴管理の恩恵を受けられること。
もう一つは、GitHubのワークフローを受け入れることで、プルリク機能が使えて、ソーシャルコーディングならぬソーシャルライティングが可能になること。

【2-1】1点目の利点は言うまでもない。
出版業界でも、Word主体が多いが、たぶんもう時代遅れだと思う。
Wordの変更履歴機能もあるが、正直使いにくいと思う。

【2-2】2点目の利点は、小説の推敲作業にもプルリクを使うことで、小刻みな改善がスピーディに行えるようになることだ。
僕も4冊ぐらい出版したので経験があるが、1冊の本を書くには10万~20万文字くらいの分量がいる。
それだけの文章にチェックを入れて、フィードバックを反映する作業は正直面倒だ。
その反映作業を漏れなくスピーディに行うのは、GitHubのような構成管理とチケット管理の両方の機能がなければ難しい。

その時に、プルリクが使えると便利だ。
編集者は、修正すべき該当箇所を指摘するチケットを起票するだけでなく、修正パッチをプルリクで提供すれば、Masterを管理する小説家はそのプルリクを吟味した後、取り込むだけで済む。
つまり、編集者は小説を改善する開発者、小説家は小説を管理するコミッターの役割で置き換えられる。

【2-3】他に、世の中の小説作家と編集者は今すぐ Word や G Suite を窓から投げ捨てて Git と GitHub の使い方を覚えるべきだ - Qiitaで共感する箇所は、「過去に書いた文章を再利用しやすい」部分だ。

(引用開始)
小説書きにはあるあるだと思うんですが、あるとき「ここ全部要らない!」となってバッサリ切り捨てることがあります。
そして後になって「あ、ここはあの時の文章が使えるのでは?」という時が必ず来ます。1割くらいの確率ですが。
そんな時のために退避場所として「退避ファイル」を作るのもひとつの手ですし、片倉もそうしていますが、切り捨てる際に「退避させなかった」文章は掘り返せません。
でも Git なら大丈夫。全部記録しているからね。
(引用終了)

1冊の本を書く時、最初に当然、目次と構成をラフに決めてから、書き出す。
しかし、良い本を出版しようとする時、必ず1回は、目次や構成をビッグリファクタリングするタイミングが訪れる。

そのビッグリファクタリングでは、目次や構成が大幅に変わってしまうので、今までの文章をざっくり削ったり、大幅に入れ替えたりする必要が出てくる。
一度削った内容を参照したり、一部だけ取り出すこともあったりする。
すると、Gitのような構成管理ツールで管理していなければ、こんなビッグリファクタリングの作業は怖くてやってられない。

こんなビッグリファクタリングが発生する理由は、自分が書きたい内容を書き出していくと、想定以上の分量になってしまい、出版媒体という箱の中に入れるには、大幅に削るしかない状況に陥るからだろう。
僕の経験上、そんなタイミングを数冊の本で経験したので、たぶん、他の人もそうではないだろうか。
書きたい内容がいくらあっても、それを一連のストーリーに論理的に配置して、読みやすい分量に収納するには、ビッグリファクタリングで大幅に削ったり、構成を見直す事が必要だから。

一方、それを最初から計画するのもあまり意味がないように思う。
やはり、執筆するのはかなりのパワーを浪費するので、最初は多少論理がずれていても、とにかく書き出しておけばいい。
その後で、Gitで履歴管理しているのだから、少しずつ修正すればいいだけ。

【3】さらなる利点は、GitHubとCIツールを連携することで、小説を多種多様なフォーマットに出力して、色んな媒体で公開できることだ。
Web小説のリリース自動化 - Qiitaに、こんな一節がある。

(引用開始)
動機
なぜ小説をいくつものフォーマットで発表する必要があるのだろうか。これにはふたつの理由がある。
第一に、作品を発表する場所が増えれば増えるほど、人の目に触れる可能性が高くなる。
特に、小説投稿サイトには小説を読むことを目的とした人が集まっている。
第二に、特定のプラットフォームに依存しなくて済む。
たとえば、小説投稿サイトには、突然規約が変わったり、サービスが終了したりするリスクがある。
そうしたリスクは分散させておいたほうがよい。
しかし、作品を発表する場所が増えれば増えるほど、運用が大変になる。作品の変換やアップロードに時間を取られれば、肝心の作品を書く時間が減ってしまう。
また、運用に失敗すると、場所によって内容が違い、どれが正しいかわからないという事態にもなりかねない。
逆に、更新作業が面倒だからという理由で誤字脱字等を放置するようになれば、それこそ本末転倒だ。
運用作業を自動化してしまえば、そうしたことに頭を悩ませる必要がなくなる。

方針
自動化の理想は、原稿を書いたり修正したりするだけで、はじめに挙げたすべてのフォーマットで小説が公開・更新される状態である。
この記事では、それに限りなく近いものとして「作品をGitリポジトリとしたとき、origin/master を更新するとすべてのリリース作業が自動的に行われる」という状態を目指す。
これはソフトウェアの世界でいう「継続的デプロイ」の一形態である。
(引用終了)

Web上で自分が書いた小説を公開する時、BlogやカクヨムのようなWebサービスは確かに良いが、閉鎖されるリスクはゼロではない。
閉鎖されると、自分の作品が消えてしまうリスクがある。
だから、リスクゼロのためには、GitHubに小説本体のソースは一括管理しておき、Blogや有償サービス、AmazonのKndleに配布するような手段を確保した方が良い。

すると、その手法は、継続的ビルド、継続的デプロイのような仕組みと一致するだろう。
僕もそういう考え方は以前から持っていたし、既に多くの人も同じようなことは既に考えているわけだ。

電子書籍の作り方: プログラマの思索

電子書籍の作り方part2: プログラマの思索

epub出版システムの作り方: プログラマの思索

Pandocでテキストファイルからドキュメント生成: プログラマの思索

Web小説のリリース自動化 - Qiitaでは、Webサイトへの変換にJekyllを使う事例まで載っている。
JekyllはRuby製の静的ジェネレータなので、使い方は簡単。
また、Jekyllプラグインには、カクヨムと小説家になろうへの投稿のための「jekyll-deploy-shosetsu」、電子書籍の作成のための「jekyll-build-ebook」など色んなGemが使える。

他に、達人出版会のReVIEWも有名だろうか。

ReVIEW記法 基本文法最速マスター - 達人出版会日記

TeXとRubyだけでWindowsにRe:VIEW環境を構築した話 - Qiita

【3】以上の話は、プログラマには無関係だろうと思われるかもしれない。
しかし、プログラマは技術書同人誌を書いてみよう、という記事もあり、ネタさえあれば簡単に出版できるらしい。

技術書同人誌を書きましょう! - Qiita

いろいろ試してみる。

【追記】
@8amjpさんのRedmine小説も流行していましたね。

Redmineを主題にした小説「Redmineで始める異世界人心掌握術」が流行しているらしい: プログラマの思索

「Redmineで始める異世界人心掌握術」を連載中です。 | at 8 AM, JP.

他に、@akiko_pusuさんの本「Redmineでやってみた」もありましたね。

Redmineでやってみた - うさぎまんじゅう - BOOTH

| | コメント (0)

2015/05/31

GitBookのメモ

GitBookのリンクをメモ。

GitBook・Markdownで書いて電子書籍/HTMLを生成 MOONGIFT

Gitbookで学生向け講座の資料を作った話 - モノクロタイム

Yukaary Craft: gitbook試してみる

GitHubのMarkdownで文書を書くのが最近は普通になった。
Markdownでテキストを残しておけば、Pandocなどの変換ツールで、epub・HTML・PDF・Docなど多種多様なファイルに出力できるメリットがある。

出力フォーマットが多彩であれば、Webで公開したり、スライド資料で使ったり、Office文書で配布したり、スマフォで見たり、紙に印刷したり、色んな用途に使える。

GitBookはGitHubのMarkdownに特化したepub変換ツールらしい。
今度試してみる。

| | コメント (0)

2014/11/09

Pandoc ユーザーズガイド 日本語版のリンク

Pandoc ユーザーズガイド 日本語版のリンクをメモ。
これは非常に助かる。

【参考】
ドキュメント変換ツールPandoc:ユーザーズガイドを熟読して分かったマニアックな使い方 - Qiita

Pandoc ユーザーズガイド 日本語版 - Japanese Pandoc User's Association

HTML - 多様なフォーマットに対応!ドキュメント変換ツールPandocを知ろう - Qiita

Pandoc - Installing

僕は、Pandocを愛用している。
よく使う利用シーンは、記事や原稿を書く時、資格勉強の専門知識をまとめる時に、PC上でMarkdownでテキストで書いておく。
そして、PandocでWordファイルやEpubに変換して、iPhoneに送って、隙間時間に読む。

記事や原稿は、何度も推敲して、文章を洗練させることが大事だが、PC上の原稿をEpubに変換しておけば、目次も作ってくれるし、画像ファイルも挿入して後から読める。
通勤の電車、歩いている時、ぼーっとしている時に、iPhoneで気軽に読めるのがいい。

Pandocの利点は、Markdownで書いておけば、色んな出力ファイルに対応していることだ。
GitHubやBitbucketでmdファイルをコミットしておき、CIサービスで定期的にepubへ変換してiPhoneに送るようにしておくのもありかもしれない。

下記の記事を読むと、てMarkdownをTextileに変換して、RedmineのWiki記法に合わせる事例もある。
色々な使い道があるだろう。

pandocでmarkdownからredmineのwiki文法に変換する - Qiita

MacにPandocを入れてMarkdownをTextileに変換 - Qiita

| | コメント (0)

2014/02/08

教育にソフトウェアによるプロセス改善サイクルを導入する~カーンアカデミーによる教育の未来

世界はひとつの教室 「学び×テクノロジー」が起こすイノベーション」を読んだ。
ものすごくインスピレーションを受けた本だった。
今、大学で教育学を受講している学生がいたら、この本を読むことを強く勧める。
感想をラフなメモ書き。

【1】カーンアカデミーは本来、カーンさんの従妹が数学の単位換算が分からない質問に対し、カーンさんがビデオで講義してYouTubeに公開する所から始まった。
その活動が数年たつと、ものすごい影響を及ぼす。
最終的には、グーグルやビルゲイツの支援も受けて、世界中に教育ビデオとソフトウェアを無料で発信している。

本の著者であるカーンさんの文章を読むと、金融アナリストやプログラマという側面だけでなく、哲学者のような雰囲気を受ける。
すごく頭の切れる人なのだろう。

教育は人文科学の中でも、最も根本的な問題をはらむ学問だ。
「人に創造性を育てることはできるか」
「効率的に学習していくには何が必要なのか」

従来の教育制度は、プロイセン式の軍隊スタイル。
40人ほどの教室に子供たちを年齢別に押し詰めて、年齢に応じて学習内容を教師が一方的に教える。
そのスタイルは、国家が未熟な頃は良かったけれど、現代のように、暗記能力よりも創造性やリーダーシップを重視する流れでは、限界が来ている。

そういう問題に対し、ソフトウェアとビッグデータを使って、教え方の仮説を立てて、生徒の学習記録から検証し、経験則を見出していく。
まさに、PDCAのプロセス改善サイクル。

例えば、本の一節に、2つの6年制クラスに、数学を「1+1」の初歩から教えるクラスと、5年レベルの授業から教えるクラスに分けて、習熟度をテストした話がある。
つまり、いわゆるABテスト。

A/Bテストとは何ですか? - Mizeni

その結果は、実は「1+1」の初歩から教えたクラスの方が、最終的には成績もよく、学習能力も伸びたという驚くべき事実。

その理由の一つは、例えば、微積分を理解するには、三角法や指数・対数などの基礎を知っておく必要があるのに、それら一つが欠けていると、理解できない事実と似ているという指摘。
つまり、微積分は難解であるのではなく、前提となる基礎的な知識を理解していない限り、微積分を自由に操る能力は生まれない。
その理由と同じ現象が、小学6年生の算数にも表れたわけだ。

カーンさんはそういう事象をスイスチーズ的学習と呼ぶ。
スイスチーズは表面はきれいだが中身はスカスカらしい。
つまり、テストをクリアするなどの目先の目標にとらわれて、理解が不十分なまま、先に進んでしまって、理解に支障が生じる現象を指す。

このエピソードは、ソフトウェアが教育を変えるという事実だけでなく、ソフトウェアはビッグデータやABテストなどの手法を使うことで、自然にPDCAの改善サイクルを生んでいる事実の方が面白かった。

ソフトウェアの凄い点は、ネットで提供することで場所や時間に依存しないことだけでなく、人の行動を記録することで、その中から意味ある経験則を見出す可能性があること。
つまり、たくさんのデータから帰納的に法則を見出す研究がソフトウェアのおかげでとてもやりやすくなったという事実があるだろう。

さらにソフトウェアが重要な点は、仮説を立てて、その結果を記録し、評価して次に向けて是正対策を立てるというPDCAサイクルを自然に実践していることだろう。
PDCAサイクルはプロセス改善の基本的な構造だ。
このサイクルがあるからこそ、人もチームも成長する。

リーダーや管理職ならば、自分だけでなく、チームにも、PDCAサイクルを適用して、変化をもたらす手法を身に着けないといけない。

しかしながら、プロセス改善を回した経験がないというリーダーもとても多い。
そうなると、「これだけ! KPT」に書いてあるように、プロセス改善を回した経験のない管理職がどんどん増えて、自分たちの組織が成長できなくなる。

でも、ソフトウェアが書けるプログラマは、PDCAサイクルを回すプログラムを自分で書くことができる。
自分の仕事の記録、工数の記録、学習した記録、何でもいいから記録を残して、その記録から意味ある経験則を見出すアルゴリズムを適用するプログラムを書いて、PDCAサイクルを回せば、プロセス改善できるきっかけになる。

【2】「世界はひとつの教室 「学び×テクノロジー」が起こすイノベーション」の本には、教育の根本問題に関する優れた洞察が書かれている。

・カーンアカデミーが提供するレッスン時間は10分にする。
 学生が集中できる時間は10~18分に過ぎない、という過去の教育理論家の研究がある。
 なぜ、学校は今でも45分も長時間の授業をするのか?

・ビデオには、人は出ない。音声と動画だけ。(当初は)
 人は生まれつき顔に注目するので、黒板の方程式よりも教師の言動に注目してしまう。
 教師と顔を合わせる時間と学習時間は別にする。

・カーンアカデミーの教育プログラムは、完全習得学習という教育理論に支えられている。
 つまり、生徒はある学習内容を十分に理解したうえで、次の高度な内容に進む。
 完全習得学習の効果については、過去の教育理論家が既に研究して残している。
 
 なのに、今の学校は、生徒の理解度が分からなくても、先に進んでしまうのはなぜか?
 理由は、従来の教育ではコストがかかることと、官僚主義という名の惰性。
 現代は、ソフトウェアによって、そのコストはほとんど無料に押し下げることが可能。

・完全習得学習の効果として、生徒が当事者意識を持つことがあげられる。
 完全習得学習プログラムを経験した生徒は、自らの学習に対する責任を引き受けるようになった。
 つまり、なぜわからないのか、と自発的に掘り下げて、理解できなかった知識を習得できるように自発的に身に着けようとする。

・知識マップを使う。
 数学、国語、歴史、物理などの教科は単独で教えるのではなく、学習した内容をつなげて、有機的につなげる。
 知識の記憶は、複数の知識に紐づけると残りやすい。
 そのために、学習記録から学習内容の知識マップをプログラムで自動生成する。
 さらに、学習内容に関する問題生成プログラムを自動生成し、生徒の学習結果を評価する。
 生徒は、今まで自分が習ってきた「いままでの場所」、これから学んでいく「これから行く場所」の全体像をイメージさせる利点がある。

・ソフトウェアを使った学習の利点の一つは、マイペースで学習できること。
 時間や場所に依存しない。

 従来の教育制度で最も非効率な部分は、夏休みという学習しない無駄な期間。
 夏休みは、農業が基本的だった社会の名残りであり、現代の情報化社会には向かない。
 1か月も学習しなければ、忘れてしまう。
 むしろ、会社の有給休暇のように、学校も自由に休みを取れるようにすべき。

・ソフトウェアを使った学習の利点の二つ目は、学習した記録が残り、いつでもアクセスできること。
 黒板の内容は消されることもないし、教科書が紛失することもない。
 学習履歴が残っているので、復習できるし、過去の学習内容の関連性を思い出させる利点もある。

・従来の教育は、プロイセンの教育制度から生まれた。
 当時は、税金による公的で普遍的な義務教育制度によって、たくさんの中流階級が生まれた。
 しかし、現代では、規律や従順を重視する従来の教育方法よりも、創造的・論理的な思考が求められており、矛盾が発生している。

・テストで70点を取って合格したという意味は、本当に理解したことになるのか?
 テストは、その人のすべての能力、あるいは潜在能力を評価するのではなく、ある時点のある能力のスナップショットに過ぎない。
 
・テストとは、そもそも何をテストするのか?
 テストとは、ある時点における学習内容の一部について、生徒の記憶と理解のおおよその状況を測定するものにすぎない。

・テストには、政治や経済が混じりこむ。
 本では事例として、ニューヨーク州が標準テストをお金をかけて見直した話が掲載されている。
 変更前の古いテストでは、問題内容が予測しやすく、テスト対策をしたら得点が上がるため、上がり過ぎて標準であるという信頼性を失った。
 そこで、テスト作成会社が作ったら、翌年は得点は急落し、生徒の能力が落ちたという批判を逆に受けた。
 すると、州は彼らを首にして、別のテスト作成会社に、細かなガイドラインを提示した。
 ひねくれた問題はなくす、ややこしい否定形の問題はなくす、読解文の登場人物は前向きで模範的な人に限る、など。
 (日本でも、こんなエピソードはどこの学校でも出てきそう。)

 新しいテストは、古いテストよりも信頼できるものになったのか?

・プロイセン教育制度における能力別クラス編成は、多くの生徒から潜在能力を発揮する機会を奪っている。
 「あなたには能力が足りないので、たぶん社会に貢献できない」メッセージを送っている。

・創造性はどう測り、どう育てればよいのか?
 創造性はそもそも教えられるのか?
 カーンさんの結論は「その人を見たら創造性があるかどうか分かる」。

・宿題の正しい量はどれくらいか?
 誰も分からない。場合による。

・宿題は子供の教育に両親を巻き込むための手段である。
 だから、高学歴の両親を持つ子供ほど、成績が良くなる傾向がある。
 「高学歴な親を持つ方が子供も学歴が良くなる」経験則は、宿題の副作用ではないか。
 つまり、伝統的な宿題は不平等を促す効果があり、公教育の目的にそぐわない。

・カーンアカデミーでは「自宅で講義、教室で宿題」のやり方を試している。
 この手法を「教室をひっくり返す」と呼ぶ。
 (この考え方は、教育理論家によって以前から提唱されていたらしい)

・自宅で聞く講義は、バスでも公園でもどこでも聞ける。
 自分の好きなペースで勉強できる。
 教室で問題を解くようになれば、分からない問題や思い違いがあれば、先生や友達が助けてくれる利点がある。

・従来の教育制度はうまく機能していないかもしれないのに、間違いなくコストも高い。
 子供が小学校から大学を卒業するまで、どれだけのお金がかかるのか?
 学校、教室、教科書などの設備を用意するのに、どれだけお金がかかるのか?
 学校ごとに、教員や警備員を配置するコストがかかる。
 
 新しいテクノロジーを適用すれば、コストは無料まで抑えられるはずだ。

・新しいテクノロジーを従来の教育制度に入れても、学習う方法を変えなければ、お金をどぶに捨てるだけである、と一部の教育理論家は言っている。
 教室を再構築しない限り、iPadは有効な学習ツールにならない、と。

・教育の理論構築と実践、その検証に、ソフトウェアとビッグデータを適用する。
 教育のような人間の根本問題に関わる実証主義的研究は、従来は結果を出すのに30年以上かかっていた。
 しかし、ソフトウェアとビッグデータをうまく使えば、医学である薬剤の効果を実証する研究と同じように、数か月ないし数年で仮説検証できるはずだ。

・カーンアカデミーによるマイペースで取り組めるビデオと練習問題、教室でのプロジェクトを組み合わせた手法は、特定の生徒や先生に共感を呼ぶらしい。
 その有力な証拠が事例的にも統計的にも提出できる点に、大きな意義がある!!!!!
 (もちろん、ソフトウェアとビッグデータを使ったPDCAの改善サイクルが背景にある)

・生徒が数学の学習内容を完全に理解できていない自信のなさの原因は何か?
 一つは、中心となる内容を「概念」としてしっかり理解できていないため、何を尋ねられているのか、問題を解くのにどんな概念を使えばよいか、確信が持てないから。
 もう一つは、自分たちが理解でき当ていない自覚があり、プライドを傷つけられるから。

 その問題に対し、数学の問題を出すごく簡単なソフトウェアを作った。
 負の数の足し算引き算、簡単な指数の計算をランダムに出すだけの基本的なソフト。
 
 このソフトに、各生徒が何問正解して何問間違えたか、どれくらいの時間を要したか、何時に問題を解いたのか、などを記録するようにした。
 この学習記録を講師がフィードバックを受けることで、生徒が何を学習しているかだけでなく、どのように学んでいるか、も分かってきた。

 論理ステップを追ってコツコツと解答したのか、それともパターン認識によって答えが閃いたのか。
 間違ったのはケアレスミスか、それとも関連性を完全に把握できていないからなのか。
 生徒が学習内容を真に理解した時、何が起きるのか。
 それは事例を積み重ねて徐々に起きるのか、突然起きるのか。
 色々な概念をミックスした問題ではなく、一つの概念だけに絞った問題をたくさん解くと何が起きるのか。

・生徒の数が増えても、ソフトウェアを使えば、簡単に学習記録やその次に進む学習内容へのアドバイスなどの情報を管理できる。

・「特定の内容を習得した」ことをどのように定義するのか?
 カーンアカデミーでは、「ある科目の問題を10問連続して正解できれば、基本的な内容を理解できていると判断してよい」。
 この定義は、カーンさんの直感的なやり方。

 この定義に至った理由は、テストには生徒への期待という人間的な要素がある。
 低いハードルは、子供は自分の能力を疑うし、そこそこでいいという後ろ向きな考えになる。
 10問連続して解けるぐらいの基準は、メトリクスとしても簡単で、教師も生徒に期待しているというメッセージを送れる。

・ある州の夏期講習で、カーンアカデミーのプログラムを適用した時に、「1+1」から始めるクラスと5年生レベルから始めるクラスでA/Bテストを実施した。
 結果は、「1+1」から始めるクラスの方が断然、成績が良かった。
 5年生レベルから始めるクラスでは、壁にぶつかって進歩がみられない生徒もいた。

 6年生、7年生レベルの学習内容が分からないのは、もっと前のレベルの内容でつまずいているからだという測定結果が得られた。
 つまり、大部分の生徒は何らかの矯正を必要としており、そのギャップの発見と修復に時間をかければ、長い目で見ると時間とコストが節約され、学習も深まる。

・経験豊富な先生がカーンアカデミーのプログラムに改良点を指摘してくれた。
 「今の機能は素晴らしい。でも本当に欲しいのは、生徒がいつ立ち往生しているかを教えてくれる簡便なシステムです」と。

・学習には必ず「分かった」と「分からない」の間にある「立ち往生」の状態がある。
 カーンアカデミーのシステムでは、立ち往生を「50問解いて10問連続正解が一度もなければ立ち往生している」と定義した。
 この大まかなメトリクスでも、先生には十分に役立った。

・さらに、生徒が立ち往生しているかどうかを先生に伝える仕組みとして、生徒と学習内容のクロス集計表を毎日作成するようにした。
 これを見れば、誰がどの教科で立ち往生したか、一目瞭然。

・立ち往生のフィードバックによって、教室の在り方が根本的に変わった。
 ソフトウェアというテクノロジーを活用したことで、1対1のやり取りが促進され、どの生徒に配慮が必要か、先生もすぐに分かる。
 さらに、特定の学習内容をマスターした生徒と悪戦苦戦している生徒をペアにしたり、同じところでつまずいている生徒同士をペアにすることで、協力して障害を乗り越える経験が得られる。
 このような人間的なやり取りは、学習時にとても必要。

・カーンアカデミーのフィードバックシステムが優れている点は、生徒の習熟度に応じた学習方法を個別に提供できること。
 つまり、飲み込みが遅い生徒でも、マイペースで学習して基礎をしっかり固める機会さえあれば、上級と認められる生徒になりうる仕組みを提供したこと。
 ソフトウェアで学習記録を解析することで、生徒の立ち往生をタイミングよくフィードバックし、生徒の学習を支援する。

・生徒の習熟度を個別に管理できる学習システムがあるならば、年齢別にクラス編成する必要はない。
 むしろ、いろいろな年齢が混じっている環境の方が、年上の子も年下の子も得るものがある。
 年上の子は年下の子供に責任を持ち、リーダーシップを発揮する経験ができる。
 年下の子は年上をを尊敬し真似る。
 年齢別クラス編成は、子供にチーム運営やリーダーシップを発揮する経験を奪っている。

・カーンアカデミーが理想とするのは、年齢の区別のない「一つの教室」。
 年上の生徒やできる生徒が、理解が遅い生徒や年下の生徒に教えることで、自分の理解を深め、リーダーシップの経験を得る。
 年下の生徒は、お兄さんやお姉さんから色々なお手本に接することで、能力を伸ばす。

・年齢混合クラスを推進するならば、先生と生徒の比率はそのままで、もっとクラスを合併して大きくすることもできる。
 例えば、100人のクラスに4人の先生という配置も可能。
 複数教師制度はメリットが多い。
 教師が協力し合えるし、教師の得意分野を生かした配置も可能。
 何よりも、教育では先生と生徒の相性という人間的な要素が大きいため、複数の先生がいれば、自分に合った相性の先生を見つけることもできる。

・教師もチームスポーツのコーチのように、教師は生徒の味方であるというメッセージを送るべき。
 カーンさんは言う。
 教室での授業は実社会での競争に対する準備に他ならない。
 テストは、生徒にレッテルを貼って恥をかかせるのではなく、生徒の能力を計測するためにある。100点が取れなかったのは、頭が悪いのではなく、取り組むべき課題がまだあるからだ、と。

 可能な限り、創造的な、自分の頭で考える人間になって欲しいからこそ、基礎概念から完全に習得してもらわないと意味がない、と。

 2010年に小学校に入った全世界の子供たちの65%は、将来、今は存在しない仕事に就くだろうという予測がある。
 例えば、コンピュータやインターネットが世の中にあふれて、産業構造も大きく変わった。
 だからこそ、子供たちに何かを教えるのではなく、どのように独学の姿勢を身に着けるか、にある。

・現在の学校制度において、夏休みは全面的に見直すべきだ。
 今の夏休みは、時間とお金の壮大な無駄だ。
 世界中で、1か月間以上、校舎や体育館、教室という教育インフラが使われていない。
 先生も事務員も仕事せず、生徒も学習しない。
 生徒の継続的学習を阻害している。
 農業が基本的な産業だったころの名残にすぎない。
 未来の学校は、必要な時にいつでも休めるように、会社と似たような有給休暇の仕組みを作るべきだ。

・学校における生徒の成績表も根本的に変えるべきだ。
 従来の古い教育スタイルを変えるには、カーンアカデミーのような学習フィードバックシステムと、二つの評価方法がある。
 一つは、生徒がこれまで何を学んできたか、という学習記録。
 もう一つは、生徒の創造的な業績のポートフォリオ。

・前者については、現代のソフトウェアによって、生徒の進捗状況や勉強方法、問題解決手法を学習記録から簡単に追跡できる。
 フィードバックシステムは学校ごと、生徒ごとにカスタマイズできるし、生徒がどの程度進歩したか、一定期間の学習ペースなどを定量的に把握できる。

 興味深いのは、定量データによるフィードバックだけでなく、定性データの方だ。
 学習意欲、粘り強さ、復元力などの人格的要素を、学習記録から拾い出せる可能性がある。
 例えば、ジョニーは立ち往生している。彼は、そこで逃げ出すのか、分かるまで勉強を頑張ろうとするのか。
 例えば、モーは、勉強に不熱心で学習時間も少なかったが、突然、生物の勉強に励むようになったのは、なぜなのか?
 生徒の成長ぶりや特定分野の潜在能力を物語る事実が含まれているのではないか。

・現在は生徒評価に全く考慮されない特性「他人を助けようとする能力」もフィードバックシステムで記録できると良い。
 例えば、学習内容を他の生徒に説明するのがうまい生徒は、その内容を深く理解しているし、他人に対しても寛容だろう。
 そのようなデータが記録し続けることができれば、生徒を多面的に評価することもできる。
 
 これが後者の評価につながる。

・カーン氏は生徒の成績表の中心となる「クリエイティブ・ポートフォリオ」を提案する。
 特定の科目ができるかどうかよりも、好奇心や創造性を発揮しているか、に目を向けて、その結果を記録し、評価し、フィードバックして改善していく。

・教育にはいくつかの根本問題がある。
 一つは、最善の学習方法とは何か。 たとえば、完全習得学習スタイル。
 二つ目は、社会化とは何か? たとえば、仲間同士の協力や年齢混合クラス。
 三つ目は、資格認定制度はどうあるべきか?

・現代のテクノロジーを使った思考実験をする。
 大学から、学生を教える役割と資格を認めるという役割を切り離したらどうなるか?
 どこの大学を卒業したのか、ではなく、国際的に認知された厳格なアセスメントテストを受け入れたとしたら、何が起きるか?

 現実では、フルタイムで働きながら短大で好成績を収めるような子供は、間違いなく有名大学卒業生よりも冷遇されている。
 でも、アセスメントテストがあれば、貧富も関係なく、卒業した大学も関係なく、有名大学の卒業証明書と同程度の知識があることを証明できる。
 エリート校も独自性を発揮しようと特化するだろう。
 つまり、資格認定のコストが下がり、大学の権威が増すだろう。

| | コメント (0)

2012/07/29

書籍執筆で継続的デリバリー

@kaorun55さんがJenkins勉強会のLT資料を公開されたのでリンクしておく。
記事や原稿、提案資料を書く人は、テキストから自動ビルドしてPDF、Wordなどの印刷媒体へ自動ビルドする手法が必要になった時代だと思う。

【元ネタ】

オライリー・ジャパンのePUBフォーマットを支える制作システム - O'Reilly Japan Community Blog

Geekなぺーじ:svn+TeXでcommitするとPDF - オーム社開発部の出版システムでの書籍執筆

sphinxで Wordファイル(docx)出力する.(Windows): 100ねんごの未来予想図

sphinx で word / epub / pdf で出力した結果(windows): 100ねんごの未来予想図

Overview ? Sphinx v1.0 (hg) documentation

Sphinxでドキュメントを生成する - Basic

epub出版システムの作り方: プログラマの思索

電子書籍の作り方part7: プログラマの思索

@kaorun55さんの環境は、Sphinx上でテキストベースの原稿を書き、CloudBees というクラウドホスティングサービスにあるJenkinsを使って、PDFやepubなどを自動ビルドで出力しているようだ。

この手法の利点はいくつかある。
一つは、原稿がテキストベースなので、SubversionやGitなどのバージョン管理と相性がよく、Sphinxのようなドキュメント生成ツールと組み合わせれば、PDFやepubなど各種媒体に出力できること。

この考え方は、昔のLaTexも同じような発想だと思う。
例えば、物理や数学の論文を書く人は、Texで英文の論文を書いて、雑誌に投稿する時にTexをビルドしてeps、dviなどに出力して渡していた。
今なら、SphinxやREViewのようなツールでテキストからPDFやepub、HTMLなど各種フォーマットへいくらでも出力できる。
しかも、blockdiagramなどのツールを使えば、ネットワーク図やシーケンス図などもテキストベースから変換できるので、バージョン管理と相性が良い。
@kaorun55さんの話では、PDFは印刷媒体として相性が良いが、iPadやiPhoneなどのスマートフォンで読む時はepubが相性が良いらしい。
確かに、スマートフォンでいつでも原稿を読めるようにしておけば、即座にフィードバックしてもらえるだろう。

でも、一つ疑問があるのは、Sphinxなどに索引や目次、引用文献などを生成する機能があるのか、という点。
Texには索引や目次、引用文献を自動生成する機能がある。
紙媒体やWordで原稿を書く時に面倒な作業は、索引や文献を抽出することだ。

だから、20年以上前のIT化されていない出版スタイルでは、索引や文献を手作業で抽出後、京大式カードなどで記録してファイリングしていた。
梅棹 忠夫さんの「知的生産の技術」の本では、そんな時代では索引作りが学者として重要な作業であったことを示している。

索引や文献も、原稿に何らかのポインタないしタグを付けておけば、プログラムで自動生成できる代物だ。
多分、そういうツールはあるだろうと推測している。

もう一つは、Jenkinsというビルド管理ツールを出版システムの中核機能に配置すること。
つまり、原稿というテキストをコミットした後、Jenkinsが検知して、Diffメールを送信したり、即座に自動ビルドしてPDFやHTML、epubで成果物を配布したり、索引や文献や目次を自動生成したり、出版フローのメトリクスを出力したりする。

この仕組みは、我々プログラマの仕事と全く同じ構造だ。
実際、テキストベースで書かれたプログラムをコミット後、ビルドされてサーバーにデプロイ後、システムとして稼働されて、ユーザが直接触ることができるようになる。
同様に、小説家が原稿をテキストで書いてコミットしたら、ビルドされてPDFないしHTMLなどの印刷媒体で出力されて、読者が直接読めるようになるフローと全く同じ。
その意味では、プログラマも小説家も同じ職業であり、クリエイターでもある。

個人的には、AntなどのビルドスクリプトでテキストをPDFやepubへ変換するツールをキックするようにすればいいと思う。
Jenkinsは強力なツールであるがゆえに、単なるビルドツールだけでなく、コードレビューや原稿のレビューをビルド前に組み込んで品質チェックしたり、コミットの差分をメールで流したり、ビルド失敗をメールで流すなどのやり方もある。
他にも、原稿を書く人ないし小説家のコミット履歴から、執筆に関するメトリクスを出力して、その結果から経験則を抽出できたとしたら面白いかもしれない。

| | コメント (0)

2012/04/12

電子教科書や電子雑誌を作る方法

AppleのiBooks AuthorやGoogleカレントなどの電子書籍アプリに興味を引いたのでメモ。

【元ネタ】
Flipboardの強力なライバルに?:Google、電子雑誌アプリ「Googleカレント」を日本でも公開 - 電子書籍情報が満載! eBook USER

Twitter / @akipii: メルマガは電子書籍になるべきなのか RT @WandLT: メルマガ取り始めたんだけど、EPUB見やすいねー。普通の携帯に届くの見づらすぎて、読むきになれないもん。

電子書籍作成ツールまで無料:今度は“教科書を再発明”――Apple、「iBooks 2」「iBooks Author」「iTunes U」アプリ発表 - ITmedia +D PC USER

アップルの電子本作成ツール『iBooks Author』のココが○! ココが△!

iBooks Authorで電子書籍の未来は変わる?!日本市場でiBooksを公開する方法 | Chrome Life

紙の本を電子書籍にするよりも、メルマガや週刊誌、漫画を電子書籍にしたほうがいいと思う。
メルマガはメールを頻繁に使う人には良いが、むしろepubにすべきではないのか?
細切れの文書よりも、まとまった電子媒体の方が、過去の記事も読めるし、気になった文章を後から全文検索できる。
そもそもメルマガは文章だけだし、文章の量も少ないから、epubにしてPodcastingのように配布した方が使いやすいはず。

そんなことを考えると、現代は普通の人でも自分が編集者の雑誌を作れる時代なのだと思う。
自分に興味のある記事を書いて、毎週毎月、定期的に雑誌をネットで配布する。
iPhone・iPod touch・iPadのようなクライアントがこれだけ普及しているのだから、コンテンツの質が良ければ読んでくれる。
世に出回るフリーペーパーは1千~5万部までマチマチだが、電子書籍なら配布コストはゼロ。
読者層が多いほど、その雑誌はたくさんの人に影響させる力がある。

同様に、自分が編集者の電子教科書も作ることもできる。
epubならJavaScriptも入れることができるから、インタラクティブなユーザインターフェイスを作り込むことも可能。
特に、物理や生物のような自然科学系が向いているかもしれない。

すると、出版社や雑誌を作る会社から製本して配布するという物理的インフラは消えて、良い本や雑誌を作るという本来の役割に特化していくだろう。
それは、出版コンサルティングみたいな役割。
つまり、本の企画、コンテンツの収集、原稿の書き方など、良い本を書くための役割に特化していく。
逆に言えば、1千~1万字の記事を書く能力が優れている人は、電子書籍として配布するインフラがあるのだから、すぐに作家になれるわけだ。

HPやBlog、Wikiも良いけれども、まとまった電子媒体を配布することは、政治的にも大きな影響力があると思う。
色々考えてみる。

| | コメント (0)

2012/04/05

Pandocのリンク

Haskellで書かれたPandocを使うと、テキストファイルからPDF・HTML・epubなどを出力できるらしいのでリンクしておく。

Markdown/HTML/LaTexを相互変換「Pandoc」 - MOONGIFT|オープンソース・ソフトウェア紹介を軸としたITエンジニア、Webデザイナー向けブログ

hon.jp DayWatch - EPUB電子書籍にも対応、関数プログラミング言語Haskellで書かれた万能ドキュメント変換コマンド「Pandoc」

Utotch Blog: Pandoc で Blogger の記事を書く

RadioAgeCom:ReVIEWとpandoc

pandoc - general markup converter - Google Project Hosting

かゆいところに手が届く? Pandoc | hexacosa.net

I can 'cause I think I can! - Pandocでxelatexを使って日本語を含むMarkdownをPDFにする

Pandoc - Pandoc User’s Guide

Pandoc - Creating an ebook with pandoc

CIツールと連携させれば、電子書籍を常時ビルドして出力できるようになるはず。

| | コメント (0)

2012/03/13

epub出版システムの作り方

電子書籍の記事はたくさん見かけるが、まだどこもビジネスモデルとして確立していない。
オライリージャパンやオーム社は、独自のepub出版システムを作って、今までにない新しい出版スタイルを築こうとしている。
技術的側面とビジネス的側面についてメモ書き。

【元ネタ】
オライリー・ジャパンのePUBフォーマットを支える制作システム - O'Reilly Japan Community Blog

技術書をアジャイルに作る: プログラマの思索

Geekなぺーじ:オーム社開発部での開発体制

Geekなぺーじ:オーム社開発部の方とのやり取り

電子書籍はSaaSの一つに過ぎない: プログラマの思索

【1】電子書籍の本命はepubフォーマット。
epubは所詮、HTMLとCSSをZIP化したファイルに過ぎないが、iBooksやStanzaのような電子書籍リーダーの上で滑らかに紙の本のように読むことができる。
epubは電子媒体ゆえに、コピーも簡単だし、ネット上で配布も簡単。

技術的には、テキストというオリジナルの原稿があれば、epub用のHTMLに変換してZIP化すればいいから、バッチ処理として実装すればいい。
オライリージャパンやオーム社のepub出版システムは、GitやSVNにあるテキスト原稿からバッチ処理でepubフォーマットの電子書籍を常時ビルドする仕組みと同じだ。

技術的に面白い点は、バッチ処理で常時ビルドする仕組みとして、CIツールのJenkinsが現れること。
Jenkinsは単なるビルド管理ツールではなく、高機能なCronだけでもなく、高機能なバッチ制御ツールとして認識すべきだ。

個人的には、高橋征義さんが主催する達人出版会が持つ「ReVIEW」というEPUB/PDF生成ツールに興味がある。
テキストをepubやPDFへ変換する処理をRubyで実装している点が興味深い。

EPUB生成ツール「ReVIEW」について達人出版会の高橋氏に聞いてみた - builder

1つのソースでEPUBとPDFを生成できる「ReVIEW」を試す - builder

kmuto/review ・ GitHub


【2】ビジネスモデルとしては、本来はAppleのiTunesとiPhoneのようなソフトとデバイスを組み合わせた上で、epub形式の電子本を提供することをどの会社も狙っている。
だが、再販制度などの法律や日本独特の出版の商慣行のために、変化が見られる気配はない。

Appleが音楽をソフトウェアに変換したことで、音楽を聞く行為そのものは本質的に変わってしまった。
電子書籍も紙の本をソフトウェアに変換することで、書籍を読む行為そのものが本質的に変わる可能性がある。
個人的には、週刊誌や漫画、雑誌などのように生鮮食料品並に購読期間が極端に短い書籍は、エコの観点からも積極的に電子書籍にしてしまうべきだと思う。
1週間後、1ヶ月後には、週刊誌や漫画、雑誌はゴミ箱に捨てられてしまうのだから。

新聞も電子書籍に変えてしまうべきだ。新聞は粗悪な紙で印刷されていて、肌触りも悪いしあまり読みやすい代物とは言えない。1日の賞味期限しか無く、翌日にはゴミ箱に直行するから。

電子書籍はSaaSの一つに過ぎない: プログラマの思索にも書いたけれど、電子書籍はAppleの音楽配信と言うSaaSと同じく、SaaSの一つと捉えた方がいい。
だからこそ、ソフトウェアの技術力が高い会社が電子書籍のビジネスモデルを制覇する資格を持つ。
お金や権威のある会社がそのビジネスモデルを創りだそうとするのは自己破綻に近いのでありえないから。

| | コメント (0)

2011/03/27

kdmsnrさんの翻訳のノウハウ

@t_wadaさんのFacebookからkdmsnrさんの翻訳のノウハウのリンクを見つけたのでメモ。
手馴れた感じで上手いな~と思った。

【元ネタ】
私の翻訳のやり方 - capsctrldays(2011-03-26)

kmuto/ReVIEW - GitHub

【特徴】
(要約開始)
* 英文テキストからwcでワード数をカウントして、工数をざっくり見積もる
* xyzzyとPDICで翻訳していく
* 日本語の扱い方は『日本語の作文技術』を参考にする
** 修飾は長い順にする
** 「あなたは」を省略する:日本語は主語を省くことが多い
** 「あなたの」を省略する:自明なので
** 無生物語を主語にしない:人を主語にする
** 受動態を避ける:能動態にする
** 否定形を避ける:反対にする
** 二重否定を避ける:肯定形にする
** 「~が、」を避ける
** 文のつながりが唐突なことが多いので、なめらかになるような接続詞を補完する(しかし* その結果* つまり)
** 「~だ。~だ。」と語尾を連続させない。「~だ。~である。~だ。」のように交互にする。
* ReVIEWというツールで章単位に翻訳した作業ファイルを作る
 更にReVIEWでHTML、PDF、InDesign用XMLを出力する
* ReVIEWでPDF化した原稿をiPadに入れて、ファミレスで校正する
(要約終了)

出版作業はいまだに手作業が中心でデジタル化されておらず、Adobe製品でDTP化しているので、電子書籍にしづらい。
ReVIEWで出版作業をデジタル化できれば、原稿という元ネタをPDF・HTML・InDesignなど各種のフォーマットに変換できるから便利なわけだ。
但し、ReVIEWは青木さんが作られたツールと思うが、興味を持っているもののマニュアルを読んでも使い方が分かっていない。

色々調べてみたい。

技術書をアジャイルに作る: プログラマの思索

Blogを電子書籍作成プラットフォームにする: プログラマの思索

| | コメント (0) | トラックバック (0)

2011/02/07

iBooksの感想

iOS4に更新したら、iBooksが使えるようになったので使い方をメモ。

【元ネタ】
apptoi: PDFファイルをiBooksに同期する方法

ウェブや青空文庫をiBooksで読む!! - ZONOSTYLE

Calibreを使うと、テキストだけでなくPDFやRSSからepubを作って、iBooksへ簡単に同期してくれる。
又、DropboxにあるPDFもワンクリックでiBooksへ同期してくれる。

DropboxならPDFをカンタンにiBooksコレクションに追加できる : ライフハッカー[日本版]

但し、iPod touchのiBooksはiPadのiBooksに比べるとそれほどの驚きが無かった。
文庫本サイズの画面レイアウトなので、文字が小さいと読みづらい。

個人的には、下記の記事のように、epubをあらかじめSigilなどでローカル上で作っておき、CalibreからiPod touchのStanzaへ同期させるやり方が一番フィットしている。
文字だけの電子書籍(epub)なので、Stanza上で読みやすいからだ。

Stanzaへの本の同期 Slash×Slash

Webの情報から電子書籍(epub)をRubyでもっと簡単に自動生成できないか、色々試行錯誤中。
Rubyがもっとうまく書けるようになりたい。

電子書籍の作り方part5: プログラマの思索

電子書籍の作り方part4: プログラマの思索

電子書籍の作り方part7: プログラマの思索

| | コメント (0) | トラックバック (0)