A&Eソフトラボ開発日記

2015年8月22日土曜日

週休三日

ユニクロなどを展開するファーストリテイリングが10月から希望者を対象に週休三日を導入する、というニュースが、昨晩の深夜帯のNHKのニュースでも取り上げられていました。
週の労働時間は変えずに、5日の出勤を4日に圧縮する合理化策です。
個人的には歓迎すべきニュースで、この流れが加速してひとつのムーブメントにまで醸成されれば、日本も少しは幸せになるのでは、と淡い期待を寄せています。
実は、スポーツ用品などを扱うアルペンは1989年に既に週休三日を導入してます。ずいぶんと早い時期から労働時間の圧縮を実施していたのですね。
もう少し後になるとEPSONが製造現場での裁量制的な製造活動を実現しています。
一部ではありますが、日本もこのような流れの努力をしているのです。

とはいえ、基本的に我々日本人は働き過ぎだと思います。単なる働き過ぎではなく、働き過ぎに感覚が麻痺しているとさえ思います。とくに私たちの業界がその最たるものではないでしょうか。ここに改善の余地はないのでしょうか。
インターネット黎明期、私たちのような職種はやはり働きすぎでした。しかし、いまほど働いていなかったように思います。あれから、約20年。モノづくりの手法も考え方もツールもずいぶん合理的になったのにもかかわらず、いまのほうがずっと働き過ぎなのは不思議ではないですか？

どこに問題があるのでしょうか。

ひとつには、システムが複雑になり過ぎたというのはあると思います。工学的なシステムだけの話ではなく、社会も、サービスも、人も、複雑になり過ぎました。
それは加速度的な速さで拡大しているとさえ思います。
しかしながら、高効率な生産性を目指すプロジェクトもなかには存在します。反面、前時代的な大仰なモノ作りをするプロジェクトも存在します。
どちらが正しいか？という話ではありません。
ただ、幸福を追求する権利と、幸せを感じようとする感性を忘れないで欲しいと思うだけなのです。

2015年8月20日木曜日

Jadeを試す

今回はJadeを試してみます。
Jadeは、HTML を書くための軽量マークアップ言語であり、JavaScript テンプレートエンジンでもあります。
JadeはnodeのMVCスタックのViewの標準レンダラとして採用されている知名度の高いエンジンです。
その最大の特徴は記法にあります。

なんといっても、タグを閉じない。
class と id 属性の記法が CSS セレクタの記法と同じです。
ただし、注意点としてインデントが必須です。これは厳密です。4spaceでもTabでも構いません。必ず統一性を確保します。

では、nodeがインストールされている前提で、npmでjadeをインストールします。
今回は Windows でやってみます。

$ npm install -g jade
C:\Users\xxx\AppData\Roaming\npm\jade -> C:\Users\xxx\AppData\Roaming\npm\node_modules\jade\bin\jade.js
jade@1.11.0 C:\Users\xxx\AppData\Roaming\npm\node_modules\jade
├── character-parser@1.2.1
├── void-elements@2.0.1
├── commander@2.6.0
├── jstransformer@0.0.2 (is-promise@2.0.0, promise@6.1.0)
├── mkdirp@0.5.1 (minimist@0.0.8)
├── constantinople@3.0.2 (acorn@2.3.0)
├── with@4.0.3 (acorn@1.2.2, acorn-globals@1.0.5)
├── clean-css@3.3.9 (commander@2.8.1, source-map@0.4.4)
├── transformers@2.1.0 (promise@2.0.0, css@1.0.8, uglify-js@2.2.5)
└── uglify-js@2.4.24 (uglify-to-browserify@1.0.2, async@0.2.10, source-map@0.1.34, yargs@3.5.4)

以下のようなファイルを作ります。
index.jade

doctype html
html
head
meta(http-equiv="content-type",content="text/html; chaeset=utf-8")
meta(name="description",content= "コンテンツ")
meta(name="keywords",content= "キーワード群")
meta(http-equiv="imagetoolbar",content="no")
title Jadeのサンプル
body
h1 大見出しです
h2 中見出しです
p Jadeを試してみます。

htmlにコンパイルします。
$ jade index.jade

次のようなhtmlファイルが生成されます。

<!DOCTYPE html>
<html>
<head>
<meta http-equiv="content-type" content="text/html; chaeset=utf-8">
<meta name="description" content="コンテンツ">
<meta name="keywords" content="キーワード群">
<meta http-equiv="imagetoolbar" content="no">
<title>Jadeのサンプル</title>
</head>
<body>
<h1>大見出しです</h1>
<h2>中見出しです</h2>
<p>Jadeを試してみます。</p>
</body>
</html>

