2006年08月09日

キーワード SAP

Posted by taka1350041 at 12:24Comments(0)TrackBack(0)

test2

  
Posted by taka1350041 at 00:35Comments(0)TrackBack(0)

2006年07月05日

IT業界の問題点

久しぶりの書き込みにあたり、IT業界について私が考えていることを書きたいと思います。
(ここで言うIT業界とは、企業向けの情報システムを提供している業界に限定します)

まずは働く側にとってのIT業界です。IT業界は、現在、花形産業のひとつのように思われているかもしれませんが、現実は、むしろ、3K労働と言ってもいいくらい過酷な労働環境だと思います。本稼動前後や納期前の徹夜作業や休日出勤はよくあることですし、深夜残業はほとんど当たり前のようになっています。また、中国やインドのIT業界への進出が著しく給与面でも恵まれていない面が強いかと思います。

私の周りでも体調を壊した人を何人もみてきました。私自身が、今まで健康で仕事を続けられたのはとても運がよかったと思っています。

一方、ITを使っているユーザ企業側では、IT業界に対する不信感が強まっている感じがします。根拠が曖昧な見積もり、度重なる納期の遅延、本稼動後の不具合の連続、など。また、次々と新しいコンセプトが登場しますが、本当にそれが企業経営に役に立つのかと言う疑問も益々強まっている感があります。

これらの問題の責任は、特定の組織・人間に起因するのではなく、ITに関わるすべての人が問題意識を持って取り組まなくてはならない課題です。また、何か特別な特効薬があるわけでもなく、正しいと思われることを少しずつ積み重ねていかなくてはならないことだと考えます。

企業経営におけるITの重要度を考えると、現状は非常に危険な状態ではないかと感じています。また、このような状況が続いた場合、IT業界で仕事をしたいと考える人が減り、優秀な人が流出してしまうのではないかと危惧もしています。

本来、ITは企業経営に貢献する重要なツールですし、IT業界の仕事は非常にやりがいがあり楽しいもののはずです。その本来の姿を取り戻すことが急務ではないかと私は思います。そして、私なりにそれに貢献できる方法を考えていきたいと思います。
  
Posted by taka1350041 at 03:09Comments(0)TrackBack(0)プロジェクト管理

2006年03月28日

人間の3タイプ NLP理論から 2

NLPの理論では、人を
 視覚タイプ
 聴覚タイプ
 体感覚タイプ
に分類しています。

簡単言うと、
 ・視覚タイプは絵・画像でモノをイメージする人
 ・聴覚タイプは文字・言葉でモノを捉える人
 ・体感覚タイプは肌触りなど身体の感覚でモノを捉える人
と考えればいいかと思います。

前回はコミュニケーションでの応用を書きましたが、
今日はドキュメント作成について書きます。

仕様書などのドキュメント作成についても、この3タイプを
意識すると関係者の多くに理解してもらいやすいドキュメント
にすることができます。

・視覚タイプは、フロー図などの図による説明が
 理解してもらいやすいでしょう
・聴覚タイプは、箇条書きにコンパクトな文章にまとめた方が
 理解してもらいやすいでしょう
・体感覚タイプは、ちょっと難しいですが、仕様書の場合は
 現場で実際に利用するイメージがわきやすい文章や図を
 使用するとよいかもしれません。またはプロトタイプを
 行うのもいいでしょう

私は聴覚タイプなので、フロー図なんかより、文章で書いて
くれた方が分かりやすく感じます。

しかし、この3タイプを考えると、ひとつの仕様に対しても
フロー図、箇条書きの説明、プロトタイプと別々の手段で
表現をした方が関係者に理解してもらいやすくなると言えます。

どうしても自分のタイプのあわせたドキュメントを作りがち
なので、自分がどのタイプが把握した上で、例えば、
聴覚タイプの方は、恐らく文章が多くなりがちだと思うので、
適当に図を加えるなどの工夫をするとよりよいドキュメント
になるでしょう。  
Posted by taka1350041 at 01:02Comments(2)TrackBack(0)技術

