調達 【Amazon.co.jp限定】 ガールズ&パンツァー 最終章 第1話 (特装限定版) (「中村桜の アヒルさんでも分かる！総火演の楽しみ方講座」BD付) [Blu-ray]

キマシタワー！！

【Amazon.co.jp限定】 ガールズ&パンツァー 最終章 第1話 (特装限定版) (「中村桜の アヒルさんでも分かる！総火演の楽しみ方講座」BD付) [Blu-ray]

エンジニアとして仕事をする大義は何か

「こんにちは、センパイ。相変わらずお忙しいですか」
「見てのとおり、今日は忙しいよ」
「じゃあ、また今度にしますね」
「いいよ、今ので思考切れたし。あ…そろそろコーヒーでもと思っていたから丁度よかったんだ。なかなか区切れないときってあるじゃん。それだったしさ」
「センパイに気遣ってもらって後輩としては嬉しいです。ありがとうございます。ではそのコーヒーを奢ってもらいますね」
「やっぱりそうなるのか」
「わたしに奢れるセンパイは少ないんですよ。名誉職ですね」
「はいはい、いいよ。行こう」

「それで」
「それでとは」
「来た理由。話してみたら」
「そう来ましたか。先を読まれるのは好きじゃないですね。じゃあ雑談でも」
「コーヒーあげないよ、ちゃんと話してくれないと」
「ではお聴きますけれど、センパイはどうしてエンジニアとして仕事をしているのですか」
「どうしてって、そりゃお金稼がないと。それだろう、誰だって」
「でも他の仕事だっていいのに手間の掛かる難しいエンジニアを選ばなくてもいいじゃないですか。他の仕事を差し置いてエンジニアとして仕事をする理由は。何がセンパイをそうさせているのですか」
「何でエンジニアを選んだか…どうして、ねぇ。ふーん、そうだなぁ…それ大義みたいなものなのかな。大義ねぇ…ないよ。大義なんて」
「何も」
「何もない。きっぱり。ない」
「言いにくいことなんですか」
「詮索するなー、いつもだけど。じゃあさ、なんで後輩ちゃんはエンジニアとして働いているんだ。他にも仕事は選べたはずだ。後輩ちゃんの能力なら。なんで」
「ひどいですね、質問に質問を返すとは。それはダメだと教えてくれたのはセンパイですよ。いいですけど。わたしの大義ですか。そうですね、なんでしょうね。考えたことなかったです。」
「だろう、大義なんてそんなの持ち合わせている人なんてそうそういないんじゃないか」
「大義というから引くんじゃないですか。ほら、もっとカジュアルに考えてみたらどうですか」
「カジュアルにって…言い方変えても中身は変わってないよ。そうだなぁ、エンジニアとして仕事をする大義って、それをするために守る道義なんだよな。踏み外さない道だよなぁ。…それって価値観だな。価値観。そうだな、そう考えると考えやすいかな」
「でしょう、そうしてください。カジュアルに」
「俺の場合はさ、プロフェッショナルとして恥ずかしくないかなんだよ。プロとして自分がそれに満たない行為を選択しないことが価値の判断基準なんだ。言い方を変えればイズムだな」
「へーそうなんですか。プロとして恥ずかしくない判断をしているか、と。それは伝わり易いですね。なるほど」
「でさ、どうしてこんな質問をして来たの」
「あ、そろそろ行かないと。センパイ、コーヒーごちそうさまでした。続きはまたコーヒー奢ってくれたら話しますね」
「また逃げられた…いつもの風景だけど」

天才たちの日課 クリエイティブな人々の必ずしもクリエイティブでない日々

たったこれだけで興奮した感情を制する技術

打ち合わせをしてだんだんと気持ちが高ぶって行ったり、ついカッとなりながら話し続けてしまったりすることってあると思います。それが楽しい話で自分の得意分野で色々と話たくて話すことを続けているような（今風にいうとイキリとかいうのかな）ことだったり、仕事で仕様決めの打ち合わせをしていてどっちがいいとかレビューで痛いところを突かれてムキになってしまったとか、マネージャとの業績評価での評価がイマイチなのに説明もいま三くらいな説明しかなくてなんだよ、と思ったり、そんなケースです。

