Entries

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

フレームワークを作ったっていいじゃない


> 現代の業務SI開発はフレームワークの奴隷なのではないか説 - UXエンジニアになりたい人のブログ
> フレームワークとアプリケーションの境目 - @kyanny's blog

読んでいて、共通して気になることが2つある。
ひとつは、「フレームワークに乗っかることが正義」
もうひとつは、「フレームワークを作るという選択肢はない」

そして、これらの問題提起は、「フレームワークの枠組みを超えそうな時、どうするればいいの?」ということなんだと思う。

アプリケーションがフレームワークの枠組みを超える時、1つめの正義からすれば、フレームワークにコミットしていくのが正当だろう。
だけど、それは気が引ける。そして、オレオレフレームワークは薦めない。

これはひどく消極的な話に見える。
けど、たぶんそうではない。
おそらくはリソース(主に時間か)を、フレームワークよりアプリケーションに配分したいんじゃないのか?


なんか、「知の高速道路とその先の渋滞」って話を思い出すな。
もはやレールはない。
目の前の世界は自ら切り開いていくしか無い。
ようこそ、泥臭い世界へ!

考えられる手段は2つ。
ひとつは、フレームワークの枠内に収まるようにアプリケーションを調整する。
フレームワークが求めないことはやらない。あるいは、やれるようになるまで待つ。

これを選択すると、奴隷感が増すのだと思う。
できないから、我慢しなくちゃいけないからだ。
しかし、アプリケーションの目的に対して、より本質的な理解ができるようになる。
作るためより、使うための開発になるといったほうがいいだろうか。
Excelでやっちゃう、というのはこれに近い。

もうひとつは、フレームワークに対する比重を増やす。
やり方は、さらにいろいろ考えられる。
裏ワザを使う。
リプレースする。
Pull Requestを送る。
フレームワークを開発する。
etc...

裏ワザってのは、フレームワークのバージョンアップに追随できない使い方のことね。
場合によっては、アドオン開発も含まれるだろう。

リプレースは、今までは一般的だった。
SI的というか、納品して終わり、というやつは、これでもいい。
裏ワザってのも、リプレースまで、だましだまし使うという意味合いがあると思う。

でもこれは、欠点が大きくなってきている。
従来のシステム開発は、ハードウェアスペックが貧弱だったから、ハードウェアの交換に合わせて、定期的にリプレースできた。
しかし今や、サーバーだってクラウドで、クライアントだって随時更新が必要になる。
そうしてハードウェアが定期的に一括で更新されなくなった時、ソフトウェアはどうすればいいか?

ある時期に一括して更新ができないとなると、リプレース・コストは無視できない。
置き換えるためには、従来の機能を「作り直さなければいけない」。
新しい仕組み(フレームワーク)を導入すれば、その使い方に習熟するコスト(時間)も必要になる。
同じものを作りなおすという無駄もあり、開発は長期化する。

業務SIにおいてもサービス化の流れはある。リプレースという選択は容易に取れなくなるだろう。

私は、フレームワークを作ってもいいと思ってるんだよね。
Backbone/Marionetteを使っているけど、自作していたのが辛くなってきた時に構想に近いものがあったので取り入れることにしただけでもある。

フルスタックでないとフレームワークでない、というのはRailsの成功の功罪に思える。

フルスタック型のフレームワーク・ソフトウェアは、ロックインされすぎちゃって、後々辛くなりそうなのがイヤなんだよね。
RailsやAngularJSを選択しなかった理由でもある。

例えば「仕様書を書けばプログラムが自動生成される」なんて話を聞くと、ほとんどのプログラマが嫌な感じを持つと思うんだけど、それに似ている。
フレームワーク・ソフトウェアは違う、なんてことある?

メーカーロックインは避けたがるのに、OSSならいいの?
確かに開発には参加できるけど、じゃあPull Requestを送るだろうか。


たんに古い人間なのかもしれないとも思う。
それでも、作りたいアプリケーションのためにアーキテクトするのは、開発者の誉れじゃなかろうか。

ソフトウェア開発はぬるいか?

昨日のTwitterで、ソフトウェア開発はぬるい云々、というのを見かけた。
ちょっと燃えていたらしいが、元は、想いを140字に収めようとして言葉足らずという印象のツイート。
私もよくやる。だから、それについての言及はしない。
けど、夜中(いや朝方かな)に目が覚めて、ふと思い出してつらつら考えたことを残しておこうと思う。

