内容をすぐに忘れてしまう
読書についてです。本を読んでいて話の断片は覚えていてもほとんどの内容を忘れているということが多いです。おかげで同じ本を何度も楽しめるということはあるのですけど、そもそも自分が生きている間に面白そうな本をすべて読むのは不可能なのでそんなメリットはいらないわけで。
読んでからしばらく立つと忘れるというのであればまだましですけど、読んでいる最中なのに登場人物の名前をちゃんと覚えないまま読み進むなんていうこともままあってひどいですよね。読み方が悪いのでしょうか。
できるだろうけどどの程度簡単にできるかが分からない
スマートデバイスアプリケーション開発でのハイブリッドアプリケーションというかHTML5利用、比較表上はネイティブアプリケーションよりも良さそうですよね。なんと言っても開発言語Webシステム同じなので要員確保に困らなさそう。それを言ったらAndroidだってJavaなので要員は多そうですけどSI開発におけるJava開発要員がAndroid向けのコードを書けるという印象はあまりないようで要員確保に課題があるという認識は持たれています。
そんなわけでハイブリッドアプリケーションでの実現というのがデフォルトの選択になってくるわけですが、問題なのはUI周りでの工夫が必要になる場合。ネイティブアプリケーションだったら実現可能性やそれがどの程度の難易度なのかがある程度見当がつきますけど、ハイブリッドアプリケーションの場合は技術的にはできると思うけど具体的にどうやればよいのかわからないし、どのぐらい難しいかもわからないということになってしまいます。無理じゃないというは困りますよね。
自分の実力では無理とか実現が大変なのでコストがかかるとか説明するにしても、説得コストがかかりますしなんだかんだで面倒ですよね。
標準と独自
技術の選択をする際に標準的な技術を使うか独自技術を使うかを判断する場面があります。基本的には標準的な技術を使うことになるのですが、標準の基準がずれていることがたまにあります。
自分視点の標準：世間的に使われている商用ないしはオープンソースの技術。問題があったときにはWebで情報を探すか、商用製品であればベンダーサポートに問い合わせ。
社内的標準：自社ないしは関連会社の技術。問題があったときは開発部隊に問い合わせ。標準といっている割には使っていない人も意外と多い。
世間的に使われいる技術だと同じ目的に対して選択肢がいろいろあるのでプロジェクトによって選定するものが異なり、社内の広い範囲を見る立場の人からしてみれば、プロジェクトで独自の技術を使っているという見え方になるのでしょう。
社内的標準が目的に対して適切な手段であればよいのですが、無理筋なのにごり押しされると、(自分視点での)標準的な技術を使わずに社内ローカルのものを無理して使わないといけないなんてみたいな気分になってしまいます。
ソースコードの作成は設計か製造か
多くのSIerにおいてはソースコードの作成は製造という扱いで設計とは明確に区別されていることが多いと思います。ところがマスコミの報道ではソースコードのことを設計図と表現するのが一般的のようで、ソースコードの作成は設計を含んでいるというか設計が主になっているという扱いです。
プロがいっているのだから専門的に見れば製造の方が正しいのだろうということなのかもしれませんが、自分の感覚とは合っていません。
あくまでも私が知っている範囲の話ですけど、SIerが設計において作成する設計書というのには外部設計書と内部設計書がああります。内部設計書は完成予想図・取扱説明書・スペックシートあたりの内容で、設計も含まれていますがこれだけでは設計としては不十分。内部設計書はソースコード作成にともない加筆・修正が多く発生するという状態で、ソースコード作成前に設計が完了しているとはとても思えません。
別の観点で考えると、たとえば工業製品において設計図の漏洩と製造物の漏洩でどちらが問題かというと、設計図の漏洩の方が問題が大きいと思います。一般的には製造物は販売されているのに対して設計図は公開していないことが多いので。
ITシステムではどうかというと、完成したシステムの設計書の漏洩とソースコードの漏洩ではソースコードの漏洩の方が問題が大きいケースが多いのではないでしょうか。なにせソースコードがあれば特殊なものではない限りシステムを利用可能な状態にすることができますので。
そういう意味でもソースコードを製造物としてみるよりも、設計図と表現する方が実態に近いのではないかと思います。
余談ですが、完成したシステムの設計書通りに別のチームが開発を行ってほとんど同じシステムが作れるケースってどの程度あるのでしょう。設計書ないしは設計図からの再現率を比べるとほかの業界とはかなり差があるのではないかと勝手に想像しています。
さらに余談ですが、昔からいわれている「ソフトウェア開発においてはビルド＝製造」というのをだらだら書いてみただけです。
整理された情報が欲しいけど内容が古い
iOS用アプリケーション作成についての知識を仕入れるに当たって、情報はWebで検索すればいくらでも見つかるのですけど、どうしても断片的な情報が多く最初の一歩には向かないことが多いです。
上手に探せばよいコンテンツを見つけることができると思うのですけど、善し悪しを判断できるレベルでもなく時間がかかりそうなので入門書から入ることにしました。
入門書も断片的と言えば断片的なのですけど、自分で検索するとついつい自分が見たい情報を絞り込んでしまうのに対してある程度幅を持った知識が手に入るので悪くない手段だと思います。
本を読み進めていったのですけど内容が古さが気になる箇所が出てきました。今回はXcodeのバージョンですね。書籍内で使用しているXcodeのバージョンが違うせいで操作方法が違うところがありました。
それぐらいは補完しながら読めばよいのでしょうし実際そうしましたけど、開発初心者が初めての入門書として使うことを考えると厳しいのではないかと思います。
自分がアプリケーション開発を始めた頃は今よりも変化がゆっくりだったので書籍や雑誌での時間差はあまり気にならなかったのですけど、今の人たちはどのように折り合いをつけているのでしょうか。
何かを買うには何かを捨てないと
要は部屋が狭いと言うことなのですけど、新しいものを増やそうとすると場所を作るために今持っているものを捨てないとだめというようなことになっています。
もう一生使わないだろうなと思うものもあるのですが、捨てるとなるともったいないし面倒だしで躊躇してしまいます。
その点電子的なコンテンツは場所をとらないので気が楽です。ディスク容量が足りなくなるという問題は出てきますが、自分が使っている用途ではそれほど容量が必要なものがなくてかなり余裕があります。