こうした感情の高まる中での発言は得てして後で冷静になってああ言えば良かった、こう言えば良かったと思うのです。後悔ですね。ありますよねー。そういった後悔を防ぐやり方が簡単にあるなら取り入れたいですけれど、そういった場面で何の準備もなく確実にできる方法がいいですよね。だって、いきなり席を立って精神統一のお祈りとかしたくないですもの（しないでしょうけど）。

生命活動をコントロールする

生命活動で簡単にコントロールできる活動があります。さて、なんでしょう。ちょっと考えてみてください。

＃答えは続きを読む、で。

有益な飯テロとしての技術発信

多くの50代のユーザと同じような使い方に一見みえるけれど、ちょっと違う使い方をしているのです。別にトリッキーというわけではないですけれど、延々と美味しそうな飯テロ画像や組織の上役に「いいね！」オペレータをしていたり、なんてことはしません。まー、上役なんて繋がらない（仲の良い偉い人は除いて）のでそんなことにはならないですけどね。

ただ、こんなことを考えるのです。facebookもtwitterも道具です。エンタメの道具として使うなら楽しく使えばいいし、商売の道具として使うなら繁盛するように使えばいいです。そこは使う人の道具をどう使うかの目的に合わせて使えばいいですよね。

じゃあ、エンジニアとしてどう使うのか、と。

これを考えて用途が幾つもあって、親和性のない目的があるなら別アカウントにしたり（誤爆注意だけど）サービスで使い分けたりすればいいのです。

技術を追うためにを使う

技術を追うためにfacebookを使うとはどういうことか、と。日常を慣れ流しする使い方もあるでしょうし、個人的な思いを伝える使い方もあるでしょう。上役への忖度としての使い方かもしれない。その個人がそれでいいなら好き勝手に使われたらいいのですけれど、こう使おうと思って使っているオジサンがいますよ、という事例です。

使い方の大きな軸は、情報収集です。何のか。それは技術情報を繋がっているお友達から貰う、ということです。どうしても情報のセンサ感度が高い方には叶わない（海外の英語の情報もあったりするともうすっかり頼っちゃう）ので専門家で先端を行く方がシェアされる情報を全く見切れないTLですけど目に入った情報で追っていくわけです。

そうしたお友達も同じようなクラスタとお友達になっているので複数のお友達がシェアすれば一期一会ではなくカバーされていくので割と取りこぼしはだいぶ少なくなりますね。

繋がるために使う

 ソーシャルの基本みたいなものですけど、関心のある技術のクラスタに繋がることが人的なストックになるのですよね。専門家が多いので相談もしれっとしやすいし。

イベントで顔見知りになればその場で繋がっておけばいいし、会話しながらこれですかねとアカウントを探して本人確認すると後でと思って忘れないのでいいですよ。

ソーシャルも結局、画像とテキストでしかないので情報量としては限られます。専門分野を追うためには本人から聞いた方が良いことが多いので、繋がっておいて、困ったときにDMを交換できる程度に繋がることは大事かな、と。

将来のエンジニア人生のために

 そのうち定年ですから、その後に何かしらで食べていきたいと思うんですね。ジジイになって一人でやるのもいいですけど、団体にしてもいいし、繋がりで雇ってもらってもいいと思うのですよ。

最後のはあまりないかな、とは思うけど。

多分、1つ目と2つ目両方をやるんでしょうね。ワタシは。そのときになって探しても遅いんですね。団体にするなら仲間候補に刷り込みしてその気になってもらわないといけないし。ということなんですよ。

ただ、そればかりだと露骨だし、ワタシ自身がどんな考えを持っているか、嗜好があるか、志向があるか、思考をするかを知っていて欲しいことは飯テロをしたり情報発信したりするんです。

有益な飯テロでないとね

 極端な例でいればマニアでない松屋の画像を投げても誰も嬉しくないんですよ。貧相に見えるし。そうじゃなくて、その飯テロを見た人が次の会合で使うとか、自分で作ってみようとか、そういいった情報が手に渡ったときに使える可能性がある情報でないと有益性はないのですよ。

