サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
Cline を使い始めて2ヶ月ぐらい経った。 自分の直感として、Cline は真のイノベーションの入口であり、そして開けてはいけないパンドラの箱でもあったと思う。 ここでいう Cline は Cline型コーディングエージェントであり、広義には Devin / Cursor や Copilot Agent 等を含む話。だが、後述するように Cline でしか見えない世界がある。 その先の未来に、プログラマとしての自分はフルベットする、という話をする。 私たちが知っているプログラミングの終焉 大事なことは次の記事に全部書いてある。まずこれを読んでほしい。 (Google翻訳) Steve Yegge 氏は、置き換えられるのはジュニアおよび中級レベルのプログラマーではなく、新しいプログラミング ツールやパラダイムを受け入れず過去に固執するプログラマーであると指摘しています。 <略> これはプロ
意思決定できる人は進める手順の型みたいなものを持っているように見える。逆に意思決定が遅かったりできなかったりする人は、進めるときに型のうちの何かが欠けているのかもしれない。 体系化された話は書籍で語られつくされているとは思うが、思考整理のために雑にまとめてみる。 最後は決めるだけだという考えを持つ 目的や満たしたいことを明確にする 最終的な決め方や期日を明確にする 選択肢を広げて考える 今は意思決定しない、という意思決定も選択肢に入れる 意思決定の軸を明確にする 軸をもとに定量/定性データを集める 軸をもとに選択肢を評価する 自分はこうしたいという"推し"を決めてたたき台にする ここまでの話をドキュメントにしている ここまでのプロセスに時間をかけない 意見を聞く人を見定めてフィードバックをもらう 最初に明確にした決め方で意思決定する 意思決定できない場合は決め方と期日と意思決定軸を再定義す
「悪い人ではないんだろうけど、言葉選びが下手だなぁ」 わたしはAさんに対して、ときおりこう思っていた。 Aさんの考え方自体がおかしいわけではないのだが、なんだか癪に障る言い方が多いのだ。 なぜこの人はこんなにも言葉選びが下手なんだろうと不思議だったが、最近その理由がわかった。 彼は言葉選びが下手なんじゃない。単純に、「自分の言い分は正しいのだから、それを理解できない相手が悪い」と考えていたのだ。 かつてのわたしのように。 「言葉を選んで伝える」という発想がないAさん あるとき、数人で出身地の話をしていたときのこと。 Bさんが、Aさんの出身地を勘違いをしていた。 「Aさんって、沖縄出身だったよね？」 「いや、ちがうけど」 「あれ、沖縄って言ってたと思ったんだけどな」 「いやいや、沖縄出身なんて一切言ってないし」 「あー、ごめん。言ってたと思ったんだけど、だれかと勘違いしたのかも」 「思い込み
AI によるコーディングの支援はコード補完型からチャット型、そして自律型へと進化しています。この記事では現時点で主流となっているコーディングエージェントの種類とその特徴を整理したうえで、エンジニアの仕事の変化について考察します。 コーディングの仕事における AI 技術の関わりといえば、GitHub Copilot を代表するエディタ補完型が主たるものとして認識されてきました。補完型の AI はユーザーが途中まで書いたコードを補完する形で提案を行うことから、ペアプログラムの相方のような存在として捉えられていました。例えば function add と書き始めると、AI は (a: number, b: number): number { return a + b; } といった形で関数の定義を提案します。ユーザーは Tab キーを押すことで提案を受け入れたり、提案が気に入らなければそのままコ
こんにちは。ヨッピーです。 写真は作者である「まるでゆきみ」さんの才能にビックリして固まっている僕です。 本日お邪魔しているのはNintendo Switch向けに配信されている「ツクールシリーズ るんるんスーパーヒーローベイビーズDX」の作者である「まるでゆきみ」さんのご自宅なのですが、なんとこの「まるでゆきみ」さんは金融機関で正社員として働く傍ら、6人の子どもを育てつつ、合間を縫ってこのゲームを完成させたそうです。 6人も子どもが居たら普通に働くだけでも大変そうなのにゲームまで作ってしまうって、「いったいどういう環境でゲームを作ってるのか」「どうやって時間を捻出しているのか」などなど、お話を聞くことで「いつかゲームを作りたい！」と思っている人の参考になれば、と思って取材に来たのですが、お話を聞いているうち「この人が天才すぎて、話を聞いてもなんの参考にもならないのでは？」と思ってしまいま
はじめに デリシャスマイル〜1、nikkieです。 控えめに言って神！なオンライン勉強会に参加してきました。 レポートを綴ります〜 目次 はじめに 目次 「勉強法の勉強会」 #YUMEMIxTORALAB 勉強法LTラインナップ（見つかった資料ツイートも一緒に） アーカイブ（みんなぜひ見て！） 感想ブログ（気づいた範囲で） 「内需ドリブン勉強法」ぶっ刺さった！ 会場が色めき立った、ツイート読書術 牛尾さんのnote「プログラミングというより物事が出来るようになる思考法」を思い出す 『エンジニアの知的生産術』の「プログラミングはどうやって学ぶか」も思い出す ツイートめっちゃ流れて楽しい 一人同窓会感！ 終わりに P.S. きっかけはKanonさん 「勉強法の勉強会」 #YUMEMIxTORALAB 今回はなんとあのとらラボ！（虎の穴ラボ株式会社）さんとのコラボレーション！ 今回のテーマは、エ
プロダクト開発をしていると、ユーザーや社内から改善要望をもらうことがよくある。でも、その要望の多くが「How」しか書かれていなくて、本当に必要な「Why」が書かれていない。 例えば、よくあるものだと 「ユーザー一覧をCSVでダウンロードできるようにしてほしい」 「検索結果を50件ずつ表示してほしい」 「削除ボタンを赤色にしてほしい」 といったものだったりします。 社内の人には「HowはあってもなくてもいいのでWhyを書いてください」と言っているんだけど、実際にWhyが書かれているケースは少ない。 テンプレートみたいなものを用意してもひどいケースだと「◯◯機能がほしいので◯◯機能を作ってください」みたいなことが書かれている。 どうしてWhyが重要かというと、"最適な解決策を見つけつつ、将来の拡張性も考慮した設計にしたい"からです。 このnoteではなぜ、要望にはWhyが重要でHowが重要では
自分は現在アメリカの医療系スタートアップ企業でソフトウェアエンジニアとして働いている。カナダに在住していて、年収は日本円にして約1600万円、エンジニアとしては現在4年働いている。 もしあなたが日本のエンジニアなら、これを読んだ時に心がざわついたと思う。日本にいると表面化しづらい、世界的エンジニアの給与格差を今目の当たりにしたのだから。しかし実際には、自分はほぼぴったりアメリカでのエンジニアの平均給料を貰っているに過ぎない。 日本でのエンジニアの扱い給料Economic Research InstituteをソースにしたCodeSubmitさんの各国のエンジニアの平均給料のリサーチによると、日本は$36,024でランキングの27ヶ国中18位、1位のアメリカ($110,140)とは$74,116、即ち2023年11月現在の日本円対アメリカドルのレートで1100万円ほどの開きがある。ちなみに日
Claude Codeが変えた開発の風景Claude Codeを使い始めて約1ヶ月経ちますが「Claude Codeを使ってから、開発の概念が根本的に変わった」と僕は思ってる。 ClineやCursor Agentの登場でもでも相当変わったと思う。でもClaude Codeはそれ以上の変化だと僕は感じている。何が根本的に違うのか。 自走力の高いClaude Code - ファイルを読み、修正し、テストを実行し、エラーを解決する。まるでペアプロしているような体験。 コードを書く能力が高いClaude 4 Opus - 複雑なロジックも正確に実装できる圧倒的なコード生成能力。 Claude MAXでの定額化 - API料金を気にせず使い倒せる。この「料金を気にしなくていい」という心理的な解放が、開発のアプローチを根本から変える。 従量課金のメンタルモデルから定額使い放題のメンタルモデルへという
2025.09.22 7:40 全体的にイエス・バッド法になっていたところをイエス・アンド法に書き換えました。身についてないなぁ はじめに たびたび話題になる「技術的には可能です（でも影響範囲でかいし、品質に影響与えそうだし、結構コストかかるし、スケジュールきついし・・・無理じゃね？）」問題ありますよね。 口に出したことより、心の中の声の方がでかいみたいな。 そしてこれは、言われた側からは非常に不評でもあります。 私は比較的最近、この問題とうまく付き合えるようになりましたので、少しアイデアを共有したいと思い、この記事を書きました。 解決策 それは「できる」と「やる」を分離して できる：自分の責任 やる ：相手のバトン（責任） とすることです。 「はい、できます。リリーススケジュール調整が必要になりますが、やりますか？」 「はい、できます。追加コストが発生しますが、やりますか？」 「はい、で
前からずっと言いたかったことがある。同じ過ちを犯すゲーム開発者に。あるいは、「ゲームを完成させた体験が無い人」に。 あなたのゲーム開発に対する予測は、ほとんどの場合正しくない。それも、20%や40%などの振れ幅ではない。200%とか400%のスケールで大きく間違っている。 私はその感覚を確かめるべく一つのアンケートを実施した。結果は火を見るより明らかな傾向を示した。 個人ゲーム開発者に質問です。「１年で完成させる」と思って作り始めたプロジェクト、実際に完成したのは？ — じーくどらむす/岩本翔 (@geekdrums) June 4, 2024 Twitterアンケートの統計的な正しさは保証しない。そもそも母集団が偏っているし、最後の選択肢が「未完成」を含めていることに対して「４年以内に諦めて未完成」の人も含めているかもしれない。が、エターナったという意味では４年以上完成しないもの、に含め
今週は、Thanksgiving はお休みムードなので考える時間や、自分の本についてディスカッションしている バンクーバーのえんじに屋さんのPodcast なんかを聞かせていただいたりしてるうちに、思い出したことがあって、記録に残してみることにした。それは、エンジニアの育成方針でこれはめっちゃくちゃ違うことに気づきましたので、シェアさせていただきたいと思います。 日米でエンジニアの育成戦略が正反対だと気付いた話 採用の段階での違い 良く知られているように、新卒のケースで考えると、こちらの場合は「コンピュータサイエンス」の学位を出ていることが前提で、中途採用の場合も、「コンピュータサイエンス」の学位を出ている、もしくはそれ相当する知識が求められる。だから、新人でも少なくともプログラムが結構組めることを期待されます。 一方、日本では文系でも理系でもプログラマになれます。採用されたときに「スキル
これまでの生存戦略 それほど尖った能力や知識がない中で、私のこれまでの生存戦略としては求められればなんでもやる、少しくらい泥水でも飲むというものでした。 フロントエンドからバックエンド、データベース設計、API設計、実装、インフラ側の設定、提案書作成、プレゼンテーション、プロジェクト進行、どれも“専門家として誇れるか”というと疑問がありますが、求められればなんでもやるスタンスでそれが自分の価値提供の形と考えていました。 また、以前までは「若い」というのも、強みでした。 一回りほど上の年齢に見られることも珍しくなく、「そんな若かったのか」と驚かれるなかで、「若いのに頑張ってるね」と年齢のフィルターで大目にみてもらえました。 しかし、そんな私も気が付けば40歳、もう若さという武器はありません。 （つい先日まで20代だったはずなのに..何かおかしい..） 体力的にも無理が効かず、新しいことを学ぶ
決めていいと知らないどこまで決めて良いのか分からないのであれば、決めようがない。権限の委譲ができてないことが多いので、デリゲーションポーカーなどを利用すると良い。 提案を覆され続ける次のようなことを繰り返すと、「お伺いを立てたほうが早い」となる。 チームで決めたものを持っていくと「それじゃダメだ」と言われる 懸念点や問題点の起案をすると「今それは考えなくて良い」と無視される 決めた対応方針を伝えると「こうやって進めて」と別の指示がされる ある程度進めた後で全部仕事が引き継がれて全部書き換えられる 当然ながら、これが続けば「どうせ調べたり考えても無駄だから、全部最初から聞いてしまったほうが早い」となる。 決めさせる難しさ多くの場合上司の方が経験も知識も多く視野も広いため、90点がとれる案が脳内にできあがっている。一方で、部下が出してくる案は70点程度の場合が多い。そして上司は90点がとれる案
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 今でも語り継がれる「原則」は、それだけ価値のあるコンセプトです。 歴史を振り返ることは、失敗を防ぐための効率の良い方法になります。 👑 DRY (Don't repeat yourself) 「同じことを繰り返すな。」 Andy Hunt と Dave Thomas の著書『達人プログラマー』（1999 年）で提唱された原則で、プログラミングに関する最も重要な原則といっても過言ではありません。 DRY 原則だけでなく、どんなデザインパターンやベストプラクティスでも、同じ処理が重複することは基本的に許されていません。 これには
Hamee様 開発合宿 2021年（前半戦）の資料です。 # 参考リンク - https://speakerdeck.com/soudai/engineer-life-hack - https://www.shinryo.com/special/contents01_3.html - htt…
みなさんこんにちは。@ryuzeeです。 昨年12月に新刊『チームトポロジー』が発売になったのでぜひよろしくお願いします。 アジャイルコーチや技術顧問の仕事は多岐にわたりますが、その1つに社内での講演やセミナーがあります。 今回、技術顧問先のイベントで登壇しましたので、その際の資料を公開します。 アジャイルとは直接関係ないものも多々含まれていますが、ネタということでご了承ください。 アジャイル全般QCDSを同時にすべて固定することはできない要件の決まったものを早く・安く作る方法ではない開発だけをアジャイルにしても意味がないアジャイルで請負契約は無理だと心得ようすべてがアジャイルに適しているわけではない大規模アジャイルは小さなアジャイルの成功後アジャイル導入を支援しようアジャイル推進での組織的な課題に取り組もう無駄な社内プロセスを廃止するよう働きかけよう効率ではなく成果に着目した組織設計をし
おちえ @jarinko_rarara 私の周りは、頭の回転が速く弁の立つ人が多くて、そうでない私はそのことが結構コンプレックスだったりします。 今日、あさイチの読書特集で、 上白石萌音ちゃんが 「最近は、即レス、短い時間で気の利いた面白い言葉を返せるのがかっこいいみたいな風潮があるけど、 本は、言葉のプロが練りに練った 2025-09-10 19:44:23 おちえ @jarinko_rarara 言葉を紡いだもの。 煮込まれた言葉を大事にしたい」 （ごめんなさい、完璧には覚えてないので、一言一句この通りではないですがおおよそこのような内容のことでした） みたいなことを言ってて、私、めちゃくちゃ心の霧が晴れました😭 2025-09-10 19:44:25 ことばと @kotobatoad 上白石萌音さん「今って会話のスピードが重視されがちじゃないですか。一瞬で気の利いた返しをできる人が
アジャイル開発チーム向けのコーチングや、技術顧問、Scrum Alliance認定スクラムマスター研修などのトレーニングを提供しています。お気軽にご相談ください（初回相談無料） みなさんこんにちは。@ryuzeeです。 2022年9月6日に行われたオンラインイベント「エンジニアリングマネージャーのしごと - Forkwell Library #5」の登壇資料を公開します。 内容は、新刊書籍『エンジニアリングマネージャーのしごと』に関するものなのですが、本書は18章、350ページからなる本であり全部を網羅的に紹介するのは無理筋なので、今回は根底にある考え方にフォーカスを当てています。この発表のあとにQ&Aコーナーがあったのですが、その内容については、aki.mさんのブログ記事にまとまっていますので参考にしてください。
この記事について会社・チームで人と一緒に働いたり、コミュニティで他人のアウトプットなどを観察したりすると、「この人頭いいなー」とか、「センスいいなー」と思ったりすることもあれば、逆のこともあったりするだろう。 最近、「デザインセンス」をチームに期待するにあたり、そもそもデザインの構成要素とはどういったもので、どのようにしたらデザインという営みの精度が上がるのか、という疑問に行き着いた。 個人のデザインセンスというところでは、先天的なものとまではいわずとも長く蓄積された思考習慣による才能・素養のようにも思えるが、後天的に、例えば成人後でも訓練可能なのかという観点で考えてみたので自分なりの整理として書き出してみる。 組織レベルで考えると「チームとしてどう成熟していくか、その経験をどうスケールさせていくか」というナレッジマネジメントの問題にも行き当たるが、ここではあくまで個人としてのデザインセン
Tech BASE Okinawa 2023 2023/09/23(土) https://codebase.connpass.com/event/285901/ https://techbaseokinawa.com/
『テスト駆動開発』や『SQLアンチパターン』をはじめとする技術書の翻訳者、さまざまなIT企業をわたり歩く技術顧問、さらに最近ではエンジニアリング文化を伝える講演者としても活躍されている和田卓人さん(https://twitter.com/t_wada)。 そのソフトウェアエンジニアとしての素顔を株式会社一休CTOの伊藤直也さん(https://twitter.com/naoya_ito)が聞き出す対談の前編では、一線を画すエンジニアであり続けるために自らのプロジェクトで意識的にコードを書いているという和田さんの姿勢に始まり、ベテランとして「技術のらせん」を読み解くケーススタディとしてDDD（Domain-Driven Design）を題材に話を伺います。 ・伊藤 直也さん / 株式会社 一休 執行役員 CTO 新卒入社したニフティ株式会社でブログサービス「ココログ」を立ち上げ、CTOを務め
転職・求人情報サイトのtype エンジニアtype ITニュース t-wadaが説く、今あえて“自分の手”でコードを書く理由「バイブコーディングは、エンジニアのためのものではない」 NEW! 2025.11.28 ITニュース プログラミングAI 「バイブコーディング（Vibe Coding）」の熱狂は、プロフェッショナルなエンジニアにとって何を意味するのだろうか。その答えの一つが、2025年10月30日に開催された「AI駆動開発カンファレンス 2025」にて明かされた。 答えの主は、テスト駆動開発（TDD）の第一人者・t-wadaこと和田卓人さん。「AI時代のソフトウェア開発を考える」と題した講演の中で、「バイブコーディングはエンジニアのためのものではない」と指摘した。 果たして、その言葉の真意とは。和田さんの考えを聞いていくと、AI全盛の時代にエンジニアが果たすべき役割と、自らの手を動
このページはAmazonアソシエイトの広告を含みます。 はじめに下記イベントを拝聴した。 増田さん、ミノ駆動さんそれぞれのご講演のあと、Forkwell赤川さんによる司会進行で行われたパネルトークがとても面白かった。20代、30代、40代以降を技術者としてどのように過ごし、どんな本に出会ってどう学んだのかについて、増田さんとミノ駆動さんに伺うという企画。 僕が過去に出会い、影響を受けた本について、技術書を中心に振り返ってみよう。 20代新卒入社後に保守を担当したシステムはJ2EE（今でいうJakarta EE）のエンタープライズアプリケーションだった。Sun MicrosystemsのEnterprise 10000（通称E10K。あるいはStarfire）という当時では化け物クラスのハイエンドサーバーで稼働していて、おそらくSunのコンサルに勧められるがままにEJB（Enterprise
初めまして、kagayaです。 AIネイティブなプロダクト開発を頑張っています。 共訳した「AIエンジニアリング（オライリー・ジャパン）」が11/28に発売です。よろしくお願いいたします。 世はAIコーディングエージェント時代。 圧倒的に手数は多くなり、自動でPRを生成する取り組みも見かけるようになりました。 かくいう私も、Claude Code Actionを夜間に動かしてGitHub Issueを自動解決する実験をし、朝に作成されているPRを眺めて、「これが不労コード生活か」と思うなどしていました。 そんな中で、新しく生まれた悩みの一つは、このコード、どこまでレビューすればいいんだ？ です。 全部読んでたら、自分で書いた方が早くない？でも全部信じるのも怖い。 バイブに身を任せた結果として生まれた数千行のPRを前に、途方に暮れた経験がある人もいるのではないでしょうか。 Thoughtwo
この記事は、「KNOWLEDGE WORK Blog Sprint」第1日目の記事になります。 mayah です。株式会社ナレッジワークでは創業時より CTO をしています。開発ではプロダクト全体のアーキテクトをやっていることが多いです。普段からメンバーたちが書く Design Document やコードのレビューをする機会も多く、コードレビューだけでも月 200〜300 PR ぐらいは見ています。 さて、美しく堅牢なコードを書く上で、一握りのソフトウェアエンジニアは自然に習慣としていることで、多数のソフトウェアエンジニアは全く考えていない（もしかしたら一度も考えたことすらない）ように見えていることが１つあり、本日はその話をしたいと思います。 それは、操作よりも状態・性質に注目してコードを書くという習慣です。 ここでいう操作とは、インプットからアウトプットを計算したり、なんらかのオブジェク
こんにちは、しんざきです。週に一回ファミコン版のイーアルカンフーを遊ぶ習慣がもう15年くらい続いておりまして、そろそろ一度知見を集積しようかと思っているところです。面白いですよね、イーアルカンフー。 この記事で書きたいのは、大体以下のようなことです。 ・「評価されやすいエンジニア」とは、「ちゃんと自分の成果を言語化してアピール出来るエンジニア」です ・「アピール」というと苦手意識を持つ人が多いのですが、必要なのは自分を大きく見せることではなく、具体的な達成状況の可視化です ・「自分の成果を言語化出来るか」というのは、日々の仕事で能力を発揮する上でもとても大事です ・成果を言語化する上では、ちゃんと「ストーリー」を考えることも大事です ・ストーリーといっても、別にありもしない物語を作れという話ではなく、組織が持っているビジョンや方向性に合致する成果になっているか、という話です ・特に新人さん
はじめに @dyoshikawaです。 私の2025年6月ごろからの取り組みとして、Claude CodeによるVibe CodingでRulesyncというOSSツールを公開しました。 そこでかなり自由にClaude Codeでいろんな手法を試すことができましたので、AIコーディング全般のTipsをお伝えできればと思います。 一方で（人間の介入が少なすぎる）Vibe Codingの弊害としてコードベースやドキュメントが崩壊し、途中で開発がストップした場面もありました。ここのプロセスの反省と、どのように開発可能に復帰させたかという点も紹介します。 最後に人間の役割、AIの役割、ソフトウェア開発の未来といったトピックに触れたいと思います。 Rulesync: 主要なAIコーディングツールの設定ファイルを一括管理 まず、私が開発・公開したツール Rulesync について簡単に紹介します。 こ
はじめに私はITアーキテクトを生業としているので、ソフトウェアに関する技術力を上げることはとても重要な課題であり、日々アップデートのための学習を継続しています。実は、思考力を磨くことは同じくらいに重要であり、ITアーキテクトに限らずすべてのITエンジニアにとって当てはまると考えています。本記事では、そう考える理由について述べます。 技術を応用して複雑な問題を解決するITエンジニアが解決しなければならない問題は、多種多様で、複雑に絡まり合っていることがほとんどです。技術を単純に適用すれば解ける問題というのは実はそう多くありません。 問題を深く分析し、仮説を立てて解決策を試す、うまくいかなければまた別のアプローチを試みる、といったプロセスが必要となります。そのような複雑な問題解決プロセスを首尾よく進めるには、推論や仮説立案などの思考をフル活用する必要があります。 生成AI時代を生きのこる生成A
カミナシでプロダクトマネージャーをやっています、よしおかしおり（@oriori440）です。 「作るのが簡単になった今、機能を「大きく」「たくさん」作っていませんか？」 生成AIの進化や、ノーコードツールの充実で、非エンジニアでも「とりあえず形にする」くらいなら誰でもできるようになりました。 私自身、ちょっとしたプロトタイプはFigmaMakeやv0を活用してシュッと作り、お客様にあてることができています。 そんなある日、弊社のエンジニアがSlackにこんな投稿をしてくれました。 私は以前から「作らない」ことや「小さく作る」ことを大切にしていましたが、AIで作るのが簡単になった今だからこそ、よりその考えを大事にしながら、一方でアップデートもして行く必要があると感じています。 ▼過去に発信していたnote 今回は、私がカミナシで「小さく作る」ためにやったことや、あるいは「作らない」ためにやっ
AIに全てを任せた危険な実験 Claude Code（月100ドル）に課金し、バイブコーディングに挑戦してみました。 （バイブコーディングとは、AIに振動的に高速でコードを生成・修正させ続ける開発スタイルです。） 今回は危険を承知でAWSの認証情報まで渡し、デプロイも含めて完全にAI任せにするという実験を1か月間行いました。 結論から言うと、最初の1週間は天国、その後は地獄でした。 最初の1週間 初週の生産性はとても良かったです。 エラーが出ても、そのままClaudeに投げれば瞬時に解決策を提示し、修正までしてくれます。UIデザインも仕様書を渡せばモダンなコンポーネントが次々と生成されました。 うまくいったコードはGitHubにコミットし常に良い状態をキープするようにしてました。 AWSへのデプロイもAI任せ。1週間でデモアプリが完成し、多少のバグはあったものの、ちゃんと動作していました。
ダイバーシティという言葉は以前からありましたが、SDGsの考えが拡がる中で、日常的に接する機会が増えているように思います。クラスメソッドのカルチャーを言語化した「Classmethod Leadership Principle」の中にも「ダイバーシティ」という項目があり、クラスメソッド社員にもなじみ深い言葉でしょう。 ダイバーシティを日本語に直訳すると「多様性」になります。しかしながら、人権や雇用機会の文脈で使われる「カタカナのダイバーシティ」は、すべての多様性ではなく、人のタイプやライフスタイル、働き方の多様性を差していることが多いです。つまり、多様性とダイバーシティは、日本においては微妙に異なったニュアンスの言葉といえます。 このエントリーは主に、ダイバーシティではなく多様性の話を中心にしています。 多様性は無条件に許容されるか？ 多様性という言葉は既に一般用語となっており、特別な説明
「取締役に任命されたのですが、力不足を感じています。このまま職を続けるべきでしょうか」 先日ある講演会で、そんな質問をされることがあった。 質問をして下さったのは、勤務先企業で役員に抜擢されたばかりという男性だ。 与えられた役職を重く感じているものの、 「器が人を育てる」 と信じ、職責に取り組み続けているのだという。 しかし想いだけでは難しい壁を感じ、このまま続けるべきなのか。 どうすることが組織と部下のためであるのか意見を聞かせて欲しい、という趣旨のご質問だった。 「何が正解なのか、私には正直わかりません」 軽々に答えられない質問に、思わず本音が出る。 そして要旨、以下のような回答をする。 私自身、困難な仕事を乗り越えられた時に成長を感じることができたとは、思っている。 しかしあんな経験はもう二度としたいと思わないし、無茶をすべきとも思わない。 「自分にはできない」と思った時には撤退する
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
