セットアップと仕事のリズム

個人事業で仕事をしていると、どのように自分の集中力やモチベーションを維持するかが問題になる。

人間誰しも心身の状態に並があり、スランプに陥ることはいくらでもある。
プログラミングを初め、ITエンジニアが行う作業はとてもメンタルの影響を受け易い。

会社員であれば、調子が悪くても周りのフォローがあったりするし、（ないこともあるけど）
同量や上司がいると、適度な緊張感があるので、それほどひどいことにはなりにくい。

しかし、一人仕事となると、これが難しいことがある。

『調子が悪い』と一度考えてしまうと、
そこからなかなか抜け出せなくなってしまう。


私は最近で、

『できるだけ漫然とプログラムを組まない』

と言う考え方をしている。


自分の性格を考えてみて、
淡々と仕事を進めていくということは苦手で、
短時間にガッと仕事をして、少し休憩し、
再び一気に仕事を進めていく形の方がうまく行きやすい。


そうなると大事なのは気持ちの切り替えだ。

最近実践していることは、仕事をするために席についたら、
まず、両手の拳を握り、前身に　グッ　と力をいれる。

次に一気に体の緊張を解いて、椅子の背もたれによっかかり、
両腕をたらして　ダラ～　っとリラックスルする。
その際、大きく息を吸って、ふかーいため息を付く。

目を瞑って、数秒程度その姿勢を保ったあと、
一気にからだをおこして　よしっ！　と気合を入れてから、
パソコンを操作し始める。


いろいろ試してきたけど、これが今の私の『セットアップ』。
この状態から長くて一時間半、短いときは三十分ほど一心不乱に働く。
切れ目のいいところで、一度力を抜き、軽く休憩してしてから、
もう一度先程のセットアップを行う。



私の場合、仕事は計画の時点で一日以内にできるサイズにまで、
作業を分割しておく。。

そして、その作業をさらに切れ目のいいところで、
大きくても２時間以内で追われそうな大きさにまでさらに分解する。

今通っている事務所ではホワイトボードが使えるので、
そうして分解した項目を白板に書いておいて、
終わるたびにチェックをつけていく。


ホワイトボードは立ち上がらないと書けないところにある方が良い。
座りっぱなしは、覚醒レベルを落としていくし、
一度立ち上がって、次の作業を確認して座ることで、
やはり仕事にリズムが出てくる。


来月から事務所を借りるときはその辺をどうするかが重要と思っている。
いろいろやることはあるのだけど、ちゃんと優先度をつけて、
どれから手をつけていくかを良く考えなければならない。

システムエンジニアの教育のあり方

システムエンジニアは一生勉強だと言われる。

「学生時代や新人のことに勉強したことの多くは10年後には役に立たない」

目の前の仕事のために、その息の短い技術を身に着けなければならない。

では、SEへの教育というのはそんな非効率なものなんだろうか？


思うに、IT技術者育成のために行う教育というのは、
目の前の、そのときのトレンドに沿った技術を教えるとともに、
その中で、｢技術の学び方を学ぶ」というエッセンスが含まれてなければならない。


むしろ、


実際に使うかどうかもわからない技術を覚えることよりも、

効率的に新しい技術を吸収するためのコツ

を身につけさせることが重要である。



それも、



仕事をしながら技術を身につける方法を


を学ばねばならない。例えば、PHPを教える授業があったとして、
PHPの文法や膨大な量の関数仕様を覚えさせようというのは無理がある。

基礎文法は当たり前に理解しなければならないが、
あれだけの数の関数仕様を丸暗記しているプログラマなどそうそういるものではない。

実際にはリファレンスマニュアルを参照しながら、
必要な機能を実現する方法を探し出すという形を身につけている。
仕事の中で頻繁に使う関数についてはよく覚え、理解も深まっていくので、
自然と新しい技術が自分に身についていくことになる。



サブクエリを含むような複雑なSQLは文法を理解するだけではかけるようにならない。
エンジニアがSQLを書くときにどのような思考過程をたどるのかを考え、
その考え方の手順をうまく伝える方法を検討する必要がある。



その「思考の過程」を学ぶことで、

新しい技術を用いて開発する必要が出てきたときに、

自分で思考の過程を作り出す技術

を身につけることができれば、鬼に金棒である。



私が受け持っているDBの授業の中でも、
そうした理論上のものではない生のノウハウを教える工夫をしたい。



ちょっとだけ過剰装飾。書捨て御免っ！

エラーメッセージを手がかりにする力

何度か書いたように思いますが、とある専門学校でデータベースの授業を担当しています。

