エンプラITとプロダクト開発の違い

弊社内でもアジャイルだ―、とかDevOpsだーとか、何となく言う人が多くって、そもそも従来のSIerがやってきたようなエンプラIT（社内システム）とアジャイルとかが適用されるプロダクト開発って、全く性質が異なるよね、と言う話で作ったスライドのメモ。
やっぱりエンプラITにアジャイルって向きにくいよな、、、などと。
諸々の考え方は適用しますけどね。 

#	観点	エンプラIT（社内システム）	プロダクト開発（社外向けシステム）
1	システムオーナー	IT部門	事業部門
2	要求仕様	ビジネスルールに基づく非常に細かな要求仕様。ただ、多くの場合、明確でない。 （基幹システムの場合、2世代/3世代前のロジックを引き継いでいる場合も。。。）	詳細な要求仕様までは存在しない （作りながら考える部分も多数）
3	重視されるもの	データ/ビジネスロジック	UI/UX
4	リリースタイミング	多くの場合、一括サービスイン （周辺システムの切り替え負荷も大きいため。）	単機能ごとのリリースが可能
4	リリース後の継続的改善	（予算を取らない限り、基本的には） 不可、ITILやITGCなど管理も複雑	リリース後も継続 （継続的インテグレーション(CI)/DevOpsなどとの親和性高い）
5	売上スタイル	人月ビジネス	ソフトウェア販売/ライセンス/利用Fee
6	利害関係者	多数（それ故にPMOなどの仕事も発生）	限定的
7	障害影響	ミッションクリティカル	（プロダクトにもよるが） B2Cなどを除くと多くの場合、限定的
8	開発プロセス	(上記のような理由から) ウォーターフォールが基本となる	アジャイルが比較的適用しやすい

はてなブログでの表のサイズ調整方法がよくわからない。。

『時間を金で買う』、ではなく『脳のメモリを金で開放する』というお話

最近めっちゃ忙しいnyopです。

仕事では、炎上プロジェクトの火消しやってたり、新規事業の立ち上げしてたり、それに伴って国内外色んな所向けのプレゼンや説明や手続きやらテストマーケティングやらしていたり。
ほんとは新しい言語とか弄って遊びたいんですが。。。

一方プライベートでは妻が病気なので、8歳と5歳の息子たちがいるなかで家事全般をこなしたり、学校のお手紙の対応したり、PTAの副会長や保育園の卒対やってたり。

こういう衣替えとか年度の切り替わりの時期って学校の雑事もかなり多いんですよね。

で、めっちゃ時間無いっす。

結果、仕事では割と「移動時間に時間割くならタクシー使え」とか色々優遇してもらえたりして、プライベートでも、保育園のお迎えヘルパーさんに外注したりとか、ほぼ買い物はAmazonとかスマホで買える通販になってたり、などなど時間を買っている感覚はあります。

なんですが、時間以外に足りないのが脳のメモリ。
とにかく、仕事でも家事でも育児でも考えること/意思決定しないといけないことが多い。

そこで、最近実践しているのはToDoを頭の中に積み上げないこと。
買い物を通販に依存するというのはある意味その一つかもしれないですね。
それ以外にGTDじゃないですが、気がついた時にToDoリストに書き出すというのは昔からよくあるノウハウ。ただ、家の雑事まで全部書きだしていたらキリがない。

では、どうすれば家庭の中で発生する細かなToDoの積み上げを減らすか。
その対応としていま実践しているのが、家庭内に「モノを偏在させる」こと。

例えばAmazonで発注したものが届き、ダンボールを開くとハサミで切らないといけないような梱包があった。
その時、「リビングに持っていって梱包を解くか」と考えるのですが、コレを実行すると、

1. リビングにもってゆく
2. 梱包を解く
3. ダンボールを廃材置き場（玄関近くに）に戻す

