チームの最近のブログ記事

『欠陥ソフトウェアの経済学』を読んだ。ソフトウェアのベンダや開発者には間違ったインセンティブが与えられており、ユーザの求める方向とは異なる方向に進化している、という話。

第1章 文明の礎
第2章 60億の衝突テスト用ダミー:理不尽なイノベーションと間違ったインセンティブ
第3章 弱さの力:割れた窓と国家の安全
第4章 近視眼的見落とし:スピードに目をくらまされ激動に惑乱される
第5章 完全なる免責:訴えられるものなら訴えてみろ
第6章 オープンソース・ソフトウェア:無料の代償
第7章 進歩は可能か:別の未来へ向かう合理的インセンティブ
エピローグ
注釈 

目次は欠陥ソフトウェアの経済学 その高すぎる代償|Ohmshaより

ソフトウェアのバグを減らして安全にしたり、インターフェイスを整えて使いやすくすることは大事なことである。にもかかわらず、ユーザたちはそれにお金を払おうとしない(というより、それだけの価値をそこに見出せない)。その代わり、ユーザたちはソフトウェアに追加された新機能に対しては(比較的)あっさりと財布のヒモをゆるめる。そのため、ベンダはソフトウェアを安全で使いやすいものにするよりは、先鋭的にするほうに力を注ぐ。結果として、宣伝しやすいがあまり使わない機能ばかりが強化されていく。

というわけでソフトウェアが脆弱なものになるのは、市場経済の働きとユーザのファストフード好きのツープラトン攻撃によるものである。計算機は思ったとおりではなく指示したとおりに動く。それと同じく、ソフトウェアベンダは正しいものではなくユーザがほしがるものを作るのである。基本的には我々がほしがったものしかそこにはない。

というのはソフトウェアの消費者としての自虐であるが、生産者としての自虐もここに含まねばならんだろうと思う。ソフトウェア開発者は基本的に新しい物事が好きである。何かを提案しようとしたとき、既存のものを地味に使いやすくするより、それとは全然関係ない新しい機能をつくるほうが不思議とわくわくする。それにだいたい評価も得やすい。

評価が得やすい理由は前述したソフトウェアの消費者としての自虐がまさにそれであるし、新しい機能をつくるほうが楽しみなのは開発者なら自明である。先週書いたコードを理解するのに1時間はかかるし、1ヶ月も前に書いたコードならそれを見るのにもある程度の覚悟が必要である。気が重いことから逃げようとすると、必然的に新しいコードを書きはじめている。そしてソフトウェアの規模はまた不必要に大きくなり、再構築の可能性を小さなものにしていく。

そういう悪循環に対して開発者個人としてできることはあまりなくて、リファクタリングの機会を多く持ったり、リファクタリングしようとしたら構造ほとんど忘れてましたみたいなことを避けるために定期的にレビューすることが必要だろう。これはどちらかといえばチームとしての取り組みである。

たしかに放っておけばソフトウェアは肥大化・複雑化の一途を辿るだけなので、それを防ぐことが必要ですよ、ということを管理者とかにわかってもらうために読ませる本として、メタファが多用されて親しみやすい本書はなかなか適切だと思う。

余談。上記のとおりある程度技術的なことを把握してると、ひたすらに比喩を読まされることになって若干退屈を感じるきらいもあるのだけど、それを帳消しにできるくらい「エピローグ」が秀逸である。冷戦中、ソフトウェアのバグが引き起こした一触即発の事故の話であるが、どの程度真実かは別にして、男の子なら胸をときめかせること必至の4,5ページであると思う。



株式会社OPTiMさんが、全国の高専を巡って講演を行なっているらしい。id:hush_inの学校にやってきたという話を聞いてしばらくした頃、*1ウチにもやってくることを知った。1月の末、レポートを提出した先生が参加窓口を担当されていたので、彼から聞いたのだった。


というわけで2月7日、株式会社OPTiMさんによる鳥羽商船高専での講演を聞きにいってきました。テーマは『仕事×プログラミング』で、業務での開発がどのようなものかということを、プログラミングについての解説を交えながら、現役高専生にエールを送るというものだった。


