カスタマーサポートは参考程度に
皆さん、こんばんわ、カズヤんです。
今日は、僕がやらかした話をします。
入社して、8ヶ月が経過しようというところですが、1つやらかしました。
というのも、お客様から問い合わせをいただいた際に、SAP社に問い合わせしてから、エビデンスとしてやりとりをお客様に提示し、GOサインを出すわけです。
ここで、
カスタマーサポートコンサルタントのがyesと言ったから、yesです！！
とお客さんに伝えていたのですが、
カスタマーサポートコンサルタントがnoと言い出したのです！！
フンぎゃーっっっ！！？？
かなりの数の問い合わせをしているのですが、
今回初めて引っかかったのですが、
彼らは言うことがコロコロ変わるのです。
そのため、お客さんにはSAP社がyesと言ったけど、noと言ったのでnoです。
と伝えないといけません。
8ヶ月とは言え、私もプロのエンジニアのため、自分で調査をして、自分が抱いた仮説を立証するためにも製品サポートの意見を聞く必要があるのですが、
一旦、yesと言ったのをnoというので、それなりの理由が必要な訳です。
今回、問い合わせていた内容は、そもそもSAPの新しい機能のところなので、我々では判断が難しいところもあるのですが、まあ、サポートを信用しすぎたというところでしょうか。
自分：サポートコンサルタント意見 ＝ 7 : 3
くらいでしたが、
自分：サポートコンサルタント意見 ＝ 9 : 1
くらいで臨む必要があると痛感しました。
次回は、ないように自身の調査の質も高めていこうと思います。
すごく苦い経験ですが、次に繋げます!
こんな感じで、後2日ですが、頑張ります。
では、また明日!!
GUI750の画面設定(2)
皆さん、こんにちは、カズヤんです。
今日は、前回同様GUI750の画面設定について書きたいと思います。
前回の記事 ↓で、
Trcd：SLMTの利用により、SAP GUIの接続先設定が可能である旨を記載しましたが、
GUI Instllation Guideでは、このSLMT利用が推奨されていたとしても、実際は集中的・効率的に管理できるだけのツールであり、ファイルの差替えでも問題ないということを専門家の方から聞きました(SAPの公式見解ではない)。
このSLMT利用のためには、SAP_BASISコンポーネントの740以降となっているため、おそらく、SAP_BASIS 730以前では利用できないと思われます。
では、このSLMT機能が使えない場合はどうするのか？
いくつか選択肢があるのですが、
(1) SAPUILandscape.xmlファイルとSAPUILandscapeglobal.xmlファイルを差し替え
(2) レジストリ変更により、システムにsaplogon.iniファイルを読ませに行かせる
(3) GUI上で手動で接続先設定情報を入力する
(1)に関しては、
この、SAPUILandscap.xmlファイルの中に、「uuid」というidが振られており、このidが端末依存の場合に、他の端末に差し替えた際に利用できるかが不明なのです。
実際、チーム内の別端末でファイル差替えを実施したのですが、GUIの稼動には何も問題なかったです。
現在、SAP社に問い合わせしているので何とも言えないのですが、ここがクリアになれば、簡単にGUI750を利用できるっぽいです。
(2)に関しては、
レジストリ変更がシステムに問題ないのかが怪しいところです。
さらに、Installation Guideによると、2つのXMLファイルはかつてのシステム設定ファイルの内容を下記の要領で引き継いでいるようです。
NWBCOptions.xml
saproute.ini
sapmsg.ini
services
→ SAPUILandscapeGlobal.xml
saplogon.ini
sapshortcut.ini
SapLogonTree.xml
→ SAPUILandscape.xml
そこで、レジストリ変更して、saplogon.iniファイルをシステムに読ませたとしても、saplogon.ini 以外のファイルの内容はどう読み込ませるのかという問題が生じるので、個人的にはやめた方がいいのではと思う方法です。
(3)に関しては、
一番確実ですが、一番めんどくさいやり方です。
SAP GUIを起動し、起動後に、GUI上のオプションにて1つ1つの設定を行えます。
これは、お客さん側のユーザの規模によりますが、基本的にユーザは多いはずなので、自動化の道を選ばざるを得ないでしょう。少数だったらこの方法がベターですね。
前回、GUI760リリースについて言及しましたが、どうやら来年度にリリースされるそうです。GUI750でもこれだけ不明確なことだらけなのに、GUI760出たらと思うと恐ろしいです。まあ、正直SAP Japanに日本語のリソースを出してもらえたら嬉しいですね。英語版だと理解に齟齬が出てしますので、本当お願いしたいです。
次回も多分SAP関連書きます。次回もよろしくお願いします！！
タスク管理の重要性
皆さん、こんばんは、カズヤんです。
今回は、タスク管理の重要性について語ります。
ビジネスパーソンたるもの、自分自身のタスクを正確に把握し、それを完遂することを要求されると思うのですが、私は現在タスク管理が適切に実施できず業務でかなり困っています。
というより、業務でタスクを時間内に回せず、原因を考えていたのですが、そこでタスク管理が適切に行えていないことが判明した。というのが正しい順番です。
現在、私は常時15個くらいタスクを回しているのですが、タスクを管理する上でやはり、「タスク名」、「発生日」、「期限」、「優先度」、「作業内容」、「予想作業時間」「部門」等を正確に記載できるツールを使用しておらず、社内で利用しているメールツールのおまけのようなタスク管理ソフトで管理を行っています。
さらに、タスクが発生した際に、タスクをタスク管理ツールに記載していないことがわかりました。そのため、タスク管理ツールに書かないがために、期限が過ぎたタスクがいくつか存在しています。これは、重要度の低いものであったため問題はなかったのですが、このタスク管理ツールに書かなかった理由は何だろうか？と自分に問いかけました。理由として、考えられるのは、ツールの使いづらさからツールに転記しなかったことだと思います。
そこで、自身の失敗に対して以下のような是正策を講じて対処しようと思います。
そのために根本原因分析をします。
事象：タスク管理が適切にできず作業が漏れた
なぜ？：タスク管理ツールを使わなかった
なぜ？：１、タスク管理ツールが使いづらい
２、タスク管理ツールに記入しなかった
なぜ？：タスク管理ツールが使いづらい（オフライン利用不可)
タスク管理ツールに書くのを忘れた
なぜ？：ネットに繋がらず、タスクを書けなかったため
別件対応中のタスクがあったため
是正策：
「タスク管理ツールが使いづらい」
→タスク管理ツールを改善する必要がある
→オフラインでも利用できるタスク管理ツールを作成(1)
「タスク管理ツールに書くのを忘れた」
→タスク管理ツールにタスクを書き込む時間帯のルールを規定(2)
この2つを実施しようと思い、
(1)に関しては、オフラインで使えるエクセルによる簡単なタスク管理ツールを作成します。今週中に対応します(11/18まで)
私自身が必要だと感じている要素(「タスク名」、「発生日」、「期限」、「優先度」、「作業内容」、「予想作業時間」「部門」)もしっかりと盛り込んでいます。
(2)に関しては、タスクが発生した瞬間1分以内にタスクを管理ツールに記入する
というルールを自身の中で守ることにします。これは規定しても私の気持ち次第なところもあるため、あえて本記事内で明文化することにより植えつけたいと思っています。
最後に、
正直、タスク管理ができな過ぎて業務が回らず大変な思いをしていたので、これを徹底して、1つの作業の質と速度を向上していきたいと思っています。
新人が出せるバリューは本当に大したことがないので、指示されたタスクを超高速で回し、いつでもフリーな状態で先輩が作業を触れるようにしておくことが大切だと感じています。
今後もタスク管理に関してはシビアに取り組んでいき、結果も報告できたらと思います。
また、次回も読んでください。では!!
作業スペースとしてのスタバの魅力
皆さん、こんにちは、カズヤんです。
仕事とは関係ないですが、日頃私が利用しているスタバについて少し書いて行きます。
私は、普段何があっても家で勉強したり、仕事の作業をしたりすることは決してありません。
PCで作業をするときは必ず外で、ポケットWIFIとmacbook、イヤホンの3点セットを携えて最寄り駅のスタバに行きます。
学生時代にスタバでバイトをしていたこともあってか、私自身スタバが大好きで通うわけですが、こうやって作業をしにスタバに行く中で多くのことを発見し、さらにスタバが好きになりました。
以下では、私の思うスタバの魅力について書いて行きます。
１、優秀な人が勉強する環境
２、長居できる居心地の良さ
３、パートナーの質の高さ(特に学生)
１、優秀な人が勉強する環境
皆さん、ご存知かわかりませんが、
スタバってかなり多くの方が勉強をするのに使っているのです。
これは、休日だけでなく、平日の夜などもスーツを着た方々が会計の勉強をしていたり(おそらく、簿記か公認会計士)、女性の方が仕事をしていたり、学生は英語の学習をしていたりしているのです(近くに獨協大学があるためおそらく留学のTOEFL)。
英語に関しては、サラリーマンがIELTSの学習をしていることもあります。おそらく欧州MBA受験でしょう。
このような環境では、作業をしに入店しているとはいえ、私自身も勉強をしなければいけない雰囲気があるのです。
スタバのセンターテーブルでは、多くのサラリーマンがPCキーボードをカチカチ、カチカチと叩き、学生が英語を静かに音読しています。
草加バリエのスターバックスなのですが、個人としては、埼玉の草加でこんな頑張っている人がいるというのはかなりの励みになります。
私も負けてられないです。
２、長居できる居心地の良さ
私は、スタバにくると大抵3時間以上居座ってしまいます。
ちゃんと2杯＋フード注文するので、問題はないと思いますが、ブロガーであり、ネットサーファの私としては、ネット環境あり、電源ありのこの環境は最高に長居できるので、何か集中して作業したい時にはうってつけです。
日曜の昼盛りからこんな感じですwww ↓
３、パートナーの質の高さ(特に学生)
スタバで働いていたからわかるのですが、スタバでアルバイトをする学生は比較的にEQが高いです。IQはどうか知りませんが、空気を読める人が多く、私は常連なので、結構話しかけてくれるのですが、結構内容を覚えてくれていて、笑いをとってくれます。
そもそも、スタバの業務はある程度標準化されているわけですが、マクドナルドとは異なり、接客のマニュアルはないため、接客に関してはCS向上のためにどのように工夫をして、お客様の支払う料金500円に対してバリューを出すか考える必要があります。
スターバックスでは、新規プロモーションが始まると、全社単位でプロモーション施策が決められているとはいえ、お店ごとに違う施策を行うこともできるため、学生の立場でも十分クリエイティブなアイデアを実行することが可能です。
近所に獨協大学があるので、おそらく8割くらいは独協大生でしょうが、とても空気を読める彼らのおかげで日頃から心地よく過ごせています。
本当に感謝..
最後に、普段過ごしているスタバに感謝しつつ、明日からの仕事への英気を養っていこうと思います。また読者の皆様今後ともよろしくお願いします!!
素人がPython始める...
みなさん、こんばんは、カズヤんです。
ちょうど昨日から、何か休みの日に没頭できるものはないかなと…
考えていたんですね。
それで、条件もいくつかあって、
1、学習環境が整い、参入障壁が高くないもの
2、断然面白く、どハマりできるもの
3、副業した時に活用できるもの
この3つの条件で検討していたわけですが、
内定者時代の1年前にJavaに没頭した経緯から、アプリ系の開発言語の1つに取り組むのがいいかなと思いまして、掲題にございますが、Pythonを始めてみようと思いました。
1、学習環境が整い、参入障壁が高くないもの
Pythonはかなり汎用性が高く、アプリ開発から統計解析などいろいろできます。
さらに、オブジェクト指向言語ということで、Javaとある程度似ていることから、
一回、プログラミングを学んだ自分としては、とっつきやすいと思います。
プログラミング言語って、めちゃめちゃたくさんあるのですが、Pythonの長所・短所としては、以下があげられます。
Pythonの長所：
・汎用性が高い(アプリ開発から統計解析まで可能)
・Javaよりも習得が楽
Pythonの短所：
・処理速度がやや遅い
Javaは文系出身の自分がIT業界に入るためのアピール材料として学習していただけで、実際にアプリ開発をしたことは一切ないのが現状です。そのため、私としては、以下に簡単に習得できるかが Key Factorとなっています。Pythonはその点かなり見込みがあります。
2、断然面白く、どハマりできるもの
つまり、人気のあるポピュラーな技術に触れてみたいと思いました。
現在人気のプログラミング言語って皆さんご存知ですか?
こういうのって大抵、最先端のWEB系の言語のためRubyとか、PHPとかかと思っていたのですが、実際は異なるようです。下記リンクをご覧ください。
上記リンクは、IEEEというネットワーク関連の認証を行なっている世界でも有名な団体です(なぜ、IEEEなのかは謎ですが...)。
私は普段インフラエンジニアのため、あまり気にしたことがなかったのですが、
結果として、断然Pythonがトップであることがわかります。
SIerに勤めている人なら誰しもわかりますが、社内にDigital部門を持っていないファームでしたら、RubyとかPythonとかが一般的に使われる機会がほとんどないのが現状です。
そんな現状では、Web業界に携わる大学同期の会話についていけないことがよくあるわけです。
IT業界人あるあるとして、非IT業界の人と会話をする際に、プログラミングできるんだ~って言われますが、正直インフラなので1から説明するのがだるいですw
3、副業した時に活用できるもの
最後に、副業についてですが、私は現在一応外資系ITコンサルティングファームであり、Sierでもある会社に勤めているので、大企業のSAP(つまり、基幹システム)の運用に携わっている経緯から、このコミュニティ以外では私のスキルはほぼ通用しません。
大学のときは、財政学のゼミに所属はしておりましたが、経済学を全般的に学んでいた経緯から、データ解析など、データサイエンティストと呼ばれる分野には大変興味があります。
現在、クラウドワークスやランサーズなどのクラウドソーシング系のサイトでは、多くの求人がありますが、個人開発案件やデータ解析の仕事もあるそうです。
そのため、まあ3年間くらいは会社でSAPの案件をやりながら、相手いる時間でデータ解析系の仕事が受注できるレベルまで勉強していきたいと思っています。
ちなみに転職を考えた時には、今後は経営管理の意思決定を行う上でもデータ解析の重要性は無視できませんので、私のキャリアのあらゆる側面でプラスになると信じております。
最後にですが、
業務に関する技術知識は継続的に学習を行うとして、やはり新しいものをやりたいという気持ちが勝り、本も買ってしまいましたねwww
今後は、今までのSAP運用のネタに加えてPythonのネタもぶっこんでいきますので、ぜひ読んで欲しいです。このブログコミュニティでも先端の技術に触れながら業務を行う方々が多くいらっしゃると思うので、どんどんコメントいただけたら幸いです。
では、本記事はここまでにしたいと思います。
また、次回以降もよろしくお願いします!!
DBエラー(ORA-00060)
皆さん、こんばんはカズヤんです。
今日は、プレミアムフライデーですね笑
僕は、安定の仕事充ですがww
今日は、データベースのデッドロックについて書きます。
というのも、今日も昼過ぎに障害通知来て対応していました。そのエラーがデッドロックに関するエラーだったわけです。それで2時間拘束されましたね。ただ、既知のエラーだったので、すぐ対応できたのが救いでしたね。既知のエラーの対象なのはユーザーをこちらが把握している場合です。もしこれが、把握していないユーザ（つまり、お客様の会社のユーザ）の場合は、問題管理プロセスのワークフローを回して、新たに原因を調べないといけないので死ぬほど面倒くさいやつです。
※ ITILに則った運用を行なっているので、インシデント管理、問題管理、変更管理を順に回す必要があるわけです。詳しくは過去記事をぜひご覧ください↓
私がまだビギナーのため、このデータベースのデッドロックに向き合い必要があるため、少々長くなりますが、ご容赦ください...
1、ORA-00060について
今回ご紹介するORA-00060ですが、これはデッドロックを検出した際に出力するエラーです。
まず、ロックに関してですが、いかなるシステムでも、データベースが存在します。アプリで何か処理を行なった際にはロックを取得し、処理が終了するまでロックを保持するのがシステムの基本設計となっています。
デッドロックは、複数のトランザクションを実行した際に、互いが相手の占有ロックされている資源を要求して待ち状態となり、処理が一切実行されなくなる状態のことをさします。ちなみにデッドロック(deadlock)とは、「膠着状態」を意味する単語のようですww
例として、
2つのトランザクション(1と2)、2つのデータ(AとB)が存在する状態を仮定します。
(1) トランザクション1を実行しデータAへアクセス(ロックをかける)
(2) トランザクション2を実行しデータBへアクセス(ロックをかける)
(3) トランザクション1を実行しデータBへアクセス(すでにロック状態のため、待ち状態)
(4) トランザクション2を実行しデータAへアクセス(すでにロック状態のため、待ち状態)
この場合、相手のロックが解除されるまでの間は、永遠に待ち状態が続きます。
マジで不毛ですねww
図で描くとこんな感じですね(パワポで作ったのでちょっと変ですがそこは差っ引いてください)。オレンジの処理がロックされてるので、青は永遠に待機しています。
デッドロックの解説図
2、デッドロックの解決方法
では、次にこのデッドロックって解決できるのか？というところですが、これはケースによって対処方法が異なるようです。今回、私が体験したデッドロックは特定の表へのアクセスでデッドロックが起きたケースのため、これに関して記載します。
デッドロックは、そもそもどう頑張っても起きてしまうものなので、予防のために事前に対策を講ずることもあるのですが、発生してからの対処法としては、
デッドロック発生後にロールバックのプログラムを実行すればいいそうです。
本当にそうなのだろうかと疑問に思ってしょうがないのですが、これは私の宿題として、もっとわかった時にご説明します。
3、デッドロックの再現
ただ、どうしても今回はSQLPlusは上手くインストールできたのですが、Oracleの方が上手くインストールできないので、恥ずかしいお話ですが、実際に再現されている方のドンピシャのブログを見つけたので今回はそちらを代用させていただきたいと思います。
下記がリンクです↓
こちらの方はとても丁寧で、デッドロックを発生させた後に実際にアラートログ(システムにとって重要な情報を出力するログです。DB2の場合は、db2diag.logが該当)を確認されています。ぜひご参照ください。
4、終わりに
本日は、やや手抜きですが、デッドロックに関して説明しました。
私自身、今回の障害対応のおかげでデッドロックが何であるか？
解決策について今は理解できていないですが、どのような問題が存在するかを自身の中で整理できました。今回の記事でわからないことはまだあるので、今後も調査していきます。特に、デッドロックの検証を行う際に、Oracleのインストールができないと別のターミナル(端末)にてデータベースにアクセスする環境が整わないため、ここがクリアできません。なので、次回以降でOracleのインストールをやってみようと思います。
その方が今後も検証が早いので一石二鳥です!!
今回もお読みいただきありがとうございました。
明日以降も毎日更新していくので、よろしくお願いします!!
GUI750の画面設定
皆さん、こんばんは、カズヤです。
ご機嫌いかがでしょうか？
私は、毎日1ミリもわからないSAPの作業で終われ、Noteを読み込む生活ですwww
今日は、SAP GUI 750インストールに関して、ちょっと大切だと感じたことを共有します。
そもそも、SAPのGUIとは？
GUIは、Graphical User Interfaceのことで、コマンドではなく、視覚的にアイコンなどで画面操作ができるSAPシステムのインターフェースのことです。
現在、SAPGUI730から、新規のGUI750までがサポート対象となっています。新しい機能の多いSAPGUI750よりも、エラー修正のされているGUI740が一般的な気がします。
ここからが本題ですが、
GUI740までは、GUIの接続先設定はsaplogon.iniファイルにて管理していましたが、GUI750では、SAPUILandscape.xmlというファイルが生成され、このファイルの中で、GUIの接続先設定を行えるという事です。
さらに、従来までは新規でGUIをインストールする際に、GUIの設定が事前に盛り込まれたsaplogon.iniファイルを、新規でインストールする端末のsaplogon.iniファイルと差し替える事で、GUIの設定を変更できました。
しかし、GUI750では、このファイル差し替えができないようです。SAPUILandscape.xmlファイルを新たに差し替えることが可能なのかは怪しいところです。
なぜなら、saplogon.iniファイルの中には、無かったのですが、SAPUILandscap.xmlファイルの中には、uuidというテキストが追加されており、これが端末固有の可能性があるためです。さらに、SAP社のfrontendinstallationguideによると、このxmlファイルの変更は推奨されておらず、代わりに、Trcd:SLMTを利用したフロントエンド管理ツール利用が推奨されているそうです。
下記がインストールガイドですが、英語で書かれているため、解読に時間がかかります。
SAPのGUIは頻繁に変更されるので、今回GUI750に、触れることが出来てとても良かったです。今後、GUI760がリリースされた時にドヤ顔で対応できるようにしっかり学んでいきたいです。とてもマニアックなGUIの話しでしたが、もし携わっている方がいらっしゃったらコメント等頂けましたら幸いです。
また、次回もよろしくお願いします！
初めての月次報告担当
皆さん、こんばんは、カズヤです。
今日は、あるお客様の月次報告会に参加し、私が初の月次報告を行いました。超緊張しました...
発端は、月次報告書作成中(これがかなりきつい...レビュー入れて2日かかっている)、
「今回報告会やってみる？」
唐突でしたが、先輩から言われました。
「カズヤん君、トークセンスあるからいけるよ!」
笑い取るわけちゃうやろ！？
と内心思いましたが、どうやら本気みたいです。
この案件の元担当である先輩に聞いたところ、先輩が月次報告を行うようになったのは配属後1年以上経った時だったそうで、配属4ヶ月目の新人が月次報告を行うのは中々の異例な事だそうです。
昨日は、月次報告書作成に1日の時間の8割割いたため、かなり体力が消耗する中、報告会が始まったのです...
「A社様10月度月次報告書の説明を致します！」
ここから、
・リソース使用状況
・依頼作業
・障害連絡
・重要Note
などの説明をながながと20分ほどで行いました。
結論として、70点くらいの成果であったと思います。
反省点としては、メモリ使用量の説明が少し足りず、先輩に助けてもらった点でしょうか。
全体として問題は無いと思います。
このお客様様はとても良心的で新人の私の発表を親身に聞いてくださります。主担当として一人前にならなければならないので今後もプロとして月次報告会に参加したいです。
明日は本報告会の議事録を作成するためこれにてんてこまいになりそうですが、なんとか無事に努めあげたいです。今日はとりあえずOKとして明日以降も頑張ります。この経験が今後の私のキャリアの礎となる事を心から願いつつまた明日も頑張る所存です。
以上、新人の報告でした。
こんな感じでどんどん成長してみせます！！次回もよろしくお願いします！