という1と3の無駄な手順を経る必要があるわけです。
更にこの間に別でやらないといけないことがあると、この様な雑事が脳のメモリを専有してゆきます。そんな雑事がチリツモになっていったり。。。

こういった事があるタイミングで、
「あれ？玄関にハサミ置いとけばよくね？」
といった具合で、色々なモノを、いろいろな場所に配置していっています。

• ブラシ、ドライヤーを洗面所に加えリビングにも配置
• 歯ブラシを風呂場、キッチンにも配置*1
• 洗剤、掃除道具（ウェットタイプのクイックルワイパーとか）を各部屋の収納に配置
• 古いiPhoneを各部屋に設置（すぐ必要なものの買い物ができる）

などなど

結局お金でなんとかしているってことなんですけど、最近は100円均一とかでハサミとか割と安くそれなりのものが買えるので。

特に「脳が」「メモリが」などと意識して実行していたわけではないんですが、「最近時間ないなー。」と思う中で、こういった「モノを偏在させる」の結果がすごく快適に感じることが多かったのでメモ。

*1:家庭のルールにもよると思いますがうちは割と自由

SAP ABAPインスタンスの禁則文字について

年一くらいでABAPインスタンスの禁則文字について確認する機会があるので、関係各位とやり取りした内容も含めメモ。

■結論

• ABAP言語(フレームワーク)標準仕様として共通的なテキスト項目の入力制限は存在しない。
• ABAP言語(フレームワーク)標準仕様としては、必須項目チェック、型チェック、外部キーチェック、ドメイン値チェックのみ
• 上記チェック以外は、それぞれの「Dynproの入出力template」機能や、PAIでやるチェックロジックで対応
• SAP関係者なら誰もが知る(？)エクスクラメーションマーク*1の件は、歴史的な経緯とおのおのの標準PGがそのようにしているだけ。
  　⇒この機能は、「Dynproの入出力template」機能で設定されている。

■「Dynproの入出力template」機能について
エクスクラメーションマークは入力した値が消えてしまって、結果として入力不可文字となってしまうだけです。
それ以外にも意味がありますが、Note：1015345にこの機能の詳細が書かれています。但し、標準Dynproのどの項目で使用されているかは、一つ一つチェックしないといけないとわからないです。
チェック方法は、スクリーンペインタのレイアウトエディタの入力項目の属性。
　(標準テーブルのどこかに保存されているかもしれませんが、そこまでは不明)

レイアウトエディタの画面ショットは下記参照。
この画面ショットの一番したにある、Without templateにチェックが入っていないとこの機能が有効です。
　(日本語だとなぜか「入出力項目なし」というテキストとなり意味不明。。)

■その他参考Note
Note：734353

Note：1108179

■その他

• 入力すると文字化けするので、入力できても使用してはいけないものがある。
  ユニコードシステムの場合、APサーバは、UTF-16なんだけどサロゲートペアの文字をサポートしないため入力してはいけない
• キーボードの直接入力というより、webサイトのコピペとかで発生 

文字化けについてはトランザクションコードSCPで各文字セット毎の利用可能文字を調査可能。

得意先コード、仕入先コード、品目コードについては番号範囲チェックが適用されるため、1文字目は半角英数以外はエラーとなる。
また、品目コードについては、「&（アンパサンド）」「 *（アスタリスク）」「,（カンマ）」は2桁目以降もエラーとなります。

もし嘘ついていたら突っ込んでくだしあ。

*1:先頭一文字目に!を入れるとそのフィールドの入力文字列が消える

SAPのライセンス体系変更（Indirect Accessに対する明確化）

SAPのライセンス体系変更が発表されました。

これまではユーザーIDベースのライセンス体系が中心で、システム間連携（Indirect Access）でRFC*1とかSOAPとかRESTとか諸々のEAIツールとか、それ以外のシステム関連とか、いろんなアクセス手段があるにもかかわらず、どこまでユーザーライセンスが必要なのか明確でなかったので、歓迎すべきことかと。