事前に発表されていたスケジュールには、プロジェクトマネジメントについての内容が含まれることが紹介されていた。ここ最近、とても興味を持っていることなので楽しみにしていた。


当日の大まかな流れは次のとおり。



  1. OPTiM会社紹介, 講演者紹介

  2. 大規模プロジェクトでの開発について

  3. プログラミング演習(WinAPI/GDI, Lua)

  4. デバッグの理論と実践

  5. バージョン管理システム


プロジェクトマネジメントについての演目がないように見えるが、実際にはすべての演目の根本にそれが据えられていたので、とても得るものは大きかった。


演習後の2演目が特に印象に残ったので、その辺りをまとめたいと思います。


ええと、各演目の内容を網羅的に書いちゃうと、まだ聞いてない高専の人的にはネタバレっぽくなっちゃうかもなので、個人的にメモしてたっぽい内容について書くつもり。


アウトライン



  • 「ゆとりのあるスケジュールは非現実的」

  • バグは熱い内に打つべきか?

  • 他のレイヤを疑うべきではない

  • サンプルコードをあたる

  • 喋ってりゃ直るよ

  • ノウハウは自分たちで育てていくもの

  • Tracでガントチャート

  • 利用メンバーの固定化

  • 新人はテスタ・デバッグで育てる


「"ゆとりのあるスケジュール"というのは非現実的」


炎上するプロジェクトの多くは、スケジュール的にかなりきわどい状態になっていることが多い。そのため、余裕のあるスケジューリングを行なうことが必要だと言われることが多い。


しかし、スケジュールに余裕を持たせることは現実的ではない。"ゆとりのあるスケジュール"は"無駄を含んだスケジュール"であることも意味する。そもそも開発の期限が決まっていないことは有り得ず、他社との競合や顧客の要望を考慮すれば、初期の段階から不要な余裕は削っておく必要がある。