2006年03月27日

人間の3タイプ NLP理論から 1

NLPと言う最新の心理学的なモデルがあります。
日本語では神経言語プログラムと訳されます。

アメリカでは、普及しているようですが、
日本でも最近、関連書籍が増えて注目を
集めるようになってきています。

さて、このNLPの理論で人を「代表システム」
という3タイプに分けています。

代表システムは、
 視覚タイプ
 聴覚タイプ
 対感覚タイプ
  (体感覚とは、味覚・嗅覚・触覚)
に分かれて、人がモノを見たり、考えたりするとき
に以上のどれを主に使っているかで分類することが
できます。

各代表タイプには次のような特徴があり、これらの
情報からどのタイプかが判断できます。

視覚タイプ
 ・「見る」「見える」「眺める」と言う言葉をよく使う
 ・表現がカラフル、絵を見るように話す
聴覚タイプ
 ・「聞こえる」「考える」「理解する」をよく使う
 ・論理的
体感覚タイプ
 ・「感じる」「話の趣旨をつかむ」「とらえる」と
 言う感覚的な言葉を使う

以上を参考にすると、だいたい、自分がどのタイプ、
他の人はどのタイプがイメージできるかと思います。

この3タイプを知っているとプロジェクト中の
コミュニケーションやドキュメント作りなどに応用
することができます。

プロジェクトリーダーが聴覚タイプだったとします。
聴覚タイプは論理的で、文字で考えているため、
一般的に頭の回転が速い人が多いです。
一方、視覚タイプは、イメージしたものを文字を
変換してから話すため説明に時間が掛かったりします。
体感覚タイプは、更に時間が掛かったり、説明が
できなかったりします。

プロジェクトリーダーが聴覚タイプで、開発メンバーが
視覚タイプや体感覚タイプだと、リーダーが
「作業が遅い」
「説明が分かりにくい」
「話が非論理的だ」
などと感じて、軋轢が生まれる可能性があります。

私は典型的な聴覚タイプなのですが、以前、体感覚タイプ
の開発者と一緒に仕事をしたことがあります。

この開発者は、問題箇所を「〜感じがする」「〜気がする」
と言う曖昧な表現をよく使います。しかし、コンピュータの
は基本的に論理的な世界なので、私は、もっと、論理的に
説明することを要求します。

ところが、この開発者はどうしてもうまく説明ができないのです。

しかし、この開発者の言ったことを無視して、進めると
実は彼が言っていたことが正しかったのです。

NLPの理論を知って、彼が体感覚タイプと分かってから、
ゆっくりと時間を掛けて、彼とはコミュニケーションを
取るように改めました。そうすると、私が気がついていないような
問題がはっきりしてきて、ずいぶん、彼には助けてもらいました。

この理論だけですべての問題が解決できるわけではありませんが、
知っていると無用のトラブルを避けることができるのではと
思います。  
Posted by taka1350041 at 02:59Comments(3)TrackBack(0)プロジェクト管理

2006年03月20日

アドオンプログラムの品質

アドオンプログラムの品質はとても重要なことは
当たり前のことですが、「品質」の定義は意外と
難しいのではないかと思います。

Capers Jonesのソフトウェア品質のガイドライン
(アマゾンへのリンクは最後にあります)を参考に
品質の定義について考えてみます。

1)導入時の低欠陥、ほとんどゼロに近い欠陥
 ※ これは品質を考えたときに最初に浮かぶ
 定義です。ようはバグがないということです。

2)高い信頼性、異常結果を発生することなく
  運用可能な能力
 ※ これはバグがないと言うだけでなく、
 エラー発生時の処理が設計されている、
 ショートダンプ(異常終了)を回避する設計が
 されていなくてはならないことを指しています。

3)高い顧客満足度
 ※ 例えバグがなくてもお客の要件を満たして
 いなければ品質が高いプログラムとは言えません。

