行動指針

僕のこれまでの人生の選択や生き方を振り返ると、いつも指針となっていたのはそれが『楽しい』かどうかだったと思います。
最近はいろいろと考えすぎて悩むことも多くなってきましたが、きっと自分にとって『楽しい』かどうかを判断基準にすれば、それほどハズした選択にはならないのではないかなと。

他人の事を気にしながら生きても、100％満足させることなどできはしないし、僕の価値観は『楽しい』かどうかなので、人生を終えるときに満足できるか否かは『楽しかった』かどうかにかかってくるのではないかと。
これからもそういった選択を積み重ねていく人生を歩んでいきたいなと思いますね。

あまり複雑に考えすぎずにシンプルに『楽しく』

技術力と組織の評価

どこの会社でもエンジニアとしての実力と社内の評価というのは必ずしも一致しない。
この場合、いくらがんばって技術力を見せつけても評価は変わらない。
そもそも会社や上司は技術がわからないし、価値を見出していないのだから。
躍起になって自分を認めさせようとしても、扱いづらい部下というレッテルを貼られるのがオチ。

ここでの選択肢は2つ。
評価を得られるよう自分が軽視、軽蔑している対象のようにも振る舞えるバランス感覚を身につけるか、もしくは自分のやりたい事にフィーチャーして組織の評価などは捨て置くか。

僕個人はどちらかというと後者を選んできたけれど、組織に生きるオッサン的にはやはりバランス感覚が必要なんだろうなぁ。
そのあたりが最近のテーマの１つというか悩みどころ。
とはいえコミュ障をこじらせていることもあり、サラリーマンスキルっていうのは全く適性がないんだよなあ。

本質的にはビジネスに貢献していることを誰の目にもはっきりわかる形で示せればよいのだろうけれど。。

テスト自動化

業務中にプログラムテストの自動化に関する話題があがったので、現時点での個人的な印象をまとめてみます。

ちなみにターゲットは現地稼動まで自社で請け負うパッケージ製品となります。

テスト自動化に適する対象は以下のようなものだと考えています。

項目	向いているもの	向かないもの
変更	頻繁に手が入る	完成するとほぼ手が入らない
寿命	長期的に使われる	使い捨て
テストコード	定型的であり自動生成が可能	定型的に作ることができない

前者であれば、再テスト時のテスト工数の削減などテスト自動化のメリットを最大限に享受できます。
逆に後者であれば、テストコードの作成が単純な工数増に繋がるだけとなるだけとなります。

今扱っている素材は後者に類するものが多いです。
この場合は自動化をいったんあきらめ、マニュアルを充実させて、人系で多能工テスターを生み出す方が良いと思われます。
マニュアル化することで、現地の運用テストなども、業務知識を持たない外部のリソースでもテストが実施できるようになるでしょう。

ただし、以下の点には注意が必要と思われます。
・現地テストで得たノウハウを漏れなく吸い上げる必要がある。
・仕様の詰めや顧客との接点、製品の実装はあくまでサービス提供者が握る必要がある。

これまでのお客さん達を見ていても、サービス提供者として、顧客の肌感覚や接点、技術力を失うのは致命的だと感じています。
効率化すべきところ、握るべきところは明確に意識して、単なる仕事の丸投げとならないようにしなければなりませんね。

テスト自動化から業務の効率化と注意点に話がそれてきたところで終了。。

転職前後で変わったこと

まだ転職して日が浅いので、転職の成否の最終的な結論は出ていないのですが、現状の感触を整理してみました。

転職前後での変化

内容	転職前	転職後	評価
通勤時間	2時間	1時間	◎
給与	並？	変わらず	○
会社規模	小規模	中規模	○
業務形態	派遣	自社	◎
業務内容	新規開発	既存保守	△
開発対象	他社製品	自社製品	◎

通勤時間が半分になったことで単純に楽になりました。
また平日に家族で過ごす時間が増え、生活の充足度という意味では大きいです。

給料はあまり変わらず。
そこを求めての転職ではないため、あまり問題と感じてはいません。
会社さえコケなければ、将来的には以前の会社に留まるよりは少しくらいの上積みはあるはずです。

会社や業務内容という意味では、やはり社内で自社製品を扱うというのは大きいです。
まだ見習い期間でサービス提供者の責任というものを背負っていない部分はありますが、心理的にも他社のお手伝いではなく、自社の製品であるというのはひとつのポイントです。
ただ、実際にその環境を得てみると、会社≠自分な訳で新たなジレンマ。
結局は自分でサービスを生み出さない限り、このギャップは埋まらないのでしょう。
それを実現する意気込みと覚悟(と能力？)を持てない現状ではそこまでは望めないかもしれません。

今まで新規開発ばかりに携わっており、ほとんど保守をしたことがありませんでした。
真っ白なキャンバスに絵を描くのに慣れた身としては、他人のソースコードを弄るのはあまり好きではありません。
この点、最終的には新製品の開発に携わっていければと考えていますが、長期的な視野での保守性を考慮したシステムを設計するうえで、保守の経験とノウハウは活きてくるはず。
また単純に業務知識ゼロなので、勉強のための教材としても悪くはないかと。

気を付けなければいけないのは、社内で自社のSEと仕事をするという環境。
居心地は良いかもしれませんが、その環境と現状に甘えないようにしなければいけないですね。
会社として小さいながらも現時点では業界内で一定のポジションを築いているとも言えますが、将来的なものまで約束されているわけではない(まあ、今のご時勢そんな会社の方が少数派ですが。。)ので、社外でも通用する人材となる事は常に意識し続ける必要があります。