といっても頭からかつかつのスケジュールは少しの遅延で破綻する。プロジェクトの規模と相談しながら、セーフティネットとなるクッション期間を設けておくべき。僕の現在のプロジェクトはちょっと前にこれに救われたところです(´・ω・`)


クッションとなる期間は設けておく傍らで、バグの発生を抑える、つまり成果物の品質の向上を見込んでスケジュールにゆとりを持たせるのはナンセンス、という話。


バグは熱い内に打つべきか?


プログラマとテスタが別の人間である前提で。


バグを見つけたテスタがすべきことは、下記5項目の記録:



  1. バグの事象

  2. バグの再現手順・環境の確立

  3. 再現確率の記録


これを如何に導くかがテスタとしての腕前。


「バグを熱い内に打つ」というのは比喩で、プロジェクトの規模が大きくなればバグ修正に絡む範囲を広くなるから、なるべく早めにバグを修正すべきだという考え方。


これ自体はとても正しいけど、だからといって「簡単そうなバグだしさっさと修正してもらおう」とすぐにプログラマを呼ぶのは良くない。



  • プログラマの集中力を途切れさせてしまう

  • そもそも表面的に簡単そうに見えるだけで、実は根深いバグであるおそれがある


上記のような理由に加え、ああでもないこうでもないとしている内にバグの実体がぼやけてしまい、再現方法がわからないまま結局解決されずに終わってしまうのが危険。


テスタでも(ソースコードレベルで)原因がわかる程度の簡単な問題でなければ、まずは再現手法の確立こそが必要。


他のレイヤを疑うべきではない


ソフトウェアを開発していると、「別のモジュールの問題ではないか?」と思うことがたびたびある。


別のモジュールというのは、OSのシステムコールやプロセッサなどの別のレイヤであったり、同じプロジェクトの別のメンバーが担当しているプログラムだったりする。


自分のプログラムが正しくても、依存している別のモジュールが問題を抱えていて、それが原因で最終的なアプリケーションである自分のプログラムが意図どおりに動作しない、という経験は開発者なら誰でもあると思う。誰でもあるからこそ「今回もそうじゃないか」と思ってしまう。でもほとんどの場合、こう直感したときは自分のほうに問題がある。


僕の場合は以前、マイコンの動作する回路の設計に問題があり、意図どおりの挙動を示さなかったことがあった。このときは回路の問題だとは思わなかったのでかなりの時間調査をして、最終的に回路設計者と話して問題が解決したことがある。


厄介なことに、似たような問題がもう一度発生した。そのときにすぐに回路設計を疑ってしまったが、今回は僕のプログラムに問題があって、逆にそれに気づくまでに時間を要してしまった。


それからなるべく他のレイヤを疑うのは避けている。


ただし疑ってかかるのは危険だとしても、関連するレイヤの担当者に相談するのは悪くない。悪くないどころか、奨励すべきことだと考えている。問題がこちら側にあったとしても、解決の糸口を得られる見込みは大きい。


あと、OPTiMさん内部の事例からの教訓として「OSがバグを持っていたとしてもすぐにfixされることはない」ということがあった。他のレイヤに問題があったら、その上のレイヤでカバーせざるを得ない。ハードの問題はソフトでカバーだ。


サンプルコードをあたる


不必要に長時間詰まらないためには、初心に戻ってサンプルコードや、他人のやり方を参考にするのが正しい。そのための知識ベースとして、以下のサービスが便利。



喋ってりゃ直るよ


問題が発生したとき、ひとりで考え込んで頑張るのも大切だけど、他の人に相談することで解決の糸口が見つかることが多い。


ひとりでPCに向かって根を詰めると、どうしてもソースコード上でできることを手当たり次第にやってしまいがち。場合よっては一度試したことを何度も試みたりしていることもあって、実はかなり効率が悪いのだと思う。


そうなる理由は、コードを書きながらだと問題の整理ができないから。そのせいで漠然とした理解のまま手数だけを増やすことになって、ほとんど解決に近づけない、という状態に陥ることが少なくない。


自分が今直面している問題を誰かに話す。それは少なくとも、論理的に説明できる程度には、現状を把握できていないとできないことだ。「自分は論理性に欠けるとよく言われるから」といたって、実際のところ最悪でも時系列の整理くらいにはなる。


相談の相手は自分よりレベルの高い人でもいいけど、そのとき周りにいなければ全然技術的な理解のない人でもいい。


相手のレベルが高ければそもそも同じ問題の経験があるかもしれないし、そうでなくても解決へのアタリを付けられることも多いだろう。たくさんの助言が得られるだろうから、確実に問題解決への距離を詰められる。


まったく技術に明るくない人が相手ならそれはそれでいい。その人でもどういう問題が起きているか理解できるレベルまで噛み砕いて説明する必要があるから、自分の中でもどういう問題が起きているのかハッキリさせられる。そもそも目的は「相談しにいく」ことであって、「解答を見にいく」ことではないのだ。


その場に自分しかいなかったら、相談の相手は自分でもいい。一度PCの前を離れて、ひとりで静かに自問自答するだけでも、問題は整理されることが多い。禅である(ぇ...


ノウハウは自分たちで育てていくもの


OPTiMでは、デバッグの際にテスト項目をチェックリスト化して確認漏れがないようにしているという。こういった形式化は、組織の成熟に従ってできあがってくることだ。


講演後、組織が若い内はどうしてたのか訊いてみると、こんな回答が。


「そもそもチェックリストは突然表れたわけではなくて、あるときはもう少し短かったり長かったり、内容も変化を続けて現在の状態になった。ノウハウはどこかから借りてくるべきではない。それぞれの組織が自分たちのやり方にあわせて、少しずつ丁度いいスタイルを育てていくことが大切」


というわけで、いきなりXPだの考えてもダメなわけで、その辺りが2年前の僕の大失敗の原因だと考えている。


当然ながら今も完全ではない。OPTiMさんのスタイルもおそらくそうだろう。これからも成長を続けていく余地があるから、それは楽しいのだ。諸行無常である(ぇ...


Tracでガントチャート


Tracでガントチャートを表示できるようにしているとのことだったので、使っているプラグインを聞いてみたところ、TracGanttCalendarを使ってるとのこと。


テクノロジックアート技術者のブログ: [Trac] TracGanttCalendarプラグイン for Trac-0.10(trac-ja)


これは便利そうなので、使ってみたいと思う。


利用メンバーの固定化


Wikiやグループウェア、Tracなどのシステムは、不思議なことに使っている内に利用しているメンバーが固定化してくることが多い。僕は今のところ関わったほとんどのプロジェクトでその状態に直面していて、唯一の例外はメンバーが3人だったときで、それは最初から固定化されても残るタイプの人間ばかりだっただと考えている。


この問題に対してのOPTiMさんの対処を聞いてみると、意外と同じような状態らしい。


そもそもTracの導入を提言したのが講演者のふたりで、



  • タスク管理をTracで行なうことを徹底

  • チケット発行時のテンプレートの作成


など固定化を避けようと努力しているのだが、それでもある程度の固定化は起きているとのこと。


第一線の開発者を集めた企業でもこうなのだから、学生が集まるとなると尚更難しいのかもしれない。これについては継続して考える必要がある。


新人はテスタ・デバッグで育てる


OPTiMさんでは、新人はたいていの場合テスタを担当することが多いらしい。これ自体はさらっと流れた発言だったんだけど、個人的には最初から最後までときどき思い出して色々考えることがあった。


2年前にSCTを立ち上げたとき、チュートリアルとはいえいきなり開発をはじめさせて、かなりの数の挫折者が出るのを見た。何を作るのかも詳細に把握できない状態で、1から製作をはじめるのは難しい。


最初は動作のテストやデバッグを担当してもらって、現在プログラムがどういう状態にあるかを少しずつ把握してもらうほうが良いのかもしれない。デバッグくらいなら1から書くよりも楽だろうし、バージョン管理をちゃんとしてればそのコードが壊れても何ら問題ない。開発者として参加するのはそれからでも遅くないのではないだろうか?


言い訳しておくと、2年前のそれの場合、その時点でそれなりにコード書けるのが2/10だったので、仕方なかったといえば仕方ないのですが……まあこの辺は言い訳にしかなりませんね(´・ω・`)