4)「誤修正」を最小化にする構造
 ※ 誤修正とは、プログラム修正時に別の新しい
 欠陥を生じさせてしまうことです。
 これを避けるためには、しっかりしたモジュール
 設計などが必要です。

5)欠陥、特に重度の欠陥に対する迅速な修復
 ※ 万が一、欠陥が生じた際に修正が容易かどうか
 と言うことです。いわゆる、スパゲッティ構造の
 プログラムでは問題の原因を特定し、修正するの
 に多くの時間が掛かってしまいます。

1)2)あたりは考慮に入れているかと思いますが
3)4)5)は意外と忘れがちな面かもしれません。



  
Posted by taka1350041 at 22:56Comments(0)TrackBack(0)品質

2006年03月18日

仕様変更管理 2 ルール・回帰テスト

仕様変更管理のその他の注意点について書きます。

・プログラムの修正ルール
 仕様変更でプログラムを修正する場合、
 コメント行を入れますが、この書式を
 あらかじめルール化しておいた方が
 よいでしょう。
 
 書式は1行目に日付・修正者名
 2行目に修正内容などでよいですが、
 日付の書式もYYYY/MM/DDのように決めて
 おいた方がよいと思います。

 このような細かいことにこだわらなくても
 よいと言うご意見もあるかもしれませんが、
 保守をする際に日付の書式を統一しておくと、
 例えば、2年前の2月に実施した仕様変更の
 修正箇所を探す際にエディタの検索で探すことが
 できます。

・回帰テスト
 仕様変更を実施した後のテストは、仕様変更の
 内容が確実に動作するかのテストだけではなく、
 その修正の影響で今まで正しく動作していた箇所に
 影響が出ていないか再テスト(回帰テスト)をする
 必要があります。

 厳密にはプログラムAに対して仕様変更をした場合、
 プログラムAに対するすべてのテストをやり直すことに
 なりますが、現実には難しいですし、無駄なテストも
 あるので、どの範囲を再テストするのかあらかじめ
 決めた上で再テストをすればいいと思います。

 しかし、プロジェクトが非常に忙しい時、あるいは
 保守で違う開発者が修正する場合などは、思わぬ
 影響が出たりするので、できる限り回帰テストは
 広範囲で実施した方が安全です。  
Posted by taka1350041 at 23:04Comments(1)TrackBack(0)プロジェクト管理

実行時間分析を使ったuserexitの検索

e38f417d.bmpuserexitの検索は普通、SAP完全版IMG(トランザクションコードSPRO)
から探すことが多いと思います。

私はABAPプログラマだったので、IMGを使うより実行時間分析など
を使ってuserexitを探していました。

検索方法

1 実行時間分析(SE30)を起動
2 トランザクションにuserexitを探したいトランザクション
  コード(例えば、受注伝票登録であればVA01を入力)
3 実行ボタンを押して、実際に伝票を登録
4 分析ボタンを押して、該当対象一覧ボタンで実行された
  サブルーチン、汎用モジュールの一覧を表示
5 検索ボタンでuserexitと入力して検索
  (図を参照)

これで、userexitを探すことができます。更にそのuserexit
で要件を満たすコーディングができるかは、そのuserexitに
ブレイクポイントを設定してデバックモードで参照できる
変数などをチェックしていけば分かります。

IMGの方では、説明どおりにuserexitが使えなかったり、IMG
に記述がないuserexitがあったりするので、この方法も一つ
の手だと思います。

他にいい方法があれば、是非、コメントください。

人気ブログランキングに参加しています。この記事がお役に
たちましたら、是非、ここ
をクリックしてください。


  
Posted by taka1350041 at 00:18Comments(0)TrackBack(0)技術

2006年03月16日

仕様変更管理 2 プロセス

仕様変更管理のプロセスは次の3点に
注意すればいいでしょう。