それじゃ誰も見てくれない。

ただの飯テロでもおつきあいの「いいね！」です。それじゃ残らない。少しは役に立つように投げ込みたいものです。

で、飯テロを技術に置き換えて成立するところに注目して欲しいんですね。ソーシャルはやはりギブアンドテイクですから、有能なコンテンツを投げないと意味ないですから。

ジョイ・インク 役職も部署もない全員主役のマネジメント

誰でも出来る組織の始め方

ま、組織はチームに置き換えてもいいですし、勉強会のような外部活動団体と読み替えても大丈夫（なはず）です。チームのメンバを5人以内にしろだとか、ビジョンだとか小難しいことは考えなくていいです。出来るだけ平坦な言葉で書ければと思っています（今は）。

何ができればチームの存在価値があるか

これを決めましょう。チームを編成するということは、そのチームが存在するための目的があるということです。

その目的は必ず言葉として文字にしましょう。頭の中で思っているままではダメです。頭の中で変わりますよ。文字になっていないので文字にするとき自分の頭で思っていたハズの言葉を考え直してしまうからです。

まず、言葉にしましょう。

そうそう、曖昧な言葉にしないように言葉を選んでください。耳障りの良い言葉は曖昧です。ふた通りの意味に取られないようなはっきりした文章を作りましょう。

最小限の人数で

 始めるときにはそのチームで活動ですることはなんでも初めてです。だからこそ、最小限の人数で始めましょう。大きくすることはバカでもできます。これじゃまわらないよ、というくらいがいいです。

なので、初めは1人でやってみましょう。もう1人じゃダメだ、となったら初めて一人増やします。自分の出来ないことを出来る人がいいです。やってもらえることのありがたみが感じられます。

自分の出来ない溢れている作業を身代わりしてもらえるということを忘れないで。

常に状態を知る

 1つのタスク、作業をすることを考えたらどうなったら完了するんだ、という完了基準は毎回決めましょう。そうしたら必ず作業を進めたら今どういうような状態かを確認しましょう。まずかったら、思うように進んでいなかったら計画を変えるのか進度を変えるのかを試してみましょう。

途中参画したエンジニアの立ち上げ

昨日の帰り、会合があったのでそこそこ遅い時間に、新規参画した若手のメンバをどう立ち上げるようかとあちらこちらと思いつくことを繋ぎながら脳内でどうしたものかと歩いていたんですね。

会合に出て遅くなることって実はあまり好ましくは思っていないのです。何が好ましくないかというと、睡眠時間を削ってしまうから。子どもを持っているお家だとどこもそうかもしれないけれど、家族は22時過ぎから1人、また1人と入る感じで23時代にお風呂を使っていることが多く、そのころに帰ると待たされるとさらに睡眠時間が減っていくので避けたいな、と。じゃあ会合なんて出るのを止めればいいと思うかもしれないけれど、自分で立ち上げた会とか活動団体だったりするとやっぱりそうはいかないな、と。

矛盾したこというと、会合で遅くなるのは後に負担が皺寄せするので避けたいけれど、その会合が意義がある場であればやっぱり行きたいわけで。意義があるというのは行って会話することでこちらにもメリットがあるということでもちろん相手にも何か伝えられているとは期待したいところですが。

そんなことも考えつつ、少し緩んだ夜空をときどき見上げながら、1年前に参画したベテランエンジニアと若手エンジニアとを思い出しながらどうしたものかと。

ちょうど、その若手と1on1をする機会があって背景となるようなことをいくつか喋ってもらって思ったことはいわゆる地頭はとても優秀なんだ、ということを感じたんですね。学歴を知っているのですが少なくとも自分よりは段違いに優秀。

そうすると課題はこちらにあるな、と思うわけです。もちろん、大学などでの学生のお仕事の研究とかレポートを作成するようなこととお仕事とは求められていることが違うので比較することに意味はないし、そこのギャップというか転換、頭の切り替えに躓く若手も少なくないので。

担当してもらうお仕事もプログラミングのようにインプットとアウトプットが明確に決めらるものならゴールが明示的で割ととっつきやすいと思うのですが、仕事の背景となる情報が過多な上に全体のバランスをとりながらも確証を取りつつアウトプットをしていかなければならず、ハードルが高いことはわかっているのですけれど。

