アーキテクチャと開発プロセス
めずらしく真面目なツイートしたので備忘メモ
アーキテクチャや開発プロセスについて考えてたら、なんとなく自分がPMやりたくなかった理由が見えてきた。
— にょぷ (@_nyop) 2020年7月25日
プロジェクトマネジメントのプロセスって、あくまでプロジェクトの終了時点でのQCDを維持するための手法で、長期的な品質特性を保障するもんではないんだよね。開発プロセスという意味ではアジャイルも同義。
— にょぷ (@_nyop) 2020年7月25日
一方でアーキテクチャや設計は中長期的な品質特性に多分に影響を与える。個人的には一時的に品質を維持したからってそれが本当に必要な品質特性を満たす条件になっていない、というのが感覚的にわかっていた気がする。
— にょぷ (@_nyop) 2020年7月25日
多分それが自分がずっとPMをやりたくなかった理由。なんだけど最近PM的な仕事もやるようになったのは、アーキテクトや業務屋としてそれなりの水準に達したと感じているから。品質特性を維持しつつ、PM観点でオンスケ、オンバジェットが実現できる。
— にょぷ (@_nyop) 2020年7月25日
アーキテクチャと開発プロセスって実現したいもののベクトルが違う、というのが気づきであり結構本質な気がする。なお、引き続き、プロセスに対する興味は薄い模様。
— にょぷ (@_nyop) 2020年7月25日
あくまでアーキテクト寄りのキャリアの人間の観点なので、プロセス屋さんの反論も聞いてみたいな。
— にょぷ (@_nyop) 2020年7月25日
イノベーション関連の界隈のプロセス指向も疑問。
開発に限らず、プロセス定義というのはアウトプットの均質化を目的とするもんだと思うんだよね。そういう意味では、プロセス指向のイノベーションへのアプローチも違和感。ジョブ理論のようにイノベーションをモデル化、アーキテクチャ化するもののがしっくりくる。
— にょぷ (@_nyop) 2020年7月25日
SAP変更文書オブジェクトメモ
変更文書オブジェクトをよく使うのでメモ
テーブル:CDHDR/CDPOS
S/4から透過テーブルになったので簡単にSelectやQueryが可能に。
TrCd:SCDOから新規登録も可能
変更文書オブジェクト
<ロジ>
MATERIAL: 品目マスタ
CHARGE: 品目ロット
BUPA*系:ビジネスパートナ
COND_A: 価格条件マスタ
<販売管理>
DEBI: 得意先マスタ
KLIM: 得意先与信管理
VERKBELEG: 受注伝票
LIEFERUNG: 出荷伝票
FAKTBELEG: 請求伝票
HANDL_UNIT:荷役単位
EMBK: ライセンスマスタ
VBEX: 受注伝票ライセンス
<在庫/購買管理>
KRED: 仕入先マスタ
INFOSATZ: 購買情報
ORDERBUCH; 供給元一覧
BANF: 購買依頼
EINKBELEG: 購買発注
REVISION: 購買管理のバージョン
<生産計画/管理>
EQUI: 設備マスタ
STUE: BOM
STUE_V: BOM
<財務会計>
SACH: 勘定コードマスタ
ANLA: 資産マスタ
BANK: 銀行マスタ
IBAN: 国際銀行預金口座番号
BELEG: 会計伝票
<管理会計>
KSTAR: 原価要素マスタ
KOSTL: 原価センタマスタ
LSTAR: 活動タイプ
RKAUFTRAG: 内部指図
CMDT_PC: 利益センタマスタ
PRCTR: 利益センタマスタ
SETS: 管理会計マスタグループ
<その他>
FACTORYCAL: 稼働日カレンダ
HOLIDAYCAL: 祝日カレンダ
HOLIDAY: 祝日変更
KLASSE: 分類クラス
FEATURE: 分類特性
SAPのプロダクトサポート期間延長について
Maintenance 2040
SAPさんがリリースした保守期限延長の件が世間をざわつかせていますが、ちょっと誤解も多そうなので個人的な見解まとめ(正式なところはSAPさんの営業さんにお問い合わせください。)
SAP ERPのサポート延長について
SAP will provide mainstream maintenance until end of 2027 for SAP Business Suite 7 core applications, which are also core applications of SAP Business All-in-One, including:
- SAP ERP 6.0,
- SAP Customer Relationship Management 7.0,
- SAP Supply Chain Management 7.0,
- SAP Supplier Relationship Management 7.0 applications,
- SAP Business Suite powered by SAP HANA.
2027年までSAP ERP6.0のサポートが延長になるような記載となっています。
がNoteやProduct Availability Matirixを見るとちょっと状況異なります。
https://launchpad.support.sap.com/#/notes/1648480/E
NoteによるとNetweaver7.31以降が2027年のサポート対象。
SAP ERP6.0のアプリケーションバージョンであるEHPにすると6-8がサポート対象となります。
現状利用しているSAP ERPのバージョンがEHP5以下の企業さんは引き続き2025までのサポートとなりますのでご注意ください。
S/4HANAの2040年までのサポートについて
S/4HANAのサポートについてもあたかも一度上げてしまえば2040年までサポートされるように読み取れてしまいますが、各バージョンのサポートは原則5年間です。
最新のS/4HANAである1909であれば2024/12/31が MainstreamSupportの期限となります。
サポートを受け続けるためには定期的なバージョアップは必須、かつ、バージョンが上がるごとに旧トランザクションの廃止や各種ロジック変更などの影響を受けます。
一度S/4に上げてしまえばOKと言う訳ではないのでご注意ください。
当然ながら、バージョンを上げるごとに、SAPの新機能を享受できると言う点はメリットとして考えておくべきだとは思いますが、バージョンアップコストもかかります。
SAP業界的にざわついていた且つ中途半端な情報が出回っているように見えたので。
嘘ついていたら突っ込んでくだしあ。
SAPデバッグ方法メモ
私はデバッグが好きです。
SAP GuiのNewデバッガーが大好きです。
何時間でも遊んでいられます。
(最近は「他にやることあんだろ」と怒られるからあんまりやらないけど。)
ということでちょいちょい忘れるのでデバッグのTipsメモ。
新人さんにもどうそ。
基本のデバッグモード
「/h」をトランザクションコードのところで叩きましょう。
それ以降のオペレーションをデバッグモードで起動できます。
起動した後の基本動作は
F9>message>Enter>F8
な。
Dialog画面などのデバッグ
通常のオペレーションだといいんですけど、ダイアログのポップアップなどが出た後のデバッグができなくて悩ましいですよね。
そんな方に。
ローカルのテキストファイルに以下の文字列を貼り付けて保存してください。
[FUNCTION]
Command=/h
Title=Debugger
Type=SystemCommand
SAP Gui上に上記のテキストファイルをDrag & Dropすればデバッグモードで起動できます。
参考URL
https://wiki.scn.sap.com/wiki/display/Snippets/Debug+the+POPUP
Background Jobのデバッグ
事前に対象のPGMにブレークポイントを置いてください。
その上でSM37の画面で、ジョブを選択した上でトランザクションコードのコマンドにJDBGと入力すればデバッグ可能です。
参考URL
https://wiki.scn.sap.com/wiki/display/ERPFI/Debug+program+used+in+background
Sapphire2019 初日ざっくりまとめ
Sapphire2019 Day1について、Recapとかは以下に英語の記事が挙がっていたりするので、細かくないけどざっくりまとめ。
https://blogs.sap.com/2019/05/07/sapphire-now-2019-day-1-recap/
今朝のBill McDermottさんの講演の要点としては大きく3つかと。*1
Intelligent Enterprise
S4/C4に加えてSAP CPやSACなどの仕組みが整ったことで、Intelligent Enterpriseを実現する準備ができた。これからもサイロ化した業務プロセス、データモデル、更新タイミングの差異などに対応する改善をつづける。
Experience is everything(eXperience Management)
ユーザーや従業員の体験こそが重要である。体験によって顧客に対する付加価値は向上する。
Odata and Xdata (Operational data and eXperimental data)
旧来のERPやS/4、C/4には何が起きているかを分析可能なOperational Dataが格納されている。一方、なぜ起きたかを理解するためのデータがeXperimental Data。ユーザーの感情(Emotion, Sentiment)を把握する。先日買収したQualitricsを使って、フィードバックが収集できる。
1点目はその後いくつかのセッションを聞いていても、BlockchainやML、Data Hubなどイネーブラーがそれなりに進化して実績も出来始めている印象。いくつか明日発表の内容を前倒しで話してくれたセッションもあり、2日目のHassoさんの発表はちょっと楽しみ。
2点目もまーそうだよね、といった感覚。
3点目に関してで疑問なのが、フィードバック以外にももっとEmotionalなデータとか、私みたいにろくにアンケート回答もしないような人間からもデータを取得(いわゆるTwitterとかの形態素解析や感情分析)といった領域に触れるかな、と思ったけど触れられず。Qualitircsだけだとちょっと絞り過ぎじゃないですかねー。
とはいえユーザーFBの大切さは、SAPさんじゃないですが先日のJR東日○アプリでも実感ているので、必要だと思います。
*2))
それ以降のTim CookさんやTapestry、Shellさんの事例などは実際のSAPとの取組みにより、対応を進めている実例な話。
Appleとはもう少しMarketingやSalesで強調して行けると面白いと思うんだけどなー。
聞き逃してたのか、Appleとの提携強化がプレスリリースされていました。
https://news.sap.com/2019/05/sapphire-now-new-qualtrics-offerings-experience-management/
SAP Cloud Platform SDKの一部としてAppleのオンデバイス機械学習フレームワークのCore MLが使えるようになるとのこと。
ML周りは動きが激しいので要注視ですね。
お前間違ってる、嘘つくななどのツッコミがあれば是非。
*1:最後の締めくくりで言っていた順番や物言いとは厳密には違うけど、私の理解としてこっちの順のほうがしっくり来るので
*2:IDEOさんがデザインシンキングでデザインしたアプリのユーザー反応。https://twitter.com/_nyop/status/1119429190938320896
仕事上のコミュニケーションで気をつけていること。
最近、何度かクライアントとの打ち合わせとかで下の子達から相談を受けたのでメモ。
ここ数年、割と周りから話がわかりやすい、とか、あの人は話がよくわかってくれる、などと言われることがあり普段意識していることを。
多分正解は無いので、今後も更新してゆくかもですが、一旦2019年4月時点版。
そもそもお前誰やねん
システム屋なのですが、どちらかと言われるとアーキテクトとか新ソリューション開発とか技術よりなところで仕事をしてきた人間で、技術的な話はできるけれど、わからない人は理解しなくてもいい領域で生きていたので、畑違いの人との話が得意な方ではなく、聞く力は割とあるけど話すのは苦手なコミュ障な人間です。
いろいろあって、ここ数年、事業開発とか要件定義とかすることが多く、色んなレベルの人と話をする中で、技術としてコミュニケーションスキルの改善をしてきたので「人工的なコミュ力」を身に着けているんだと思っています。
コミュニケーション上、意識していること
以下の2つです。少なくとも今の時点ではこの2つしか考えていないです。
「☓自分の話したいこと」→「○相手にわかってもらいたいこと」
自分の話したいことを話す、が昔の自分のコミュニケーションスタイルでした。
が、最近意識しているのは「相手にわかってもらいたいこと」「コミュニケーションの結果相手にこう動いてほしい」ということを意識してコミュニケーションします。
結果目的が明確になるし、相手の理解具合や思考のベクトルをコントロールしようとしています。
「視座」「視点」をあわせる
視座、視点、視野という言葉があります。
- 視座:物事を見る上での立ち位置・前提
- 視点:物事を見る方向性・観点
- 視野:物事を捉える範囲の広さ
視野は合わせにくいし、相手のほうが広いこともままありますが、ずれていてもそんなに困りません。逆にこちらが気づきを得られるくらいで、違っていてもいいと思っています。
一方で視座はものを見る前提、視点はコミュニケーションをする上で方向性にも当たる当たるので、ここがずれると話が噛み合わないですね。
これをするにはどうするか?
「視座」を合わせる
ものを見る上での立ち位置、前提なので、同じ前提に立ってもらわなければいけません。特にこちらから話をする場合、大抵自分の方が多く情報を持っていますし、前回からの引き続きの場合でも相手が忘れていることもままあります。
なので、まずは前提を合わせます。
例えば以下のような話を始めにして、参加者全員の立ち位置を揃えます
- 「前回の打ち合わせでXXという話になったと思っているので、この点について話をします」(ラップアップ)
- 「そもそもこれからの話す件はXXであるという前提のもと検討しています」(前提条件の共有)
- 「これからXXについて話をしますが、そもそもXXについてご存知ですか?ではそこからご説明しますね」(情報提供)
- 「XXについて、あなたのほうが情報お持ちだと思うのですがお教え頂けますか」(ヒアリング)
ここで話のスタートにあたっての認識があっていれば、同じ土俵で話が出来ます。
逆に相手が異なる視座をスタートポイントにしたいなら、そこを確認しつつ、出発点を決めます。
某社では「ピンどめ」と言ったりしますね。
ヒアリングはできるなら事前か、別セッションでしたいですが、一部の情報について向こうのほうが情報を持っているケースでは聞きながら合わせるというのもありだと思う。
「視点」を合わせる
視座と共に大切なのが「視点」。議論の方向性です。
例えば以下のような発言や行動によって、コントロールします。
これは相手に理解してほしいことや、相手にこう動いてほしい、という思いに相対する部分なのでそこに合わせて。
まとめ
要は出発点が同じで、方向性があっていると、たどり着く場所は一緒になる、という感じです。
視点も視座もずれることがままあります。
視野や視点は話していると大抵ずれに気づくのですが、特に視座がずれていると噛み合わないことが多いです。
『相手がわかっていない、こちらがわかっていない情報はなんだろう?』と探りながら、『相手のほうが情報を持っているなら』わからないことを「馬鹿なんでわかってないんです、教えてください」と言いながら、合わせてゆきます。相手指向。
逆に某コンサルファームの使えないマネージャーさんたちでよくいるのは、自分がよくわからないから無視して突き進む系の人。めんどくさいからタヒねばいいのに。