1 仕様変更実施前にレビューをする
 ・一部の関係者だけの合意で仕様変更を実施すると
 後から、そのようなことは聞いていないとクレームが
 きたり、最悪、その仕様変更、そのものが勘違い
 だったり、不要なものだったりします。
 ・そのような事態を避けるためにも仕様変更実施前に
 関係者によるレビューが不可欠です。
 ・関係者としては、
   プロジェクト・マネージャー
   仕様書を作成したコンサルタント・SE
   設計をしたSE・プログラマ
   プログラマ
   テスト作業者
   ユーザ
  のうち、必要と思われるメンバーに確認をします。

2 完了確認をする
 ・仕様変更が確実に完了したかを管理する必要があります。
 ・完了確認の項目は、
   −仕様変更に関係するテスト
   −ドキュメントの修正
  があります。
 ・必要に応じて、ソースコード、ドキュメントの
 レビュー(インスペクション)も実施します。

3 ドキュメントで管理する
 ・仕様変更管理のプロセスについて、後工程から参画
 するメンバーもいるので、ドキュメント化して、いつでも
 参照できるようにします。
 ・また、1・2の作業も一覧表で管理して、仕様変更残や
 各仕様変更のステータスが管理できるようにします。  
Posted by taka1350041 at 13:40Comments(0)TrackBack(0)プロジェクト管理

仕様変更管理 1

仕様変更が発生しないための工夫を積み重ねても
仕様変更が発生してしまう場合があります。

仕様変更による悪影響には、
 −プログラム品質の低下
 −作業工数の増加による
   スケジュール遅延・予算オーバー
などがありますが、これらが発生しないような
対策が求められます。

そのためには仕様変更発生時の管理手順をあらかじめ
決めておく必要があります。

仕様変更が発生するのはテストフェーズなど納期・
本稼動が近い切羽詰った時期が多いです。
そのようなときに仕様変更管理の方法を考えたり、
議論する余裕はありません。
よって、仕様変更管理はプロジェクト前、あるいは
できるだけ早いフェーズで決めておく必要があります。

仕様変更管理には、
 ・仕様変更実施のプロセス・ルール
 ・管理に使用するドキュメント
を決める必要があります。

これらも形式的にならないように必要最小限に
絞り込んだ方がよいでしょう。  
Posted by taka1350041 at 13:24Comments(0)TrackBack(0)プロジェクト管理

2006年03月15日

仕様変更をなくす 4 課題管理表

要件定義時には、
 ・ユーザから出た質問・課題
逆に、
 ・仕様書を作成する側からユーザへの質問・課題
が、かなり、たくさん出ます。

これらをドキュメント化して管理しておかないと
未決の課題が残ったり、どのような解決案で合意
したかが後から分からなくなったりします。

対策としては、エクセルで課題管理表(Q&A一覧)を
作成して管理する方法が今までの経験では一番
有効でした。

エクセル表には、
 課題のタイトル
 課題の内容
 課題の発生日
 課題を出した人
 解決の責任者
 ステータス(未決、完了、など)
 決定事項
 解決日
などを入れるといいと思います。
漏れなく管理することが重要なので、できるだけ
シンプルな表にします。
また、管理表はプログラム単位、あるいは、小規模な
プロジェクトではプロジェクトでひとつでも構いません。

このような管理表は、どのプロジェクトでもあるとは
思いますが、形式的なものになってしまったり軽視される
ことが多いように思います。

しかし、エクセル表にすると議事録などよりも管理しやすく、
また、エクセルのフィルタ機能を使えば、残課題もすぐ
分かるので、簡単に実行できて効果が高い方法です。

私が以前、担当したプロジェクトでは、このQ&A表が非常に
役に立つと言うことで、納品物に含めて欲しいとクライアント
から依頼されたこともあります。

仕様変更をなくすには、このような小さな工夫の積み重ねが
重要だと思います。  
Posted by taka1350041 at 21:55Comments(0)TrackBack(0)プロジェクト管理