システム開発と掛け持ちの非常勤講師ですが、技術者の卵たちを見ていると、
いろいろ刺激になることも多く、いろんな気付きも得られます。


受講生は1年生。なんと、ほとんどが高校を卒業したばかりの専門学校１年生に、
データベースの概念とSQLを教えないといけない。

同時並行でWindowsの基礎とかオフィスソフトの使い方を教えてる中でのことで、
結構難しいものがありましたが、最近はなんとか実習ができるようになってきました。

１時間半の授業で後半３０分はSQLの問題集を解くのに当てています。


そろそろ問題集を解く進捗には差がでてきているのですが、
早く進む学生と、時間がかかる学生にははっきりとした違いがあります。


「エラーメッセージを読むことができるかどうか」


問題集には専用のSQL練習ソフトが付属されており、
文法ミスや、問題の意図に沿わない回答にはエラーメッセージを表示します。
（これがなかなか良くできたソフトです。たまにデータにミスがあったりしますが）

要領のいい学生はエラーメッセージを手がかりに、正しいSQLを書くことができるのですが、
進捗の遅い学生は、エラーメッセージが表示された瞬間、思考停止ししてしまいます。

はじめから正しいSQLを常に一発で書ける人はほとんどいませんし、
ベテランの職業プログラマだって、書いてみて結果を見たりエラーを読んで、
試行錯誤したりするわけですが、

「エラーメッセージを読んで何が間違っているのかを考える」

という習慣が上達の分かれ目になるようです。


そういえば思い出しのたは、以前、SOHOとしての仕事を始めたい方々に、
インターンとして開発プロジェクトに参加してもらったときも、
初めて使うツールでエラーメッセージが出るたびに問い合わせをしてくる方がいました。

エラーメッセージのほとんどは英語ですが、難しい英語はほとんど出てきませんし、
ほとんどいつも同じようなメッセージが出てきますから、繰り返し見ていれば、
何が悪いかだんだん勘が働くようになります。

しかし、はじめから、エラーメッセージと格闘するという習慣がついていないと、
そもそも何が間違っているのかを解析することが身につかない。


「できませんでした」

で終わってしまうのかもしれません。


エラーメッセージに限らず教育機関で教えるシステム開発の方法論は、
学問的な話や基礎知識、いわゆる教科書的なノウハウに終始しがちで、
実際の現場での作業のあり方についてはあまり触れられていない感じがします。

「プログラムを書くときの作業の手順と思考の流れ」

を改めて整理して、習慣化させるための教育方法を考えねばならないのではないかと思った次第です。


・問題を細分化して検討
・Webや書籍にあたって情報収集
・仮説を立てて技術検証
・エラーメッセージを手がかりにして、トライ＆エラー

などなど、ある程度の経験をつんだ技術者なら当たり前すぎて、
無意識に行っていることを、学生や若手に教えていく必要があるように思います。

若手がベテランが若手だったときと同じスタート地点から走らなければならないようで、
世の中が発展していきません。

自分が現場で身に着けたことでも、学校にいる間に覚えさせることができないか、
そういうことを考えて授業をしていきたいところです。


書捨て御免！

書き易く書いて読み易く読む

文章やデータ、プログラムのソースコードと言うのは、
読み易いようにと気をつけて書くのは面倒なもの。


一番わかりやすいのはソースコード。
何も考えず、ただ、そのとき楽に書きやすくと考えるのなら、
オブジェクト指向も構造化プログラミングも必要ない。


一番めんどくさくないのはスパゲッティスタイル。
言語仕様に強制されたり、GOTO文がマイナーになることで、
構造化プログラミングは当たり前になったけれども、
読み返すこともないような小規模なプログラムなら、
クラスを定義して記述するというのはとても面倒だ。

だから、簡単に書けるライトウェイト言語というものが出てくる。
（と言ってもライトウェイト言語にもオブジェクト指向の機能はあるし、
　読むことを意識せずに書くのはやはりよくないのだけれど）


スパゲッティスタイルのソースは読みにくい。
プログラムの構造が明確でないため、
目的の処理がどこにあるのかを探すのが大変だからだ。


同じことは文章やさまざまな文字列データにも言える。
目的の記述がどこにあるか、簡単に捜せることが｢読みやすさ」につながる。


読み易く書くためには、あらかじめ、全体の構造を明確にする必要がある。
フレームワークの役割はまさしくこれで、あらかじめ汎用的な構造を定義して、
それにしたがってプログラムを記述していくことで、
同じフレームワークを習熟した人には、他人の書いたソースが簡単に読めるようになる。


さて、しかしながら、実を言えば、複雑なシステムを作るためのプログラムこそが、
「紙のメタファー」から抜け切っていない、もっとも原始的なデジタルデータであったりする。

