タグ

仕事と技術に関するakishin999のブックマーク (30)

  • 解決法の「とっかかり」をなんとなく把握しておくことが大事だという話

    この記事で書きたいことは、以下のような内容です。 ・昔SEの先輩に、「技術の詳細に通じていなくても、「そういう技術、そういう解決法がある」ということを把握しているだけで十分役立つ」と教わりました ・エンジニアの能力を測る尺度の一つとして、「課題」「問題」に対するアプローチをどれだけ思いつけるか、というものがあると思います ・「こういうやり方があった筈だ」「こういうアプローチが出来る筈だ」ということがなんとなくでも分かっていれば、それをとっかかりに調べることが出来ます ・その「そういう解決法があるということはなんとなく分かる」という状態を広げる為に、基盤技術に関する知識が重要です ・これは、生成AIに色々聞けるようになった今でも変わらないというか、むしろ昔以上に「とっかかり」の重要性が増しているような気がします ・「引き出しを増やす」という視点での勉強と、それを活かす為の基礎の重要性を、新人

    解決法の「とっかかり」をなんとなく把握しておくことが大事だという話
  • 実装できる人がいない?大丈夫かこの業界 - orangeitems’s diary

    最近、何件かの仕事を請けて共通していることがある。頂くドキュメントが非常に良くできているということだ。なぜ作ったか。どのように作ったか。そしてどう運用するべきか。一気通貫に述べられていて読むと非常に勉強になる。 ・・・それなら、このドキュメントを作った人が作ればいいじゃないか、なぜ私の手に次の仕事が来る?。しかもこんな素晴らしいドキュメント付きで。 一つには、このドキュメントとそれを実装することの価値について、読み解ける人がいなくなっている可能性を感じた。どうもベテランと呼ばれていた人たちが定年退職したり、別の仕事をし出している。かといって次世代が育っていない。ドキュメントを読みながら思うのは、書いた人は随分下の方のレイヤーのことをわかっているということだ。クラウドであればオンプレやネットワークのことまで熟知しているということ。 ところが、最近はカタログスペックというか、このサービスを使え

    実装できる人がいない?大丈夫かこの業界 - orangeitems’s diary
  • 仕事力と技術力と不安に関する雑文

    先日「育児など家庭の色々があって自分の時間が確保できなくなった。技術力を高めるための勉強ができなくて不安。」みたいな話を聞いた この悩みの直接的な解決方法としては先人の様々な体験談および対策みたいなものが世に出回っているからご家庭の状況に応じて参照すればいい思う 子育てと開発を両立するコツは「無理をしないこと」。パパ/ママエンジニアの働き方とは 子育てを支える技術 ─ フルスタックお父さんとエンジニアとしての成長を両立させるには ITエンジニアと子育てと勉強と それよりも「技術力を高めるための勉強ができなくて不安」という点が個人的には気になった 技術力とは何か?技術力が高くないとなぜ不安なのか?みたいな話 技術力は特に明確な定義があるわけではない 例えば著名なOSSにコミットしているとか低レイヤーのプロトコルやインフラをバリバリ実装してるとか競プロで上位勢だとか、挙げ始めたらキリがなく、そ

    仕事力と技術力と不安に関する雑文
  • 質問をする技術 - くりにっき

    以前社内に書いたポエムなんだけど年に1回くらい引用したくなるので公開した tl;dr; 質問をする時はゴールを提示する【MUST】 理由1 理由2 コンテキストを詳しく共有する【SHOULD】 期待してた結果(expect)と実際の結果(actual)を書く【IMO】 2020/7/22 12:30追記 2020/7/22 19:00追記 tl;dr; テンプレ 【質問内容】 【やりたいこと or 今困ってること or 質問の意図】 質問をする時はゴールを提示する【MUST】 なにかやりたい けど実現できない、うまくいかない それで質問する って感じに、質問をする動機としてまず やりたいことありき のはずなので、それを提示すべきです 理由1 質問される側(以下回答者)は質問内容がふわっとしていると色々なケースを想定して回答を組み立てます *1 例「Aの場合は~だけど、Bの場合は~」 こうい

    質問をする技術 - くりにっき
  • 集中力のない人の戦略

    集中力がないといろいろなところで苦労します。とりわけ苦労したのが学校です。学校では決められた時間で学ぶ授業、決められた時間で問題を解き結果を出す試験があります。これが当に集中力のない自分には地獄でした。とにかく決められた時間で何かをするというのがとても苦手でした。 恐ろしいほど集中力がなく、決められた時間の中で結果を出すことができない自分がどうやって仕事をしているのかという話を書いてきます。 ダラダラ継続する結論を先にいうと「人の何倍も時間をかけて、常に変化する分野ピンポイントにダラダラと継続する」という戦略を取ることにしました。 継続といえばカッコイイですが所詮は「ダラダラ」です。つまり気分が乗ったときだけダラダラとやっていきます。 ただ、ダラダラやるのも1年、5年、10年と続ければ結果は出ます、多分。 また、常に変化する分野であれば集中力よりも、継続が求められるはずだとも考えました。

  • 良いテックリード、悪いテックリード - 小さなごちそう

    記事は、下記の記事の翻訳です。著者の許可を得て翻訳しました。 この記事はフォースクエアの技術的リーダーシップを簡潔に説明したガイドだ。 ベン・ホロウィッツの「良いプロダクトマージャー、悪いプロダクトマージャー」からインスピレーションを得ている。 チームワーク / Teamwork 良いテックリードはチームの一員として振る舞い、自分の成功とはチームが成功することだと考える。面倒で退屈な仕事の一部を担って障害物を取り除き、チームが100%のパフォーマンスで稼働できるようにする。チームの技術的能力を拡大し、システムの重要な知識が属人化しないように務める。 悪いテックリードは注目の集まる仕事で自分の成果を示すことを好む。その成果は部分最適に留まり、開発チームのアウトプットを増やすにはエンジニアの人数を増やすしかない、という状況から脱することができない。 技術的ビジョン / Technical v

    良いテックリード、悪いテックリード - 小さなごちそう
  • サービスか受託か。Webサービスを作るということ | F's Garage

    先日、某SIコンサル社にいる方が、まだ転職を悩んでるという前提でのカジュアル面談に臨んだ。その人の転職理由というのは、僕が受託の会社から転職した時に言っていたこととそのままだったので、是非、面接に進んで欲しいと思った。 その一方で、受託からWebサービスに来る人に、よく言うことして、 「受託からWebサービスに来ると、ファンタスティックな案件がなくなってつまらないかもしれないですよ」 と言う話をする。これはどういうことか?というと「技術的チャレンジ」を求めるならば、筋の良い受託の会社にいる方が楽しくて、Webサービスはコードを書いている瞬間から技術的なレガシーを産んでおり、先々に渡って最初の選択の影響を受けるので、あなたの技術力の定義が「話題の言語でコードを書けること」であるならば、Webサービスはあんまり勧めません、という話をする。 当時僕がいた会社は、技術の共通化がまだ進んでおらず自

    サービスか受託か。Webサービスを作るということ | F's Garage
  • SIerの下請け開発者ってレベル低すぎない? - UXエンジニアになりたい人のブログ

    ネット上ではSIer批判=技術のことをわかっておらずプログラムも書けずPMも出来ない非効率でダメダメな上流工程と、 人月単位での労働力提供という業界の慣習に縛られ、持ち前の優秀な技術力・知識を生かせず非効率な作業を強いられているかわいそうな下請け開発者、という構図が確立されているように思います。 自分が関わるまでは、まあそうなんだろうなと思っていましたが、しかし実際にそういう立場のひとと関わりをもつにつれて、どうもそうではないのではないかと思うようになりました。このあたりの実情を書いていこうと思います。 なお、先に言っておきますが記事で書くことは、上流工程がどうのとか、業界の多重請け負い構造がどうのとか、給料が安くてとか労働条件が過酷でとか、そういう話とは全く関係がなく、純粋にプログラミングのスキルの話だけです。 対象はおもに詳細設計、実装UTだと思ってもらえれば。外部仕様が決まった状態

    SIerの下請け開発者ってレベル低すぎない? - UXエンジニアになりたい人のブログ
  • まつもとゆきひろ氏が「生涯プログラマー」でやっていきたい若手に贈る3つの言葉 - エンジニアtype | 転職type

    2015.06.03 スキル 社会人になったばかりの若いエンジニアの中には、一度この道に足を踏み入れたからには、自らの技術で身を立てていけたらという、強い思いを胸に秘めている人も少なくないのではないか。 そう考えて今回、Rubyの父として知られるまつもとゆきひろ氏に、あえて「これからの時代に技術だけで生き残るには?」という偏ったテーマで取材を依頼した。返ってきたメールの冒頭にあったのが、次の一文である。 「技術だけで生きるというのは幻想である」 まずはその真意を聞くところから、取材は始まった。 まつもとゆきひろさん(@yukihiro_matz) 1965年生まれ。筑波大学第三学群情報学類卒業。プログラミング言語Rubyの生みの親。株式会社ネットワーク応用通信研究所フェロー、一般財団法人Rubyアソシエーション理事長、Speeeをはじめとした複数社の技術顧問、Herokuチーフアーキテ

    まつもとゆきひろ氏が「生涯プログラマー」でやっていきたい若手に贈る3つの言葉 - エンジニアtype | 転職type
  • エンジニアとしての落としどころを作る | こえむの編集後記

    コンピュータのエンジニアをやっていると、技術を高めたい、最新の技術を得たい、そして尖ったエンジニアになりたいと一度は思うものです。ただ、僕はそれらは諦めて、今年からは自分なりの落としどころを作ってやってみることにしました。 では、落としどころとは何なのか、です。のんびり考えていた中で、方針を決めてみました。 問題解決に関わる立場であり続けることを念頭に置く 最も効率よく開発・改善し続けられる技術を選択する 泥臭く・人懐っこくやる 仕組みを作る立場であり続けることを念頭に置く 僕はソフトウェアエンジニアとして転職を何度かしています。仕事をする中で、現在いる・過去にいた組織のどの上長も評価して頂いていたのは、人・お金・情報のバランスを取りながら、ソフトウェアを基盤にした仕組みを作って結果を出している点でした。 ソフトウェアエンジニアでありながら、最高の技術を導入したとか、最新の技術を普及させた

    エンジニアとしての落としどころを作る | こえむの編集後記
  • 製造を外注しても技術力を失わないアップルの凄み 欧米モデルを誤解し安易に模倣する日本企業のリスク

    株式会社O2(オーツー)、株式会社XrossVate(クロスベイト)、株式会社安田製作所代表取締役。1970年生まれ。千葉県出身。早稲田大学政治経済学経済学科卒。大手化学メーカー、外資系ITベンダーのディレクター、コンサルティングファームのディレクターなどを経て、2004年株式会社O2を設立、代表取締役就任。2013年に新会社XrossVateを設立。2014年に射出成型用金型メーカ株式会社安田製作所に出資を行い経営参画。 日の丸製造業を蘇らせる!“超高速すり合わせ型”モノづくりのススメ 日の製造業は危機に瀕していると言われて久しい。様々な業界関係者が口にする「日企業は技術で勝っても事業で負けている」という言い訳は、当に正しいのか。実は、日のゲンバにはもっと根深い質的な課題がありそうだ。日企業の5重苦、7重苦の原因は、日技術力の低下そのものにあり、その原因は大きく「技術

    製造を外注しても技術力を失わないアップルの凄み 欧米モデルを誤解し安易に模倣する日本企業のリスク
  • エンジニアの評価基準とキャリアパスのお話 | 外道父の匠

    春になって暖かくなると、ついつい意識が高ぶってしまいますね。 今回はあくまで個人的な、エンジニアの評価基準とキャリアパスについての私見を、どちらかというと新人の方向けに垂れ流してみたいと思います。 はじめに 新人の方々は今頃は、研修に追われていたり、それが終わっても配属先で揉みくちゃにされる日々が待っているでしょう。中には既に後ろ向きな思考になっている人もいるかもしれませんが、そういう人には今回どうでもよい話で、前向きな人がそのエネルギーをエンジニアとしての成長に無駄なくつぎ込むために、若いうちにあまり考えないけど、考えておいた方がよい話をします。 ITエンジニアとして始動すると、目の前に与えられた仕事だけでも楽しいのに(その過程で苦しむのは別として)、さらにその先にIT知識が広く深く待ち受けていて、こんなことをやりたいんだ、全部マスターしてやるんだと意気込むかもしれません。そして、目の前

    エンジニアの評価基準とキャリアパスのお話 | 外道父の匠
  • 技術そのものがリスペクトされる風土がこれからは大事なんだと思う - UNIX的なアレ

    ITに携わる人たちの間で、エンジニアが大切でエンジニアを中心とした組織づくりをしようとしている会社がすごく増えてきました。実際にいま存在感がある会社はどこもエンジニアが活躍している会社です。 なぜ非エンジニア向けに技術を学ばせるのか nanapiでは非エンジニアむけの技術研修を毎週実施をしていて、コードのかけない人はいないようにすることを目標にしています。これはコードを書けることでそれを普段の業務に活かせるようにしようというだけではなく、技術そのものに対してリスペクトしてほしいという思いがあります。 nanapiエンジニアはコミュニケーション能力が非常に高いので非エンジニアのレベルに合わせて技術の話をすることができますが、実際はエンジニアが遠慮せずに話してそれを非エンジニアの人が理解しようとするほうが圧倒的に仕事のレベルは上がるはずなです。やっぱり普段の仕事の会話は高いレベルに合わせたほ

    技術そのものがリスペクトされる風土がこれからは大事なんだと思う - UNIX的なアレ
  • 結婚したら勉強できなくなった

    結婚したら著しく勉強時間が減った。 パソコンに向かいWebサービス作ったり新しい技術を試したりすると、つい時間が経ってしまう。 それが原因で喧嘩になったことがある。このままだと離婚になりかねないと思い、二人の時間を作ることにした。 その結果、何かに集中できる時間が減って、色んなスケジュールの進捗が芳しく無くなってきた。 1週1アプリハッカソンが出来なくなった。オンライン講義受けるとあからさまに嫌な顔をされるようになった。 甘えられるのは嬉しいけど、設計中にやられると少しイラッとくる。 無駄に残業して家に帰らないおっさんの気持ちがよく分かる。 これは病気なんだろうか。 追記: 反響がありまくってびっくりしました、当方新婚の夫です。 色々ご指摘いただいた件、ご尤もだなと。元々時間管理がうまい方ではないです。 嫁と話し合うのはまずやるべきことでした。 朝早く起きる、スタバドヤするというのはうまく

    結婚したら勉強できなくなった
  • 自分を首に出来るように働く - プログラマでありたい

    年末ということで、自分がどのような働き方を目指しているのかを改めて考えてみました。結論的には、自分がいなくても仕事が回るような仕組みやチームを作り、いつでも抜けられる状態にするということです。つまり、いつ首になっても問題が無いポジションに落としこむということです。この働き方は、圧倒的に楽です。自分にしか出来ないことがないので負荷が集中しないし、代わりの人間がいるので心理的にもプレッシャーは少ないです。そもそもルーチンの仕事は、自動化などでシステムが出来るようになります。そうすると、面白い仕事が出てきた時に取り組み易くなります。 反対に自分にしか出来ない仕事を抱え込んでしまうとどうでしょう?自分自身がボトルネックになるので、休めないし心理的なプレッシャーもあります。そして、延々と同じ仕事を続ける必要があります。10数年働いてそれなりの数の人を見てきましたが、自分のポジションを保つために仕事

    自分を首に出来るように働く - プログラマでありたい
  • 若いエンジニアへ

    エンジニアなら誰でも突貫工事に喜びを見出した経験がある。深夜2時の夜を共にした同僚のことは、その職業人生を通じて忘れることはない。しかし、そこにいかなるドラマがあろうとも、突貫工事は例外である。これを常態としてはならない。 メーカーの組込みプログラマとしてエンジニアのキャリアをスタートした私は、「よい製品はよいプロセスから生まれる」ことを頭に叩きこまれた。素晴らしい製品を生み出す工場は静かである。常に誰かが大声で叫んでいるような工場には明らかにプロセス上の問題が認められ、素晴らしい製品を生むことは決してない。 物のエンジニアは突貫工事を好まない。突貫工事とはプロセス上の誤りであり、つまり誰かが大声で叫ばなければならないということだからである。エンジニア仕事は計画され、コントロールされたものでなければならない。 長時間労働によって成果を生み出そうとすることも、やはり例外としなければなら

  • 同じ開発チームの「批評家」とどう接すべきか悩んでいる

    同じ開発プロジェクトのメンバーに、頭でっかちで、口は達者だが、まったく手を動かそうとしない、いわゆる「批評家」な人が居る。その人とどう接したら良いのかわからず、悩んでいる。(以下、「先生」と呼ぶ) 先生はあまり技術スキルが高く無かった。先生が担当する部分のシステム仕様や、そのシステムに関連するスキルの習得状況が芳しくないことと、そもそも基的なプログラミングスキルも、低いとは言わないが、安心してまかせられるレベルではない、ということが分かってきたため、最終的には、スキルが求められる部分については、分割して他の人が分担して持つことになった。 先生はそれなりに時間ができ、スキルアップのために技術書を読み始めたようだった。それはとても良いことなのだが、どちらかというと、はじめての◯◯、とか、でもわかる◯◯、等を読むべき技術スキルだったにも関わらず、読み始めたのがデザインパターンやリファクタリン

  • 二つの技術選定プランと知識社会 - fujimuradaisuke.com

    この記事を読みました。 カネと時間考えるならPHPやっとけ。たぶn :村上福之の「ネットとケータイと俺様」:ITmedia オルタナティブ・ブログ で、ちょっと前にメモっていた事を思い出したので共有します。 Webアプリケーションの技術要素を選ぶにあたって、大きく2つのプランがあるなと思いました。 1. 例えばいわゆるLAMP構成 よく使われてる技術を採用して潰しが効くようにする方法です。上記のブログ記事はこちらですね。 普通のレベルの人を集めやすい 尖った人を集めにくい 普通の人がパフォーマンスを出しやすい 尖った人がパフォーマンスを出しにくい 人海戦術 人間のスケールアウトを重視 標準化された作業がある 低い知的負荷 2. 例えばEdge Rails 尖った技術を採用してパフォーマンスを出す方向です。 普通のレベルの人を集めにくい 尖った人を集めやすい 普通の人がパフォーマンスを出しに

  • ポキっと折れない柔構造の人生設計 - アンカテ

    僕は自分より頭がいい人がたくさんいることを知っているけど、このことを知っているのは自分ひとりじゃないだろうか?と思うことがよくある。 インターネットによって損をした人も得をした人もたくさんいると思うが、頭のいい人にとってインターネットは天の恵みだろう。インターネットがいきわたると、頭のいい人のできることはどんどん増えて、彼らは世界を変えていく。 僕は、昔COBOLプログラマという仕事をしていたけど、頭がいい人が世界を変えたことで、この職を失った。今でもCOBOLプログラマと名乗る人はいるが、それは僕がやっていた仕事とは随分違うものになっている。 それ以来、自分の人生設計をする上で、頭のいい人が次に何をやるかを一番先に考えるようになった。 その頃は、コンピュータ関係の仕事でなければ、そんなことは気にしなくてもよかったと思うが、今はネットがあるから、多くの仕事が影響を受けるだろう。 頭のいい人

    ポキっと折れない柔構造の人生設計 - アンカテ
  • エンジニアtype 技術者のキャリアを考えるWebマガジン - 転職@type

    エンジニアtypeは、各種エンジニアをはじめ「創る人たち」のキャリア形成に役立つ情報を発信する『@type』のコンテンツです。

    エンジニアtype 技術者のキャリアを考えるWebマガジン - 転職@type