ソフトウェア開発がぬるいか?といえば、私もぬるいほうだと思ってる。
一番は「バグのないソフトウェアはない」ということが公然と認められていること。

多くの、ソフトウェア以外の産業では、表立って発売(リリース)時に不具合があることを認めたりはしない。
不具合が発見されれば、回収することになったりする。
でも、ソフトウェアの場合は、不具合が出ても、パッチを出すだけだ。

そりゃ、人命に関わるようなものなら、不具合が出ること自体が問題だったりもするけれど、
ほとんどの分野では、そこまで致命的なことはない。
あと、回収騒ぎになった時の担当者や責任者の評価や行く末なんて問題もあるけど、ここでは除外する。

まぁ、パッチを当てるといっても、インストールするソフトウェアの場合、ということになるかな?
ROMやCDのまま実行するゲーム機の場合は、ハードウェア準拠か。

してみると「固定化」というのがキーワードなのかもしれない。

ソフトウェアというのは、その名の通り、柔らかいもの。
柔らかいってのは、修正ができるということ。

これはプログラムに限った話でもない。

例えば、文章。
ワープロで文章を書いていると、いつまでたっても完成しない、という話がある。
印刷しないと、校正がうまくできない、とか。

一部を変更すると、全体に波及したりすることがある。
誤字や、てにをはを直すだけのつもりが、文をいじりたくなり、段落で変えたくなり、文章全体に影響がでてきたりする。
容易に変更できると、それが起こりやすくなるのだろう。

いじれるうちは、いじりたい、というのが人の性なのかもしれない。
印刷をすると、その影響を押さえ込めるのだろう。

一般の開発では、固定化の順番でスケジュールが決まっている。
そうして、固定化して後戻りできなくなる前に、その段階での不具合がないことが確かめられ、次のステップへと移行する。
してみると「ウォーターフォール」というのは、ソフトウェア以外の産業の影響を色濃く受け継いでいる、といことになるのだろう。

固定化の順番でスケジュールが決まる。つまり、マイルストーンがある。そうして、それが締切になる。

「学生症候群」と呼ばれる現象がある。
期限ギリギリにならないとレポートをやらない、という学生の習慣から発見されたということらしいけど、ひどいネーミングだと思っている。
だって、それ。学生だけじゃないじゃん。
ま、それはともかく。

なぜ人は、ギリギリにならないとやらないのか?

おそらく人は、ギリギリまで固定化したくないのだ。
そして、変更できる状態で、長く手元においておくことは、心的負担が大きいのだ。

時間的に余裕があるうちに手を付けないのは、期限までの長期にわたって、それに関わり続けることになるのを避けるためではないのか?
ギリギリになって手を付けて、締切が来たら、えいや!でリリースする。
リリースして、自分の責任から手放してしまえば、もはや変更することはできない。
そうして、不安定な状態に関わる時間を短くしようとしているのではないか?

「ウォーターフォール」が上手くいかない理由も、これでよく分かる。
ソフトウェアの開発は、上から下まで柔らかいままだ。
どの段階においても、固定化されることはない。
そうして、だから、簡単に手戻りし、スケジュールは乱れる。

だけど、ソフトウェア以外の分野では不具合は出ないのだろうか?

なわけないよね。「人はミスを犯す」
「バグのないソフトウェアはない」は、それを言い換えているだけだ。
回収までいかなくても、妥協されている不具合は、たくさんあるはずだ。
ならば、そこには避ける知恵もあるはずだ。

例えば、毎年マイナーチェンジした新機種が出るのは、不具合対策ではないのか?
固定化の後に発見された不具合は、次の機種で修正されるのだろう。
外観は同じで機種名も同じでも、同等品ということで内部が違うということはある。

新しい機種が出るたびに、「何で変えたの?」という疑問を聞くけれど、
こうなれば、理由は明白だ。
人は完全ではないから、ということになる。

ソフトウェア開発でも、アジャイル化が進んでいる理由も同じだろう。

ソフトウェアは、抱えている限り、いつまででも変更できる。
だけどそれは、いつまでも完成しない、ということでもある。
どこかで固定化は必要だ。
だけど、それはどこでやればいいのだろう?

Gitを使ったワークフローに、git-flowとGitHub Flowがある。
端的な違いは、リリースの考え方にあるように思う。

git-flowは、どちらかというと従来型で、リリースの前に正当性を確認しよう、という考え方。
GitHub Flowは、マージするときに正当性が確認して、マージしたならリリースしてしまえばいい、という考え方。

どんどんリリース(固定化)して、不具合があっても、新しいリリースで上書きしていけばいい。
まさに、ソフトウェア的だ。

