2012年4月22日日曜日

@IT自分戦略研究所エンジニアライフ

またまた、再開後、更新がストップしてしまいましたが、やはり、もう少しがんばろうと心を入れ替えました。
まあ、血液でさえも、4ヶ月もあれば新陳代謝で入れ替わるといわれていますので、いくらでも、心の入れ替えは可能ですけど・・・

そこで、@IT自分戦略研究所エンジニアライフ に記事を投稿することにしました。
タイトルは、「SEの格言・迷言・ことわざ集」です。

とりあえず、毎週土曜日に投稿することを自分自身に課すことにし、長期連載を狙います。
# 将来は、単行本化か?

で、それに伴い、自分のホームグラウンドが必要になってきましたので、こちらのブログも再開しようと思いました。

ただし、こちらは、不定期のままです。

そんなに、ネタがあるはずもありませんし、あちら側は、毎週書くことにしたので、優先順位はあちらが上です。
ただし、あちらが、表の顔だとすると、裏の顔が、こちらになると考えています。

まあ、心配するほど、読者が付くとも思えませんが、こちらは、何でもありなので、自由に書かせていただくつもりです。

それなりに、お楽しみに!


2011年10月9日日曜日

投資と消費

openGion は、社内システムの開発のためのフレームワークとして生まれたのですが、やはり、一般的な請負開発とは、根本が違うような気がします。

まず、社内開発の場合、顧客=親会社、または、関連会社ということもあり、要求そのものは、比較的「なあなあ」なところがあります。
つまり、要件定義を行って開発は始めるのですが、途中でも後からでも、追加要求が来ます。契約とか、約束というものは、あまり通じません。当然、完全に追加仕様などは、料金を上乗せしますが、同じグループ内会社のことですから、経営から見ると、右のポケットのお金を左に移すだけなので、本当に必要・効果がある要求なら、対応するのが当たり前という考えです。

逆に、システムの出来が悪くて使えない場合、裁判で賠償金を請求することもありません。やはり、やり直しになります。やり直し費用を自腹で持っても、今度は左のポケットのお金が出て行く(といっても社員の給料にですが)だけですけど。

よって、お互い、(発注側も受注側も)妥協と要求を繰り返しつつ、ベストな着地点を目指します。これはこれで、案外良いと思っています。

問題は、その要求が、現場サイドから上がってくる場合(というか、ほとんどがそうですけど)最初の方針や要件と離れていることがままあります。
なぜなら、方針や要件は、経営側の要求であり、改善要求は、現場からの要求なので、種類が異なっています。

判りやすく言うと、経営側は、システムに、「投資」しているので、目的は「回収」です。ところが現場は、「消費」の観点から要求してくるので、趣味の色合いが濃くなります。

例えば、使い勝手の向上が要求の場合、「投資」であれば、その機能の開発にいくらかかり、それによって、何時間の時間短縮ができるので、何年で元が取り戻せるか、が基準です。担当者1名が年2回のたな卸しで、1回、8時間の時間短縮ができるとして、5年で、80時間=0.5人月の工数削減になりますが、それを、1人月かけて開発するか、という計算が行われます。
経営判断では、NO ですが、担当者から見ると、毎回毎回、邪魔くさい作業をさせられていると考えていますので、改善してもらいたいところです。

こういうケースで話し合いになると、結局、対応することになります。

経営判断的にはNGでも、社内システムという観点では、まあ、やってあげてよ、という感じになります。

※ 経営側としては、その担当者がシステム化で空いた時間を有効活用し、もっと建設的な仕事をするという理論で、「投資」しているという判断です。それが本当なら、良いのですけど・・・・

2011年10月3日月曜日

シンプル・イズ・ベスト

まあ、システム開発においては、常にいわれる言葉だと思います。
ペーパーレスと同じくらいに・・・(^^)

ちなみに、ペーパーレスといわれるようになってから、プリンタの性能も向上し、ツールの利便性も向上したため、逆に、印刷枚数は、増えているという意見もあります。
同じように、シンプルに、といわれていますが、要求される仕様は、ますます複雑になってきていると思います。

