地方でやっていくための地産地消と手厚いサービス

地元の会社と取引がしたい。都心の会社と取引するのはいいですが、1日に8時間の勤務時間をするのに往復で3〜4時間の時間と交通費(*1)がかかります。システム開発はビジネスですがら契約する時にはそういうコストも加味して見積もりを作ります。しかし、同じシステム開発をするにしても、地元の企業からの注文なら見積もりの金額を下げられます。概算では2割の値引きはできます。近隣であることを生かせば都心の会社には真似できない手厚いフォロープランも用意できる、いや、やります。

せっかく地方で会社を始めたのだから地元の会社の仕事に目を向けていきます。大企業にはできない地元業者ならではサービスを始めます。

*1.北総公団線は料金が高いことで有名。
北総公団線

slackを導入して1週間たったので雑感をまとめる

slackが便利すぎる。もうメーリングリストで情報共有するやり方には戻れない。これは仕事にしか使わないのではもったいない。非エンジニアな居酒屋コネクションにslackを導入したらどうなるのかやってみたのでその結果をまとめておく。

メリット

  • チームに招待してしまえば人の管理がとても簡単。
  • 過去のやり取りの読み返しが簡単。
  • メッセージはメールのように内容を1つにまとめる必要がない。
  • 個人宛の連絡はダイレクトメッセージで対処できる

デメリット

  • 「了解」しか返さない人がいる。対面と違ってどこまで伝わったのか分からない。
  • メールで招待状を送ってだけでなくログインできるとこまでフォローが必要。
  • メニューが英語だと言うだけで参加を拒否る人もいる。

課題もあります。スーさん、ハマちゃんとかあだ名しかわからないのところへ、プロフィール写真が空白なので誰が誰なのか分からない。覆面してパーティーしているみたいなマッドなムードです。

今、何が怖いってインフルエンザほど怖いものはないです

今年も木枯らしの吹く時期になったので、インフルエンザ予防接種を受けてきました。注射した部分が固くコリコリして身体もだるいです。予防接種は効果がないから無駄だという方もいますが、なんせ独り法人なので私がインフルエンザにかかったとしても誰も代わりはいませんし、仕事の締め切りが伸ばせるわけじゃない。例年、冬の外出時はマスクとハンドスプレーでがっちり防備しているのですが、それでも発症する時には発症します。予防接種は発症した時でも症状が軽く済む効果もあるそうです。インフルエンザが流行せずに注射が無駄になっても、それならそれで構わない。なんせインフルエンザの辛さといったら風邪とは比べもにならない。高熱が3日も続くとかなりやつれます。あのつらさが多少でも緩和されるというのなら注射くらい喜んで受けますよ。

最近ではメガネをかけないとプログラミングや読書ができなくなりました。マスクとセットであると便利なのがメガネが曇り止め。

プログラマーが着てそうだけど、実は絶対に着ない変なTシャツ

ドリンクカップ

アマゾンで変なTシャツを見つけました。テレビドラマとや映画じゃあるまいし、こんなTシャツを着るやつはいませんよ。

これは皮肉です。例えばあるプログラムで計算結果を整数(0,1,2,3..)で出すように作ったとします。計算結果の少数の部分は切り捨てられるので検算すると答えが合いません。つまり3を2で割ると答えば1.5なのに、そのプログラムでは答えば1(少数なし)になります。それを「バグだ」と指摘された時に、計算結果は整数しか想定しないなのだからこれは「仕様通りです」となるわけです。

初めてプログラム言語を使うときに画面に”Hello World”と表示させるのは初学時の通過儀礼ではあるけど、やっているのは教科書の丸写しであって、法則や真実があるわけじゃない。そこが数式とは違う。なんとなく頭が良さそう見えるかもしれないけど、英語を話さない人たちの前で、”This is a pen.”っとやって自慢してるような気がしませんか。

Print paime numbers from 1 to 10000.
たしかにC言語のソースコードだしアルゴリズムも正しい。けどコーディングのスタイルが古い。ネットで拾ったANSI-C(C98)の頃のコードをパクっただけなんでしょう。細かいことをいうと冒頭のvoid main(){}のところが目障り。せめてはint main(){}に変更しないと今時のコンパイラーは通らないじゃないのか。これこそがC言語だとばかりにデカく「C」って書いてあるけど、そんなのは一目でわかるのだから書くことなかった。

Calculate pi one thousand decimal places.
シャツに書くコードの量じゃない。円周率を計算すると書いてあるが、ただの模様にしか見えない。これではシマムラで売ってるヘンテコ英語の服と変わらない気がする。それに数値計算するのにわざわざC言語は使わない。

