人を動かす＆道は開ける（カーネギー本）

古典的な名著のようですが、今さらになって読んでみました。

人を動かす

人を動かす　新装版

よくある人を思ったように操る方法を取り扱ったノウハウ本がありますが、そういったものとは一線を画します。
昔から変わらない人間のサガや習性、結局は感情で動く生き物であるということを理解したうえで、いかに他者に働きかけるか・・・といった内容を当時の事例を交えて解説しています。
僕のような人の気持ちに対する感受性が低い・・・所謂コミュ障にとってはいろいろと考えさせられる内容でした。
ノウハウ本のような即効性はないものの普遍的な内容となっており、読んでおくとその後の人生において必ずためになると思います。

道は開ける

道は開ける　新装版

こちらは他人との関係性ではなく、自分の内面を扱った内容となっています。
基本的には全ての状況を好転させるも悪化させるも本人の気の持ちよう次第であるという事をこちらも当時の事例を交えて解説しています。
どちらかというとこちらの方が即効性のある内容で、閉塞感や重圧感、焦燥感にいつも駆られていて落ち着かず、体調不良にも悩まされているような状況に置かれている方はぜひご一読ください。
読むだけで良い薬となります。
実際、僕もそのような状況におかれていましたが、この本を読み進めるうちに何の行動も起こすことなく、気分がずいぶん楽になりました。

いずれも名著と言われるだけあって、どんな人でも一度は読んで損のない本だと思います。

美容院と1000円カットでは、どちらが儲かるか?―できるビジネスパーソンになるための管理会計入門!

美容院と1000円カットでは、どちらが儲かるか?―できるビジネスパーソンになるための管理会計入門!

多少古い本ではありますが、なかなか面白かったです。
有名な前作(餃子屋と高級フレンチでは、どちらが儲かるか？ (PHP文庫))は読んでいないのですが、今作は会計知識だけではなく、ERPパッケージ導入に纏わる話を扱っていてSI業界の関係者にも興味深い内容となっています。
僕にとっては今さら手に入れても遅い知識ですが、ERP導入やコンサルティングに関わるSI業界の新人さんなどは読んでみると良いのではないかと思います。

以前、ERPパッケージ導入の炎上プロジェクトに関わった結果、なんとなくボンヤリとパッケージを業務に合わせてカスタマイズするのはご法度で、業務部門の抵抗があろうとも、パッケージに合わせた標準的な業務とすることでしか、ERPの恩恵は得られないんだろうなぁ…と感じましたが、ERP導入の目的などはあまり理解できていませんでした。
この本を読んで、今更ながらこの根本のところが理解できたのがよかったです。

確かにあの時の案件も業務部門の要求を丸呑みにした奇怪で巨大なサクラダファミリアが出来上がりました。
それも当時、ERP導入を目指した企業のあちこちで起こっていた決して珍しくはない悲喜劇の1つだったのでしょうが。。

ユーザー企業のシステム部門は動かないシステムを前に業務部門から突き上げられ、障害を頻発させるベンダーを非難していました。
ただ、ベンダー側の利益の構造を考えれば、本当は極力カスタマイズを避けて、後々に禍根を残すべきではないとわかっていても、自らのメシのタネをみすみす手放すことはなかったんだと思います。
システム部門にしてもERPの知識などないですし、単なるコストセンターとしてしか認識されていない日陰の部門でしかなく、現状を変えることをよしとしない業務部門との力関係で思うように身動きもとれなかったのでしょう。
本来は社長の意向を受けたプロジェクトオーナーが全社に対して強権をふるうくらいでないと成功は望めないのだと思います。
まぁ前提がグダグダなこんな状態ではプロジェクトの失敗は必然だったんだと今では思えます。

ただ、管理会計というものも決して銀の弾丸というやつではなくて、机上の学問的なところもあるので、現実への適用の仕方を誤れば、またおかしな方向へ向かってしまうのかもしれないなとは感じました。
この本の事例にしても、わかりやすく説明する意図だとは思いますが、そのまま現実に当てはめるには適切でない表現もあるように見受けられましたし。。
やはり情報というのはそれ自体には可能性しかなく、本当の価値を生み出すのは使い手の目的意識と使い方なんでしょうね。