前に、「TOCとJIT」でも述べたように、今必要な機能だけを実装する、という考え方も、シンプル・イズ・ベスト につながってきます。

システムは、単純にしておく。さらに、使っていない機能ならば、削除してしまう事も時には必要だと思います。

openGion においても、最初は実装したが、後に不要になったり、使われないと思われる機能は、削除していっています。
(Ver4まで、です。Ver5=正式な、openGionになってからは、簡単に削除できなくなりました。)

さて、このシンプルに保つというのは、結構難しいことです。
私自身がそうですが、あまり考えなくて、実装しているときは、難しいコーディングや複雑なロジックを駆使して対応しているケースが多いです。頭でイメージしてさくさくっと書いているように見えて、実はあまり頭を使っていないということです。
ところが、同じ機能を実現するのに、しっかり考えて、将来的な拡張性を視野に入れつつ、今は使わない状態にするコーディングは、じっくりと考えないと実現できません。しかも、じっくり考えているのですが、ストレートなのです。ここが、重要です。

じっくり考えて、アクロバット的なコーディングや、短いが、判りにくいコーディングにしてしまうと、後でメンテナンスができなくなります。(追加機能の要望があっても、対処できないということです。)

要求仕様にストレートで、かつ、単純で、しかも、じっくりと考えて作られている様なコーディングを、シンプル・イズ・ベスト なコーディングと呼んでいます。

※ 要求仕様にストレート・・・という表現が誤解を招くかもしれませんが、この場合は、要求仕様をストレートなものにしている、といったほうが良いかもしれません。その話は、また、今度ということで。

2011年9月25日日曜日

SEは、3手先を読む

SEでなくても、3手先を読むのは良いことです。
3手というのは、比喩なので、きっちり3手読む必要はありません。 (^^)

要するに、常に先を読んで、リスクを最小限に止めておく努力を欠かさないことが重要です。

プロジェクトを進めるにあたり、何らかの問題が発生することはある程度覚悟が必要です。それに対処できる準備をしておくことで、何か発生したときに、冷静に対処できます。

ここで、注意しなければならないのは、リスクと障害は分けて考える必要があるということです。
リスクとは、簡単にいうと、まだ、発生していない障害、といえます。そうなると、障害とはまさに、今まさに発生している事象といえます。

障害は当然、全力でつぶす必要があります。ただし、優先順位を決めて、場合によっては、つぶすのではなく、回避することも選択肢もひとつです。

リスクは、まだ、発生していないので、対処する必要はありません。というと誤解されそうですが、障害として発生した場合に、何らかの手が打てる状態にしておく、または、速やかにその状態が作れる状態にしておくことが大切です。
判りにくいかもしれませんが、リスクに対しては、費用対効果を重要視すべき、ということが言いたいだけです。

例えば、プロジェクトメンバーが、5人いる場合、リスクとして、メンバーの誰かが急病や怪我などでチームを離れるケースが考えられます。これは、リスクです。その場合、最初から、メンバーを6名にしておくのか、一人が抜けても大丈夫な納期を設定しておくのか、欠員が出てもメンバー内で対処できるように、メンバー間で情報共有を欠かさないようにしておくのか、色々なリスク回避方法が考えられますが、まだ、起こりもしていない障害なので、できるだけ費用はかけない方法をとる必要があります。当然、発生した場合に、プロジェクトが破綻してしまうと、リスク管理にならないので、ここが腕の見せ所にもなります。

また、リスクをつぶす場合、発生確率は重要ですが、本当に重要なのは、そのリスクが現実になったときに、プロジェクトが破綻する場合、やはり優先的に避けておくべきです。

そのあたりのさじ加減は、可能な限りのリスクを見極め、将来的に発生しそうな真の障害を避け、プロジェクトが何事もなく、完成させるためには、非常に重要な能力になってきます。

3手先を読むとは、その裏に、膨大な読みが必要になるということです。

2011年9月18日日曜日

TOCとJIT

オープンジーオンとは、何か? を語る上で、判りやすい例と思われるのが、「TOCJIT」です。