それ以外についても、文章データや表形式のデータも実際には、
「紙のメタファーの呪縛」から抜け切っていない。



「紙のメタファーの呪縛」とは、データの取り扱いについて、
原始的な情報媒体である紙の欠点を受け継いでしまっていることだ。

１．書いたときと同じ見え方
２．修正すると過去の記述が消える
３．読みたい箇所までページをめくったり目で追ったり

３については、テキスト検索の力によってだいぶ変わっては来ている。
２については、例えばソースコードならCVS、SVNなどのバージョン管理システムの利用によって、
過去の修正履歴を残していくことができる。
１については、DBMSを利用したり、専用のアプリを容易すれば解決する問題だ。

だけど、一般的に使われているほとんどのアプリケーションはこれらの問題を置き去りにし、
「紙のメタファーの呪縛」から抜けていない場合が多い。

その理由は、ユーザ自身が紙のメタファーから抜け出せていないからだろう。



さて、「書きやすく書いて読み易く読む」ためには、
紙のメタファーの呪縛の１、「書いたときと同じ見え方」という問題を解決する必要がある。


私はこれをうまく解決したのがTwitterではないかと考えている。
Twitterは、とっても「書きやすい」。

わずか140文字しか一回に入力できないが、
ログオン後、すぐに文章を書いて、一発でポストできる。
実に気楽に文章を書ける仕組みだ。

そして、読み手はフォローの仕組みによって、
自分が読みたい文章を簡単に閲覧できる。
140文字ずつであるため、一画面に十数件以上をいっぺんに表示し、
上から順番に読んでいける。


ログオン後、すぐにだ。


うまいと思うのは、それがあたりまえ、自然と思わせるインターフェイスだ。
Twitterのフォローという仕組み、その意味をほとんどわかっていなくても、
単に「お友達」という意識だけで、自然と「紙のメタファーの呪縛」から抜け出せている。


これは実に面白いことで、呟きを読みあうだけの仕組みにするのはもったいない。
Twitterそのままではないけれども、これにヒントを得て、
ビジネスや教育、生活に役立つシステムを作りたいと思っている。


書捨て御免！（最近忘れていた・・・）

沈黙の飲み屋街

私が住んでいるのは、札幌の琴似という地域。
西側にあるすすきのとは別の札幌の代表的な飲み屋街です。


すすきのもここ数年の低迷が目に付きますが、
琴似はもっとはっきりとしています。


飲み屋の店主たちは口をそろえて言います。


売り上げは半分にまで落ちたと。
住人の目から見ても、明らかに人通りが少なくなりました。

琴似はJR琴似駅から市営地下鉄琴似駅までの本通に飲み屋が集中しています。
地下鉄駅よりもさらに南に向かって国道旧五号線までいったり、
一本裏に回ってもありますが、飲み屋街と言えるのは本通り沿いです。

その、本通に人が歩いていない。
金曜日の夜でも人出はまばらなのです。

かつては、金曜日の夜などに予約なしで数人の宴会をやろうとすると、
満席でない飲み屋を探すのに苦労したのですが、
今ではいつでも席が空いています。


そんな折、とある、スナックのママが言ってました。


「儲かっていたときの売り方を忘れてしまった」


私と同い年の若いママですが、
経営者に見出されて二十代半ばからママをしている人です。


彼女この言葉、実はそれでいいのではないかと思いました。


儲かっていたときと言うのは、景気のよかったとき、
実際に琴似の中で消費しきれないほどの需要があった時期です。
黙っていてもお客は入っていた。

それでいて、その需要を分け合っても、なおあまりが出ていた時期。
今はそういう時期ではありません。新しい売り方考えなければいけない。


琴似でお酒を飲む需要自体が激減した今、
「そこにある需要」を他店と取り合っても以前のような売り上げにはつながりません。

需要は新たに作らねばならない。
酒を飲まなくなったという若者をどう店に呼ぶのか、
家庭に回帰し始めたお父さん方をどう店に呼ぶのか、
そういうことを考えて、ないところに需要を作るという戦略を考える必要がある。

そのためには、むしろ、「儲かっていたときの記憶」は邪魔かもしれません。



私の場合、独立した直後は簡単に仕事にありつけていました。
メールを十件ほど書けば、半数ぐらいは返事が来て、
一件か二件は受注につながったという時期があります。

リーマンショックの影響が出始めてからは、
百件書いても返事が来ないという状況です。


そういう時は、まったく新しい土地でまったく新しい商売を始めるような気分で、
位置からでなすつもりではじめるのがいい。

そんなことを考えていました。