どうでしょうか。
案外、簡単だったと思います。
ちょっとしたサンプルを作ろうとか、大量に静的なページを作るといったようなシーンに活躍すると思います。
nodeでMVC + RESTfulを達成するExpressionを使用するには必須です。

興味を持たれた方は、調べて深みにはまるのもいいでしょう。

2015年8月19日水曜日

仕事力

優れたエンジニアとはどのような人のことを言うのでしょうか？

スキルが高い人！

と一般的には思われている、あるいは、望まれているかもしれませんが、自身はこのような意見に積極的には賛成できません。
なぜなら、スキルだけではモノは作れないと思うからです。
誤解のないように書いておくと、ここで言うスキルとは教科書的な模範的スキルのことです。
次にでてくるのは

人間力？

人によっては政治力？

このあたりは要求は高いと思いますが、ちょっと視点がずれてくるような気もします。
では、スキル = 技術力とひとまず仮定義して考えてみたいと思います。技術力は一朝一夕で当然身につくわけでもなく、まずいかなる分野においても準備が必要です。準備にもいろいろな種類があり、基礎的な範疇にまつわる技術素養がまず必要です。これは地道な努力の積み重ねにより堆積してゆく養分みたいなもので、この部分がしっかりしていれば、いろいろな展開に対して柔軟なアプローチが取れます。
当然、この部分に安住してしまうとどんどん考え方が古くなり、技術の進歩についていくのが難しくなってしまうというリスクはあります。このような現象に対する有効な手段が次のステップです。新しい技術や考え方の摂取です。もちろん、世の中の流れにのる、いわゆる時流や流行に敏感であるべきという種類のことではなく、日々、個々が課題として抱えている問題の半年先や1年後を、あるいは、もう少し先を見据える技術です。こちらのほうが準備と捉えるとわかりやすいと思います。
乗り越えどころというのは急にやってくるわけではなく予兆なり流れが必ずあります、これは個人個人で性格の異なる流れだと思います。この流れ、つまり　ビジョンを持ち続けてどのように進んでいくか？　という展望を思い描けることが重要なポイントでもあり、また　重要な技術力でもあるわけです。
このステップにまで突き進んでいくには、旺盛な知的好奇心とチャレンジ力が必要不可欠になります。とくに前者は感性に属する初動で柔軟に、かつ、いかに物ごとに感動し得るか？　というような繊細さも必要ではないかと思います。

これらのことを、自身は「仕事力」と呼んでいます。

実は、仕事力を語るには、もうひとつ大事な視点があると考えているのですが、それはまた別の機会に書こうと思います。

2015年8月18日火曜日

喜びの瞬間を捉えよう

Googleを語った書籍の広告が、JRの車内にありました。
ここではあえてその内容には触れませんが、購買力をあげるなかなか興味深いコピーがならんでいます。
昨日のニュースでは、Googleの共同創業者でもありCEOのラリー･ペイジが新しい会社を起業し、その傘下にGoogleを置くという話題がありました。
Googleは巨大になり過ぎたのです。

さて、仕事は楽しいですか？
もしかしたら、大半の人が冗談じゃないと声を荒げるかもしれません。

では、コードを書くのは楽しいですか？
またもや、もうへとへとだよ。深夜帯も休日も返上してコードを書いていて楽しいわけがない。という声をあるかもしれません。
仮にある刹那を切り取ってみましょう。きっと生き生きとコードを書いている瞬間が必ずあるはずです。食事を摂るのもわずらわしいほどにタイピングの指の動きが止まらない瞬間があるかもしれません。もし、そのような瞬間に幸運にも出会えたら、あるいは、心当たりがあるならば、そのボルテージの高まりへのストーリーを想像してみてください。

また、このように捉えることも出来ます。
私たちは日々コードを書き続け、クラスを定義し、組み合わせ、そして走らせるわけです。もっとも緊張する瞬間ですが、想定どおりの動きを目の前で展開された瞬間は、きっと喜びに満ちているはずです。

2015年8月17日月曜日

MBA教材としての清掃サービス