まとめ


念のため: OPTiMさんの講演のまとめではなく僕の考えたことのまとめです、、、



  • 大きな壁があったら誰かに相談してみる

  • プロジェクト管理の手法はまだまだ考える必要がある

  • ルーキーをテスタ兼デバッガで育てるのは試してみる価値あり


というわけで個人的にはかなり実りある講演でした!講演者のおふたり(学校がらみなので名前出して良いのか良くないか迷ったのでとりあえず伏せておきます)はありがとうございました!




*1:2009/2/8削除: 僕の勘違いだったようです




ここのところ付きっきりだったプロジェクトでの開発が一段落ついたので、ひさびさにブログ。


プロジェクトは5人のチームで進めていて、美術担当1人とデバイス担当2人、ソフト担当2人(僕とid:Waroe)という分担。といってもそれほどきっぱり分かれているわけではなく、できそうなところをできそうな人がやる、といった感じ。プロトタイプの開発だけではなく、資料作成や量産用の回路の簡素化などもやらないといけないので、みんなにぎゅうぎゅうに分担するのは危険だなと思ってユルく(よく言えば柔軟に、悪く言えば適当に)動くことにしている。


そういうわけでソフト担当だった僕もここしばらくはファームを書いている。2年ぶりにPICに触ることができたし、今回は回路から自分たちで作ったので、困難は絶えなかったがそれと同時にわくわくした。おそらく三大欲とは別であろうこういった快感は、僕やみんなのような人種にとっては代え難いものなのだろう。


困難といえば、同じ問題で最も長く行き詰った期間は4日間で、PIC18F2550のUSBターゲット機能が有効に働かないというものだった(詳しくは近いうちにまとめるが、VUSB-GND間のコンデンサを省いていたのが問題だった)。


4日間。長いだろうか?短いだろうか?


