Archive for the ‘mosha’ Category

大阪弁翻訳の巻

木曜日, 8月 28th, 2014

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

 

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

 

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

 

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

 

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

 

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

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

これは、つまり

 

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

もしゃ@東京支社

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

火曜日, 8月 12th, 2014

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

一つの例ですが、

 

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

 

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

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

 

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

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

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

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

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

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

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

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

 

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

 

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

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

などなど。

 

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

 

もしゃ@東京支社

当社ブログ開設にあたって

火曜日, 7月 8th, 2014

 

1985年、ひとつの卵からシステムエイジは生まれた。

早いもので今年の10月で会社設立から29年がたつ。私が入社してから25年、月日が経つのは早いものだ。開発スタッフの平均年齢が29歳ということを考えると改めてビックリしてしまう。

設立当時から大分本社にてスタッフ持ち回りで、日々の仕事で気づいたこと、プライベートなことなどをテーマにスピーチをおこなっていたのだが、東京支社の開設で社員が異動になったりとか開発現場に常駐するスタッフが増えたりとかで、大分本社スタッフが少なくなったことも影響し、昨年ストップしてしまった。

このブログであるがスピーチの代わりという意味で、各スタッフの発信の場、等身大の会社や社員の姿が表現できればと開設した。堅ぐるしい感じにならず、ざっくばらんに情報発信できればと思う。

 

堅ぐるしい感じにならず、、といったそばから堅ぐるしくなってしまった。次回からは緩い感じで発信だ!

もしゃ@東京支社