詳細は以下のJSUGのページに掲載されているのでそちらをご参照ください。

間接アクセス向けの新しいライセンス体系のお知らせ | ニュース | JSUG -JAPAN SAP USERS' GROUP-

ざっくりまとめると以下のような感じかと。

• Indirect Access用のライセンス方式を新たに追加し、SAPシステム上に記録されるドキュメント（トランザクション）をベースに課金する。
  ドキュメント種類毎*2に係数があり、登録（Create）は課金対象だが、Read/Update/Deleteは課金対象外。IDOCとかもこの方式が適用されそう。
• 従来のライセンス方式で既にSAPを利用している場合、新しいライセンスモデルに移行するか否かは、ユーザー側に選択肢がある。
• 既存のライセンス（Named User単位）は、新しいライセンスに変更することができる。

従来、リアルタイムアクセスはライセンスがいるとされていた、参照系が課金対象外というのはありがたいですね。

一方IDOCなど、バッチの伝票登録系は課金対象になりそうなので要注意かと。

また、伝票系はある程度明示されてるんですが、マスタ系の取り扱いはどうなるんだろう、という疑問が。。

なお、本記事の記載はリリースを元にざっくり記載したもので、SAP社のの公式見解に沿ったものではありませんので、内容に誤りが有っても何ら保証できません。
くわしくはSAP社の営業さんに聞いてください。

*1:Remote Function CallというSAP独自プロトコル

*2:受注伝票、請求伝票、購買発注、サービス/メンテナンス指図。製造指図、品質管理、タイムシート、会計伝票、在庫。会計と在庫の係数が低い

TrackRで迷子対策

我が家の次男氏（4歳）は、遊園地で唐突に「とーちゃんバイバイ！」と走り出して迷子になったり（しかも親側が迷子になったと思っている）割とたちの悪い息子でして。

世間的に叩かれているハーネスとかも考えたのですが、流石に4歳にハーネスというのもなぁ、ということで別のツールを利用して割といい感じなのでご紹介。

www.kinakoneko.com

TrackR bravoって何？

最近、bluetoothでスマホとペアリングして失くしたものを見つける系のガジェットがいくつか出ています。

TrackR bravoもその一つ。

TrackR bravo Item Tracker ブラボーアイテムトラッカー シルバー[並行輸入品]

機能としてはシンプルで、以下のようなもの。

1. スマホとbluetoothで繋がっているいると、スマホのGPS＋専用アプリで凡その位置情報を記憶しておける。
2. bluetoothでつながっていると専用アプリから端末の音が鳴らせる。
3. bluetoothでつながっていると端末のボタンを押すと、スマホの音が鳴らせる。
4. bluetooth接続が切れるとアラートを鳴らせる。(設定次第、バッテリー消費増える)
5. bluetoothで繋がっていない時に探索モードにしておくと、他のTrackR利用者のスマホが端末を検知すると場所が通知される。

1-4が基本機能で5はまだ利用者が少ないんでおまけな機能ですね。

鍵とかにキーホルダー代わりにつけて、見当たらない時に探す、というのが基本的な使い方かと。

迷子対策に使える？

子供のリュックにつけてみました。

基本的にはbluetoothで繋がっている必要があるので、つながっているかどうかで近くにいるかどうかを判断できます。

アプリの画面はこんなイメージ。

スピーカーボタンの周りのがbluetoothの接続状態の強さを表していて、どこで場所が確認されたかが上の地図で確認できます。

（場所の更新がアプリ立ち上げ都度では無いようなので、接続されていても場所が更新されないケースも。その場合はアプリを再起動すると最新化されます）

スピーカーボタンを押すと、端末の音がなる感じですね。

実際に使ってみた

次男氏には
「この丸っこいやつの音がなったら、とーちゃんが探してるってことだから立ち止まれ」
と教えた上で二週間ほど運用してみました。

結果、2度ほど行方不明になったのですが、割りといい感じ。

