最近、「もし高校野球の女子マネージャーがドラッカーの『マネジメント』を読んだら」（以下、もしドラ）という小説を読んだ。2009年12月の発売以来、販売部数が38万部を超えるベストセラーという。この4月に、ビジネス誌が「ドラッカー特集」の冒頭で6ページにわたり「もしドラ」を紹介していて、気になっていた本である。 この小説のストーリーを簡単に紹介すると、主人公は高校野球部の女子マネージャー「みなみ」。ドラッカーの経営書『マネジメント（エッセンシャル版）』を読みながら、野球部を甲子園に連れていくべく、マネジメントする――というもの。ピーター・ドラッカー（1909-2005）といえば、「20世紀最高の知識人」「マネジメントの発明者」などと評される経営・社会学者である。そんなドラッカーの経営書を高校生が読んで実践するという破天荒な設定なのだが、これが面白い。 「もしドラ」では、要所要所でドラッカーの

前回は，どの会社でも通用する仕事術を構成する7つの力のうち，(6)の「褒める」を説明した。7つの力は以下の通りである。 仕事を円滑に進めていくためには，「褒める」ことが非常に重要である。部下や後輩を褒めるのは言うまでもない。時には上司や同僚，取引先の関係者もうまく褒めることが，仕事がうまく進めるコツである。これこそ，どの会社でも通用する仕事術と言えるだろう。褒めるについては，筆者のWebサイトでチェックリストも用意しているので，ぜひ利用していただきたい。 今回は，(7)の「叱る」を取り上げる。これも，どの会社でも使える重要な仕事術である。組織をマネジメントする場合も，部下を指導する場合も必要になる。 基本的に，叱るというのは上司が部下に対して使う，あるいは先輩が後輩に使うマネジメントの手段である。ただし，言い方に細心の注意を払えば，上司と部下，先輩と後輩以外の関係でも威力を発揮する。 叱る

ひろりんママが若かったころ、一人で食事をしている女性は稀でした。仕事の都合で、一人で外で食べなければならないことが多かったひろりんママは、レストランや喫茶店で他の男性客から向けられる好奇の目が苦手で、外で菓子パンをかじったり、駅のホームでおにぎりを食べたりしたものです。若かったんですね。 今から思えば、昼は誰かと一緒に食べなければいけない、女性は一人で食事をするものではない、友達がいない人という風に見られたくない、という既成概念にがんじがらめにしばられていたんだと思います。 冷静に考えれば、周囲の人が好奇の目を向けていたというわけではないと思うんです。むしろ、自分で「外から見れば自分はこう思われるに違いない」という、自意識の囚人になっていたんだと思います。「この人は一緒にランチを食べる友だちや仲間もいないのか」と思われるのが怖かったんですね。愚かだったと思います。 “付き合ってもらう”人は

夏野 剛／慶應義塾大学 特別招聘教授 日本人は，悲観論好きが多すぎる。この空気を変えたい。これが，「超ガラパゴス研究会」を始めることにした理由の一つだ。 日本には「日本は駄目なんだよね」と，なぜかうれしそうに話す経営者が多い。その理由は以下の三つに集約できる。一つは，やらない言い訳を作りたい。自分自身の能力でなく，産業全体に問題があるとすり替えたいのだろう。 二つめはビジョンが無いのを隠したい。自分にビジョンが無いことを正当化するには，今いる産業に将来がない，あるいは日本が悪い，だれかが悪いということにしたいのだ。 最後が，自分としてはベストを尽くしているので，ほかの事業のポジションを下さいという甘えである。「この事業は駄目ですね」と言うことで，自分の立場が無くなるとは考えないのだろうか。米国企業なら，自身の事業を否定する経営者などあり得ない。 真の経営者なら「5年後はこの産業を伸ばす」，