新幹線の車内清掃サービスをご覧になったことがある方は、もしかすると案外多いのかもしれません。
いまや世界的にも注目されているこの仕事は、ハーバード大の経営大学院の教材としても取り扱われるほどです。
以前は、3K職場などと揶揄された時代もありました。
清掃の現場はカーテンで閉ざされ、クローズされた車内空間で戦闘が繰り広げられていました。これが、以前のメンタリティなのです。ところが、現在ではひとつのパフォーマンスとして捉えることが可能なほどに、メカニカルで想像力溢れる作業効率を実現、かつ、追及して7分間の Show としてまとめられています。この変化はどこから来たのでしょう？
米流に考えるならば、成果を上げれば報酬で評価し、あるいはその逆であれば罰則を強化する。ところが我が国の文化はまったく違ったようです。新幹線の車掌も、あるいはグリーンアテンダントも清掃スタッフも、お客様に見られることを意識したマインドセットを重視したそうです。これは、オープンであることの重要性だと思います。
しかしながら、ここまでの技術に昇華するには様々な紆余曲折があったことは容易に想像できます。ここにポイントが隠されてると思います。経営サイドや運営陣ではなく、現場から能動的に発信される改善案には必ず明確な根拠があることの重要性を、しっかりと受け止めるまでに成熟した文化が根付いたことの証だと思います。私たちもそこから学ぶべきことは少なくないはずです。

2015年8月6日木曜日

抽象的な工場の提案

ファクトリ（Abstract Factory）は極めて応用力の高い実装パターンです。
昨日にも書いたように、もし、if文の入れ子構造があまりにも深いのであればリファクタリングの兆候です。
同様にif文のコンビネーションの中で階層表現として扱われる問題は、結局は同じシリーズであるわけです。ただ、ほんの少しだけ条件が変わるだけなので、そういう場合は頭を冷やすなり、もう一歩引いた視点で俯瞰する必要があります。

これは決して難しい問題ではありません。
たとえば、ある車を生産する工場があったとします。その工場ではたったひとつの車種を生産します。しかしながらオプションの種類が多彩で、その都度生産条件を変更してやる必要があります。まさに if文で判定するわけです。
しかし、その方法ではおそらくすぐに限界がやってきて作業ミスが多発する問題は避けがたくなるだろうと思われます。
この問題をどのように回避したらよいでしょうか。

先にも書いたように、もし○○○であれば、XXXのオプションを追加するという考え方をやめてしまうのです。そして、そのパラダイムをXXXのオプションで○○○を実施するという方向にシフトします。

工場はいろいろな条件でモノを生産します。
条件が違うだけで、ベースになるものは同じです。つまり、生産物はシリーズであるわけです。であるならば、ベースになる部分をごく抽象的なインタフェースでルールのみを定義してやることにより、オプションで肉付けをすることが可能になります。
これがアブストラクト・ファクトリの基本的な考え方です。

2015年8月5日水曜日

実務に即したファクトリ実装

もし、○○○ならば、XXXをする。

これは極めてソフトウェア工学の中ではポピュラーなモノの考え方です。
常に通奏低音のように鳴り響き、まるで呪縛のように私たちを取り巻いている、ひとつの習慣として醸成されています。

今回はここを取り崩そうと考えています。

上の if文の中でさらに条件を想定して、もし、△△△ならば、□□□をする。というような構造を考えてみます。いわゆる入れ子構造です。

ここまでを整理します。
すると以下のような構造が見えてくると思います。

if ○○○ {
if △△△ {
□□□
}
else {
XXX
}
}
else {
// 何もしない。
}

ここでは、3つの処理系が存在することがわかります。
さらに、もし、△△△ならば…　という条件下でさらに入れ子になる構造…　と考えたところで、うんざりしますね。そしてバグの不安に駆られます。このような構造が（そう、構造そのものなのです！）ソースコードの平面的な世界観の中で表現された場合、人間の頭の中ではどのくらいの階層まで把握、管理ができるでしょうか？

いいえ、このような発想は、おそらくナンセンスなのでしょう。
もっと、シンプルに整理、管理できないのか？　ということに頭を使ったほうが、余程世のためなのだと思います。

皆さんであれば、どのような工夫をするでしょうか。

このように整理してみます。

if ○○○ {
if △△△ {
□□□　Aの処理系
}
else {
XXX　　Bの処理系
}
}
else {
// 何もしない。Cの処理系
}

この構造を階層で表現せずに、バラバラにしてまずはコンテキストで表します。
（表現が冗長になるのためコンストラクタの記述は割愛します）

まずは、AとBの処置系
class ABClass implements IFactory {
public void Execute() {
if △△△ {
// Aの処理をする。
}
else {
// Bの処理をする。
}
}
}

次にCの処理系
class CClass implements IFactory {
public void Execute() {
// Cの処理をする。
}
}

この段階でAとBの処理系をドライブする表現を記述します。

IFactory target = null;
if ○○○ {
target = new ABClass();
target.Execute():
}
else {
target = new CClass();
target.Execute():
}

if文の入れ子構造をひとつ減らすことができました。
ポイントは、もし、○○○ならば、XXXをする　という考え方から脱却して、XXXという条件で○○○をする　というように捉え直します。
いわゆるポリモフィズムの実務に即した応用です。

登録: 投稿 ( Atom )