個人的には、ある程度の規模のシステムを開発していたら、何らかの問題で数日悩みっぱなしになるのは毎度のことなので、さほど長いとは思わなかった。むしろ「4日で済んでよかった」とすら思ったくらいだ。半月近く行き詰ったままだったこともあった。それから考えれば全然順調に進んでいるなー、と考えていて、実際これまで経験したどのプロジェクトよりも円滑にゴールに向かっている。局面ごとの判断ミスはまだまだあるものの、大局的にみればメンバーそれぞれの持つ背景を折り合いをうまく付けられていると思う。


4日間悩み抜いた課題を解決したあと、気分転換の散歩に出た。開発のため使わせてもらっている部屋のゴミ箱が一杯だったのに気づいた美術担当のメンバーがゴミ出しに行くというので、それに同行しながらの散歩にする。


世間話の種もなくなってきたので、今後の動きについて話す。「ここまでで試作に必要な技術は出揃ったから、近いうちにプロトタイプが完成する。それからコストダウンや量産の計画と並行して営業活動をはじめるので、作ってもらった資料が主役になるよ」というような内容。


そのときの彼の反応に、自分でも意外なくらい驚いた。


「おおー、もうダメかと思ったw」


ジョーク的な側面も含んでたのだろうけど、4日間も悩んでいるっていうのは、周りからは本人以上に困難にぶつかっているように見えるらしい。


実際には暗中模索ながら一歩一歩進んでいるので、本人としては手がかりが見えていてそこまで苦しんではいない。むしろその事実があるからこそ、やたらに周囲に「悩んでますよ」的なオーラを振りまいてしまうのかもしれない。特に僕はその傾向が強いように思う。そのせいで無闇に周りを不安にしてしまう。直したいクセだ。


同じ4日間といっても、問題に直面している本人とそれ以外、同様の経験があるかどうかで感じ方は全然異なってくる。当たり前のことだけど、こうやって実際に起きてみるとやはり戸惑う。


今年はプロジェクトマネジメントの見識・経験を得たいと考えている。マネージャにとって、メンバーの不安というのは最も恐ろしい敵だ。解消するのはまだ難しいので、今はせめて自分がその不安の種を作らないようにしたいものだなー。




はてなブックマークの制作に携わった人たち (2008/11/25)


はてブがリニューアルされたのも、もはや旧聞に属するところになりそうだけど、ふとしたきっかけで制作スタッフの一覧を見つけて、なんとなく眺めていた。有名な人もいて、そうでない人もいて、その多くの活躍がはてブの完成に欠かせないものだったのだと思う。


普段は漢字やハンドルで見るその名前は、晴れ着でもまとうみたいにアルファベットの姿をかりて堂々と収まっている。映画のスタッフロールよろしく、名前の上にはプロジェクトでの役職も紹介されている。Director, Managerにはじまり、Back Office, Beta Testerまで、およそ進行にかかわったであろう人物はみんな名をつらねているのだろう。


その中で、Direcor, Manager, Lead Programmerといった、いわゆる肩書きの後に並ぶ、一風変わった役職名がある。



  • Atom API

  • Bayesian Classifier

  • Content Extraction

  • Crawler

  • Favicon Proxy

  • Fulltext Search Interface

  • Guide pages

  • HTML/CSS

  • Image servers

  • Mock Design

  • PFIers

  • Similarity Engine

  • Servers and Network

  • Text writing


カンのいい人にはすぐにわかるように、これは役職というよりも、担当箇所といったところだ。それぞれがそれぞれの技術的な難度を含み、それが故に楽しみがある。そのためもあるのかどうかは定かではないけど、おおむねのモジュールは1人の開発者に割り当てられている。


実はこれができるのは、綿密な設計がある状況に限られる。


それぞれのモジュール間は完全に独立しているわけではなく、お互いに連携して動作することもあれば、あるモジュールが別のものに依存していたりする。


使い方のわからない機械を渡されて「これで車の燃料を補給してください」と言われても、使い方がわからないのだから補給できるわけがない。それと同じで、使い方のわからないモジュールを利用したプログラムを書けというほうが無理というものだろう。しかも場合によっては、実際には機械は完成していないということもある。