ということで、総括するとこの先はわからないものの、現時点ではおおむねポジティブな面が多いということになるのでしょうか。

それよりも今回の一連の活動で一番大きかったのは、『何かを望み、それを実際の行動に繋げることができれば、年齢関係なく状況を変えることができる。』ということを認識できたことでしょうか。

Webアプリとネイティブアプリ

ここ最近のお仕事でSharePointアプリなんていうニッチなもので、SPAモドキを作りました。

ASP.NETに頼らないWeb開発的なものは初めてだったのですが、JavaScript、HTML5、WebAPIでここまでできてしまうとなると、ネイティブアプリの優位性はどこにあるんだろうと考えてしまいます。

オフラインでの利用というのは1点あるのかもしれませんが、世の中的にもはやネットワーク接続は前提になる方向なので、そんな考え自体がナンセンスになっていくのではないかと。
どうしてもオフライン利用がしたいなら、Windowsストアアプリ化すれば、Webの資産をアプリ内で抱え持ちしてオフライン利用も可能にできますし。
WebAPIが使えない場合の考慮は必要になりますが。。

あとはせいぜい見栄えやアニメーションくらいなので、必要となるのは豊かな表現やレスポンスが要求されるゲームくらいで、一般的な業務アプリやサービスはWebアプリで十分な気がします。
Webアプリであればブラウザを意識する必要があるものの、プラットフォーム依存は考慮する必要がないのも魅力的なメリットにうつりますね。

タッチ操作に対する考慮と従来のインターフェースとの両立というのが、現時点では課題に思えますが、端末判定とCSSの組み合わせとかで乗り越えていくのでしょうか。
誰か頭の良い人がもっと斬新なアプローチを考えてくれませんかね。

今年一年のお仕事総括

今年は例年より仕事に恵まれた感がありまして、WPFやWindowsストアアプリ、Microsoft系のクラウドサービスなどこれまでより技術的に新しい分野のサービス寄りの仕事ができました。
イチからのアプリ開発を存分に楽しめましたし、日常の学習を含め、これまでよりも技術力を伸ばすことができ、収穫の多い一年だったのではないかと思います。

それでも仕事面を総合的に評価すれば、年齢なりの職責という意味では、全く物足りない点も多々あります。
この点に関しては、現状の環境のままでは改善は難しいということもあり、継続的に転職活動に取り組み、なんとか新しい環境を手に入れることができました。
これもまた大きな収穫のひとつであると思います。

そういうわけで来年は大きな変化として新年より新しい会社に移る・・・というイベントがあります。
そこで現在の僕の最大の弱点である業界に特化した深い業務知識やマネジメント能力を手に入れたいと考えています。
また当面は.NET製の自社パッケージの保守業務がメインとなる想定ですが、早い段階で力をつけ、いずれは新規パッケージの開発を担当していきたいと考えています。
そう考えると、今年手がけたMicrosoft系の新しい技術も活きてくるのではないかなぁと思います。

年齢的なものを考えても、あまり立ち止まっている時間もないので、来年は仕事に全力投球することになりそうです。
転職先が全ての問題を解決してくれるパラダイスと考えられるほど若くはないですが、高いモチベーションを維持できているので、今から年明けが楽しみです。

アプリ開発の問題点

今の現場のアプリ開発の問題をあげてみたいと思います。
底辺現場らしく、非常にレベルが低い問題点であることにそもそも大きな問題を感じざるを得ませんが。。

まず顧客の資料の提示が遅く、設計がなかなか確定しない。
正式な資料が提示されても、細かい挙動について、Q&Aのやり取りが多々あり、更に実装が遅れる。
顧客としてはUIの動きを確認したいので、早めにβ版が欲しいと要求するが、提供したアプリは開発遅れのキャッチアップ中で、マトモに動かず不興を買う。

もう少しマネジメント側で顧客を上手くコントロールしてくれ…というのは言っても詮無い話なので割愛。。
開発側としてウォーターフォール型のアプローチでは無理があるので、画面モックだけを作り上げ、顧客に提供、フィードバックを得る一方、裏で共通部品作成、内部ロジックの作成などを進める。
顧客との合意が取れ次第、一気に組み合わせてテストまで完了させる…などなにがしか別の方法論を考える必要があると思うのですが、毎度同じ失敗ばかり。。
結局、僕が力技で間に合わせてはきたけれど、スキルの属人化に警鐘を鳴らすも虚しく、僕が抜けてしまえば完全に修羅場注意報です。

スケジュール管理にも疑問を感じます。
あくまでも人月は対お客さんに見積もり(=プロジェクト予算)を通すための(一見すると定量的に見える)道具でしかないと認識しています。
横着してこれをプロジェクト内でそのまま使おうとするから話がおかしくなると考えています。
今の.NETは昔のVBみたいにアホでも組めますってものではなくて、一見さんお断り感ハンパないですから。。
知っているか知らないかだけでパフォーマンスは天地の差なので、新規参画者の学習期間を設けないのであれば、スキルを無視して均した人月計算など無意味です。。

今後のお仕事で、もし自分がプロジェクトを主導できる立場になれば、もう少しマシなアプローチを取りたいなとは思います。
そういえば、アジャイル開発の本とかも積んであるのだけど、全然手付かずだなぁ。。