ウェブ業界なんかだとデザイナーさんがいるので、「デザインがーーーーー」みたいなのはクリティカルな問題にはならないのかもしれないが、製薬系の研究所とかだと、研究所内のシステム構築のためにデザイナーを雇うとかまずあり得ないので、しょっちょう悩みます。

特に、イントラでウェブサービスやろうとか思ったらjQuery使って見ためを良くしたりとかユーザビリティとか考えて使いやすくしたりといったフロントエンドのスキルは必須。

つまり、モックを使ってできるだけ早く70点のユーザーインターフェイスを作るスキルが超重要なわけだ。

しかも、twitter bootstrapを使おうと思ったら、頻繁なバージョンアップに対応しないといけないわけで。

GitHub対応

GitHubハンズオンやったので、その時の@ishisakaの資料を参考にすればいいと思います。

とりあえず、本家からforkしたらcloneして、upstreamを設定します。

git clone git@github.com:kzfm/bootstrap.git
cd bootstrap/
git remote add upstream https://github.com/twitter/bootstrap.git
git fetch upstream
git merge upstream/master

これで最後のニ行を叩けば常に本家の更新に追随できるようになります。

設定を変更

Twitter Bootstrap Customization Best Practicesの後半を参考に、bootstrap.lessとvariavles.cssをコピーして自分用の設定ファイルを用意する。my_bootstrap.lessとmy_variavles.lessにした。Makefileのbootstrap.lessもmy_bootstrap.lessに変えておく。

こうしておけば本家のファイル群を変更する必要がないので、いつでも

git fetch upstream
git merge upstream/master

すれば、本家の更新に対応できる。

コンパイルしたい場合には