TOCとは、theory of constraints(制約条件の理論)というもので、『ザ・ゴール』という小説で有名ですが、ここでは、手法を述べているのではなく、何をしたいのか、という所に注目してください。 私の中では、「スループットを短縮すると、イノベーションを起こせる」と読み替えて解釈しています。 

そして、JIT(just-in-time)とは、トヨタ生産方式の一つの柱である「必要なものを、必要なときに、必要な数量だけ」調達・生産するという考え方です。ソフトウエアの世界では、XP(Extreme Programming)やアジャイルソフトウェア開発でのジャストインタイムの方が有名かもしれませんね。

オープンジーオンが目指しているのは、「開発のスループットを短縮してイノベーションを起こす」ことと、「必要な機能は必要になってから作る」という所です。 

開発で言うと、お客様に対して、ヒアリングを行い、システムの要件定義をまとめていきます。通常、何度か繰り返して、プレゼンして、各社(数社)で見積もり、開発納期などを出し合い、色々な条件(当然、付き合いやすさや雰囲気も大きな要因です)を考慮して受注ということになります。それから開発・・・ですが、オープンジーオンで実現したいのは、最初のヒアリングである程度のシステム要件を聞きだした後、2回目のプレゼンや提案時に、実際にシステムを動かしてみせる、という事です。 そう、受注の直前では、殆どシステムが出来上がっている状態です。当然、受注できれば、費用は言い値ですから、他社に負けることはありませんし、失注しても、営業費用の範囲で落とすという考えです。 

上であげた例はパッケージ販売では通常の手法です(すでに出来ているのですから)。ただし、カスタマイズ設計の場合は、ありえません。しかし、カスタマイズ開発が、ものすごく効率的であれば、殆ど営業がプレゼン資料を作成するのと同じ程度の工数で実現できれば、受注率があがれば十分実現できると考えています。
さらに、要件を聞きながら、今必要なのか、必須機能なのか、便利機能なのかを判断し、プレゼン時にはあくまで基本のみにしておくことで、初期投資を抑え、拡張性を持たせることで、予算に対して、必要な機能から順番に実装していくという事も可能です。 

実際、我々もそのようなことは出来ていませんが、目指している方向は、そういうところにあります。

特に、Do IT(情報技術) Yourself の世界では、自社システムを自社開発するので、上記の考え方はさらに強力に働くはずです。システムが必要になればすぐに作ればよいし、そうやって作ったシステムなら、成果がでなければ、捨てればよい。

そういうツールを目指しています。

2011年9月12日月曜日

Do IT(情報技術) Yourself

おっとあぶない。
ブログ再開を宣言して、いきなり、無期限の閉鎖になるところでした。
土日に書くはずが、今日は無理から書いています。

例のブログ投稿における、タイトルを決めました。

『Do IT(情報技術) Yourself』

どうでしょうか?

it のそれ が IT:情報技術 と掛けている・・って、ちょっと単純すぎ?

まあ、いいか。本人が気に入ったんだから。

openGion というフレームワークは、社内システムに向いています。つまり、自社のシステムは、自社で開発しましょうという DIY のコンセプトにマッチしています。

まあ、生い立ちがそこから来ているので、当然といえば当然か?

このコンセプトに沿って、色々とopenGionの良いところ,足りないところをつらつら書いていければと思います。

2011年9月4日日曜日

ブログを再開します

2009年の年末から、更新が途絶えていましたこのブログを再開しようと思います。

きっかけは、「@IT自分戦略研究所エンジニアライフ」に投稿したい! という事で、いきなり連載というのは多分無理だと考え(このあたりは、結構真摯に自分を見ている?)まずは、ここをきちんとまわす事をやってみようと思い立ったというわけです。

今までは、技術ねたを主に考えていたのですが、もう少し範囲を広げて、何でもありにしようかと思っています。

さて、どうやってまわすか? と考えたとき、自由に、気ままに・・・すると、1年以上もほったらかしになるのは、実証済み(^^)" なので、定期連載にしようと思います。
つまり、毎週土曜か日曜に、必ず投稿する! という「ルール」でまわす、という事で始めてみようと思います。

どこまで続くか判りませんが、まあ、気楽にやってみたいと思います。