勉強会その後
放置のまま年が越そうとしているので簡単に。
勉強会自体は許可を取ってできるようになった。大々的にしないので半公的といった感じで。
ネタはweb上のものだったりで問題はないと思いますが、一応公的ということで、blogは控えてたり。
今のところ講義の形態は、勉強したい/広めたい内容を持つ人が、参考ページなりコードなりをUPを連絡しておく。その資料を基に進めていく。其れに対して質問なりする。1時間くらい。
内容はプログラム以外も自由に行う。
両手で収まるくらい実施したところで、自分も含めほとんどのメンバーが分散し、休業中。消滅してないのは"やることストック"が幾つかあるからと思われる。常に実施されるには有る程度人数が要るようなので、メンバーを増強しようと思う。
後は、勉強会で得た成果や出たくても出れなかったメンバーへの情報を、どう残すかというのが課題。終わってから改めてまとめるのは面倒であるので、最中に何か楽に行う方法を検討しないといけない。
良いお年を
《某炎上事件について》
堺の商人になりました。
なかなかいい環境で、まだまったりしてますね。明日は休みです。
ここで発言するのはいかがかなものかもしれないが、タイトルのことについて一言。学生時代に事故解析をかじっていた身としてある手法を提案してみようかな。それは4M4E分析。
詳しくは・・・ ttp://cocomo.jp/4m4e/
を見てください。。日本では医療事故、米ではNASAでも用いられている事故解析手法ですな。ざっくりいうと、一つの事故（ヒューマンエラーなど）について多角的な視点で解析をしようよ！！てな感じです。小さな事故でも組織の問題を発見できることができます、なんてね。
分析を行っているかと思いますが、こういった手法があれば簡単に行えるかも知れませんね、視点があらかじめ決められているので。
もともと解析手法とは解析者の負担を減らすよう作られたので、機械的作業で解析を行えます！！ 昨今事故が多発しているのでこういった手法はいくつもあります。○ヨタさんみたいに5回も分析なんか行ってる時間も金もねえよ！！てな団体・企業は数多くあるのです。
またこういった手法を用いると、トーシローには「おお、なんかすげぇ！！」といい印象を与えることもできますな（ちなみに昨今では手法に走りすぎて、解析だけで満足することが非常に多いのが問題ですが・・・）。
例
１．Man−Education：SubVersionの使い方が統一されていなかった
２．Management−Example：過去の事例が生かせていない
などなど。こんな感じでやれば時間も減らせるし、もし発表することになったらちゃんと解析してるな、印象を与えられるかもよ。
以上、雑談でした。。。
まとめ by 堺の商人
まとめます！
○私がやりたかったこと
１．なにか一つの事を通じて体系的にソフトウェア開発を学べればなぁ、と思ってました。今までの経験上OJTという名の放置プレイ状態（？）だったので、何がよくてなにが間違いなのかふわふわした状態であって一から学びたい、と。（なんだか間違ったまま年をとるのか不安）
２．テクニカルな部分とかソフトに関した知識が得られるかな、と。参加者は自分を抜いてソフトに詳しいので、自分では決して知ることのない知識を享受したいとも思ってたかな。
３．ようするにソフトウェア開発の知識を深めれば自分はよかった、と思ってました。パソコンにあまり興味がないので、現在こんなテクニックがある！とか知る機会が自分だけであったら取得しないので、みんなで話せば何かしら知識が増えると思ってました。
○感想
１．テクニカルな話ではだいぶ勉強になったと思う。
２．どうすれば勉強できるか、と考えたとき一つのソフトを0から作ることをせんたくしたが、進め方がいまいちうまくいかなかった。参考書を用意すべきだったか。
３．時間をいつまでになにをやる、と決めなければ進まなかったかな。完璧でなくてもある程度妥協して前進することも重要かな、と感じた（妥協しすぎるのもだめだし、後で修正することを前提にするとフォローする時間も考慮しなければならないね）。
４．業務に支障をきたすのはどうか、とやっていて疑問にも思った。あくまで業務が本業のなか、忙しい状況で無理にでも時間を作ってやるのは個人的にモチベーションが下がった（各個人によるかと）。宿題をやる、といっても休みの日にはやらないし、業務中にできなかった（言いだしっぺでした）。一時間できっちり終わる方法を考えればよかったかなぁと反省してます。なにに力を入れるかは個人によって違うので、ここがずれれば勉強会の意義も変わると思います。
５．人数については自由にやりたかった分、目をつけられないように、としてました。成果を見せろ、と言われると余計なプレッシャーがかかり、負荷になるとおもったので。最終的には堂々としすぎでした。2週に一回のほうがよかったかも？？
研究所自体で、勉強会を行う習慣になれば一番よいのだけれど、業務の都合で継続はむずかしいし、悩みどころだね。会社外のところでやるのが一番よい、と思った。会議室をレンタルするなどしてね。
○今後について
１．知識向上はすばらしいとおもので、個人でもみんなでも勉強は続けたいと思ってます。長い時間をかけず、単発で終わるほうが勉強会はやりやすいのかな。たとえばコードを書きたい人と、ソースにはあまり興味がないひとが同じテーマでやっていくのは両者ともモチベーションに差がでそうだし・・・今月はDB,来月はオラクル、再来月はAjailとテーマを割り切ったほうがよい？
２．自分は修行にでますが、オープンにはしないほうがよいかと思ってます。いろいろごちゃごちゃ言われるのはいやなので。成果は各個人が業務で見せ付ければよいわけだし、頑張っているところをみせて情けをかけてもらうのは嫌いです。男は結果がすべて！！
以上一気に書きました。入力欄が見え難いので誤字脱字あるかと思いますがご了承を。。。てことで
あると思います！！
何故はじめて如何したいのか
立ち上げた経緯と何がしたいかを書く。これも各人で違うと思いますが、取り合えずメモ程度に書いてきます。
続きを読むレビューや会を続ける上でのまとめ。
続けるために必要だと思ったことを書く。
考えを纏めたメタな知見ではないので、何が言いたいのかはっきりしないだろうけど、とりあえず、材料や情報は沢山あれば良いだろうと思っているので(ゼロはゼロだろとか無しね)、だらだら書く。取捨選択できるほどの力がないしね。仕事だとこんなんじゃ駄目々々なんだけど。せめて推敲くらいするべきだろうけど、、、。と言い訳と反省してると見せかけて↓。(今は夜中だ。なんだかよく分からなくなってきた。明けてきた)