仕様変更をなくす 3

要件定義のフェーズで有効な方法論のひとつとして
プロトタイプがあります。

アドオン開発でも画面(Dynpro)を作成して
標準機能をコールトランザクションなどで呼び出す、
いわゆる、カバーディンプロと呼ばれるアドオン開発
では、有効な方法です。

しかし、特にR/3のアドオンのように基幹系システムの
場合、画面の仕様よりもビジネスの仕様を正確に把握
することがより重要なことが多いため、プロトタイプに
頼り過ぎないように注意が必要です。

アドオン開発時のプロトタイプのポイントを3つ書きます。

1 時間をかけすぎない
 ・プロトタイプをするとユーザから色々な要件が出てきて
 しまい、予想以上に期間が掛かってしまうことがあります。
 ・そうなると、詳細設計以降のスケジュールにも影響
 しますし、プロトタイプの工数も膨れてしまいます。
 ・そのようにならないように、期限をしっかり、決めて
 プロトタイプをする必要があります。

2 技術的難易度に注意
 ・SAP GUIの画面でもウェブの画面でも技術的に限界が
 あります。(技術的に不可能な場合と工数的に困難な
 場合)
 ・プロトタイプで顧客の要求を何でも受け入れてしまうと
 開発不可能な仕様書ができあがる可能性もあります。
 ・それを避けるためには、可能であれば、技術者に
 参加してもらう、あるいは、レビューをしてもらう
 必要があります。

3 プロトタイプは万能ではない
 ・最初に触れましたが、プロトタイプを作っても
 すべての要件を抽出できるわけではありません。
 ・ビジネス上の細かな要件はプロトタイプとは
 違うアプローチが必要です。プロトタイプに依存
 しすぎないように注意しなくてはなりません。  
Posted by taka1350041 at 00:19Comments(0)TrackBack(0)プロジェクト管理

2006年03月13日

仕様変更をなくす 2

仕様書作成段階の作業は、
 ・アドオンプログラムの要件を抽出する
 ・アドオンプログラムの振る舞い(動作)を規定する
  − どのようなデータを入力できるようにするか
  − 入力されたデータに対してどのようなチェックをするか
  − どのようなアウトプット(伝票など)を作るのか など
のが目的です。

したがって、この段階で、設計作業、つまり、
 ・内部テーブルなどの内部構造
 ・アドオンテーブルの構成
 ・処理のアルゴリズム
等は含めてはいけません。

設計を含めてしまうと設計段階で矛盾が生じたり、
求める機能が実現できなかったりします。

例えば、仕様書に
 ・10明細ある伝票がX秒を目安に保存できること
 ・内部テーブルXXXの項目は・・・・・
などと書いてしまうと、内部テーブルまでが規定されて
しまっているため、パフォーマンスをあげるための
内部構造・アルゴリズムを設計する妨げになってしまいます。

アドオン開発の現場では、次のような設計フェーズでやるべき
ことが含まれることが多くあります。
 ・アドオンテーブルの設計
 ・内部テーブルの設計
 ・標準の汎用モジュールに渡すパラメータ値
これらは基本的に設計で行うもので、仕様決めの段階では
そのような作業はせずに、プログラムの機能を詰めることに
専念する必要があります。

どうしても上記の記述が必要、あるいは、その方が仕様の
理解が進むと言うことであれば、例えば、
 このアドオンテーブル構造は仕様の理解のために
 記述したもので設計時に確定される
と言うような記述を付け加えた方がよいでしょう。
そうすれば、設計段階で、自由に変更が可能となります。  
Posted by taka1350041 at 16:44Comments(0)TrackBack(0)プロジェクト管理

2006年03月11日

仕様変更をなくす 1

アドオン開発での仕様変更をなくすための
仕様書作成について何回かに分けて考えます。

仕様書作成に関しては、
 これをやればOKと言う方法論やマニュアルはない
を肝に銘じる必要があります。

