まず、Webフロントエンドのアプリケーションにおける「状態管理手法」とは本当は何なのかを考えてみます。
Webフロントエンドの典型的な「状態管理手法」は、以下のようなことを行います。(全てを行うとはかぎらない。一部のみを行うものもある)(括弧内ではReactの状態管理ライブラリでそれを行うものを参考といて提示)
- UIで処理対象とするデータを保持します。
- UIで処理対象とするデータを更新する手段を提供します。
- UIで処理対象とするデータが更新されたときに、UIの更新を効率良く行います。
- 外部からデータを取得し、UIで処理対象とするデータを更新します。
- サーバサイドの状態を取得し、クライアント状態としてキャッシュします。適宜キャッシュのinvalidate処理を行います。invalidateを契機にデータの再取得を行います。(TanStack Query, SWR)
- Reactの場合Suspenseで必要なデータ保持を行う
- オフライン状態を検出し、オフライン時のローカル状態更新と、再接続時に外部との相互同期をおこなう。(Firebase)
- サーバサイドの状態からクライアントサイドへの状態の移動を行う(SSR)
- データのlocalStorageへの保存復帰を行う(Redux,)
こうしてみてくると、何のことはない、「状態管理」とはアプリケーションのデータにかかわる処理全般を、一律の方針で、ライブラリ実装によって行うことです。
Reactを始めとするフロントエンドUIライブラリでは、「UI」の機能と役割がはっきりと定義されているので、残る「UI以外」を、状態管理と言っているわけです。
フロントエンド界隈で状態管理手法が乱立しているように見えるのは、アプリケーションのデータ処理一般、設計一般についてより良い一律の方針を決めたい、というニーズがあるからです。乱立というのは、アプリケーションのよりよい設計の提案が複数あるということになります。それが一つではないのは、たぶんニーズが多様なので正解がないからです。
状態管理の手法についてはさほど詳しくないですが、おそらくはHTTPというステートレスなプロトコルに無理くりに状態管理を乗っけたがゆえの混沌というところなのでしょうｗ はじめから状態管理を考慮したプロトコルであれば、こんなことにはならなかっただろうとは思いますね。
その通りです
ミュータブルオブジェクトではなくイミュータブルオブジェクトを使うという話もここ十数年の話ではないでしょうか
マイクロサービスアーキテクチャーの普及により分散システムを扱うことが一般的になり、いくつかの問題が発生しました
更に、スマートフォンの台頭によりプッシュ通知のような仕組みもほぼ必須になってきています
これらを解決するために非同期処理、リアクティブプログラミングと呼ばれる手法が使われていますが、デバッグが難しくなる等の問題もあります
先日行われたSpring FrameworkのカンファレンスではNetflixのエンジニアが「リアクティブプログラミングは私達には早すぎた」という旨の発言をしており、これらの仕組みが持っている複雑さはかなり深刻な問題になっています
Web開発技術が未熟で不便だったからです。
ここ数年でHTML5やCSS3xまた高速なJavaScript実行環境が次々と浸透し、Web開発はものすごい勢いで進歩＆複雑化しています。
おかげでようやく、Webサービスでもデスクトップアプリケーション並みの複雑なサービスを開発できるようになってきました。そうすると、効率化を求めてライブラリやフレームワークも急速に成熟に向かいます。今はその途上ということですね。
デスクトップアプリケーションの場合、そのOSの開発元が状態管理機能も含め、フレームワークやライブラリを提供します(というかOSそのものが開発用フレームワークです)が、Web界隈にはそういう独裁者がいない為、フレームワークやライブラリが乱立するのは必然の流れといえるでしょう。今はWebのOS的な存在(王者？)を目指した戦国時代ですね。
成熟……はしてなかったですね、「そうです」で良さそうな気がします。セッション管理や状態管理の定番書、良書、というのをなかなか見聞きしないです。
(私のアンテナの感度が悪いだけの可能性は大いにあります、下記はその状態から見ての感想です)
状態はUIの場合TSSとかPCでプロセスの中のステップで持っていましたから、
それがウェブに成ると、
まず最初は素のHTMLでは画面を取得した瞬間で処理が終わってしまいます。
状態を全部INPUTやファイルとかクッキーとかで持っておくようなことになってしまいます。
また途中で中断されたときの片付けかたも考えないといけません。
で、いっときフラッシュやJavaやその他何社かのプラグインでクライアント(ブラウザ)でUIアプリを動かす方向に行きかけてもちろんある程度細かいUIでの状態はローカルでもつことになったのですが、プラグ・インはイカン！とそれをGAがぶっ潰してJavaScriptになりました。
結局、JavaだろうがJSだろうが半端な小さい範囲の状態は持ちますが、画面をごそっと変えると書き直しなのでサーバ側の状態もかわります。
- サーバーのパックのDBサーバー内に、ユーザーごとのセッションの管理をするか、
- サーバーでウェブとは別にセッションが生きている間プロセスを生存させるか、
- サーバーは完全にステートレスに作って、クライアントに状態をもたせるか、
などなど、Applicationによって手法はテンデバラバラです。
乱立したと言うより、あれもこれもWEBのインターフェースに持って行ったので混乱が起きていると言うだけですね。
例えば、ビデオ映像を見るとして、ビデオレコーダーとテレビのリモコンは相当沢山のボタンがついています。
テレビのオンオフ、ビデオレコーダーのオンオフ、メディアのロードエジエクト、再生、停止、早送り、巻き戻し、音声を大きく／小さくする、、、
ある意味機器のコントロールだけに特化したリモコンでさえこれだけのインターフェイスを用意していて、それでも混乱は起きています。
これを貴方は家電業界の成熟していない証拠というのでしょうか?
家電にVTRやLDなどが出て来たのはもう40年も昔のことです。
WEBの本来のインターフェースはクリックしたら、そのリンクが示すコンテンツを表示すると言うだけのことです。実にシンプルで混乱の起きようがない構造です。
そこに映像やら、3Dコンテンツやら、非同期通信のなんとかやらが相乗りした結果、相乗りしたもののインターフェースの混乱が現状に繋がっていると言うことでしかないです。
これをWEBの技術が単独で何とかできるわけはないです。個別の相乗り先が混乱を修復し、その結果を抽象化して統合することによってしかWEBでの混乱収束はあり得ません。
全てに対して万能に使えるシンプルなインターフェースなどないのです。
見積もりを要求する時点で完全な内容を確定していないからです。 殆どの発注側が作る内容を一切決めていない様な物ですから。 建物を作って下さい！みたいな注文でソフト開発依頼してるんだからそりゃロクに見積もれるわけが無いでしょう？ 宮殿を作るのか犬小屋を作るのすらわからない、広さがどれくらいで何階建てでどんな構造でどんな工法で何部屋あってどんな設備があるのか一切わからない、その上、大抵の発注者は漏れだらけで、あとから色々言ってくるからその分も誤差が出る。 いい加減な注文をしているから、いい加減な見積もりしか出ないのです。
完全な内容が決まっていれば作る内容が確定しているから正確な見積もりが出来ます。 もっとも、その完全な内容が決まっていたら殆どコードを書くだけで良いので自分でやれば良いと思うよ？って話になりますが。 正確に見積もれる程に詳細を詰めるところが開発の肝で、実装なんて大して難しくないんですよ。
夜明け前に目を覚ます習慣なんてどうでしょうか。
まだ外は暗く、ベッドは暖かく、枕は思い通りの形で、窓に雨のしずく。近所の人たちはみんなまだ夢の中…。
そんな時に起きてみましょう。
「なぜ、歯を磨いて、冷たい水を顔にかけなければならないのだろう」と不機嫌になる時間でもあります。なぜ、自分にそんなことをするのだろう？それは残酷ではないだろうか？
私も同じことを考えていました。これは私がこの2ケ月間に実践してきた新しい習慣ですが、もともと朝型人間の私にとってすら調整が必要でした。睡眠不足にならないよう、早く寝るようにしましたし、夕食の時間も早くなりました。しかし、このような夜の習慣の小さな変化は、それほど大きなものではありません。
私が得たのは、「時間の余裕」です。それはとても贅沢なことでした。
メリットがあるかって？ええ。数えきれないほど。
時間が増える：
まるで誰かに時間をプレゼントされたかのように、突然、1日の時間が広がり、いつもよりずっと長く感じられるようになりました。仕事を終わらせる時間があるかどうかを心配せずに、リラックスして過ごせるくらいです。時間管理という考え方は、それほど難しいものではありません。また、次から次へと急いで仕事をする必要もなく、マルチタスクですべてをこなす必要もありません。
静かである：
環境音が気になる家庭や地域に住んでいる人は、騒音がどれほど気になるかご存じでしょう。家で仕事や勉強するときは、静かに仕事ができる場所を探したり、交通量の多い道路の音を消すために音楽をかけたりします。耳栓をして静かに過ごすこともあるでしょう。しかし、早起きをしていると、それらのことが問題になりません。
集中力が高まる：
静かであることだけでなく、前の晩に十分な睡眠をとっていれば、脳が十分に休息しています。早朝は、ニュースや電話、ツイッターやインスタグラムの閲覧など、あらゆる方面からの新しい情報がまだ氾濫していないゴールデンタイムです。目の前のことに集中できるのです。
ディープタスク（ディープワーク）をより早い時間に完遂できる：
私は一日の早い時点で、ディープタスク（ディープワーク：問題解決や読み書きなどの複雑な認知タスク）を行うことを強く推奨しています。なぜなら、こうしたタスクは、エネルギーと意志のレベルがまだ高いうちに行ったほうが楽だからです。このような難しい課題に早く取り組めば取り組むほど、その日の気分は良くなります。そして、次のポイントが見えてきました。
自分のスキルに自信が持てるように：
時間があれば、何か目標のためにトライすることができます。それは、試験に備えて学習計画を立てることであったり、仕事のために記事や研究論文を書くことであったり、大きなプロジェクトの一部を仕上げることであったりします。何かに時間を費やせば費やすほど、目標に向かってより多くのステップを踏めるようになります。気がつけば、問題解決、勉強、時間管理、仕事の取り組み方など改善が進んでいくでしょう。結果、自信がつき、この習慣を続けようという気持ちになります。
私は、今のところ、この習慣がとても気に入っています。朝に煎れる、最初の一杯目のコーヒーが格段に美味しく感じられるようになりました。実際、今から淹れてみようと思っています。
これまで、200人ほどの方とお仕事させていただきましたが無能な人間は見たことありません。その方が待たれてる能力とうちが求める仕事が合ってないことはありました。また大変だなとおもっていたスタッフがある時期に大化けすることもあれば、大丈夫と信用していたスタッフがいきなり辞めたりした事もあります。2:6:2のスタンスで組織は成り立っていると思うのでバランスの舵取りができない経営者が無能かもしれませんね。零細企業の私がゆうのもおこがましいですが。
社員の能力に気づけない無能な社長が1番タチが悪いかもですね。
米国は世界のソフトウェア産業の中心地ですから、そこに比べれば、他の国はソフトウェア開発者の地位が低いということになるでしょう。米国のソフトウェア企業は、高い利益を享受しており、従業員に高い給与を払うことができますし、社会的影響力も大きなものになります。
では、日本は米国以外の他の国に比べてソフトウェア開発者の地位が低いのか？ という問いに置き換えると、おそらく多少は低いということになるでしょう。
その最大の理由は、雇用制度でしょう。
日本ではこれまでに積み重ねられた判例によって終身雇用制度が確立されており、企業は従業員を解雇することにかなりの制約が課せられています。
このような条件下では、企業はなるべく専門職の雇用を避けようとして、いろいろな仕事に転属できる総合職を育成しようとします。専門職員が余ってしまうと困るからです。
そのため専門職の給与や雇用体系などの処遇を他の従業員と差別化することも嫌がります。これが理由で、弁護士を従業員として雇う、いわゆるインハウスロイヤーもなかなかうまく行っていないと言われています。
社内に専門家がいなければ、システムコンサルティング企業などの専門家集団にシステムの構築を依頼することになりますが、社内で目利きができないために、厳選されたプロを雇うというよりは、一山いくらのような形でお金を払うことになりがちです。そのため一山いくらで雇われたプログラマの待遇は当然悪くなります。また社内に専門家がいなければ構築されたソフトウェアの品質は下がり、経営的成果も大幅に少なくなります。
またシステムコンサルティング企業は、景気の波を受けやすい産業と言われており、時期によって仕事の受注量に大きな波がでることになります。そのため、彼らも内部に多くのプログラマを雇うことを避けて、必要なときだけ下請けに派遣を依頼するという形になりがちです。そのためプログラマは中間搾取の犠牲となります。
さらに日本ではシステム構築は請負契約によって行われることが多いのですが、請負契約では供給者は発注者に対してシステムを確かに納品する責任を負います。この形では、システム構築には資本力のある巨大企業しか参入することができなくなり、より中間搾取が激しくなります。
また請負契約では、必然的に発注時にシステムの要求仕様を確定させる必要があり、開発プロセスは時代遅れのウォーターフォール型にならざるを得ません。
ですが、システム開発は、プラント建設などのプロジェクトよりも、より一層、研究開発(R&D)に近いプロジェクトであり、ウォーターフォール型や請負契約は必ずしも適しているとは言えません。なぜなら誰かが一度作ったことがあるシステムは、再度開発する必要がなく、そのシステムを買ってくれば済むからです。
良いシステムを作るためには仕様変更は必須です。またソフトウェアでは、ユーザーインターフェースやデザインなどの契約に記載することのできない品質も重要になります。そのため、ウォーターフォール型によって開発されたシステムは、品質が劣り、経営的な成果も大幅に下がります。
ウォーターフォール型になると、いわゆる上流工程において、仕様策定を行う、いわゆる日本型システムエンジニアの重要性が高まってきます。なぜなら仕様策定が全ての品質の大本になるからです。そのため、仕様が決まってから参加する他のメンバーは品質への貢献度が大きく下がります。すなわち重要ではないということです。
また納期の厳守が最大の目標となるため、徹夜などが常態化していました。
こうした理由によって、日本ではこれまでソフトウェア開発者の重要性や待遇が悪くなっていました。
ちなみにウォーターフォール型の開発企業でのソフトウェア開発者の待遇が悪いのは日本に限ったことではなく、インドのInfosysのような有力企業も従業員にひどい扱いをするので良く知られています。ただしインド人はどんどん独立するので日本とは状況が違いますが。
また雇用制度は別の面でもソフトウェア開発者に悪影響を与えています。それはインターネット革命以前のソフトウェアというのは、主に業務の効率化、すなわち人を減らすことに役立っていたのであり、解雇に制約が強い日本ではソフトウェアの有用性が減ることになります。
インターネット革命以降、ソフトウェアは単なる効率化の道具でなく、事業にとって欠かすことの出来ない本質的な存在となってきていますので、この状況は日本でも変わってきています。
とくにインターネット企業では、ソフトウェア開発者の待遇は大幅に改善されているので、そういう会社に入ることができる開発者にとっては日本の待遇が悪いとは言えなくなっています。いまでは、銀行のシステム開発プロジェクトのような仕事に好き好んで就きたいプログラマは全くいないでしょう。
ファイルはエクスプローラーで直接開けません。Webブラウザ経由となります。ただし、Google drive ファイルストリームを使えばエクスプローラーで普通のファイルと同じ扱いができます。
どちらにせよ今まで社内サーバーへアクセスしていたものがインターネットでのアクセスとなりますので、回線容量やルーター、プロキシサーバーの能力は今以上に必要となります。頻繁に更新するものは社内サーバーを引き続き使用して、成果物だけGoogle Driveに置くという使い方も一案です。
また、法人契約でしょうからG Suiteですよね。容量は無制限ですがファイル数の制限がありますので、念のため確認しておきましょう。
最近のエディタやIDEでは、インデントのためのタブとスペースは自動的に調整されるので、もはやあまり意味がなく、むしろ環境によって差異が出ないスペースのほうが好まれるというのは別の方も回答していますね。
補足的な情報として、いろいろリソースが足りなかった頃は、１文字(１バイト)で最大８文字分のインデントができるタブのほうが好まれることがあったと聞いたことがあります。もう、ずいぶん昔のことでしょうが。
まず理論的なところから、ご回答します。下図はカッツモデルと言う労働者に必要な能力の割合と管理職が保有すべき割合を概念化したものです。トップマネジメントとは役員クラス、ミドルマネジメントとは部課長クラス、ローワーマネジメントは係長クラスと捉えるとわかりやすいと思います。
おそらく現時点で管理職経験がないということですので、転職されても次の職場で即時に管理職採用はありえないと思います。なのでその職層の転職市場で期待されるのは①将来の管理職候補となりえる人材かどうか（ミドルクラスマネジメントを想定）、②入社後に様子を見て現場リーダークラス（ローワーマネジメント）を任せられる人材かどうか、という点になると思います。
そこで、カッツモデルを再度見ていただくと、ローワーマネジメントはテクニカルスキルとヒューマンスキルの割合が高いことがわかります。テクニカルスキルとはいわゆる実務力のことです。
次にローワーマネジメントに期待される能力のひとつであるヒューマンスキルです。ここには、他メンバーの支援や、幾分担当者の職掌を越えた問題解決能力が含まれます。例えば他部門との折衝、いわゆる働かないおじさんをどう扱うかなどです。
さて、ご質問の「どうすれば管理職になれる/管理職経験を積めますか？」についてのお答えです。
- まず実務者の中ではエース、部門で一番手と言われるくらいまで仕事を極めましょう。これはテクニカルスキルを充実させるということです。
- いまの役職が担当者であっても、部門の困っている仕事、他の方の仕事を手伝いましょう。そして問題解決を行ってみましょう。これはヒューマンスキルの基礎を身につけるということです。
- そこで得られた経験を転職市場で採用担当者に話して下さい。やってみないとわからないこと、言えないことがたくさんあるはずです。採用担当者の評価があなたの市場価値です。
- つまり、今、管理職でなくても実質的に管理職相当の経験を一部積んでいることを説明できれば採用突破には有利です。
日本の会社の場合、基本的に年功序列なので上が詰まっていて当たり前です。よって狙うべきは人員構成に課題があるか、急成長しているなど事情があり、中間層（ローワーマネジメント層）が薄い会社になると思います。
ただ、ここに書いたテクニカルスキル、ヒューマンスキルの双方を転職市場を突破できる程度に充実させようとすると、短くて3年、ほとんどの場合は5年以上かかると思います。
なので、会社の規模や職種によりかなり異なりますが、また他にもいろいろな人事制度上の観点があるのですが、一般的な日本の会社では主任クラスへの登用は5-7年目くらい、係長クラスへの登用は10年目前後と、人事制度設計がされていることが多いのです。
テクニカルスキル、ヒューマンスキルの習熟を待たずに転職も可能だと思いますが、その場合、いわゆる横に移動する転職になるので、担当者→担当者の転職になることが多いです。また期待されるマネジメント能力に対する習熟度が低い（管理職として即戦力でない）にもかかわらず管理職や管理職候補として採用するということは、相手側にもそれなりの事情があるはずです。転職には、いろいろリスクがあるのでご注意下さい。
MarkdownをレンダリングしてサイドバーでナビゲーションするHTMLを生成するだけではなく、加えて章節番号や目次のついたPDFや、docxも生成したい場合、pandocがおすすめです。
またその文書の一部としてapiリファレンスを含めてジェネレートしてリンクするのもありかもしれません。pdoc3やjavadocで生成したものをまとめるということです。配布物としてはhtml+api htmlもしくはpdf+api htmlを固めたものにします。
そのようなオペレーションは、githubやgitlabでCIでビルドする場合も、あるいは手元でそうする場合もdocker化しておくのが得策です。
経験的から見ると、コピペで仕事が出来ているエンジニアは優秀なエンジニアだと思います。コピペ道はそんなに易しくありません。まずコピペ元になるソフトを探すこと、それを状況に応じて小改造すること、実際に動かしてデバグすることには実は結構才能が要ります。
ここは思い切ってコピペ道を究めたトップエンジニアを目指しましょう。とりあえず、ある程度複雑なソフトをコピペ技術でクローンを作り、他のプラットフォームに移植しましょう。この技術はかなり需要があるので、収入が増えると思います。
0 コメント:
コメントを投稿