プログラマが知るべき97のこと

【楽天ブックスならいつでも送料無料】プログラマが知るべき97のこと [ ケブリン・ヘニー ]

けっこうかかりましたが読み終わりました。
一本一本は見開き程度のコラムなので、通勤の途中にちょいちょい読むのに適しています。
即効性のあるノウハウ本ではありませんが、一流のプログラマの考え方の一端を知ることができます。

寄稿者のみなさん頭が良いだけに難しい話が多くて、読み物としてはソフトウェアアーキテクト版の方が読みやすく楽しめたかもしれません。

最後のRuby開発者のまつもとゆきひろさんの『適切な名前をつけることができれば、設計の8割は完成している。適切な名前をつけかられないのであれば、設計者も設計を理解しきれていない。』というのは非常に感銘を受けました。
このレベルの方が語る言葉だからこそ更に重みがあります。
やはり言葉は何を言うかよりも、誰が言ったかが最も大事ですね。

【楽天ブックスならいつでも送料無料】ソフトウェアアーキテクトが知るべき97のこと [ リチャード・モンソン・ヘーフェル ]

ダメなオフショア開発

また相変わらずのグダグダなオフショア案件に巻き込まれてます。。
コミュニケーションだ～、設計書の品質が～言ってますが、聞き飽きましたわ。。
テキトーに書いたアプリ設計書を、空気を読みすぎる日本人エンジニアに丸投げする感覚でブン投げて、当然すぎる帰結として炎上を引き起こしています。

まず海外の優れた開発者の技術を買うのではなく、単にコスト削減狙ってオフショア開発するなら、バックエンドのビジネスロジックやWebサービスなどある程度定型的で手数が必要なものに限定するべきだと思います。
フロントエンドはイメージや微妙なニュアンスの部分が強く些細な変更も頻繁なので、日本語圏ではない開発者に漏れなく正確に伝わるような設計書を書くのはコストが高すぎるし困難、せっかくのユーザーからのフィードバックへの対応も絶望的に遅くなってしまいます。
そんなことをやってるうちにコード書いてユーザーに使ってもらいフィードバック回した方が早い。
キッチリした設計書なんて後付けで十分ですし、モノさえしっかり仕上がっていれば、そんなにコストかけて詳細な設計書を書き起こす必要もないでしょう。
フロントエンドを投げたいならニアショアくらいにしておくべきではないでしょうか。

また低コストな開発者は教育が必要になったりする訳ですが、所詮はアウトソーシングなので、コストを払って他社の人間を教育してもメリットはありません。
育つ頃には賃金が上がってコストが合わなくなるので、その投資を回収できないです。
他社の人間を育てる事に目を奪われている横で、社内の若手が貴重な開発経験を積む機会を奪ってしまっている事も大きな問題です。
上流工程に社内のリソースを注力させる・・・と綺麗ごとを言ったところで開発経験のない人間に、マトモなシステム設計ができるはずがありません。
結果、開発能力が弱体化、社内のエンジニアのなり損ないは社内政治命の単なる管理屋となって、最後には委託先に仕事を奪われ声がかからなくなってしまう末路が待つのみです。

とにかく闇雲なコスト圧縮志向で、コストの投資先や費用対効果が置き去りになっている感が否めなさすぎます。
何より重要なのは、とりあえず僕をショボいオフショア開発に巻き込まないでほしい・・・という事ですけどね。。

新天地でのチャレンジ

「30歳まではサッカーが嫌いだった」元日本代表・加地亮、新天地での今。(1/3) [海外サッカー特報] - Number Web - ナンバー

元サッカー日本代表、加地選手の心境は、今の僕とすごく近いものを感じました。