数々の開発方法論、分析手法が存在し、新しい考え方も
日々登場しています。特に新しい方法論に関しては、
それをやれば今までの問題が解決する決定打にように
紹介されがちです。
しかし、それぞれの手法にはメリット・デメリットが
あり、ひとつの手法でうまくはいきません。


逆の言い方をすると仕様書作成段階では、
 今、やれることはすべて徹底的にやる
これが仕様変更をなくすための一番重要な心構えだと
考えます。

インテルの前CEO、アンドリュー・グローブは、
 「パラノイアだけが生き残る」
と言う言葉を残しています。
パラノイアと言うのは偏執狂のことですが、
偏執狂と言われるくらい徹底的にこだわって、
こだわって経営のことを考えないとだめだと
彼は言っているのです。

アドオン開発で仕様を確定する作業もそれと同じ
ことが言えます。兎に角、徹底的に何度も何度も
考え抜くことが漏れのない・後で変更を必要最小限
に食い止めることができる仕様書作りにつながります。

次回は、具体的なポイントについて書きます。

参考文献

大前研一 ザ・プロフェッショナル

アラン・デービス ソフトウェア開発201の鉄則
  
Posted by taka1350041 at 23:07Comments(0)TrackBack(0)技術

2006年03月10日

詳細設計の原則2

詳細設計の大原則として
 1 文章(ドキュメント)化する
 2 プログラム開発前に実施する
 3 レビューをする
の3つを上げました。

2のプログラム開発前に実施する の必要性を
前回、説明しましたが、実現するためのポイントを
プロジェクト管理者の立場から何点か書きます。

1 プロジェクトスケジュールに組み込む
 ・これは当たり前のことですが、詳細設計を作成する
 作業がプロジェクト計画に組み込まれている必要が
 あります

2 担当者にプログラム開発前に実施する必要性、意義
 について説明し、納得してもらう
 ・命令してやらせるのではなく、なぜ必要なのかを
 理解して、納得の上でやってもらわないと、品質の低い
 設計書になります

3 テンプレートから不要な項目は削除
 ・詳細設計書は決められたフォーマット(テンプレート)
 を使いますが、このフォーマットが不要な章が多かったり、
 記述がいらないものがあったりします。
 このようなフォーマットでは開発者のやる気が落ちますし、
 形式的で内容が伴わない設計書になる可能性が高くなります。
 詳細設計書に各内容は本当に必要なものに絞り込むべきです。

4 開発者(担当者)とよく話し合う
 ・1〜3も含めて、開発者の意見をよく聞き、取り入れるべき
 ものは取り入れるようにします。

そのほか、必要に応じて、サンプルの詳細設計書を用意したり、
作成ガイドラインを作ることも有効です。  
Posted by taka1350041 at 12:57Comments(2)TrackBack(0)プロジェクト管理

2006年03月09日

詳細設計の原則

ここで言う詳細設計とは、
要件定義、仕様確定後に行う
プログラムの内部設計、アドオンテーブルの設計を
さします。


詳細設計の大原則は次の3つと考えています。
 1 文章(ドキュメント)化する
 2 プログラム開発前に実施する
 3 レビューをする
  ※レビューの用語については別の機会に
  取り上げます

どれも当たり前のことなのですが、現場では
スケジュールの都合で実現できていないことが
多いかもしれません。

特に2に関しては、開発者や外注のソフトウェア
会社さんから激しい抵抗を経験しました。

しかし、高い品質の成果物を作るには2は必須と
今までの経験上、考えています。

プログラム開発前に実施しなかった場合に発生する
問題をまず書きます。

1 モジュール化がうまくいかない
 ・サブルーチン化、汎用モジュール化がうまく
 いかないケースが多くなります。
 実際にあった極端な例では、サブルーチン名が
 XXXX_checkとなっているので、値のチェックと
 DB更新が記述されていました。似たような例では
 データを読み込んで、更新するプログラムで
 XXXX_readと書かれているサブルーチンに更新処理
 まで書かれていたケースもありました。

 ・アドオンプログラムは複数のデータを一括する更新
 するようなものも多いので、事前に設計をしないと
 このようなプログラムになってしまいます。

 ・このようなプログラムは不具合時の問題の発見・
 修正が難しくなりますし、仕様変更への対応も
 厳しくなります