$ make bootstrap
mkdir -p bootstrap/img
mkdir -p bootstrap/css
mkdir -p bootstrap/js
cp img/* bootstrap/img/
recess --compile ./less/my_bootstrap.less > bootstrap/css/bootstrap.css
recess --compress ./less/my_bootstrap.less > bootstrap/css/bootstrap.min.css
recess --compile ./less/responsive.less > bootstrap/css/bootstrap-responsive.css
recess --compress ./less/responsive.less > bootstrap/css/bootstrap-responsive.min.css
...
cat bootstrap/js/copyright.js bootstrap/js/bootstrap.min.tmp.js > bootstrap/js/bootstrap.min.js
rm bootstrap/js/copyright.js bootstrap/js/bootstrap.min.tmp.js

bootstrapディレクトリ以下にコンパイルされる。

その先

あとは、Twitter Bootstrap＋その他で「本当に」イケてるモックを作る手順なんかを参考にしながらいい感じの自分用モックを量産すればいいと思うのだが、そういうのをもくもくとやるといい気がしませんか？

というか、やることにしたので興味があれば参加するといいと思います。プレゼンしたいひとも歓迎。

静岡デベロッパーズつくる会#6 (Mock! Mock!)

• ATND 静岡デベロッパーズつくる会#6

だらだらと作ってもよし、黙々と作ってもよしのつくる会です。前回同様、好きな時間に来て好きな時間に帰ってかまいません。

今回はMock! Mock!とモックをモクモクいじる回にしてみました。みんなで一緒にtwitter bootstrapをいじりましょう。

レスポンシブ・ウェブデザイン標準ガイド あらゆるデバイスに対応するウェブデザインの手法
こもりまさあき
エムディエヌコーポレーション / 2625円 ( 2012-05-25 )

だいたい知っていることだった。出張報告書の予想版を予め書いておくというのは参考になった。

通勤どこでも仕事術
美崎栄一郎
ぱる出版 / 1470円 ( 2011-07-30 )

電源タップは持ち歩くのに便利なのが欲しいなぁと思ったので、モバイルタップを買ってみた。

SANWA SUPPLY モバイルタップ 2P・3個口 ホワイト TAP-M1W

サンワサプライ / 682円 ( 2012-01-31 )

2月くらいからredmineを使い始めて、中規模なサイトを2,3個作って、チケットの粒度とか運用サイクルとかリズム（トヨタ生産方式でいうタクトに近いかな）なんかについて色々とわかってきたので改めて読んでみた。

Redmineによるタスクマネジメント実践技法
小川 明彦
翔泳社 / 3444円 ( 2010-10-13 )

最初は複数人で使うつもりで啓蒙してみたりしたんだけど、予想通り難しかったので、他人にふった仕事もIssueとして全て自分で管理したら、うまくまわった。4.２節の権限ポリシーをワークフロー型に振って、他人に仕事をアサインするっていうタスクをチケットとして切ったことになるのかな。

他人への仕事のアサインを不確実性のあるタスクとして登録して、タイムアウトしたら自分に再アサインするというやり方にしたわけだけど、これで淡々とこなせるようになったし、さらにイライラしなくなって精神的にも都合が良かった。

ついでにチケットも会議と紐付けるようにしたので、会議を定期的にやれば、プロダクトの開発サイクルもそれにつられてタイミングが揃うようになったし、会議の議題とかチケットの粒度も次の会議までの期間でできそうな(3週間くらい)に揃えやすくなった。

変化を受け入れる技術、プロジェクト管理、開発環境がなければ、アジャイル開発は絵に描いた餅です

これはそうだよなとしみじみと思った。というわけで、これも読む予定

チケット駆動開発
小川 明彦
翔泳社 / 3444円 ( 2012-08-24 )

その他

化合物の合成を１つのチケットにしてbacklogsプラグイン使えば、かなり便利に使えると思うんだけどどうかな？と思った。そのうち試してみたい。

先日のtwitterのやりとりが、FAQっぽかったので@32nmのススメもあってLSQAに投稿しておいた。LSQAは主にバイオインフォマティクス系の話題をとりあつかうもんだと勘違いしていたので、これからはもう少し質問しよう(回答も)と思った。

うちの職場でもOSQAを入れているのだが、なかなかアクティブにならないので、検索した時にヒットしなかったら別のサイトに検索書けるようにならんだろうか？P2PみたいにQAがつながらないかなぁと。GitHubみたいにQAがフォーク出来る感じだといいんだけど。

まぁ、ユーザー100人規模だとなかなかアクティブにしにくいのかなぁ？もっとずっと規模の大きい研究所で試してみたいなぁと思うこともあるが、それは甘えなのかな（多分そうなんだろう）。

ただ、個人的にはこういうことをやる場合のユーザー数は時間を超えた述べで考えないといけないのかなと思っていて(つまり一年後の自分は他人)、持続的で効率的な研究スタイルのためには絶対必要な仕組みだと思うんだけど、プロジェクトに張り付いていると、目先の問題を解くことで一杯一杯でなかなか理解してもらえないとこがもどかしい。

そういう意味では、ChEMBLはちょっとしたブレークスルーかもねーなんて思ったりする。従来メディシナルケミストリー的な情報は閉じていて出てこなかったのが、気軽にデータをあつかえるようになったから、個人の趣味レベルで色々やれるようになったし、パブリックデータベースに閑する質問はパブリックでやればいいだろうから、これからもっと面白い情報も出てくるんじゃないかなーと。

ケモインフォマティックス―予測と設計のための化学情報学
J.Gasteiger
丸善 / 18900円 ( 2005-02 )

今週は夏休みってことで会社を休んでいた。

で、朝起きてご飯を食べたら、コードを書いたりブログを書いたりしている隣で、娘が夏休みの宿題をやるというルーチンだったのだけど、色々気づくことが多かった。

特に「学ぶことの習慣化」と「学習レベルのコントロール」は家庭でやるべきなんだろうなぁと。

一方息子はポケモンばっかりやっていた。あいてのポケモンが穫れないとか言ってブチ切れたりしてたなー

ポケットモンスターホワイト2

任天堂 / 3927円 ( 2012-06-23 )

wifiの通信対戦(ランダムとかレーティング)のやつは結構面白い。勝った負けたは結構熱くなるね。

コミュニケーションスキルの本。NLP多め

部下がウツになりまして 成果がすぐ出る職場のコミュニケーション・スキル
榊原　明美
毎日新聞社 / 1575円 ( 2012-02-25 )

NLPにおけるミスコミュニケーションの分類

• 言語の歪曲
• 言語の省略
• 言語の一般化

コミュニケーションには癖があり分類すると

• 視覚型(Visual)
• 身体感覚型(Kinesthetic)
• 聴覚型(Auditory)

NLPではミスコミュニケーションは情報処理の癖が違うことで起こりやすいという立場に立つらしい。

が、自分を当てはめようと思って考えてみたけど、どれにも当てはまらないような気がする。目の動きの話とかちょっと眉唾っぽいんだよなー。

wikipedia

NLPは、効果を実証する不十分な経験的証拠しかないため、プロフェッショナルな信頼性の問題があり[1]、一般の社会科学からは広く無視されている

• 新型うつ病は若者が発達していく上での心理的疾患

事務局力のススメ。技術としては面白かったけど、これに頼ったジョブはどうなんだろうね。

「管理職を目指す行動指針」では管理職にするらなれない

評価制度に関しても

短期的な評価の積み上げが長期的な出世につながる人事評価メカニズムは、近視眼的な思考を促す。その結果、視野の狭い仕事だけで評価された人が管理職になって、経験不足で失敗することになる

と、客観的にみている。そういう状態で会社でうまくやるには事務局力をつけて裏方から仕事を動かすことを説く。まぁ、普通は転職と天秤に賭けるんだろうけど、本書は如何に頑張るかという内容なので、そういうことは書いてない。

裏方ほどおいしい仕事はない!
野村 恭彦
プレジデント社 / 1500円 ( 2009-10-15 )

• 社内をぶらぶらしよう
• 情報はどんなひとのところに集まるか
• 提案が通るかどうかは、内容よりも参加者の顧客満足によって決まる
• ホウレンソウに対比して「置き石、水やり、待ちぶせ」

ちょっと人情系入りすぎだけど、改善した後の短縮された時間をどう使うのかという認識が一致していないとうまくいかないというのは盲点だった。

改善するための前提

たとえば導入した結果、従来と同じ量の製品をつくるのに要する時間が、一時間短縮できたとする。この短縮した１時間をどう使うのか。そこをはっきりさせておかないと、時間を短縮した意味がなくなる。

自分の場合、効率的に仕事をして、余った時間は「より高度なことにチャレンジするか、早く帰って家で新規な技術を試すかっていうこと」に突っ込むの当たり前じゃんって思ってたので。

単に時間労働って考えている人にとっては時間ギリギリまで引き伸ばすのは当然の事なので違和感を感じるのかと気づいた。思い返せば確かにグダグダ言ってるな。

ホウレンソウとは

事実は起きた瞬間に事実ではなくなり、見たものの主観に左右されてしまうからである。主観で書かれたものは、もはや事実ではない。

プロジェクトの報告もプロジェクト側から語られるものはそういう性格を帯びる。そういうのを客観的に眺めたくて色々チャレンジしているところ。

僕もホウレンソウのうち報告と連絡は無駄だと思っている。あんなのはコンピューターが定期的にレポートを出して、相談に時間を費やすべきであろう。

ムダとはどこからみて

答えは、ひとつ。あくまでも「後工程」にとってムダかどうかである。

これはどうなんだろう。ちょっと悩んでいる。生産だとシーケンシャルだから、後工程ってのは直後の行程であることが多いだろう。多次元最適化とかやってる場合後工程ってのはデータが全部出揃ったとこのことなのだろうか？

「トヨタ流」現場の人づくり―トヨタ元生産調査部部長が明かす (B&Tブックス)
田中 正知
日刊工業新聞社 / 1680円 ( 2006-11 )

失敗を貴重な体験と考えよう！

なぜメモをとらない若手社員が増えているのかというエントリを読んだ。ちなみに僕は、メモ魔なのに取ったメモを読み返さないで、同じ失敗を何度も繰り返す年上の部下に「お前のメモに「メモを読み返すこと」ってメモっとけ！」ってブチ切れた苦い思い出があるのでメモ魔は苦手だ。

リンク先にも書いてあるが、

メモをとる理由は、打ち合わせの内容・やるべきアクションを「忘れない」「確実に実行」のためです。よって仕事上で正確なメモをとるようにしないと意味がありません。

実際は、これプラス合意が必要だろう。打ち合わせのメモというのは議事録的な性格を帯びていることが多いし。

さて、そのようなものは指示を受けるほうが用意しないといけないだろうか？

否というのが僕の考えなので、最近は上司に仕事を振ることの多い僕が試している方法を2つほど紹介してみたい。

メモや議事録をWIKIでとる

会議の最後に5分ぐらいラップアップの時間を設けて、WIKIをスクリーンに表示しながら議事録をつくります。いつまでに誰が何をやるかを合意していきます。メモはあくまで主観的な情報の羅列だし、こういったものをもとにメールベースで議事録を作ろうとすると、行った言わないとか無駄なオーバーヘッドが発生するので、その場で合意するのがいいね。

これは外資系出身の元上司に教わって、試してみたら自分に合っていたのでそれ以来できるだけこのやり方をしている。

議事メモの作成は書記的な人を指名してお願いしてもいいけど、

3．本質を見極める習慣が身につく。 打ち合わせで話した内容で本当に重要なことは何か？を覚えておける範囲は限られる。だからこそ、重要なポイントを探る力が身につくようになる。

とかいう言い訳じみた事を言う人にラップアップやらせれば要点だけのスマートな議事録が出来て、自分たちも先方も喜ぶかもしれない。。

redmineを使ってその場でチケットを発行しておく

最近気に入っているのが、redmineを使ってタスクに落としてしまうことだ。これだとwikiで文章化する手間が減りますし、先にも出したメモの本来の目的である

メモをとる理由は、打ち合わせの内容・やるべきアクションを「忘れない」「確実に実行」のためです。よって仕事上で正確なメモをとるようにしないと意味がありません。

という5W1Hが簡潔な形で記述されます。

タイムラインで見たい場合にはガントチャートで表現できるし、誰にどのくらい仕事が振られているのか一目でわかるので調子がいい。

業務の引き継ぎとか新人研修みたいなのはWIKI

同じことを繰り返して教える場合はWIKIがいい。まずはWIKIのマニュアルを見てやってもらってわからないことがあれば質問してもらうという方式にする。わからないことは丁寧に教える代わりに、覚えたことをWIKIに足してもらうことで、マニュアルが洗練されるし、次に教わる人にとってもより分かりやすくなるので、みんなの利益になっていい。

まぁ、これはどこでもやっていることだと思うけど、一応載せてみた。

まとめ

メモをとらせるというのは、自分で仕事をコントロールしないで相手任せにしすぎな行為の気がする。結局、いつまでに何を取るかの合意を明確にしたいんだから、今だったら色々やりかたあるよねと思っている。

プルプッシュはMapReduceとかをイメージしたほうがわかりやすいのでそっちから生産管理のイメージにつなげていく。

• 「プッシュ」スタイルはHadoopがmap関数に1行分のレコードを渡してくれるが、複数行に対しての処理ができない。
• 「プル」スタイルは複数行に対しての処理が可能だが、map関数のレコードのフェッチを制御する必要がある。

よくわかる「プル生産とプッシュ生産」の本 (ナットク現場改善シリーズ)
越前 行夫
日刊工業新聞社 / 1890円 ( 2008-09 )

• お客様は常にプル
• 後工程は前工程に必要な物をとりにいく
• プル生産がチェーンシステムとよばれるのは、鎖を引っ張ればピンと張ってスムーズに動き、止めると全体がさっと止まるから
• 生産リードタイムの長い製品をプッシュで流すと異常や変更があった場合のフォローが大変

個人的にはプルプッシュの話は色々参考になることが多くて、お願いします脳なんてプッシュ方式についてまわる弊害の１つなんじゃないかなと思いながら読んでた。

アッセイ系を依頼書方式（つまりプッシュ）で回していくと、後工程はお願いされる立場になるので

お願いされたらやる -> お願いされたことしかやらない -> お願いされなきゃやらない

ってマインドになっていって、保守化したのち、考えることをやめる。そういう人達と話すと頭がクラクラして精神衛生上よくないのでなんとかしたい。

例えばプル方式にして常にMAXまでアッセイ系をまわすのを奨励するようにすれば、生産性は上がるんじゃないかなぁと思うんだけど。