そんな状況で、どうやって未完成のモジュールに依存したプログラムを書いたものか。


言うは易しだが、使い方だけ先に決めてやればいい。そこで決めた使い方で確実に動くようにモジュールを作れば、あらかじめ教えられた使い方に則って先んじてプログラムを書くことができる。


ソフトウェアの設計とは、おおざっぱにいえばこの「使い方」を先に決めてしまうことだ。


そうすることによって、多人数でモジュールを分担して開発することができる。そうすると全員がひとつのものに食らいついての開発に比べて、混乱が起きにくいそうだ。


もちろん本当にそのとおり行くかというと、そうでない場合もある。設計がいいかげんだと、そういうことになるんだ。


例えば、完全に独立していると思っていたら一部で同じファイルを利用していたとか、ひどいときは使い方そのものが変わってしまうこともある。こうなると、それに依存したモジュールはすべて書き直しになってしまう。開発時間にも悪影響を与えるし、当たり前だけど士気だって下がる。


なんでそんなことを知っているかというと、これ以上ないシンプルな理由がある。


他ならぬ自分自身がそういう設計をしてしまうからだ。


関わるプロジェクトの多くで欠陥を含んだ設計をしていて、そのたび開発者として参加していた人には迷惑をかけている。本当に申し訳ないと思う。


そういうような気持ちを、はてブの制作スタッフ一覧を見て感じた。


開発者ひとりひとりが、自分の信念に基づいて削り出した立体的なピースを組み合わせたシステムを公開できたとき、どんなにうれしい気持ちだろうか?


もしかしたらソフトウェアは立体よりももっと高次元なものかもしれない。人間の感覚では0に近いくらい小さな確率の隙間をすり抜けて手をつないで、共同作業をする自分の作品を見るのはどんな気持ちだろう?


そんな気持ちを感じてみたい。感じてもらいたい。自分と同じチームで開発する人に、そのよろこびを知ってもらいたい。もちろん自分でもそれを知りたい。


公開したサービスのスタッフ一覧というのは、さながらプロジェクトの完成記念撮影のようなものだ。


そんな貴重な一瞬の時間を切り取った写真に、自分の苦痛と愛を一点に注いだモジュールと並んでに写れたら、それはたぶん一生自慢できる、一生消えない思い出の品になるはずだ。





諸君、私はチーム活動が好きだ


諸君、私はチーム活動が好きだ


諸君、私はチーム活動が大好きだ



開発チームが好きだ


イベント運営が好きだ


勉強会が好きだ


読書会が好きだ


情報系の部活が好きだ



都内で


学校で


ホールで


オフィスで


自宅で



この地上に存在するありとあらゆるチーム活動が大好きだ



巧妙に連携するチーム活動が好きだ


一見ばらばらに動いていたかと思われていた個々人の成果が見事に結びついたときなど心がおどる



お互いを補足しあうチーム活動が好きだ


同じ期間で作られた個人製作の作品との差が圧倒的であったときなど胸がすくような気持ちだった



矮小な凡人が大作を産み出し得るチーム活動が好きだ


ひとりではどう足掻いても届かないような表彰台に登ったときなど感動すらおぼえる



チーム内で活発な意見交換が行われているときなどもうたまらない


ディスカッションの中で革新的なアイデアが生み出されるのは最高だ



古い掟にしがみつく狸どもが新チームの発足を妨害してきたのを


既存の枠組みを利用せずゲリラ的に集団を組織した時など絶頂すら覚える



和やかな雰囲気で交わされる会話が好きだ


辛辣な発言によって重苦しい空気が流れるのはとてもとても悲しいものだ



プロジェクトリーダーとなって鮮やかに製作集団を指揮のが好きだ


適切な権限が与えられず統制が取れなくなるのは屈辱の極みだ



諸君 私はチーム活動を 生命体様なチーム活動を望んでいる


諸君 私に付き従うチーム活動好きの諸君 君たちは一体何を望んでいる?



更なるチーム活動を望むか 


糞の様なチーム活動を望むか?