2 重複した変数
 ・事前に設計をしないと似たような名称の変数が
 グローバル変数、ローカル変数のあちことに存在
 したり、flag_1, flag_2のように用途がよくわからない
 非常に紛らわしい変数が増えてきます

3 不適切な内部テーブルの設計
 ・特に複雑な更新処理をするアドオンプログラムでは、
 内部テーブルを上手に設計することが重要になります。
 事前に設計をしないと異常に項目数の多い内部テーブル
 になったり、読み書きが何度も発生する内部テーブルに
 なってしまいます。

4 不適切な名称
 ・プログラムを書きながら変数名やサブルーチン名を
 決めていくと、おかしな名前にしてしまいがちです。
 また、プログラムを書きながら適切な名称を考えるのは
 意外と時間が掛かります。


開発者が自分の作ったプログラムをずっと保守してくれる
のなら上記の問題は問題にならないかもしれません。
しかし、現実は保守したり、機能追加をする担当者は別
になることがほとんどです。

そのため、いかに分かりやすく保守性の高いプログラムを
作るかが非常に大切になります。

次回は「プログラム開発前に設計をする」を実現するための
工夫について考えます。  
Posted by taka1350041 at 12:28Comments(0)TrackBack(0)プロジェクト管理

2006年03月05日

EXITとBADI 2

4cfa780d.jpgEXITは、
 ユーザEXIT
 カスタマEXIT
に分けることができます。

今回は、この二つのEXITとBADIのそれぞれの
特徴について説明します。

ユーザEXITは、標準プログラム内のuserexitで始まる
サブルーチン内に実装するものです。
実装にはオブジェクトキーが必要となるので、
技術的にはモディフィケーションと同じです。
ユーザEXITはモジュールによって、ばらつきが大きく、
例えば、SDにはたくさんのユーザEXITがありますが、
MMにはあまりありません。

ユーザEXITでは、サブルーチンが定義されている
プログラムの内部テーブルも含むグローバル変数
すべてにアクセスができます。
したがって、かなり自由に色々なことができます。

逆に言うと自由度が高いため、データの不整合が
発生するなど問題のある実装をするリスクも高いです。
前回、ご説明したEXITの問題点が一番、発生しやすい
のがユーザEXITと言えるかも知れません。

カスタマEXITは、カスタマEXIT用の汎用モジュールが
あらかじめ標準プログラムに組み込まれており、
その汎用モジュール内のインクルードプログラムに
実装するものです。

カスタマEXITでは、あらかじめ定義してある受け渡し
パラメータにしかアクセスができません。
よって、ユーザEXITより自由度は低いですが、その分、
リスクも低いです。

BADIは、簡単に言ってしまうと、カスタマEXITの
オブジェクト指向版で、メソッド内に実装します。
OABAP(オブジェクト指向ABAP)では、使用が禁止
されているABAPの文法が幾つかあり、注意が必要です。

今後、SAPから新規にユーザEXITやカスタマEXITが
組み込まれることはなく、BADIのみになるようです。
既に実装済みのユーザEXIT、カスタマEXITが使えなくなる
ことはないかと思いますが、BADIに実装する機会が
今後増えると考えられます。  
Posted by taka1350041 at 16:54Comments(1)TrackBack(0)技術

EXITとBADI 1

EXITとBADIはアドオン開発は別と考えることが
多いかと思いますが、ABAPをコーディングする
ことには変わらないので取り上げます。

最初にEXIT、BADI(以下、EXIT類)に共通する注意点をあげます。
重要なポイントはEXIT類は開発チームではなく、
コンサルタントが実装する場合が多いことです。

