コンウェイの法則と企業情報システムアーキテクチャ
コンウェイの法則とは
The organization of the software and the organization of the software team will be congruent, (中略)If you have four groups working on a compiler, you’ll get a 4-pass compiler
訳すと、
『ソフトウェアとチームの構成は一致する。4つのグループでコンパイラーを作れば4つのコンパイラーができる。』
もうちょっと意訳すると
「アーキテクチャは組織に依存する」
という話ですね。
以下の記事ではOSを例に挙げており、なるほどなぁ、と思ったり。
コンウェイの法則（Conway's Law） - Plan9日記
3機関が協業した複雑なMulticsに対して少数精鋭の研究者がシンプルに作ったUNIX。巨大化する商用UNIXと、原点回帰したPlan9。Microsoftの発展と、MS-DOSからWindowsへの流れ。オープンソース革命とLinux。
ソフトウェア開発においては、
開発チームの構成に依存してアーキテクチャが決まる為
逆に
アーキテクチャに応じて開発チームを構成すべき
とも言われたりします。
コンウェイの法則と企業情報システムアーキテクチャ
よくソフトウェア構成や開発について言及されるのですが、企業情報システムアーキテクチャにおいても同様だと思っています。
というかそういう例をクソほど見てきました。
旧来の企業情報システムは組織ごとにシステム化が進んできました。
財務会計、出納、外貨管理、人事、在庫管理、生産計画、生産管理、設計、受発注などなど。
1990年台後半からERPが流行り始め、システム統合が進みました。
ERPといえば
「ベストプラクティスがー」とか「BPRがー」とか言われますが個人的にはどうでもよくて、
アーキテクチャ観点での本質は
「組織間のデータの共用化」
だと思っています。
本来的に企業の組織は相互に影響し合う振る舞いが必要で、これまでバッチでインターフェース連携していたのが、ERPになって、データの連携が自動化・リアルタイム化されて、また、領域をまたいでデータが見られるようになった。
が、最近はSaasやSoEやSoRといった考え方で、部門ごとにシステムを切り出す方向にトレンドが流れている。
多分その流れは止められないのですが、これをIT部門が弱い企業で進めると、かなりカオスになります。（というか、なっています。まじで。）
システムを分ける、というものの、一度ERPで実現したシステム間の相互連携は必要で、個別システム化にあたってのポリシーがないと、ツギハギだらけの増築を繰り返したいびつな旅館みたいなシステムが出来上がります。
利用言語、OS、MW、基盤の乱立、システム間連携のトポロジー複雑化、言われるがままに仕様追加してスパゲッティ化した仕様やコード、再利用なんてとんでもない。
企業の場合、アーキテクチャに応じて組織を設計する、というのは難しい話。
組織毎のシステム構築の流れが進む今、全体を俯瞰して計画する従来のEAを推進するような役割とアーキテクチャに対する原則やデザインルールなんかを整備できない企業は、気がついたら90年代以前の手がつけられない情報システムの状態の再来を招くことになりそうです。
slackのSAPとの提携
周りの人何人かからコメントを求められたのでメモ。
SlackがEnterprise Gridのリリースと合わせてSAPとの提携を発表しました。
Enterpsise Grid自体は期待できますね。
BIツール連携みたいのも考えているみたいでエンプラIT屋として、Sharepointや糞手組みポータルに変わる社内コミュニケーション手段として胸躍るものが有ります。
記事中にも有りますが、企業知識ベースを意識したFacebookのWorkplace、MicrosoftのTeams、Jive、CiscoのSparkといった最近新たに出てきているトレンドかと。
ただSAPとの提携の話を合わせてリリースしたのはEnterprise Gridリリースの釣り感があります。
SAPとの提携とは
Enterprise Grid、関係ありません。
SAP的には、経費精算のConcur、人事管理のSuccess Factors(SF), PaasのHANA Cloud Platformの3クラウドサービスに係るchat botをリリースしたよ、という話。
Enterprise Gridと関係なく利用可能です。
botの詳細は以下参照。
まだベータ版のようですが、旅程の確認や経費精算のレシートアップロード、経費精算申請に対応しているよう。
Driving Conversational HR with the New SAP SuccessFactors Slack Bot | SAP Blogs
SF上でのアクティビティやアチーブメントの登録やフィードバック、レビューなんかができるそうな。
HCPに関する情報はまだなさそう。
Slack提携へのSAP屋としての期待
SAPとしてはSAP Jamやワークフロー関連のタスクリストなど、コラボレーション系のツールはあるものの統合は進んでいない印象。
ビジネスソリューションというよりもプラットフォーム型のソリューションで、既にFacebookやMicrosoftなんかはSNSで培ったノウハウを持っておりSAPが新たに入り込むのはどうかなぁ、というのが個人的見解。
餅は餅屋というか、SAPとしてSlackやそMicrosoft、Facebook等のソリューションと連携してワークフローやコラボレーションを実現していくような形にすすんでほしいなぁ、などと。
【Memo】ABAP CDSビューについての雑記
ABAP CDSとは
S4HANAがリリースされて冗長テーブルが排されて、テーブル構造がシンプルになった代わりにABAP CDSビューという、アノテーションで計算処理とか色々できるView機能がABAP CDSビュー。
ABAPの移送機能が使えるのでHANA単体のCDSよりも推奨される。
このあたりが参考によさそう。
Getting Started with ABAP Core Data Services | SAP Blogs
SAPエンジニアがABAP CDS取り組むべき理由
非正規化されてた集計テーブルとか多数の冗長テーブルを無くせたのは、CDS Viewで従来のDBでは重くてできなかった処理をDBにpushdownできたから。
それ故、標準を触る上でCDS Viewの理解は必須。
さらに、従来ABAP の内部テーブルでぶん回してたアドオン処理もDBに寄せれてアドオンも楽になるし、ついでにOdata化とかAnnotationでできるようになってるよ。
CDSビューとUIの関連
CDSは単にビューを作るものではなく、データモデリングを行うもの。
エンティティ間の関係性をCDSでモデリングし、そこにくっついてるAnnotationを元に、UIはFiori Smart Templateで自動生成しちゃう。
更新系だとBusiness Logicの実装にBOPFも必要。
参照系も更新系も（分析系も）同じモデルをベースに作ることになるイメージ
BOPF関連リンク
https://archive.sap.com/documents/docs/DOC-45425
https://blogs.sap.com/2018/05/01/where-to-find-learning-material-about-bopf/
https://sapyard.com/bopf-for-beginners-part-1-introduction/
データマネジメント観点でのCDS View
データの利活用って観点を入れた時に、上記の自動生成系UIとデータモデルが密結合になるアーキテクチャが良いのか、っていうのは正直疑問だなー。
非正規化してCDSで加工して見せるというのは大賛成だけど、CDSやUI生成ツールの特性に合わせて、データモデルが制約を受けるようなケースが有ると望ましくない。
DAとアプリケーションは切り離されるべき。
このあたりは検証しながら考えていきたい。
お料理とシステム構築
エンプラSIな現場で料理の話をしてたら、
「そういえばこの案件で料理するのテッキーな人ばっかっすねー」
って話になって走り書き。
料理には3つのプロセスがあるなー、と。
- 作るものを考える
- 作る工程や順序を設計する
- 実際に調理する
で、なんでそんなことを考えてたかというと、日本のSI業界に対して感じてた違和感がふと胸に落ちたところがあり。
システム開発のプロセスも大きく分けて3つ。
- 企画:どんなシステムを作るか
- 計画:どう作るかの計画作り
- 構築:実際に作る
ボリュームとしては圧倒的に後ろ２つが多いですね。
で、日本のSI業界は多重構造になっていて、大手SIやITコンサルファームの人たちは、実際にものは作らないので、計画と構築が予定通りに進んでいるかの管理をする。
所謂プロジェクトマネジメント的な。
今所属してる会社もそんな人たちで溢れてますし、そこをきちんとしないと評価されないよ、と言われています。
ただ今は技術的な革新期。
新しい食材がどんどん出てるような状態で、それを知らずに管理だけするような人たちが、いつまで価値を出し続けられるのかなー、と。
個人としては『新しい食材を知り』『新しい料理を考え』『美味しく調理できる』人になりたいもんです。
ウチの現場の管理屋な人たちが料理に興味ないのも、そんな志向の違いかな、とふと思ったので。
2015年買って良かったものメモ
2015年に買ってよかったものメモ。
これも今年中じゃないとまとめる気もしないだろう、と。
Amazonで買ったものを見返してた。
Bluetoothヘッドセット
ジムに通うようになって、ipodを別持ちするのも面倒と思い、iphoneで音楽を聞いたり動画見たりしながら運動するのに、Bluuetoothのヘッドセット。
値段相応だけど、それなりに使えてます。
マイク内臓とあるけど、多分マイクは入ってないので要注意。
iPhone6sカバー
iphone6以降、蓋付きのケースが主流になりつつありますが、個人的にあまり好きではなくて、前面ガラスを保護できて、蓋なしのケースが欲しかった。
前面が画面より少し高さがあって、画面を下にして机などにおいても傷がつかないカバーを探していて、これを発見。耐衝撃性もそれなりなので良い感じ。
iPhone6S /iPhone 6 ケース カバー Sライン シリコン TPU アップル Apple アイホン ６ 【ブラック】【MiniSuit】【日本正規輸入代理店品】
- 出版社/メーカー: MiniSuit
- メディア: エレクトロニクス
- この商品を含むブログを見る
スマホ自転車マウント用ホルダー
チャリ通時のスマホマウント用に購入
6sに機種変して薄くなると、ホールド感が減ってしまいましたが、オプションで付いているスポンジを追加で貼り付けて底上げすれば、問題ありませんでした。
信号で停まった時にIngress活動などに。。。
※運転しながらのスマホ操作は禁止されています！安全運転！
ステム径に合わせて数商品展開されているので、事前にステム径を図って買いましょう。
![MINOURA(ミノウラ) スマートフォンホルダー [iH-400 OS] オーバーサイズ 27.2mm/31.8mm/35.0mm](http://ecx.images-amazon.com/images/I/51zwUPQvRzL._SL160_.jpg "MINOURA(ミノウラ) スマートフォンホルダー [iH-400 OS] オーバーサイズ 27.2mm/31.8mm/35.0mm")
MINOURA(ミノウラ) スマートフォンホルダー [iH-400 OS] オーバーサイズ 27.2mm/31.8mm/35.0mm
- 出版社/メーカー: MINOURA(ミノウラ)
- 発売日: 2012/07/17
- メディア: スポーツ用品
- この商品を含むブログを見る
モバイルブースター
iPhoneの電池を長持ちさせよう、そう考えていた次期が私にもありました。。。
が、Ingressとかチャリ乗りながらGPS動かしたりとかするとなると、そもそも浪費が激しい前提で、運用すべき、ということで。
最新は20100Ahですねー。
急速充電対応ですが、ケーブルも急速充電対応が必要なのでケーブル選びも注意しましょう。
みよーん、てなるやつ。
肩こりが酷く、この手の肩こり対策グッズは結構いろいろ試しているんですが、これ、会社と自宅用に2つ買いました。
肩甲骨剥がしに必携。
酸素系漂白剤
はい、お鍋の焦げ取り、服についた汚れの漂白、洗濯槽の掃除など、何でもござれ。
大掃除でも大活躍してもらいました。
他にFirestick TVとかはやっぱ買って後悔なかったけど、特に書き出すとしたらこんなもんかなー？
2015年、転職してました。
2015年、新卒で10年勤めた会社を退職し、新しい会社に移りました。
こんな話年内に書かないともう書かないだろう、と思い、大晦日にバタバタ更新。
そもそもお前誰？
いわゆるエンプラSIerで、SAPの ERPコンサルタントと言われる免許持ちでお仕事をしていた*1人間です。
キャリア的にはちょっと変なキャリアで、ERPの導入をずっとやってたわけではなく、いわゆる周辺系含めてアーキテクチャ標準化とかのエンプラSIにありがちな重厚な感じのお仕事や、業務アプリより少し深め（？）なレイヤーのお仕事*2をしたり、データモデリングみたいな領域の事業化なんか担当してました。
言語は読んだり書いたりもできますが、あまりバリバリ開発ができるわけではない、腐れSEチックな人間です。
そもそもSAP関連の人の転職記事もあまり無いような気もしていて、叩かれるかもしれないけど、こんな人の戯れ言が書かれたエントリもあってもいいかなー、と思い。
なんで転職したの？
エンプラ向けのSIに嫌気が刺したわけではないです。
前述の多通貨、複数税率とか丸めとかビジネスロジック萌え属性持ちらしく、エンプラ系には携わっていたいなー、というのは正直な所。UI系はあまり興味ない。
あと、SAP ERPって素晴らしいんですよ。上記のビジネスロジックみたいな観点と、開発周りの機能（構成管理とか）にすごいお金かけてたりとか、業務アプリの開発基盤としてはかなり洗練されています。（データ型に金額型とか数量型とかあるんですよ！）
同じ会社に10年も勤めるとは正直入社時は思ってなかったのですが、それなりに面白いことをやらせてくれたし、事業化の取り組みなんかも好きに動かせてもらえたというところで、感謝してます。一応事業としては立ち上がったし、恩返しもできたかな？と。
一方で10年目でやめるに至った経緯は大きく以下3点。
- ウォーターフォールな人月商売に嫌気
SIer的な価値観に嫌気が刺した、というのが大きいかも。
WFでスコープ決めて、いらない機能でも作ってヘッドカウントを稼いだり、
「今の経営環境だとこっち作ったほうがよくね？」
って言っても
「うるせぇ、契約に無いもん作ろうとすんな」
みたいな。
まぁ人月/請負商売の残念なところですかね。
小規模な案件ではお客様と調整のうえ、いわゆるScrumみたいに調整できる進め方をしていたケースもありますが、基幹システムとかだと自ずと領域も広く規模が大きくなりがちなので、やはり難しかった。
- 成長の可能性
「10年も仕事してて成長って今更w」
って笑われそうですが、そんな大きな会社でもないので、人手不足感は常にありました。
そんな中で、実際問題10年も仕事して新しい事業の推進とかそれなりのお仕事をやらせてもらってると、第一人者として認知されてしまって社内であまり議論をできる人がいなくなってきてました。
もちろんマネタイズなどの話はできるんですが、その事業に対するお客様の要求や技術面とかのコアにある領域の深掘りができない、というか。
お客様のところに行って議論をしたり、SNSとかで議論したり意見交換したりのほうが楽しくなったり。
あれ？俺なんでこの会社に所属してるんだっけ？という感覚。
- お金
やっぱりお金は大事。プライベート面もいろいろある中で、嫁子供食べさせないとなので。
転職活動
転職活動、ほとんどしてません。
炎上プロジェクトの火消しをしながらだったのもあり、余裕がなかったというのが正直な所。
一応何社かは事前にお誘いを頂いていたので。
「転職しようかなぁ」とSNSで話していたら、更に数社からもお誘い頂けましたので、SNS転職は可能だな、と思いました。
転職サイトには以前から登録していましたが、エージェントなどは利用しませんでした。
転職サイトのノウハウ集なんかも見ましたが、結局転職サイトもエージェントも自分のキャリアで無理めの転職をサポートする仕組みだなぁ、というのが個人的な感想。
中間マージンがとられると給与交渉などが難しくなるかな、と考えていた部分もあるし、正直一時金の交渉のネタにしました。
それなりに実績作ってる人で、転職したい先の会社の目星がついてて、その会社に自分の何が訴求できるか考えられれば不要。
転職先の決定は、金額面/非金額面の両面でご提示頂いた条件と、各会社の文化やワークスタイルが自分の希望と一致するかで絞りました。
転職先は？
SAPとかのキーワードでRFPの出し先なんて大体両手で数えられるくらいに絞られる絞られるわけで、まぁ、その中の何処かです。
しばらくは結果残さないと行けないので、現場でお仕事しながら新しい研究開発的な話にも関わっていけるようなポジションを頂けました。
2016年もがんばるぞー。