個々人の好みや欲望が有機的に結びついた生命体のようなチーム活動を望むか?



チーム活動!! チーム活動!! チーム活動!!



よろしい ならばチーム活動だ



だが、会社・学校・家庭などの母集団で革新的結束を阻止する古びたルールに耐え続けて来た我々には


ただのチーム活動ではもはや足りない!!



大チーム活動を!! 一心不乱の大チーム活動を!!




我々はわずかに小数


個人製作者に比べれば物の数ではない



だが諸君は一騎当千の互いに高めあえるベストパートナーだと私は信じている


ならば我らは諸君と私で総兵力100万と1人の大製作集団となる



我らを忘却の彼方へと追いやり、個人製作者を叩きのめそう


髪の毛をつかんで引きずり下ろし 眼(まなこ)をあけて思い出させよう


連中に人との関わりの喜びを思い出させてやる


連中に意思と意思のぶつかりあいを思い出させてやる



チーム活動には奴らの哲学では思いもよらない世界がある事を思い出させてやる


1000人の互いに高めあえるベストパートナーの集団で 世界を製作集団で埋め尽くしてやる


目標 社内革命


新規プロジェクト 状況を開始せよ


征くぞ 諸君


諸君、私は戦争が好きだ: wids.net



On Off and Beyond: 中3を家庭教師した頃の話


"クリエイティブな解にたどり着く思考法の訓練"。もしかすると、私たちに足りなかったのはこれなのかもしれない。



「正解なき問題を解く」


ことを特訓。例えばノートに私が


「このうさぎは●●●に生まれました。」


といきなり書いて、●●●を埋めな、とか言うわけです。


「今私が適当に書いただけだから、特に正解は無い。文章として変じゃなければそれだけでいいんだよ。」


と。


(中略)


ま、これは別に「あてずっぽうでもいいから書く」だけが目的ではなくて、クリエイティブに解にたどり着く思考法の訓練でもあるんですが。


On Off and Beyond: 中3を家庭教師した頃の話

仕様を満たすことだけを求めるなら、適合するコードは無限に存在する。5.0 = x + yの解x, yの組み合わせが無限にあるのと同じだ。


でも「じゃあ書いてよ」となると、専門とか高専の学生には何故か書けない。授業で文法は習ってるはずだし、そのときにはちゃんと書ける。


0から書いていいよとなったら好きに書けばいいのに、どういうわけだか書けない。


傍で見てる指導者の好みに合わせる必要もない。自分の好みのコードを、自分のスタイルで書けばいい。それが書けないのは、元記事で言及されているように、



あまりにシャイで気が小さいため、間違った答えを書くのが怖い



ということが原因だったのかもしれない。


もしそうだとすると、この"クリエイティブな解にたどり着く思考法の訓練"によって解決できるかもしれない。これからしばらく、メンバー個別に教える機会がある。その際に試してみようと思う。


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




【スタッフの連携】


・よりよいチームワークは、雑談ではなくお互いの頑張りによって培われる


・スタッフ同士で素材を見せ合って刺激しあう。お互いに作ったものが報酬


・集団作業に関わっている自覚を持つ。自己都合ばかり主張しない


・チーム内で派閥が発生することもあるため、予め作業方針を決めて全体の統一を図る


・やる気がある人たちが集まって、やる気のない集団から抜けるのはこの限りではない


【作業ペース】


・大まかな作業計画は立てておいた方がいい。立てても守らないと意味がない


・自分なりのペースがあっても、全体のペースについていく努力は大事


・月日が流れると、生活の変化で離脱せざるを得ない人も出てくる。長引けば長引くほど不利


・モチベーションの低下も含め、長期戦にはデメリットが多い


・シナリオが上がらなければ絵も塗りもできない。ライターは他のスタッフを一歩先行く覚悟で


no title

このアーカイブについて

このページには、過去に書かれたブログ記事のうちチームカテゴリに属しているものが含まれています。

前のカテゴリはアセンブラです。

次のカテゴリはバージョン管理です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。

ウェブページ

Powered by Movable Type 4.32-ja