その点から派生する問題は下記のようなことです。

1)カスタマイズ(パラメータ設定中)に作業が
 行われ、十分なドキュメントが残されない

2)設計を行わずにすぐに実装に入ることから
 複雑な仕様の場合、パフォーマンスが悪かったり、
 保守性が非常に低いコーディングになりやすい

3)標準機能と同程度のテストしか行われず、複雑な
 EXIT類の場合、テストが不十分な場合がある

4)開発契約では、瑕疵担保期間が通常設けられるが、
 コンサルタント契約の場合は瑕疵担保がないため、
 EXIT類の不具合は瑕疵担保保証を受けられない

以上のことから、アドオン開発が少なくてもEXIT類が
多ければプロジェクトのリスクが高まります。

単純にアドオン開発が少ないプロジェクト=いいプロジェクト
とは考えずに、アドオンとEXIT類のバランスを考慮
する必要があります。  
Posted by taka1350041 at 16:24Comments(0)TrackBack(0)技術

2006年03月04日

技術のわかるPMのメリット・デメリット

私はABAPプログラマーを経て、アドオン開発の
プロジェクト管理をするようになったので、
技術面を理解しているプロジェクト管理者と
言えます。

技術のわかるPMのメリットとしては、
 1 精度の高い見積ができる
  ※ もちろん、ABAPの知識あるだけでは
  これは保障されませんが、ABAPなどの技術的な
  特徴を把握しているとやはり精度は上がります
 2 精度の高いプロジェクト計画が立てられる
等がありますが、それよりも
 いざとなったら自分が作業できる
という部分が結構大きいかと思います。

もちろん、これに頼ってはプロジェクト管理者としては
問題ですが、最後の手段で自分で設計・プログラミング
ができると言うのは大きいです。

一方で、この部分がデメリットにもなります。

まずは、開発者がプロジェクト管理者に依存してしまう
傾向がでてしまうことです。
特に優秀なSE・プログラマーだった方は注意が必要です。
また、優秀なSE・プログラマーだった方ほど開発者の
細かいところが気になってしまうものです。

品質の大きく影響する部分を見逃してはいけませんが、
ある程度は開発者を信頼して任せないと、開発者の
モチベーションが下がりますし、自分も作業負荷も
高くなり、肝心のプロジェクト管理が疎かになります。

また、プログラミングや設計から離れていると腕は
確実に鈍くなります。
そのことを理解していないと、土壇場で自分がやった
ところがうまく作れなかったり、品質が悪いものに
なりかねません。

自分の技術力が落ちるのは寂しいかもしれませんが、
これは自分の立場を考えて、受け入れるしかありません。  
Posted by taka1350041 at 01:15Comments(1)TrackBack(0)プロジェクト管理

2006年03月01日

非同期更新2

76e0f6aa.jpg非同期更新は見かけ上(画面上)の処理速度を
あげるための技術です。

通常の更新処理(同期更新)をABAPで
記述すると更新処理もそれ以外のプログラム処理も
ダイアログワークプロセスですべて処理されます。
したがって、DB更新が完了するまで画面上に
メッセージは返ってきません。
(図の上段を参照)
大量のDB更新処理がある場合、ユーザはすべての
DB更新処理が完了するまで次の作業はできません。

一方、ABAPで非同期更新の記述をすると
ABAP内でcommit work命令が発行された時点で
更新用ワークプロセスに更新処理が渡されます。
(図の下段を参照)
したがって、DB更新が終わっていなくても、画面上に
メッセージが返ってきます。

よって、ユーザから見た場合の処理速度は向上すること
になります。

R/3の受注伝票登録など多くの標準更新トランザクションは
非同期更新で記述されています。

EXIT・BADIを実装するときなども非同期更新のメカニズムを
理解しておく必要があります。

次回は非同期更新の注意点について記述します。  
Posted by taka1350041 at 21:28Comments(1)TrackBack(0)技術