Archive for 8月, 2014

3年ぶりに

金曜日, 8月 29th, 2014

しばです!

3年ぶりに愛車(自転車の方)の復活計画をスタートしました。
思い返せば3年前、最寄駅の駐輪場で”前輪が無い”と言うハプニングに見舞わられ「あ、東京なんだな・・・」と魔都の世知辛さを噛みしめました。
余りにも思考の斜め上を行った事態だったためか、しばらく暫く立ち尽くし、有るはずも無い前輪を頻りに探した事が昨日の様に思い出されます・・・

とりあえずレストアするために様子を見てみたのですが、これはどうもホイール交換だけでは終わらなそうな気配が・・・
やはり機械ですから、動かしていない方が痛みの進行が進む様で、チェーンやらワイヤー類やら一通りの交換が今後必要となりそうです。
今回はとりあえず走る様にするため、ホイールの交換を行いました。

前輪はそのままタイヤを組み替えて、ブレーキのロータを組み付けてはめるだけなのですが、後輪は若干厄介で、ギヤの取付をしなければなりません。
今の規格は9~10速のギヤ数が主流なのですが、私の自転車は”クラシック”なので8速の規格な訳です。なかなか8速ギヤの新品が見つからなかったのですが、流石ヤフオク様は品数が豊富で助かりました。
ちょっと調子にのって自転車用の工具も一通りそろえなおしたし、これで自転車一台一から組める状態になりました。

ホイールも組み付け、ノリノリで試走してみたのですが、フロントサスペンションから嫌な音が・・・・
これはまだ数回このシリーズが続きそうな気配がしてなりません。。

他の人のソースコードを見ること

木曜日, 8月 28th, 2014

ソースコードを解析することで、プログラミング学習が可能になるWebサービスまとめ!
http://plus.appgiga.jp/masatolan/2014/08/27/53422/

 
もしゃ@東京支社

大阪弁翻訳の巻

木曜日, 8月 28th, 2014

大阪の営業の方は、乗せ上手である。 俺の相手をしてくれているこの方は、百戦錬磨の営業の方で、持ち上げて持ち上げて、そして持ち上げて、こちらとしては気分は良いのだが、これにだまされたら大変。

 

ニュースにも登場した、一種の褒め殺しに違いない。 殺されたら大変だ。 当然、こちらが使えないと分かったら、手のひらを返されるであろう。 そういうシビアさも含めて、この方が好きなのだが。

 

持ち上げられて気分は良いのだが、評価はその1/100だと認識すれば、天狗にならず正常にお話し合いも出来るであろう。

 

「あなたしかいない。」「スーパー営業マンのもしゃさんだったら、、、」「営業も開発もスーパーがつくから」、、、。 これは結局「これやってよ」「単価高いなぁ」って吹き替えられる。

 

うちの会社にも、持ち上げられて勘違いしている人いるんじゃない? 気をつけなはれや!

 

こういう人のためにも、戸田奈津子さん!大阪の営業の方のトークの吹き替えやってヨ。 結構おもしろいんじゃない。

「すばらしいシステムでんな。 うちのこのハードとセットにしたら、鬼に金棒やで。 それにしても、ようこんなシステム開発したな。 お宅天才とちゃう?! ほんまに天才やわ!」

これは、つまり

 

「お宅のような大したことないシステムでも、うちのハードとセットにすりゃ、なんとか売れるんちゃいまっか?! このハード買わな、売れまへんでこのシステム。 うちのハードがあったから良かったけど、よくこんなシステム作りましたわ。 ある意味ビックリでんな。」

もしゃ@東京支社

「気がつく」ということ

水曜日, 8月 27th, 2014

私がこの業界に入ってから20年が過ぎましたが、当時は専門的な分野というのが
一般的だったと思いますが、昨今はPCが普及し、言語も多種多様で入手も容易
という環境下で、その気になれば比較的簡単に誰でもソフトを作る事はできる様に
なってきたと思います。
こんな事を思い出しました。

あるユーザーのところにインストール作業を行いに行った際に、一緒に行っていた
ベンダの方が、ちょっとした不便さを感じ、私にその場で修正する事ができるか
相談してきました。
その場で対応するには少し時間がかかるので、現状のままとして後日対応版を
リリースすることにさせてもらったのですが、現状をユーザーに説明した際にも
同じ事を指摘されました。

実は作っている最中に、自分でもなんとなく操作に面倒さを感じていた部分だったの
ですが、当時はどうやってシステムを標準化・汎用化するかを重点にしていたので、
そちらばかりに目がいき、ユーザー視点に立って作ってなかった事を思い知ら
されました。

PCが普及し、簡単にソフトが作れる世の中になっても、この点は変わらないと
思います。
いくら高価で機能が多くても、使ってもらえなければゴミ同然。逆にいくら安くて
機能が少なくても要件を満たして使ってもらえるものの方が評価が高い。
身近や世の中を見ると、そんなソフトありませんか?