そうして、これは仕事に対する取り組み方を変える。

マージしてしまえば、仕事は終わりだ。
締切まで待つ必要はない。
ならば、どんどん手を付けて、どんどん終わらせていけばいい。

学生症候群には陥らないだろう。
締切で仕事が終わる、という考え方は古いと言えよう。
締切には仕事は終わっている、のだ。

これはなにもプログラミングに限らないだろう。

ITによって、たいていのものがソフトウェア化している。
文章はワープロで書き、イラストはPCで描く。
配布だって、オンライン配信で、紙やCDに固定化する必要がない。
小説も、音楽も、イラストも。もはやソフトウェアだ。

固定化に則ったスケジュールと仕事のやり方は、ITの影響を受ける部分から変わっていくだろう。
そうして、固定化に対する責任は軽くなる。
それは、いずれソフトウェア以外の分野も、ぬるくなっていく、ということだ。

固定電話を解約しました。カケホとデジラにした理由


NTTの固定電話を解約しました。

いやまぁ、使ってないんですよね。
留守電にしたまま出ないし、最近は留守電も聞いてない。
ほとんど勧誘電話、あるいは間違い電話っぽいのばかりだし。
昔は連絡先の電話番号が携帯番号だと信頼がないみたいな話があったけど、今はもう、そんなことないし。
フレッツADSLだったころなら、あっても良かったけど、ネットはケーブルテレビにしたし。
名刺には携帯番号しか書いてないし。

じゃあなんで固定電話を保持していたかというと、なんか抵抗があっただけなんですよね。
ようは、ちゃんと考えてなかった。

去年、スマホの機種変をしたんですが、その時に契約は「カケホとデジラ」にしました。通信容量は2G。

ケータイの通話も、使ってないですよ。
苦手だから、使わないようにしてるし。
無料通話の繰越が上限になってたかな。
思い返しても、長電話したのは去年の夏に一回くらい(あれも、かかってきたんだけど)。

機種変の時も、LTEフラットを勧められました。
あんまり「カケホとデジラ」は勧めていない、という話も聞きますが。

スマホの料金も高いんで、なんとか安くならんかなぁ、と格安SIMなんかも調べたんですが、結局、通話があると、そんなに安くできない。
キャリアは高い、って言うけど、SIMフリー端末も高いしね。

通信だけなら格安SIMでもいいのかな、と思うんだけど、そもそも通信も使ってないんですよ。
だいたいWi-Fiあるし、モバイルで動画なんて見ないし、まぁこれは特殊事情だろうけど、在宅ワークなんで外出がほとんどないし。
通信容量は2Gにしたんだけど、実際、2Gいかない。

通話も通信も使わないのに、なんで一万円近い料金を払ってるんだと思うとやるせない。
とはいえ、手放せない。
仕事柄もあるし、無いと困ると思うくらいには便利に使ってるんで。

で、ちゃんと考えることにしました。
最初に考えたのは、NTT固定電話を止めること。
使ってないからね。

使ってないのに、止めるのには、なんか抵抗があった。
いろいろ考えると、「0120(フリーダイヤル)」のためだったんじゃないかと思うんだよね。
携帯からかけると無料にならない場合もあったので。
まぁ、これも携帯番号の信頼性が云々と同じで、今や昔なんだけど。

よくよく考えると、従量課金がイヤなんだと思う。
なんかの時に、急に支払料金が増えるのが困る。
普段は使わないようにしてるから、トータルでは、固定料金のほうが高いのだとしても。

結局のところ、通話のために高い料金を払ってるんだよね。

通話、無くならないですかね?
ムリか。

じゃあ、「カケホとデジラ」にして、2Gにすれば、LTEフラットより気持ち安いし、NTTの電話代を繰入れれば、まぁ、いいかな、と。

VoLTEが一般的になれば、また事情も変わるかもしれない(とはいえ、安くはならんのだろうなぁ)けど、ま、次の機種変の時ですね。

Appendix

プロフィール

いむら@fintopo いむら@fintopo

ガーデニングが趣味のフリーのシステムエンジニア兼プログラマ(フルスタックエンジニア)です。

仕事募集中です。個人なので、融通がききます。 大規模な開発はできないかもしれませんが、研究や製品開発レベルでの小規模開発、特に相談しながら新しいものを作っていくのが得意です。詳しくはWebサイトをご覧ください。
詳しくは「fintopoとは」をご覧ください。

> fintopoとは

このページのQRコード

季節暦

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。