フリープログラマってどんな生活をしているんだろう，と考える人は多いかもしれません。ここでは，プログラミング専門誌「日経ソフトウエア」で2001年から続いている長寿人気連載「フリー・プログラマの華麗な生活」（現在も連載中）から，その厳しさ，楽しさを垣間見ることができる記事を12本，厳選してご紹介します。 連載筆者の中條氏は1960年生まれ。大手SIベンダーに勤めた後，何度かの転職を経て1999年に独立。モバイル・コンテンツ系のシステムをはじめ，Webシステムの開発を得意とするフリーのソフトウエア技術者として10年にわたって実績を上げてきました。 もちろん，現在に至る道は決して，平坦ではありませんでした。しかも最近は，「100年に1度の大不況」で，大きなプロジェクトがいくつもクローズし，首都圏でもソフトウエア技術者は余り気味。中條氏もその例に漏れず，人材派遣会社との仕事探しの顛末を日経ソフトウ

このコラムを読んでくださっている皆さんは、みな、受験のハードルを苦労して越えてきた人ばかりのはず。そして、今また、就職というハードルを前に、思い悩んでいらっしゃる方も多いのではないかと思います。正直申し上げて、皆さんの就職がうまくいくかどうかは分かりません。うまく希望通りの就職ができた方には、心からのおめでとうを申し上げたいと思いますが、経済環境が厳しい中で、正直、希望通りの就職ができない方の方が多くなるのではないか、とちょっと心配しています。 まだ20年少しの人生しか生きていない皆さんにとって、受験・就職や恋愛で自分が思う通りの進路に進めない、というのは、大変な挫折に感じられると思いますし、挫折にあった時の悲しみや苦しみは、つらいだろうな、と気の毒に思います。でもね、人生46年間も生きてくると、小さな挫折、大きな挫折も含めて、世の中は自分の思う通りにいかないことがほとんどなのだと、だんだ

最近、「おたくを信用できません」とユーザー企業が言い、クラウド関連商談が流れた話をいくつか聞いた。信用できないと言われた企業は、私が思うに日本で最も信用できる部類の企業ばかりだが、情報漏洩事件が相次いだことでユーザー企業が過敏に反応したらしい。一方で、Google Appsのようなクラウドサービスの利用は日本の大企業の間でも進んでいる。さて、このあたりのどう考えればよいのか・・・。 日本でのクラウド・コンピューティングのビジネスで厄介なのは、ユーザー企業の担当者のリスクに対する過剰な“怯え”だ。特に情報漏洩に対する心配は尋常ではなく、不安で頭がいっぱいになり、思考停止してしまう。いくらコスト面や運用面のメリットを説明しても「ダメなものはダメ」。従来のアウトソーシングならともかく、複数の企業でリソースを共用するクラウドなんか論外ということになる。 しかし、本来これはおかしな話。日本で最も信用

「部下を生かせない上司」は，IT部門にも例外なく存在します。部下の良き理解者というだけでは，組織や部下が望む方向に能力を伸ばすことはできません。これはIT技術者でなくても言えますが，部下にとって興味がわく仕事かどうかで，それに対する姿勢は極端に違いますし，そこから得られるスキルアップの幅にも大きな差が生まれるからです。 部下を生かせない状況をそのままにしておくと，「組織として成果が上がらない」「本人がやる気を失う」など，個人と組織の相互成長は望めません。 テクノロジストを働かせるには IT技術者は，高度な知識・技術と肉体労働を合わせて仕事をする人達であり，経営学者のピーター・ドラッカーは「テクノロジスト」（注１）と呼んでいます。私もプログラマからシステム・エンジニア，ITコンサルタントとなり，汎用機からミニコン，ERP導入などITの仕事をしてきました。テクノロジストの1人として言うと，IT

日本では神道系の信仰を持つ人々が約1億600万人。仏教系が約9600万人。キリスト教系が約200万人。その他が約1100万人。合計すると2億1500万人となり，なんと日本の総人口の2倍となってしまう。話を単純にすると，1人あたり2宗教かそれ以上。ゆえに通説では，日本は多神教の国であると言われる。 しかし，一神教と二項対置させ多神教をとらえるのは，元来，一神教側からの見方だ。安直に日本を多神教の国と見るのはいかがなものか。多神的であると同時に，歴史を通して幾重にも宗教的なるものが埋め込まれ，積み重なり多層的な姿を形成している。すなわち，日本の宗教的な風景は多層・多神教的な姿の上に立っている。 プロテスタント，カソリック，その他の会派を含めても，日本のキリスト教の信徒は全人口の0.8％で少数派。前の講座では，原始キリスト教の話をしつつ少々脱線してミトラ教について一言したが，日本ではキリスト教は