SIの現場でシステム開発をしてきて、今のような環境ならこれからも(多少の惰性の中で)特に問題なく仕事をこなしていけると思います。
ただ、中堅と言える年代も終わろうとしている今、ビジネスの環境や自分の体力を考慮すると、このままのスタイルの仕事をあと何年続けられるかずっと考えていましたし、生活のための仕事というものはそんなに好きになれませんでした。

縁あって新しい環境に挑戦をすることになり、おそらく様々な面で苦労はあるでしょうが、今は楽しみな気持ちが強いですし、まだまだ成長したいと思います。
もしかしたらシステムの仕事だって好きになれるかもしれません。

僕も加地選手のような強く明るい気持ちを持って、新たな挑戦に乗り出したいと思います。

派遣法改正

Yahoo!ニュース - 派遣法改正でITエンジニア30万人に迫る危機 （東洋経済オンライン）

国内のSI業界は技術者派遣なしにはなり立たないビジネスモデルになっているので、なんだかんだと言って、抜け道を考えるでしょうし、偽装請負問題のように、必ずしも法律を遵守するとは限らない(コンプライアンス？なにそれ？)ので、全体としてはそれほど悲観的な状況にはならない気もします。

それでもこの業界のかなりの部分を占める中小SI業者は大きな打撃を受ける可能性があります。
2015年問題での需要減とのダブルパンチでコア事業を持たない企業は廃業するケースも相当数でてくるかもしれません。

特定の顧客の現場で長年ぬくぬくとやってきてしまったロースキル系派遣SEも、他で通用するスキルを持たない限り、戦力外通告を受ける身分になってしまうでしょう。
僕が派遣SEから転職をした要因の１つにこの法案に対する危機感というものがなかったわけではないですし。

クラウドやパッケージの導入も進み、2020年頃にはSI業界の景色もかなり変わっているのかもしれませんね。

【SharePointアプリ】イヤなところ

この1ヶ月ほど低スキルな僕がSharePointOnline上でのSharePointアプリなんていうニッチなものを扱っていて感じたことのメモ

 

①要らんものを吐くな

SharePointホスト型でサーバーサイドが使えないにも関わらず、ポストバックを実現するスクリプトやformタグを勝手に吐いている。

それでいてプロジェクトを途中からサーバーホスト型へ切り替えることはできない。

 

②ライブラリが動かん

①のような勝手なことをやっているので、微妙なCSSも相まって(？)、jQueryのメジャーなライブラリでも動かないものがある。

iFrame化して回避できたものもあるが、それでも動かない場合がある。

 

iFrame化は以下エントリを参照

【SharePointアプリ】iFrame追加 - 惰ログ新館（仮）

 

③デザインが変

SharePointで指定されているCSSやデザイン要素を引き継いでいるためかtableの幅を％で指定するなどが正しく機能しない。

かといってそれらを排除してしまうと完全独自デザインとなってしまい、テーマの変更に追従できない。

 

④REST APIが使いづらい

SharePointと連携するためのAPIが使いづらい。

変数名がまちまちだったり突貫工事感も。

ファイルコピーのAPI、コピー先のパスをURLパラメータで渡す設計とかないでしょ。

深い階層にはコピーできないって？

ネイティブ言語に対応したラッパーAPIもあるが、ドキュメントなさすぎで以上。

 

⑤SharePointOnlineが不安定

急にアクセスできなくなったり、パフォーマンスが落ちたり。

今の時代、単なるGUIアプリのインストールに5分以上かかるとか許されないでしょ。

最近のMicrosoftはけっこう酷い。

グローバルトップサイトが内部サーバーエラーでアクセスできなくなった時は心底呆れた。

 

結局のところ、②の問題なども本線のASP.NETがWebフォームからMVCへ移行しようとしている理由の1つなのだろうけれど、SharePointアプリはニッチ過ぎてこのまま放置されるんじゃなかろうか。。

 

旧来のような業務アプリ作成時のWebフォームの生産性は一目置くところがありました(新しいものは高度化しすぎて一見さんお断り感が激しかったけど。。)が、正直、個人的にもSharePointアプリだけはもう勘弁といったところです。。