話を優秀だに戻すと、優秀なのだから課題設定を適切に（こちらが）御膳たてしておくと多分、吸収とアウトプットの精度は上がるのだろうな、と。

地頭が良いのに仕事に慣れるところで躓くように見えるのは、情報処理の方が早すぎてコミュニケーションが追いつかないからではないかと思い当たったところまで住宅地の角までたどり着いて。そう言えば、同期（だったか）数学科出身で頭がものすごく良くて（と思っている）けどコミュニケーションが追いつかないエンジニアがいてそれと似ているのでは、と。そうか、そうかと変なところに合点して。

とすると、公式、セオリー的なものを明示して、繰り返し経験知を上げていく方が良いのかもしれない。ただ、膨大な背景的な情報、つまり文化的なもののインプットのタイイングがどうしても後出しじゃんけんになってしまわないように。

若いっていいなと思う。

ジョイ・インク 役職も部署もない全員主役のマネジメント

エンジニアのプロジェクト基礎筋力をつける基礎筋トレメニュー

プロジェクトマネージャに限らず、システム開発に携わるエンジニアは体系的なシステム開発手法とプロジェクトマネジメントを形式知で良いからフル装備でストックしておく必要があると考えています。

どういうことかと言うと、体系的なシステム開発手法では、現場ではウォーターフォールでもアジャイルのスクラムやカンバンのどれを採用しているとしても、ーー要件分析から商用利用までの工程（工程名称は個々の組織が独自性文化を発揮するのでそれぞれで読み替えるとして）の名称と概要、使用するドキュメントフォーマット、工程毎のインプット、プロセス、アウトプット、完了基準、並びにそれらの工程をマネジメントするためのプロジェクトマネジメントの管理プロセス、例えば作業標準、品質管理、進捗管理などについてシステム開発手法とどのように組み合わせて使用するかーーについては前提とする基礎知識としてエンジニアが知っている必要があると思うのです。

今の現場では担当する工程でのパフォーマンスだけ上げられる知識があればいいと思って仕事をしているとホント単なるオペレータの価値しかありません。なぜなら、システム開発のやり方を訓練する機会を作れないから。

たまたま偶然にも小さなプロジェクトを任されたとき、何を根拠にプロジェクト計画を作り、プロジェクトを回せられると自分の持っている経験知だけで作ることができるかどうか。無理なのですよ、やることが多くて。だから、経験したプロジェクトでやっていて自分に見えていた上部だけをなぞって形ばかりのプロジェクトをやって失敗するわけです。だって知らないんだもん、できるわけないじゃん。

じゃあどうするかと言えば、理想形のシステム開発手法とプロジェクトマネジメントのやり方を体系的にやっているプロジェクトをお手本に理想のプロジェクトを作ることです。

自分が「完璧だ」と思う洋画や海外ドラマを見た後、「自分がこの脚本を５分増やせと云われたらどうするか」「キャラを一人減せと云われたら」「対象年齢を５歳下げろと云われたら」等々の思考実験を延々やってると、信じられない勢いで創作の基礎筋力がつきますよ。どんな世界も基礎トレ大事。

— 朝霧カフカ (@kafkaasagiri) 2018年1月7日

togetter.com

このツイートを見て、そうそう、と思ったんですよ。完璧＝理想と読み替えるなら理想のプロジェクトマネジメントを知らないとプロセスのテーラリング（ツイートで言うところの5分増やしたりキャラを減らすことに相当すること）ができないので。

念のために言っておくけど、アジャイルのスクラムでもカンバンでも中身の作業プロセスはウォーターフォールの作業プロセスと同じだからね。使い方が違うだけで。

一番の壁は理想のシステム開発手法とプロジェクトマネジメントのプロセスを見つけることですけど。その点、大規模プロジェクトは仔細に無駄が多いいかもしれないけれど近いところにあるのでそういったプロジェクトに一度は参画すると良いかもしれません。

筋トレが最強のソリューションである マッチョ社長が教える究極の悩み解決法