COBOLが消えたらIT業界が変わるそうです

仕事部屋のドアに掛けてある「外出中」のプレートが落ちまくる。ITProにも荒れ模様の記事があったのその感想を書きます。

ITPro 2015/10/15
損保ジャパンがCOBOL一掃を決断 金融機関が変われば、IT業界も変わる

記事としては面白いですが、COBOLをやっている人たちの声が聞こえない。実際はどうなんでしょうね。
記事にはプログラミング言語をJAVAに置き換える計画だとありますが、COBOLとJAVAは考え方が違いすぎるので機械的な翻訳はできません。そもそも継ぎ接ぎだらけて誰にも解析できなくなったプログラムコードを放置したのが問題なわけで、JAVAに置き換えて道具がモダンで開発効率が良くなっても、根本的に仕事のやり方を変えないと元の木網だと思います。

システムの老朽化はどこにもある問題なので、今後どう対応していくのか気になるとですが、情報が公開されないので想像するしかありません。既存のシステムの解析にCOBOLのプログラマは必要でしょうし、JAVAの開発スキルを身につけたプログラマーはCOBOLのプログラムコードを解析する気はないでしょう。プログラマーが同じプログラミング言語をずっと使い続けていると、だんだんそのプログラム言語に合わせた考え方をするようになります。きっとCOBOLをやると”頭が腐る”と言って嫌がります。斜陽な分野をこれから極めようなんて人もいない。影響の少ないサブシステム程度の入れ替えならとっくに終わってるでしょうから、残っているのはコアな部分でしょう。時間が経つほど事態は深刻になる。実に難しい問題です。

もっとオープンにして風通しを良くすれば、解決方法も見えてくると思うんですがね。きっと秘密がいっぱいあるから、そうはいかないんでしょうけど。

追記:
ちょっとCOBOLerをキーワードに拾ってみたら面白い記事があったので貼っておきます。
@IT 2014/07【8】コボラー(COBOLER)に関する都市伝説について

プログラミング言語より業務仕様の理解のほうが圧倒的に難しいです。顧客に聞かないと機能や存在理由、使われた方、頻度とかはわかりません。下手すれば顧客もわからないものもあったります。

実装の仕様が誰もわからないのにシステムは稼働しているということですか。こう言う状況はWeb系のプロジェクトでもありますが、勘定系はトラブルの程度によってはテレビで報道されることもあるのでエンジニアの負担の桁が違います。

まさかCOBOLとPL/Iの案件がくるなんて

ある日「あなたの希望する条件にあったお仕事が見つかりました」という見出しのメールが届いた。1年前からメルマガを購読してるが、いつもスルーしてる。しかし、今回は勤務地ヨシ、稼働時間も期間もヨシ。これはと思った案件の時は直に電話してしまうに限る。メールは受信してからすでに2日が過ぎていた。今からメールしても返事がこない可能性もある。ややあったが掲載案件のことがわかる担当者に電話がつながった。

「どちらも経験者であることが条件の案件です」

どんなプロジェクトなのかと話してみて驚いた。プログラミング言語はCOBOLかPL/Iでメインフレームでの開発でした。話の途中で吹き出してしまった。COBOL?知ってるよ。学校で実習をやったよ。ソースコードにディビジョンってので分かれてさ、環境部、入力出力部、データ構造部を書いてさ、処理部にようやく制御命令が出てきてプログラムらしくなる、あのプログラミング言語でしょ。私はサラリーマン時代に「もうすぐダウンサイジング、オープソースの時代がくるからメインフレームに未来はない、すぐに撤退するべきだ」と言い続けて社内の8割を占めてたメインフレマーを敵に回してしまったという過去がある。PL/Iでしょ。知ってるよ。ピーエルワンって読むんだよ。ミニコンの開発プロジェクトの制御プログラムの開発言語で使ってた。ほとんど覚えてないがソースコードはC言語っぽい構文なのに配列の添え字にSTR[-1]みたいにマイナス値が使ってあって頭が腐りそうだった。COBOLにしてもPL/1にしても30年前の話。開発環境も言語仕様もすっかり変わっている。

千葉県の印西市でIT企業の仕事となればあのデータセンタービル絡みの募集にたどり着いたのは想定の範囲内だけども、まさか電話してみてメインフレームとかCOBOL、PL/Iの話がでたのは驚いた。

学校の授業で教科書に使っていたのコレでした。