小さいとこだと、管理者に任せっきりになってるんじゃない？って思います。
（うちもそうだけど）
で、うちの場合の話だけど似たようなとこ多いんじゃない？って感じで
結構我流というか知識量あんまりないんだろうなーってレベルで
管理してるからなんか効率悪いし、
それぞれPC扱う人間もなんかわからんけどーみたいな感じで
PCに関しては分かんなくても許されるみたいなのがずーっと続いてる感じなので
余計効率が悪い。
クルマに例えるなら、オイル管理エア管理くらいのことを管理者が我流でやってて
工具とかをいい加減なのを使ってたりする。
使用者はガソリン入れたら車は走るもんだというくらいにしか思ってなくて、
オイル管理やエア管理なんてのは意識にない（本来はそれくらい自分ですべき事だけどね）。
で互いに仕事したつもりになってる。
GSや整備するとこに定期的に任せる形で、使用者自身が自己管理して、
管理者は自己管理の徹底や問題の先読みや改善に努めて、業者に任せてしまえば
業務量とかは減るし、状態もいい状態が保てると思うんだけどね。
完全に調子悪くなってから業者に出すからどうしょうもなくなって
余計にコストかかるってこともなくなると思う。
PCとかITも同じようなもんじゃない？
毎月末、請求書を送らせていただき、入金確認する時に、社会性が全くない高収入ニートみたいな生活ができてることに、つくづくプログラミングは魔法だと思います。ちなみに商売替えしてからプログラムで売り上げをあげるために、家から一歩も出たことがありません。顧客とお会いしたことも一度もありません。
自分の構想にしたがってプログラムを組むという甘美な喜びに浸っているうちにプログラムが出来上がり、それが付加価値を生み出して、ここが重要なんですけど収入を生み出す。
問題の解決方法を効率よく記述できる方法を考えて、それを実装しその工夫が非常に効果的だった時はとても満足です。
実装が容易で、テストも容易な設計を考案できた時にもすごく満足を感じます。
この問題の解決方法を考えられるかできないかのところに、バカの壁があり、そこを頭の体操を楽しむ感覚で効果的なやり方を考えるこどかできるかが勝負です。バカの壁でギリギリ乗り越えられるのを選ぶと、だいたいブルーオーシャンでそれが商売のポイントです。
アカデミックな興味が集中するところはレッドオーシャンなので、頭の良い人に任せた方が良いです。世界には宇宙人みたいな天才が、山ほどいますから。
この商売の素敵なところは、寝てる間とかボケーっとテレビ見てる時とか、サーフィンしている時とかに、すっと洗練された解決方法を思いつくことです。
SIerはかき集めた人で作業できるように基本バカの壁をかなり低めに設定してるので、凝った難しい問題は職人肌の仕事人だけが超えるようにできてます。その中から、ビジネス的に美味しそうで、かつ、自分が超えられるものを選ぶのがフリーランサーのプログラマの一つの勝ちパターンです。
収入と労働時間を知る知人と家族の中には、私の仕事に「違法性はないのか」と真顔で心配する人もいます。もちろん、合法で倫理性には一点の曇りもありません。
世の中広くて、私よりももっともっと頭も稼ぎの良い人はたくさんいるので、日々精進して魔法をもっと効果的に使えるようになって、たくさん稼ぎたいです。
大した資本もいらず、ソーシャルネットワークを整備する必要もなく、ひたすらコードを書けば、それで終わり。
やっばり魔法だとつくづく思います。
私は小さなことでもどんどん報告して欲しい派です。ただ、不具合っぽく見えても、
- プログラムの不具合: 仕様どおりに動いていない
- 仕様の不具合
- ユーザが想定しているワークフローと仕様に齟齬がある
- インタフェースや慣習から想定される動作と仕様に齟齬がある
- 補助情報(ドキュメント、オンラインガイドなど)の不備
- ガイドと実際の動作で印象が異なる
- ユーザが迷った時に必要なガイドにすぐに到達できない
- チュートリアルが必要なのに不十分
などいろいろな理由があり得ます。さらに、プログラムの不具合だったとして、特殊な条件が重なった時だけ出現するので報告を受けたプログラマの手元では再現できない、ということもよくあります。
なので、
- 何をしようとして
- どういう操作をした/入力を渡したら
- こういう結果になった
- しかし私はこういう結果を期待していた
- なぜなら… (通常業務ではそうだから/それが自然に思えたから/前のツールではこうだったからetc.)
といった点について具体的に記してもらえるととても助かります。その動作が起きた状況を再現できるデータがあるとなおよろしいです。
ユーザにとっては、期待している動作と結果が食い違ったら不具合に見えます。それは実は仕様で想定しない使い方をしていたからかもしれません。仕様を実装する仕事の人は、それを不具合と言われるとカチンとくるかもしれません。でも、システム全体として見た場合、ユーザに使い方を誤解させるならそれは仕様か運用に問題があるということです。誤った使い方ができないような設計にしたり、誤解が生じやすいならチュートリアルを入れるといった配慮が必要かもしれません。
ですので、報告自体を控える必要はないと思いますが、問題を切り分けられるように丁寧に報告して頂けるとよい結果を生むのではないかと思います。
以前在籍していた会社でSKYSEAを導入しました。導入担当者と運用管理者という立場で接しました。
抜け道としてはほぼないと思ってください。なにかしたら大抵バレますので。例えば、特定端末でSKYSEAがインストールしてあるけど、○日間SKYSEAが起動してないとか、「いまSKYSEAが強制終了されました」とかもリアルタイムで見れます。
逆にそういう特徴のある動き以外はほぼ見ませんでした。
- 30分PCが動いてない->来客中
- １時間PCが動いてない->会議中
- １日PCが動いてない->倉庫で資料整理してた
等、PCの動きから何やってるかを推測することはほぼ無理です。
本当にサボっていた場合、アウトプットが少なくなると思いますし、そちら方面から目をつけられ何やってるか調べてくれという形で該当者の直属の上司から調査依頼がくるという形で何らかの事態は発覚することはあるかと思いますが、サボっててもちゃんとアウトプットがあれば特にそういうこともないかと思います。
私としては、PCの資産管理やトラブルが発生したときの後追い（こういう操作をしたらエラーが出た）、リモートでのQA（遠隔拠点の相手に対する操作説明）などがメインの用途で、人の管理には使えないという印象なのでそこまで神経質になる必要はないかとおもいます。
あえて金銭的な成功という一軸に徹して書いてみます。あまり通念的なことは書いてないので、不愉快に思われたらすいません。こんな変わった異論もあると軽い気持ちで読んでやってくださいませ。
やらないこと
- 自分自身を労働市場で売ること クラウドソーシングとかマジ勘弁
- 流行りを追いかける
- 時間単位で生産性を計ること
やること
- 自分しか知らないこと、できないことで他に競争者がいない領域を作る
- 自分が所有管理するソフトウェア資産を築く
- ライセンスもしくはサーバーベースのサービスとして提供する
- ユーザーと一体化しニーズを細かいところまで熟知する
- ソフトウェアをゆっくりと品質重視して作成する
- 商流を作り販売者が利益をあげれるような仕組みを作る
- 1〜5年先の未来に集中する
Javascriptのフロントエンドのギミックとか、あるサービスのAPIを徹底的に研究するとか、もう少しマニアックに国際調達している会社向けに、為替と商品相場と先物取引市場の現状を分析して自動的に計画を作るソフトを作るとか。
限界費用が1/nになるという性質があるので、先行すれば圧倒的に有利で後発は追いつけません(nは開発費です。)。逆に先行者がいる場合には、追いつくまでがかなり大変です。ただし、開発が実質止まっているプレーヤーもいるので競合次第です。
年間10億ぐらいの小ぶりな市場で良いので、そこで競争力を確保すれば良いのです。なんか、全ての問題が金の山に見えてきます。
世の中あなたによって、スマートに解決されるのを待っている金を生み出す課題で溢れています。
あー、「寝言は寝て言え」ですね。
とりあえずこの2人の言葉を投げつけます。
「Clean Architecture」ではこう書かれています。
先ほどの開発者のごまかしは、崩壊したコードを書けば長期的には遅くなるものの、短期的には速度が上がるという考え方にもとづいている。このことを信じている開発者は、崩壊したコードを書くモードから、いずれどこかでクリーンにするモードに切り替われる、というウサギのような自信を持っている。だが、それは事実誤認である。事実は、短期的にも長期的にも、崩壊したコードを書くほうがクリーンなコードを書くよりも常に遅い。
「レガシーコードからの脱却」ではこう書かれています。
… (もっと読む)最高の開発者がいちばんきれい好きな開発者であることに気づいたとき、私はびっくりした。速いプログラマーは雑なプログラマーだと思っていたからだ。だが、実際は正反対だった。
(中略)
コードを書く速さとコードのきれいさに関連があると認識したあとでも、私はその2つのあいだの因果関係を見つけるのに時間を要した。コードの品質を高く保っていた「にも関わらず」速いのではない。コードの品質を高く保っていた「からこそ」速いのだ。このことを理解したら、ソフトウェア開発に対する見方が変わった。
んー。
これは相対的にトップがクソに見えるだけ。だと私は思っています。
日本社会は、と言ってるので恐らく海外比だと思います。
海外だと逆でトップがダメなら生き残れないのでダメなトップがいないだけです。厳密にはいないわけではないのです。すぐ淘汰されてしまうだけです。
これは末端まで仕事を回せないからです。
アメリカなんかがその最たるシステムですが、仕事を辞める時でも引継ぎがないです。ある意味システムができているように見えるかもですが、反面それだけ機械的に動いているだけだった。とも言えるわけです。
日本においてでいえば責任が末端まで分配されます。その大小はもちろんありますが辞める時引継ぎが必要な程度には仕事を任されます。
どっちが優秀でとかを議論する気は無いし、システムの違いなだけという側面もありますし簡単に優劣はつけがたいのですが。
とにかく仕事の構造が異なります。
海外だとトップが引っ張らないと絶対に企業が成立しない。のに対し、日本の企業は「みんなで考えよう？」という構造（稟議的構造）で構築されている為、トップをやる人のハードルは海外より低いと思います。
もっともハードルが相対的に低いだけで、日本のトップが本当にクソなのか？というと甚だ疑問ですがｗ
でもまぁ海外でいうカリスマ的存在を必要としないが故にそんな社長はめったにいないわけですが。
どうして？と問われれば、必要ないから。と、私なら答えます。
データの破壊的変更を避け、イミュータブルにするときに適用します。
メソッド呼び出しの場合、メソッドを持ったオブジェクト(レシーバ)は、そのメソッドの引数の一つだとみなせますので、これはオブジェクト自身を変更しない、イミュータブルオブジェクトというデザインパターンそのものです。
イミュータブルオブジェクトは標準ライブラリでも多用されている技法であり、例えばJavaの場合、文字列Stringを大文字に変換するメソッドはtoUpperCase()ですが、決してStringオブジェクトが内部的に保持しているchar[]を破壊的に大文字に書き換えることはせず、変換した新しいStringオブジェクトを返すようになっています。このような振る舞いが、Stringクラスをとても使いやすくしています。
→ cf.防御的コピー
効率面のトレードオフが起きる可能性があるので、常に非破壊的にすべきとまでは言えませんが、ライブラリを書くとき、呼ぶとき、呼び出す操作が破壊的か非破壊的かは常に意識すべきことです。言語によっては配列やリストのソートなどは、破壊的と非破壊的の両方があって、どっちがどっちか覚えるのが大変です。関数型プログラミングスタイルを適用すれば、常に非破壊になるので覚えなくて良いので楽です。
0 件のコメント:
コメントを投稿