本記事は日経SYSTEMSの特集をほぼそのまま再掲したものです。初出から数年が経過しており現在とは状況が異なる部分もありますが，この記事で焦点を当てた開発・運用現場の本質は今でも変わりません。 かつてSEとして働いていたころ，毎日が残業でした。土日の休みもあまりなかった。「誰よりも頑張っている」。そんな自負を持って，夜遅くまで会社に残り，残業漬けの毎日を送っていました。 そんな仕事のやり方を変えたのは，ボストン コンサルティング グループに転職してしばらく経った30代後半のときです。より厳しい職場に身を置いたのに，残業はほとんどゼロ。19時には退社するようになりました。あるきっかけがあったのです。 実は転職した当初，仕事のスピードにまったく付いて行けませんでした。年下のコンサルタントが，私の何倍もの仕事をこなす様子を目の当たりにしました。焦らないわけがありません。毎日深夜まで仕事を続けまし

Google検索サービスのインフラストラクチャを基盤にした「Google App Engine」。各種ライブラリやアプリケーション・フレームワークが提供される。データを永続的に保管するサービスがあり，それをデータベースのように利用可能。その一方で，「リクエストの処理は30秒以内」といった制約がある。 米Googleが提供する「Google App Engine（以下，GAE）」は，Webアプリケーションの開発・実行環境を提供するサービスです。基本的にはGoogle検索サービスと同じシステム基盤なので，スケーラビリティに優れた実行環境であるといえるでしょう。GAEの上でアプリケーションを開発する際，何がポイントとなるのでしょうか。その基本を，今回と次回の2回に分けて解説します。 今回はGAEの概要編で，まずGAEの全体像を説明します。そのうえで，開発の手続きと環境，提供されるライブラリとフレ

BlackLine・Concur・MS Copilot、ハイパーオートメーションツールが充実 2024.09.19

コーディング規約は，プロジェクト・メンバーに，プログラミングのルールを認識してもらうために作成する文書である。通常，ソフトウエア・アーキテクトがまとめる。コーディング規約に多数のルールを詰め込むと，プログラマはそのすべてを頭に入れておくことが難しくなる。結局，遵守されなくなってしまうので注意が必要だ。 既存の規約を実情に合わせて改変する コーディング規約の作成は，地味で手間のかかる作業である。プロジェクトごとに，ゼロから作成する必要はない。他プロジェクトで使用されている既存のコーディング規約をベースに，使用するプラットフォームや開発言語に合わせて改変すればよいだろう。 コーディング規約に記述する項目は，一般には「コーディング・スタイルやコメント書式」「識別子のネーミング」「プログラミングの禁止事項」「慣例やTIPS」の四つである。 このうち，「コーディング・スタイルやコメント書式」と「識別

日経クロステック登録会員になると… ・新着が分かるメールマガジンが届く ・キーワード登録、連載フォローが便利 さらに、有料会員に申し込むとすべての記事が読み放題に！ 【キャンペーン実施中】年額プランもお得 ＞＞詳しくは

課題分析や要件定義における合意形成の重要性を考えれば，たとえ時間がかかっても，メンバー全員が納得するまで議論を尽くして結論を出すべきだ。反対意見がくすぶったまま議論を打ち切れば，あとで不満が噴出したり，メンバーの参画意識が削がれてその後の会議に支障を来したりする。 ファシリテータは議論の節々で，メンバー1人ひとりに反対意見がないかどうかを確認する必要がある。例えば，筆者は業務要件を決めていく際に，「目的の実現を阻害している主要な問題」，「主要な問題を引き起こしている本質的な原因」，「主要な問題を解決するために取り組むべき課題」，「課題を解決する新しい業務の仕組み」といったポイントに分けて，反対意見がないか確かめている。 結論が見えたときファシリテータがいきなり締めに入ると，反論があったとしても出にくい。結論を出すまでに段階を踏むことが肝要だ。 まず，そこまでの議論の過程を簡単に振り返る。そ