ショッピングモールで居なくなったときには、bluetoothでつながっているかで近くにいるかどうか分かるので、闇雲に探す、という感じではなくなりました。

端末から出る音はさほど大きくないので人混みでは聞こえませんが、音を鳴らすと
「とーちゃーん！ここだよー！」

と叫んでくれたので、すぐに見つけられたり。

接続が切れたときのアラートは今のところ設定していないのですが、お出かけの時だけ有効にする等すればより便利かも。

子供用のケータイを持たせるにはまだ早いけど、迷子が心配、と言った同じようなお悩みを持たれている人はお試しにどうぞ。

読書感想文ってなんやねん

先日、長男氏（小1）の小学校の面談で、

「感想を言ったり書いたりがあまり上手にできないですねー。」

と言われて、自分も昔そうだったし、それはそれでいいんじゃないか、と思っていたのですが、以下の五味太郎さんの記事を見てふと思ったこと。

netgeek.biz

そもそも、読書感想文って、以下2つの大きな壁があるんじゃないかと。

• そもそも文章を読まされている
• 感想を求められていない

そもそも文章を読まされている

読書感想文ってそのきっかけが強制的なんですよね。
例えば国語の教科書に乗っている文章であったり、宿題として本を読んで感想文を書いてこい、と言われたり。

与えられた課題に答えないと、とは思うけど、求められていることが理解できていないので、「別に読みたい文章でも無いのに、感想なんて無い」「ふーん」「別に」というのが小さい頃に思っていた記憶。

感想を求められていない

読書感想文で求められているのは感想ではなく、人にオススメする紹介文なんだと思うのです。

「私はこの本を読んでこう思いました。なぜなら、こういうところが素晴らしいと思ったからです。ほら、みんなも読みたいでしょう？」
みたいなことを求められているのではないかと。

Amazonのトップレビューをコピペすれば非常に良い感想文が出来そうですね！（ダメ

読書感想文の意義

結局、読書感想文で養われるのは
「大きくなって、別に好きでもないなんの思い入れもない商品を人に売り込まないとイケない時に役立つスキル」
なんだと思う。

長男に本や文章を読ませて感想を聞いても以下のような感じ。

　自分　「その文章読んでどう思った？」

　長男氏「おもしろかった。」

　自分　「どこが？」

　長男氏「主人公がxxしたところー。(文章後半の覚えてる所)」

　自分　「なんで？」

　長男氏「……」

全くもって興味ないんだろうなー。
別に読書感想文をうまく書け、とは思わないけど、まずは興味のある事や話に出会わせてやる所からだ。

N+1問題

N+1問題ってご存知でしょうか？

N+1問題 / Eager Loading とは - Rails Webook

N件のデータをSelectした後に取得してきた1件ずつをfor文で回して再度Select処理して、N件が大きくなればなるほどパフォーマンスに影響を及ぼすやつですね。

1+n問題って言ったほうがわかり易くないか？と心の底から思っていますが。

SQLレベルだとJoinとかINとかサブクエリでSelectするとかっていうので対応できるので、まぁ作る時にきちんと気にしましょうね、という話。

ではこれがどんな時に問題になるのか、というと、ここのところAPIエコノミーみたいに流行り言葉になっていますが、APIが固定されていると問題起きがち。 

一覧取得系のAPIと、詳細取得系のAPIが分かれて実装されていたりすると、クライアント側の実装によってはすごい負荷になります。

APIをリリースする側が大量アクセスで負荷が高くなったり、クライアント側で大量のアクセスが発生してブラックリスト入りしたりするので、結局公開側とクライアント側の双方で気をつけるべき話なんですが。

なんでこんな話をしているかというと、某S社のCRMの標準APIってgetlistとgetdetailを分けて実装になっており、先日Multi Thread Programmingのブログが上がっていて、そもそもの解決策ってそんなとこじゃないよなぁ、と思った次第。

Use ABAP Multi-“Thread” programming to deal with a real performance issue | SAP Blogs