「気がつく」かどうか、コンピュータの基礎知識なんて必要ないことろです。
私は、技術ばかりに目が行き、自己満足(エゴ)に走り、使う側の事を考えて
いなかったのです。
先に気がついて、提案できていればポイント高かったかもしれないのに
残念ですよね。

どうしても自分の考えに偏りがちになると思いますが、一歩引いて第三者的に色んな
角度から物事を見れるか、相手の立場で物を見れるか、これが気がつく事に繋がる
かどうかなんじゃないかと思います。

気づくかどうかは、人に言われる事を鵜呑みにして、そのままやっているだけでは
気づく訳がありません。また、気づくだけでは意味がありません。

そういえば昔、上司に言わた事を思い出しました。
遠慮はせんでいいけど、気は使え
当時は10代だったですし、当時は???でしたが(^^;
何が言いたいんだろうなぁ~と思える文章?だったものかもしれませんが
い~んです!
色んな事を想像して、感じて、考えてもらえれば。

社会人になって変わったこと

水曜日, 8月 20th, 2014

今年入社しましたabe-tです。この春から、頑張っています。

 

入社してから、色々なことが変わりました。

 

まず、朝起きる時間が早くなったことです。

最近では慣れてきたので目覚ましが鳴る前に起きたりするのですが、入社したての頃は、目覚ましが鳴った後、二度寝、三度寝・・・慌てて会社に行くことがありました。

車の運転時間も増えました。

片道1時間、往復2時間、1週間で10時間、1か月で200時間。できればこのまま無事故、無違反でいきたいと思っています。

体重も増えました。

入社して1か月であっという間に増えてしまいました。最近では体重を維持するためにランニングをはじめました。

 

そして、一番変わったことと言えば、「仕事」をしていることです。

入社する前にもアルバイトをしていましたが、アルバイトと仕事は全くの別物だと思いますし感じています。責任のある仕事を主体的にこなしていかなくてはいけません。(まだまだ主低的に動けていませんが・・・)

仕事では、わからないこと、大変なことが多くあります

そんな中で、わからないことが解決したり、与えられた業務を終わらせることがでると、達成感や充実感を味わうことができます。自分が努力すればするほどに達成感や充実感は大きいように感じます。

これからも、仕事に達成感、充実感を感じられるように1日1日頑張っていきたいと思います。

 

abe-t@大分本社

属人化からの脱却を目指す

火曜日, 8月 12th, 2014

 

我々の世界は、どちらかというと「腕っ節の世界」という印象があるかもしれません。この事の否定はできません。我々技術者はやはり職人ですから、個人の力を否定することはできません。だけど、そのことを前提としてプロジェクトを進めていく事は大きなリスクに繋がります。リスクとは、その人がいなくなったときに誰も分からない、という事です。

 

どうすれば個人に依存する問題を回避できるか。個人に依存しないとは、チーム(会社)として同じサービスを提供すると言うことです。

 

飲食業を例にとるとより分かりやすいかもしれません。マクドナルドに代表するファストサービスやファミレスなどは、どのような方法で一定のサービスを提供しているのか?それは一定のサービスが提供できるようなマニュアルがあるということです。

 

マニュアル主義などというと、世の中ではあまり良い言葉として表現されていません。しかしマニュアルがすべてではなく、マニュアルの本質は「ミス」を無くす(減らす)ことなのです。
つまり、マニュアル通りにおこなうことが最終目標ではなく、マニュアルに何かしらのエッセンスを付加してその人なりのサービスができるようになることを最終目標とするということです。

 

マニュアル化というと、我々の世界では、誰が作っても同じプログラム・ドキュメントができる、と言うことですね。でもそれが難しいことも理解できますし、誰が作っても同じものができるなら、もしかしてプログラマはいらず、機械が自動的にプログラムを作ってしまう事ができる、と同意だと思いますから。

 

さて話を戻して「同じサービスを提供する」ということ。
チーム(会社)として、ある一定の品質を担保できない、ということがエンジニア個人に依存して、そのリスクを回避できない、ということです。お客さんからの電話に「前の担当者が退職したから分かりません」など最悪です。

 

人に依存する部分は否定しませんが、このリスクを回避するために何かしら対応しなければサービスを売っている会社として恥ずかしいです。
同じ物はできなくても、同じ思想で作ることを目指したいですね。

 

同じ思想で作ることを目指す、といいました。では同じ思想とは何でしょうか?思想なんて仰々しい事をいってますが、「同じサービスを提供する」ことを具体化していき、その具体的な項目・内容に準じて開発することではないでしょうか。同じ思想の具体化は、つまり標準化に他なりません。ただ標準化すれば、すべて収まると言っているわけで無く、飲食業の例で説明したように、あくまでミスを減らし一定のサービスを提供できることが標準化であり、それぞれの開発者が標準化のライン上で、どうエッセンスを付加することができるかが重要であることは言わずもがなです。そのエッセンスが「さすがAさん!」と言われることなのです。

 

この標準化という方向を皆が考え、進んでいきたいと考えています。それが属人化からの脱却に繋がると信じています。

一つの例ですが、

 

1、技術
言語やフレームワークを統一化することで新しい技術だからわかんない、というリスクを排除します。統一した技術のノウハウの共有化をおこなって、効率もあがることも期待できますしね。
それとは別に新しい技術などは、会社をもっと大きくし、新しいことが好きなスタッフが増えたら、社内オフ会(勉強会)などで盛り上がりたいですね。

 

2、コーディングスタイル
エントリー系のコーディングスタイル標準、印刷系のコーディングスタイル標準を考えていきます。
エントリー系であれば、項目名とかテーブルのカラム名とかを記述した定義ファイルがあれば、ソースのひな形ができる事が理想です。こう考えるとマスターメンテなんてコーディングしたくはないですね。それこそ自動化、自動化、自動化を目指しましょうよ。
帳票の場合は、連票・1ページ毎に集計がある帳票・ページの中間に小計などがある帳票などでロジックの標準を決めます。結局はループをどう使うか、どこでデータを読み、集計するかが標準化されていれば、見やすいソースになるのではないでしょうか?!コーディングスタイルと言っても変数の命名規約などではなく、モジュール構成や制御分の使うタイミング等に重きを置きます。
エントリー系で言えば、エントリー項目が追加になったときなど、どこのモジュールを見れば良いかを重視します。どこに何が書かれているか、一発で分かるようなソースが理想ですよね。

またSQLについても、すべてSQLで集計できても保守性が悪くなるようならば、SQL+プログラムで作るようにします。保守性が悪くなるかどうかの判断が難しいのですが。

 

3、ドキュメント
ドキュメントと言っても、用途として大きく2種類ありますよね。それは、作るためのドキュメントと残すためのドキュメント。

残すドキュメントを詳細設計のレベルにすると、逆に保守性を悪くします。ドキュメントは、メンテナンスされていなければ結局ソースを見ることになりますし。

ドキュメントは、システムのイメージが分かるレベルで統一します。
システムを構成するプロダクト、機能、コマンドの一覧。ある修正でどこが影響するかをチェックするときなどに使えますし、システムのすべてはこれです、と言えるドキュメントになっていることが重要です。
以前、システムのすべてって何?どんなサブシステムで構成されているの?って確認したところ、担当者が知らなかったり、そういう資料が無かったりしたことがあります。それって最悪ですよね。

次は、業務というキーワードです。なぜこうなっているのかが分かる資料が必要です。ソースをみて処理は分かりますが、なぜその処理になったのか、必要なのか等、その理由は分かりません。それを補う資料が必要です。

業務フロー、データ関連図、プログラムの関連図などの資料も必要です。それぞれの関連ってソース見ただけじゃ分かりませんものね。

このシステムが構成されているのすべてって何とシステムの概念が分かれば残す資料としては十分だと考えます。

データベース定義は、リバースエンジニアリングでドキュメント作れば良いし、プログラム仕様はヘッダに記されているはずですし。

必要最低限のドキュメントを目指します。
まさにアジャイルでしょう、プログラマ諸君。

 

4、テスト項目
エントリー画面や帳票のテスト項目は標準化できるはずです。
エントリーの画面や帳票などは、コントロール数や印刷項目数に対して項目数が計算できます。これに3で記した業務というかビジネスロジックのテストが加わります。
体系的・定量的に考えていけば、ある一定のテスト項目や項目数の標準化は可能です。

 

5、レビュー
コードレビュー、ドキュメントレビューは必ずおこないます。
社内のスタッフの中でも、一番大事だといっているスタッフもいます。

コードやドキュメントが最低限、標準にあったものであるか、チームとして確認していきます。チームとして確認し、作った人しか分からない、を脱却します。レビューした人たちは、俺が作ったんじゃないから知らないとは言わせませんよ。

などなど。

 

こういう標準化を考えることで人に依存する部分が減ってくると思います。頭を悩ますのではビジネスロジックやプログラマが一番苦手なレイアウトだけにしたいですね。

 

もしゃ@東京支社

もしかして都市伝説?

月曜日, 8月 4th, 2014

はじめてなんです。
スタッフブログへの投稿って。

以前、こんな噂を聞いたことがあります。

昔々ある所に、競馬が好きなおじいさんとおばあさんがいました。
ある日突然、メールが送られてきて、「次のレースでは、1番の馬が勝つ」と書かれていました。
おじいさんとおばあさんは、迷惑メールと無視しました。
おしまい。
・・・
・・



じゃなくて、
半信半疑でしたが、とりあえず、メールに従い、1番の馬を買いました。
そしたら、なんと、1番の馬が勝ちました。
翌週、また、メールが届いて、「次のレースでは、5番の馬が勝つ」と書かれていて、
5番の馬を買うと、5番の馬が勝ちました。
翌々週も、その翌週も同じようにメールが届いて、メールに書かれてある馬を買うと、
その馬が勝ちました。そして、その年は一度も負けなかったそうだ。

このようなことが現実にありえるのでしょうか?
皆さんのコメントをお待ちしています。

私はあるといいなって思います。っていうか、現実にありえます。
なぜなら・・・
この続きは、皆様方からのコメントが多ければ、書きたいと思います。
 
 

F513@大分本社