今回はPythonの代表的なWebアプリケーションフレームワークであるDjangoを紹介しましょう。 DjangoはPythonを代表するフルスタックなフレームワークで，独自のテンプレートエンジン，O/Rマッパー等を備えています。DjangoはGoogleAppEngineのSDKにも含まれています。 前回の記事ではGoogleAppEngineでDjangoのテンプレートを利用する例を紹介しました。DRY(Don't Repeat Yourself)，テストサーバーを利用した素早い開発，正規表現を用いたURLディスパッチ，再利用性の高いコンポーネントといった特徴を持ちます。これらの特徴はRubyのフレームワークであるRuby on Railsと似ているところがあります。 昨今，Railsの台頭により国産のスクリプト言語Rubyが人気を集めていますが，Pythonは可読性が特に高く，未経験

GoogleAppEngineについて前回紹介し，SDKを用いたローカルでの開発方法，および「Hello, World」を表示して公開するところまで説明しました。 今回はかんたんなアプリケーションの作成を通してGoogleのwebapp Frameworkを説明します。サンプルとして，かんたんなひとことブログサービスを作成します。このアプリケーションの作成チュートリアルを通して，データの投稿や削除，ユーザー認証などWebアプリケーションの基本的な機能を実装する方法を一緒に学んでいきましょう。 仕様を決める 実装する機能は以下の通りとします（図1，図2）。 ひとことの投稿 ひとことの削除…自分が投稿したひとことを選んで削除できる すべてのひとことの削除…管理者のみすべてのひとことを削除できる

メンバーの「引き継ぎ」は，人の出入りが多いプロジェクトには付き物である。しかし，引き継ぎをうまくマネジメントしているプロジェクトは非常に少なく，同じ過ちが何回も繰り返されている。7つの典型例を通して，引き継ぎに潜む問題点を見ていこう。 後藤 年成 マネジメントソリューションズ マネージャー PMP ある程度の規模があるシステム開発において，プロジェクトの立ち上げから本番移行を見届けるまで，一貫して同じメンバーで作業を実施することは，ほとんどないでしょう。小規模案件や保守作業を除けば，少数のメンバーで要件定義を始め，開発・テストに向けてメンバーが増えていき，本番移行に向かってまたメンバーが少なくなっていくはずです。 この「メンバーが増減するとき」には，プロジェクトマネジメントにおける重要な課題があります。まず，追加メンバーが着任する時は，新メンバーに対してプロジェクトに関する説明や，プロジェ

技術者として働く面白さとは何か。先輩技術者は，どのような苦労を乗り越えて活躍しているのだろうか。プライベートはどう過ごしているのか。会社とは，どのようなところか。技術者を目指す学生が就職先の会社を選ぶときに重要なことは何か――。このような数々の疑問・質問に対して，1000人を超えるTech-On！読者の皆さんに答えてもらいました注1）。第1回目は，「技術者として働く醍醐味」について，Tech-On！読者の技術者の意見を紹介します。 注1）2009年6月19日～26日にWebサイト上で調査を実施した。「Tech-On！」読者を対象に，アンケート用URLを告知した上で回答を依頼。1053の有効回答を得た。有効回答者のうち，技術者（611人）および技術者兼管理者（329人）の合計（940人）が全体に占める比率は89％だった（図）。

進捗会議や検討会議，障害対策会議やちょっとした打ち合わせなど，システム開発プロジェクトの現場では日々何らかの会議が行われる。その際，事前に資料を準備して配布する方法もあれば，ペーパーレスでプロジェクタに情報を映し出して行う方法もある。これらの会議は，やり方次第では何の成果もなく終わることが少なくない。終わった後，いったい何のための会議だったのかと思うことはないだろうか。“空中戦”主体の会議を行っていると，どうしてもこのような会議になりがちなのだ。 ここで言う空中戦とは，お互いの意見を文字にすることなく，ただ口頭だけで会議を行うことを指す。参加者の頭の上をお互いの言葉が飛び交い議論（戦闘）している様子が，まるで戦闘機が空の上で戦っている様子に似ているところから作られた造語である。確かに見た目には華々しい空中戦ではあるがそれで大勢が決することはない。 7時間を無駄にしたKさん Kさんは入社12