  |
はてなキーワード: 進捗管理とは
obsidianとNotionだと思う
どちらもMarkdownエディタとして使えるが、大きな違いはObsidianがローカルのマークダウンファイルを操作するものに対して、Notionはウェブベースのデータベースという感じだ。
Obsidianで書いたものはローカルのmarkdownファイルそのもの。PCで見れば単に.mdファイルを作っているに過ぎない。逆に言えばそのまま他のエディタで再利用できることを意味する。Obsidianはmarkdownを独自に拡張してより見やすく便利に使うためのアイテムだ。画像をファイルに入れておけばいつでも呼び出せるなど、簡易のブログ的な使い方もできる。
最近になってスマホのアプリもリリースされているし、目次機能もある。
特徴的なものにグラフビュー機能があり、AファイルとBファイルをリンクさせるとそれが視覚的に見やすくなる機能がある。これによりとあるメモが他のメモとどれだけリンクしているかが見れるので単純に自分がどういうものをどう利用してきたのかがわかり面白い。wikiを視覚化したものと考えて良い。
プラグインも多く作られており様々なことができる。
簡単に言うとPCで自分用のメモや長文の日記を書くことに特化している。他の様々なメモアプリがウェブ上での共有を簡単に行えるが、obsidianはそれがハードルが高い。
例えばGoogleKeepはどこでも気軽にメモを取れるし家族間での買い物リストなどにも使える。けれどobsidianでそれをしようとすると家族の端末にあるobsidianのファイルをこちらと共有しておかなればならない。そのための機能はあるものの有料か無料ですると手間がかかる。
つまり、一人でPCでマークダウンでたくさん文章を書くためには便利であるが、不特定多数の人に文章を公開したり、メモを気軽に共有するということが目的なら他を考えたほうがいいかもしれない。
また便利なのは便利だがマイナーなので知見が溜まっていない上にスマホでの操作もちょっと微妙ではある。
メモアプリの本命と言われているが、実態はウェブベースのデータベースだ。
何でもできるのが特徴でobsidianとは真逆に最初から共同作業や共有を前提としている。カレンダー機能から進捗管理、議事録を作ったりTrelloのような使い方もできる。書き方もマークダウンとほぼ一緒だけど、マウス操作でできるのでwordpressに近いと思う。
アップデートが非常に活発な上にwebAPIが一部公開されているため、非常に機能が豊富で拡張性も高い。Notion関連のサービスだけで何十もある。
例えばGoogleDriveと連携させたりといったことも楽だ。
例えば一つのファイル内で同じ画像を複数使いたい場合、obsidianなどではそのファイルのリンクを貼ればいいだけなのに対して、Notionはいちいちアップロードしないといけない。これが不便な点とよく言われる。
またSpredSheetsのようにも使えるが現状ではGoogleSpredSheetsのほうが使い勝手は良い
ただ、やはりメモアプリに高機能なデータベース機能がついたものなので使い方次第といえる
元増田の使い方にあっているのはNotionかもしれない
もちろんもっと汎用性の高いGoogleDriveなどのほうがいいかもだが、Notionはここ数年で一番盛り上がっているメモアプリだし知見が溜まっているのが推せる理由だ。
趣味でブログとか時々動画を作っている。全てにおいてプロットやシナリオを書いているんだが、とにかくそれらの管理が煩雑になりやすい。
アイディアだしはケータイのメモ帳や手帳で充分だけど、常日頃からそれらをどこかしらにまとめる必要もありこれが地味に大変。いわゆる週次レビューとかいう奴ね。
まあ週1でやってるわけじゃないけどさ。
大抵はNotionにそれらをまとめている。
では実際にシナリオをどうするのかってことなんだけど、Notionは書くことには特化していないからやりづらい。Notionはあくまでもデータベースや進捗管理に向いているためだ。もちろんマークダウン記法は使えるしそのままブログとして公開も可能と優秀ではあるのだが、中間作業的な雑多なプロット等には向かない。履歴や差分が取りづらいのと検索機能がそこまで優秀ではないから。
やはりそこはテキストエディタが優秀なのでobsidianを使っていた。これは非常に良い物なので多くの人が勧めているが、問題は異なる端末間での同期が取りづらい点。仕事用PCで使いたくても単独アプリな上に同期がやや面倒なんだよね。まあそもそも仕事用のでやるなって話しだが。
Notionだと厳しい面もあるので、今はVSCodeとgitで管理している。これならそこそこ使えるし仕事用のPCだとしてもウェブ版を駆使すれば問題ないからね。
雑多にメモ書き
半導体に関して、国が関与しようとしていて、また失敗するのではという論調は多い。
だが、放置して民間だけに任せておけば成長するという時代は終わっている。
競争相手を見てみればわかるが、米国、台湾、韓国も国をあげて支援をしている。
金だけじゃなく、技術も、人も、法律も、国家リソースを注ぎ込んでいるのに、1企業では対抗できない。
金さえ出せばいい、という意見もあるだろうが、日本の場合、金を出すだけだと失敗する。
研究環境が整ってない所や、技術がない所にいくら金を注ぎ込んでも芽が出ない。
進捗管理だけして他社に投げて失敗する。
国に足りてないものは沢山ある。
半導体のような分業体制になっている場合、把握出来てないのだ。
報道陣も把握出来てないので、業界ランキング上位企業やコンシューマ向けニュースのみで検討となる。
日本の場合、国が研究費を出しているが、民間に技術をどう移管するかというのが弱い。
研究内容についても、民間とアカデミックで離れてしまっているので、研究者の興味関心に閉じてしまい、活かしにくいというのもあろう。
そもそも国が、日本国内でどういう研究が行われていて、どう民間に移管して稼ぐかという戦略がない。
米国が強いのは、人、金、物、技術を国の組織が把握しているからだろう。
常にゲームチェンジャーとなる技術が米国外含め世の中に出ていないか情報収集をしている。
日本の場合、国内報道されるものだけが全てになっているし、メディアも力が弱くなり政治以外は国外まで把握出来てない。
あーわかったわかった（わかってない）って流されちゃうんだよね。
報告してる内容は右から左で、なんか文句言ってんな～って事しか伝わってないと思う。
仕事中ずっとゲームやってる上司が「これやっといて」でなんでも新人君に丸投げするんだ。
稟議、業者の窓口、複数業者の調整、システムトラブル対応、他部署との連携、会議の段取りと議事録
スケジュールの作成と進捗管理、中長期の業務改善計画の立案、もちろんその他の雑用も。
ゲーマー上司・新人君・私の3人しかいない課なので、私がフォローせざるを得ない。
そんで上司の上司や人事部に報告と対処をお願いしてんだけど、流されちゃうんだよね。
しつこく何度も言ったり、メールしたり
かなり強い言葉を使ったり、他部署にも聞こえるくらいの大きな声で話したらやっと問題意識は持ってくれるけど
ヒステリー・怖いおばちゃん・きかない・素直じゃない・愚痴と文句ばかり・宥めるのが大変とか言われてる。
ゲームの件も「やってないって言ってたぞ」で終わる。
普通に考えて正直に言うわけないだろ。
新人や中堅を配属されるのは3人目だ。
彼らは3年で転勤しちゃうので、頑張って仕込んでもすぐリセットされちゃう。
ヤバい社員がいても3年我慢すればバイバイできるから、みんな見て見ぬふりをする。
ゲーマー上司が新人にやらせてた仕事は、異動する時に何故か私に引き継がれる。
弊社のおじさんの心にはおじさんの話しか響かない。
何も改善はしてないけど…
私の条件ではこれ以上望めないような好待遇なので、できれば転職は避けたいけど
バブル世代の定年まであと少し…
これ
家庭にBacklogを導入してタスクを可視化しようとしたら大失敗した
https://anond.hatelabo.jp/20220607152713
会社でもよく見かける気がするんだけど、複合問題だと思うんだよな
やりたいこと：タスクをやってほしい
ここでずれてると思う
「タスクをやらせる」の解決策として「タスク管理ツールの導入」は間違いどころか逆効果かもしれない
元増田も気づいてるけど
会社では、予算や計画を立てて、リソースを確保し、それを実効するというのが基本サイクルだから
その全タスクが膨大だったとしても「やりたくないなあ」にはならない、仕事なんだから
じゃあ私生活でこれをやるとどうなるかというと
・可視化されたらやることが膨大でやる気を無くす
・リソースが限られている
・やっても金が稼げるわけでもない
から、当然やらない
これは家族間でやってもそうだし、自分でやってもそうだろうと思う
「タスクをやらせる」というのは、普通に親のようにガミガミ言ってやらせるか、もしくはゲーミフィケーションの導入が妥当だと思う
ものすごく平たく言うと「恐怖で支配する」か「褒めて伸ばす」か
つってもゲーミフィケーションも難しいし大変なんだけど
夫婦間？無理に決まってる
ところでこの
・可視化されたらやることが膨大でやる気を無くす
・リソースが限られている
・やっても金が稼げるわけでもない
から、当然やらない
という状況はベンチャー企業の状況に似ている
彼らがよく言うやり方は「タスクの取捨選択」「イテレーションを回す（スクラム、かんばん）」だ
タスクを洗い出す、1週間でできることだけやることリストに入れ、実施し、振り返る
このフローだとよりうまくいくかもしれないが
これだってやる気が無いやつのケツを叩くだけのパワーはないので
スクラムマスターのような、いわゆるマネージメントをする存在は不可欠であり
マネージメントでできるのは上で言った「怒る」「褒める」程度のものなんだろうと思う（ここらへんは専門外なので詳しくない）
ちなみにBacklogはこのようなかんばん方式もフォローしたらしいので使ってみるといい
https://backlog.com/ja/blog/backlog-update-2020-01-28-kanban-board/
長かったね
俺の記憶だとブームがredmine→Backlog→jiraと変遷したと思ってたけど着実に頑張ってたようだ
たまに使ってるよ
ーーー
確かそう言う本あったよね、詰んでるわ笑
パワハラって具体的に何なのかわかんないけど、力関係的に逆らいにくい人にプレッシャーかけられたので多分そうなのかなと思う。
どんな感じだったかというと
2.実装していくとどうすればいいかわからない部分が出てくるので、仕様を尋ねる
3.無視される
5.後々、仕様と違うことを詰められる
という感じだった。
詰められ方は
「バグが多すぎます、ちゃんと確認やテストを行ってください」とか
「この不具合はシステムの構造上致命的です、早急に修正してください」とか
いまチャットの履歴から引っ張ってきたけど、原文はもうちょっと高圧的だと思う
普通じゃんと思うかもしれないけど
だったりするので、小さなミスでも大きなミスとして圧をかけてくるのが辛かった。「そもそもそんな仕様だったことすらこっちは知らないよ！」っていうのでも責められるし。
そしてミスはミスだからこっちが悪いので言い返せないんだよね…
未経験からエンジニアになったというか、新卒→自営の流れを汲んだ人間で初社会人だったから「世の中こんなものなのかな？」とか思ってたけど
いわく下についた人を二桁近くやめさせてきた人間らしくて外れ引いたんだなって思った
今その会社の評価星1.2とか凄まじいことになってるんだけど、
昔は良かった的なコメントがついているのでもしかしたらこの人のせいで良いエンジニアがどんどんやめていってしまったのかなとか思ったりした。
技術力も低くて尊敬できる所一つもないんだけど、こういう人に限って社内政治が得意だったりするもんだから、上の方のポジションに居るんだよね
だから指示も抽象的で「いい感じに頼む」みたいになるし、GUIで状況がわかる段階になってから「こうじゃない！」とか言い出すから困る
一つだけ良かったこととしてはありとあらゆることが適当に投げられて後よろしくされてたので、急速に技術がついたこと。
DBもよくわからなかったし、SQLも書けなかったけど、半年ぐらいでフルスタックの開発を一から任せてもらえたりしたし、実際にどうやればいいか分かれた。
---
冒頭に戻るけど、SEは
・大まかな設計
・進捗管理
など、いわゆる上流工程のこと指して使ったけど、結局こういうポストに収まる人って社内政治得意マンが多いんだろうなって思った
社内政治が得意で技術力もあるっていう人は、仮にどちらもレア度10%だとしたら掛け合わせで1%なわけで、多くは社内政治だけ得意なことが多い
つまり技術力は対してないから具体的な指示が出せなくて、曖昧なところを『いい感じ実装』する羽目になる。技術力なかったら具体的な質問に的確な回答を返せないしね。
……正直そんなSE嫌われてる論とかどうでもよくて、
勤怠の打刻と作業報告くらいは当たり前だと思うんだけど、報告先が多すぎて笑う。
朝礼時：作業予定報告
分報：何か進捗あるごとに、
または作業を切り替えるごとに報告
昼時報：14時に一度、まとめて報告
終礼時：18時30分に、当日分をまとめて報告
■メール
日次：当日分を指定のフォーマットで進捗率も含めて報告 ＋ それぞれ一言コメント
日次：どのプロジェクトの、どのタスクに何時間使ったかをWEBフォームに入力
日次：何時間働いたかをWEBフォームに手入力／8超えるとアラートが飛んでくるので8固定
追記：残業は勤怠管理システムで（固定残業代分の範囲内では）別管理されている。福利厚生システムは外部サービスで、勤務時間やその他自己申告内容から、医療アドバイスとかアプローチを受けられるサービス（その恩恵を受けたことはない）
恒常的に8時間超えると会社と自分にメールが来るから固定でねとのこと。
当該の福利厚生システムで、マッサージは割引になるが、ネットのクーポンの方が安い。
社内チャットとメールはエクセルベースで（個人的に）半自動化できてるんだけど、他の入力箇所に手で入力するのも併せると、毎日計40分くらい日報書いてて、辛い。
上長指示で、各種報告・入力後回しにして仕事してたら、管理部署から社内チャットで入力催促くるの怠い。
の割には、どちらも評価に厳密に関わってくるの謎。
追記：自社サービス自社開発なので、最悪リリース日は伸ばせるものの、当初予定から遅れると（自分起因でなくても）評価が下がる。
前の開発会社だと、下請けで納期が決まっていて、会社側も請求のタイミングから考えてリスケしたくない→「残業休出でなんとか終わらせてくれ、金は払うぜ、頑張ってくれた分は評価もするぜ」という感じだったので、その違いに驚いたり。
前の会社だと、もっと緩く回ってた（分報はあった）んで、KPIとメール日報の時点でこの会社は厳密だなぁと思ってたら、数年でどんどん増えてきやがった。
そして朝礼・終礼で読み合わせするという。
「進捗の管理を徹底していて残業時間が比較的少ない」ってのが売りで入ったんだが、
「残業時間が固定残業代分の時間までに制限されていて、それ以上になると処分があるから誰も計上しない」が実態だった上に、進捗管理が煩雑すぎてそれに時間が食わせられるのが無駄すぎる。
…と、
月曜でまだまだ余裕のあるなかで、笑い話として書き出してみたら、結構ヒドかった。
そういう、仕事するための仕事であったり、その辺りの業務上の納得いかないこと聞かせておくれ。
または、うちの会社は楽だぜって話でも。
C++、C#、Pythonなど文法くらいは勉強して書けるようになるが、
ソフト開発の業務が本業ではないので、業務の間に片手間で書くのが精一杯、
という前提で聞いておいて欲しい。
クラウドサービスは規定で使えなかったり、高いソフトが買えないといった制限で、
マイクロソフトがMS ProjectをOffice365契約していると自由に使えるようにしてくれると、
マシになるのかと思いつつも、個々人の進捗を管理したい場合と、報告用の表示フォーマットが違うので、
データベースは同じで、表示をパワーポイントで見やすいようにして欲しいだけなのだが無いのだ。
要は満足なソフトがないのでずっと困っている。
メンバーのタスクはメール、Teams、定例で追加され、それがプロジェクトのスケジュールのどれに対応しているのか紐付けたいが、それが自動でできない。
タスクを分けたいことも多い。
進捗率の入力についても最後まで必要な時間が人によって違うのでなんとかしたい。
プロットする時にデータを間引いて表示すればいいと言われるのだが、
製造していると数少ない不良品をとらえないといかず、間引くのが難しい。
こっちはこっちで、数秒に1回しか起こらない変な挙動を起こすといったのもある。
しかもノイズだらけだったり、オーバーシュート/アンダーシュート、Jitterなどがある。
オシロの中に入っている機能で統計データは取れるのだが、本当に知りたい場所が取れない時があり、
ひとまずデータをパソコンに取り込んでから処理しようとしてもかなり困ることになる。
某大手SIerと共同でアプリ開発することになった。そこで、とあるプロジェクト管理ツールで進捗管理することになったんだけど、先方が
って文句をつけてくる。確認したら、アカウント登録後の確認を行っていないことが分かった。メールに記載されたURLにアクセスすることで、登録確認する奴な。だから、
「アカウント登録後に、登録したメールアドレスに確認メールが届くから、24時間以内にそこのURLをクリックして下さい」
という案内をした。ところが、いつまで経っても奴らはユーザ登録を完了して来ない。たかがワンクリックするだけなのに。このままだと、こっちも仕事が進まないから非常に困る。
一体どうなっているのか聞くと、どうやら「このURLをクリックしていいですか」という許可を上長に取らなければいけないらしい。その承認に2日くらいかかるから、いつまで経ってもユーザー登録ができないらしい。
アホかと思った。本件に限らず、こいつらとの仕事は何かとストレスが溜まることが多い。IT企業なのにとにかく技術力が低すぎるし、それ以前に常識が無い。上の件だって、そんな承認を取ることに何の意味も無いことは小学生が考えたって分かりそうなものだ。
俺も以前は、ネット上で「SIerはクソ」と言われてるのは、一部の人が大袈裟に言っているだけだと思っていたが、全くそんなことは無かった。本当に技術力が低いし、意味の無い仕事で関係者全体の仕事を遅らせている。
元アジャイルコーチとして、アメリカのガチの、ガチのシステム開発現場に、言うたらエスノグラフィ（行動観察調査）をしてるようなもんです。三流プログラマながら。
そういうリファレンスみたいなことをお伝えしたら、皆さん（Regional Scrum Gathering Tokyo 2022の参加者）が喜んでくれるかなとか思って、内容を構成しています。
ただ、僕が知っているのはマイクロソフトだけですし、自分の職場だけなので、主語が大きすぎるとか、そう言うのはやめてください。心が傷つくから（笑）
そういうのを踏まえて聞いてください（笑）。全部一次情報で、人から聞いたものではないです。ちょっとだけマネージャ関連のところはマネージャに聞いたところもありますが、基本的には自分が経験したことのみで構成します。
ウォーターフォールは使われていない
まず滝。ウォーターフォールがどれぐらい使われてるのかって話ですけど、これは簡単です。ゼロパーセント、本当に見たことないです。
だからといって本当に素晴らしいスクラムをみんなやってるかっていうと、そうでもない。どれぐらいプロセスに対してマチュア（成熟）かはチーム次第なんだけど、少なくともイテレーティブじゃないのはないし、アップフロントデザイン（開発前の仕様策定）を大量に時間をかけてやってるというのもない。
デザインドキュメントっていうのを書く人もいれば書かない人もいて、書く人が多いですけど、書いても5ページぐらい。
何年か前にサム・グッケンハイマーというDevOpsで有名な人が日本に来たときに日本のお客さんに「ウォーターフォールとアジャイルのメリットデメリットを教えてください」って聞かれて、彼が「ウォーターフォールは全くメリットがないのでやめておきなさい」って言い放って。
私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い - メソッド屋のブログ
分かります。誰も使ってないんだから。やっぱりもうやめといた方がいいですよね、正直話無理があります。
次は、僕のチームがどんな感じで運用されてるかっていうお話をします。
マイクロソフトには統一プロセスとかなくて、基本的にチームをどう回すかはチーム次第なんですよ。でもだいたいみんな似たような感じでやってると思います。
基本的にはスモールチームです。どんな大きなプロジェクトであっても、スモールチームの集まりって感じです。
自分のチームについては、これがよいやり方かは分からないですが、個人商店みたいなもので。「IC」というのはIndividual Contributorですね、開発者。
マネージャからアサインされるバックログが基本的にはふわっとしているので、ICがそれを明確にします。
ICが仕様を自分で明確化して、自分でデザインして、インプリメントする。だからそれぞれがレスポンシビリティを持っていて、それぞれが実装をする。
ただ、同じマイクロサービスをメンテする役割の人みたいなのがいて、それは「Buddy」（バディ）みたいになっていて、僕の場合は例えば「スケールコントローラー」っていうのを開発していますが、スケールコントローラーのチームでバディになってると、質問というかお互いに話が聞きやすい。すぐに答えてくれやすいですね。
他のチームとかになると、ちょっとバリアがあって。やっぱりみんなそれぞれの仕事をやっているので、プライオリティがそれぞれあるんですよ。だから違うチームの人になると意地悪じゃなくて彼らのレスポンスは1日に1回とかになったりするわけですよね。仕方がないことです。
多分このチームの単位はマネージャが管理できる最大以下の人数で構成されてるんじゃないかなと思います。だから本当に自分のチームはそれぞれが個人商店みたいな感じですね。自分でレスポンシビリティを持って自分でやる。それは新人であっても一緒です。
司会）ここでちょっと会場から質問が入りました。このチームというのはどういう単位なんでしょうか。プロダクトの単位なのか、どういう単位なのか。
（右下の点線で囲われたところ）このチームはスケールコントローラをやっていて、（右上の3つのICを指して）このあたりはプラットフォームと言って中の基盤みたいなことをやってたりします。
でも基盤もかなり巨大なので、内部でいくつか分かれているんですけど、同じマネージャが見て、みんなを助けている、という感じですね。
司会）隣のチームと、このチームを分けているのは、マネージャが違うだけ？
ええと、大きな機能で分かれているというのがあります。例えば隣のチームはランタイムっていうチームなんで、Azure Functionsのランタイムを担当してるんですよ。
さて、エンジニアの評価っていうのはどんな感じになってるかっていうと、この図にはマイクロソフトは入っていないのですが、僕の友達に「ゆうさん」っていう人がいて、彼がブログでGAFAの給与体系みたいなをまとめてくれて、マイクロソフトも似たような感じです。
参考：GAFA米国本社のエンジニアの年収をジョブレベル別に比較してみた【Google・Amazon・Facebook・Apple】
こういう情報って外部に公開されてるので別に隠すことはないし、マイクロソフトの給料の額とかも調べられるんですよ。
どういうふうになってるかっていうと、エンジニアとしてランクがあるんですよね、「SDE1」「SDE2」とか。マイクロソフトの場合は「シニアソフトウェアエンジニア」があって「プリンシパルエンジニア」がある、みたいな。
このランクの人はこういうことができる、っていうのが明確に定義されていて、それによって給料が決まるんですね。
だから自分が給料を上げたかったらどうするかっていうと、プロモート（ランク上げ）してもらえるように頑張るって感じです。他の人との戦いじゃないんです。
いまより一つ上のランクの仕事をしばらくしていれば、マネージャが「こいつは今はシニアだけどプリンシパルの仕事してるからプロモートしよう」とノミネートしてくれる。
そうやってノミネートされたら次のレベルに行けるし、行けなかったら転職をする。転職するとそこでネゴシエーションしやすいので、その時に例えばシニアとかプリンシパルになれればその給料がもらえる。
ただ、そういうふうに上に行くとレスポンシビリティも大きくなるので、自分でチョイスする感じですね。自分でチョイスするし、自分との戦いなので。だから他の人と比べて不公平とか全然思わない。
給料を上げたかったら次のレベルになればいい。そういうアクションをとればいいので、あくまで自分との戦いって感じになります。
マネージャの存在っていうのは僕的にはすごい（日本と）違ってるように感じています。
日本にいるときはマネージャって進捗管理や課題管理をしたりとかして、プログラマとか開発者を指揮するとかそんなイメージだったんですかね、僕のイメージとしては。
アメリカの場合は、彼らが重視してくれるのは僕のキャリアなんですよ。僕がハッピーかどうかとか、僕がキャリアで成功するかっていうのをすごい重視してくれるんです。
これまで何人かマネージャが変わりましたけど、みんなそうでした。マイクロソフトには明確にそう定義されているんです。だからマネージャはみんなそういう動きをしてくれます。
マネージャのすごく大事な仕事に「アンブロック」というのがあります。IC、つまり開発者の人がどこかで詰まっている状態になると、マネージャが助けてくれる。ブロックされているものをアンブロックしてくれるんです。
例えば、僕が技術的に詰まるとして、誰かに聞かなあかんけど、誰か聞かなあかん人がなかなか答えてくれへんとか、そういうこともあるかもしれないです。
そういうブロックをされる状況が一番生産性を阻害すると思うんですね。
そういうときにマネージャがアンブロックを手伝ってくれる。ある人に繋いでくれたり、マネージャ経由で他の人が僕に協力してくれたりとか。
マネージャが、このプルリクエストを見たら分かりやすいよと教えてくれるとか。
あと結構面白いのは、少なくとも今の僕の職場では、納期が基本的にない感じです。
あるときもあるんですよ。どんなときかっていうと、マイクロソフト最大のイベントの「Build」というのが5月ぐらいにあって、そのキーノートで発表される予定のプロダクトみたいなもの。それが決まったら納期があるのかもしれないですけど。
マネージャも僕に対して「早くしてください」って言ったことは1回もないですね。どっちかというと、僕が「何か遅くてごめんな」とか言ってたら、「いやそんな気にすんなよ」って、「よくあることだよ」とか言われたりする。
これは多分いろんな意味合いがあるんですよね。多分クラウドのプラットフォームって、難しいことがいろいろあって、例えば自分が1週間でできるって思ったのに2カ月かかったりとか、ほんまにあるんですよ。
例えば、JVMにあるJarをアタッチするだけに見えた仕事に、僕は半年かかりました。
僕の能力のなさもあるかもしれないですけど、そういういろんな予想外のことが起こる。
やっぱり世界中の人が使うプラットフォームなので、よく分かってない実装とかしたらむちゃくちゃになるんです。ちゃんと理解して、より良いアーキテクチャを作らないとひどい目にあう。
だから多分マネージャは絶対に急かさないんだと思います。ちゃんと理解して出来るようになれば、次からは開発が速くなる。だからマネージャとしてはそこで急かさないことによって未来への投資をしてる感じなんじゃないかなと、僕は思ってます。
バックログはあり予定もあるが、達成されないこともしょっちゅう
司会）すいません、マネージャの話しに行く前に。質問が集まっていて。納期がないという話に関して皆さんが大混乱に陥っていてですね（笑）。納期がないとすると逆に何があるのか。バックログみたいなのがあるのか、ロードマップがあるのか。どういうものを始点に駆動されていて、牛尾さんの仕事が始まるのか。
バックログですね。大きなトピックだけはある。今期はこれをやろう、というのはあるんですよ。
だいたい今期はこれとこれをやっていこうというのがあって、それを荒い粒度ですけどブレイクダウンしたストーリーにして、それをICにアサインするんです。
でも、それが今期に達成されないということはしょっちゅう起こります。
思ったよりもすごく難しかったとか、あるシステムで改変が入るのでそれまで作れないとか、そういうのがしょっちゅうある。でもそれでそのICが責められることはないです。
変化は見通せないので仕方ないですよね。オーガナイズはされているけど、できなかったときはできないと認める、ということです。
司会）お客様からバックログの元になるような要求がきて、それがリリースされるまでのタイムスパンはどのくらいなんでしょうか？
僕らの場合はプロダクトオーナーみたいなチームとしてプロダクトマネージャがあって、バックログの発生元はプロダクトマネージャが決めるのですが、そのインプットソースとしては、彼らの戦略（ストラテジ－）とカスタマフィードバックですね。
あとはハッカソンでエンジニアがなにかプロポーズするときもあります。
そういうもののなかからプロダクトマネージャが、今期これをやればインパクトがあるんじゃないかと考えるものがピックアップされます。
で、それが達成されてリリースされるまでの期間は本当にピンキリです。
僕の場合は、早いときは1週間で終わりましたけど、さっきの話みたいに1週間で終わると思ったやつが半年かかったこともあります。
僕の上にはプリンシパルマネージャがいるんですね、それが日本で言ったら課長みたいなもので、その上に部長みたいなのがいて、で、テクニカルフェロー、これは事業部長みたいな感じです。
彼らの技術力はどんな感じか。
僕の1つ上の上司は、Azure FunctionsのJavaランタイムをイチから書いた人です。
その上の人は、Azure Automationの開発をしている人で別チームなので細かいところまでは知らないのですが、技術力がハンパない、ということだけは分かります。
何でかと言うと、どんなテッキーな話題を振っても、ものすごく早く深く理解するんです。彼が経験したことのないことであっても、Kubernetesでも、彼がやったことのないPythonとかでも、完璧に理解してアーキテクチャの深い話をするんです。
で、テクニカルフェロー。これはAzureの主要なサービスをイチから書いていたりします。
つまり何が言いたいかというと、僕の上司で僕よりもプログラミングができない人なんて一人もいないんです。
そしてこういう人が僕の仕事のサポートをしてくれる、応援をしてくれるわけです。
だからこんな上司に何かを説得する必要なんてないんです。彼らがテッキーなミーティングに参加して、しかも僕らにすごい鋭いアドバイスをくれるんですよ。
皆さんがもしマネージャをやるときには、こういう人たちと世界で戦わないといけない、ということをちょっと意識していただきたいんです。
経営者なりたての新参者だけど、とても興味ある話題だったので書いてみる。
うちは今年創業の、まだ出来たてほやほやの会社。業種はWeb関係。
スタッフは6名、20代～30代前半がメインで、ITツールを使いこなすスキルもある。
コロナ禍真っ最中の創業当初、リモートワークをフル活用して新しい働き方を目指すぞ！と意気込んでいた。
スタッフ全員にMacbook proを配布し、ヘッドセットも用意し、オフィス内にはGoogleMeet専用のiPadを設置して、
いつでも気軽にオフィス内スタッフともコミュニケーションしやすいようにした。
リモートワーク中はMeet接続推奨だけど、必須では無く、カメラやマイクも必要に応じてONにするルール。
クラウドサービスも駆使した。Googleカレンダーで予定を共有し、Trelloで細かいタスクの進捗をリアルタイム可視化した。
普段のやり取りはSlackでスピーディに行い、業務データは全てDropboxとGoogleDriveで完全共有。申請等もほぼペーパーレス。
しかし色々試行錯誤する中で不都合が多いことに気づき、今では事情がある場合を除いて、オフィス勤めとしている。
よく言われることだけど、やはりこれが最も課題だった。私の力不足と言われればそれまでなんだけど、管理職ってほんと難しい。
スタッフ一人ひとり、能力も性格も、欠点も得意分野も、好き嫌いも全員違う。たった6人のスタッフに気持ちよく動いてもらうだけで、毎日必死だ。
そう、管理職って、スタッフに気持ちよく動いてもらう場作りが仕事なんだと思っている。
そのためには、スタッフ一人ひとりをしっかり観察して特徴を把握し、活躍しやすい場を提供することが大切なんだと。
例えばあるスタッフは技術的にベテランなのだけど、仕事に過剰なくらい真面目に細やかに向き合ってくれる。
一方で、放っておくと細かい部分で悩みすぎて手が止まってしまうことも多い。
であれば、ちょっとでも悩んでいるようならすぐに声をかけて、私がスピーディに判断を行っていけば、さらにパフォーマンスを上げられると考えた。
一方で新卒で入社したスタッフもいる。社会人成り立てで、当然ビジネス上のルールなどをまだ理解できていないので、つきっきりで教える必要があった。
遠方から引っ越してきたために友達もおらず、唯一人とコミュニケーションが取れる機会が、うちの職場だった。
ちなみにうちの会社はいわゆる「コワーキングスペース」に入居しており、他社や学生など色々な人が出入りする。
この地で心地いい人間関係を作ってもらい楽しく生活してもらうためにも、リモートだけでは難しかった。
このようにスタッフによって全く異なる条件を踏まえて、彼ら彼女らがもっとも活躍できる環境を「早急に」組み立てていくには、リモートワークはハードルが高かった。
もちろん潤沢な時間があれば、スローペースでも問題ないだろう。
けど、創業したてで事業が安定していない中、最短で利益を上げられるようにならなければ会社の未来は無いと判断した。
あるスタッフは、大都市の大手企業のもとでバリバリ経験を積んできた方だった。
その会社では、大手広告代理店直下の過酷な環境の中で利益を上げることを最重要視したビジネスを行っていたと聞いている。
しかし、ウチは少し「ソーシャルビジネスの要素」が入ったビジネスモデルを志向している。
そのためクライアントにもそういう団体等が多く、うちも利益「だけ」を目指す仕事の受け方をしていない。
全く利益にならなくても、社会益があると判断したら受ける案件もある。
そのためには、うちの会社がどこを目指して歩んでいくのか、という「ビジョン・ミッション・バリュー」の共有がとても重要だった。
ベクトルを合わせて目標に向かって進んでいくのは、立ち上げたばかりの会社にとっては死活問題だ。
しかし、いくら標語を掲げても、全体MTGで話をしても、そういうものってなかなか伝わらない。
日々の雑談のはしばしや、経営者の働き方や姿勢をフルタイムで見せていって、やっと伝わるものだと思う。
目指したい価値をチームで生み出すためには、単に決まった時間に仕事をスタートさせて、
数字で表現できる成果を上げて、定時まで働けばOK、というわけには行かなかった。
人間関係って、相手のことを理解するまで不安にさいなまれることが多いと思う。
この人は本当は何を考えているんだろう、裏切ったりするんじゃないか、とか。
スタッフ側もそうだと思う。
この会社は本当に信頼して自分の人生の一部を預けることができるのだろうか、と。
そういう不安を払拭するには、沢山コミュニケーションをとって、さらには態度で示していくしか無いと思っている。
私は、あなたを信頼している、だからあなたも信頼してほしい。そのために、こんなに色々あなたのためを思って考えている。そういう態度。
そういう安心感があると無いとでは、仕事へのモチベーションも変わると思うし、
もし会社がピンチな状態になったとしても信頼があれば力を合わせて乗り切れると思う。
ちなみにうちではスタッフごとにノルマのようなものは設けておらず、「みんなで協力し合って案件を達成する」ことに重きを置いている。
新卒の子でも得意分野ではベテランスタッフを助けることもあるし、もちろんその逆もしかりだ。
そういうしっかりした人間関係に基づいた信頼感、安心感の醸成には、やはりリモートワークオンリーは厳しいと感じた。
他にも細かい理由は沢山あるけど、そういうわけでうちはリモートワークを非推奨にしている。
ざっくりまとめると、「ビジネスとは言え、ビジネスライクなだけでは組織は成り立たない」ということだった。
例えば、体調が優れないとき（本当に調子悪いときはもちろん休暇を取らせる）、子供が調子悪い時、
重要な荷物が届くなど自宅にいる必要があるとき、年末年始の混雑を避けて帰省したいとき、など。
そのくらいの柔軟性があったほうが、社長自身にとっても都合がいい。
ちなみにスタッフの感想によると、オフィス環境も居心地が良いように気を配っているためか、積極的にオフィスに来たいと思ってくれているようだ。
集中できるし、スタッフ間で相談もしやすいし、おやつ食べ放題だし、地方なので満員電車に揺られることも無いし。
定型業務が多く数字で成果を出しやすい業態、ベテラン揃いでスタッフが自立して動ける環境、出勤するだけで満員電車等でエネルギーを消費する環境、など。
それであれば、諸々考慮してもリモートワークのほうが成果が出るかもしれない。
逆に言えば、どんなに働き手にとって都合が良かったとしても、事業として成果を出せなかったらリモートワークは選択できないとも思う。
なるべく柔軟にいくつもの選択肢を用意して、結果としてスタッフが成果を出しやすい働きやすい環境を作るのが重要なんだと思っている。
異論反論、質問、歓迎です。色々な人の意見、聞いてみたいです。
そうですね、権限移譲はとても大きいと思うけど、強いチームを作るには後者の３点が欠かせないが故にリモートワークオンリーは難しいと思っている。
意思統一については、本文には書かなかったけど、引っ越しを期に完全リモートで遠隔地にいるスタッフがひとりいて、
その子とは１年以上毎日膝を突き合わせて議論を重ねていたので、例外的に成り立っていると思っている。
音声チャットは考えていなかった！ちょっとやってみるよ。電話にせよLINE通話せよ、もちろんZOOMも、それなりにハードルあるんだよね。
へええ、こんな考え方あるんだ。勉強することたくさんあるなぁ。組織が一丸となって目標達成させるためのもので、ちょっと高めに設定するのね。
ガチガチに目標設定して、結果マイナス評価になりがちなものより、ポジティブに機能しそうな気がする。
ちなみに今でもざっくりとしたチーム全体の目標売上とかはちょっと大きめに共有している。もうちょっと深堀りしても面白そう。
確かにそれが理想。いずれそういうふうにシフトしていきたい。今は創業初期でメンバー少ないゆえの一枚岩戦略なんだなーと改めて自己認識した。
組織が大きくなったらそうもいかなくなるし、逆に多様な考え方の中から価値あるものが生まれてくると思う。
経営者に発信力があって（多分魅力的なビジョンやフィロソフィーが明確にあって）、増田さんもそれにしっかり向き合っているのだろうな。
そういう事柄の重要性を相互に理解しあっているというか。リモートでも強い組織を作っていけそうな環境ですね。
ほんまか！ありがとう～嬉しい
すまんな・・・。ちなみに以前会社勤め（銀行系SI）していたとき、多分私も増田さんと近い感覚やった。
やりがい搾取、サービス残業、業務外の付き合いとか、無くなればいいって。
雇用契約で9～18時働くことになっているんだから、それで十分だろうって。
（今も大体そう思ってるけど）
経営する立場になって気づいたんだけど、信頼できる関係性内での多少の融通は、人生を変えるほどの大きな変化を生むってことに気づいた。
おれ30歳過ぎてから一度うつ病を患ってて、数ヶ月寝たきりで、それまで勤めてた会社も辞めて信頼できる仲間も友達もだれもいなくなって、
けど、たまたまPCやウェブに詳しかったから、知り合いの知り合いとか、頼ってくれる人が周りにいたんだよね。
少しばかり無理して頑張って要望のちょっと先を目指してみたら、クライアントがめちゃめちゃ喜んでくれて、びっくりするほど感謝されて、差し入れまでもらえて。
そこから地域での居場所や信頼関係が強固になって、困ったことがあったら助けてくれるような関係性が生まれたり。
それが、会社、スタッフ、クライアント、その他ステークホルダーを超えて、広がっていった。
そうこうしているうちに、うつ病は完治してしまった（何年もかかったけど）。
そして会社を作ったわけだけど、個人事業主時代から一度も宣伝広告を打ったことがない。
口コミとリピートオーダーだけで法人化してスタッフ６名まで成長できた。（まだまだ極小零細）
会社勤めしていた10年間、会社に言われた通りに仕事をしていたけど、自分自身が価値を生み出すべきだ、なんて考えたこともなかった。
みんな惰性で働いているか、上司のパワハラやクライアントのクレームが怖いから、仕方なくがんばってた。
そこで理解したのは、どんなに時間通りに真面目に働いても、価値を生み出さなければ意味が無いし、そうなったら会社組織は存続できないってこと。
けど、経営者と被雇用者はもちろん立場が違うから、スタッフをおれと同じようにさせるわけにはいかない。
なるべく自由で居心地のいい環境でパフォーマンスを出してもらうことを毎日考えている。
顧客に対してぼったくることもしない。取引先を無理に叩いて値下げさせるようなこともしない。
そんな中で考えたのが、ビジョン・ミッションを明確にし、チームが一丸となれる体制づくり。
限られた労働時間の中で成果を生み出すためには、色々な物事を価値を生み出すために最適化・効率化しないといけない。
（リモートワークチャレンジもその一環だった。うまく行かなかったけど）
ビジョン・ミッションはスタッフも含めてみんなが幸せになれるような理想を描く。と言っても全く手が届かないようなものではなく、
頑張れば少しづつ実現できそうなもの。そのために、みんなで頑張ろう！それも、楽しくやっていこう！って。
ドライに仕事をして責任を全うし報酬を得ることだって十分立派だと思ってる。
けど、それだけでは生み出せない価値を、うちのチームでは生み出したいといつも願っているし、それがスタッフやクライアントや地域の利益につながると信じている。
※以下、「エンジニア」と書かれている場合には「ITエンジニア」と読み替えてください
社員数1000人超のユーザ系SIer→Web系事業会社に転職して半年が経過したので所感を残しとく。いわゆる転職エントリってやつ。
Web系エンジニアの転職エントリって大体つよつよエンジニアの情報しか出てこなくてウッってなったから、自分のようなクソザコエンジニアの事例をネットの海に放流しとこうと思った。
みんなブログだと当たり障りのないことや技術的に意識の高い内容しか書かないからさ、パンピーの本音ベースでの不満や転職活動の内容ってなかなか見つからんのよね。
文章の感じとかで分かると思うけど、ほんとに意識もスペックも低い人間です あと一定以上の長さの文章書くの苦手だから箇条書き多いけどゆるして
入社して1か月はコンプラ研修とかビジネスマナー研修とか受けてた。
そのあと3か月くらいF士通のプログラミング講師みたいな人からIT研修を受けた。教科書に書いてある通りにLinuxのコマンドポチポチしたりJavaのコードを写経するだけだった記憶
研修が終わり晴れてインフラ系の開発運用を行う部署に配属されたんだけど、やっていたことは下記の通り。
業務ではコードを書くこともターミナルでコマンドを打つことも全くなかった。ひたすら溜まっていくユーザーや開発側からの問い合わせへのメールを返信する存在だった。
配属された部署がたまたまそういう場所だったというわけでもなくて、同期の話を聞く限りアプリ部門だろうがQA部門だろうが似たような感じぽかった。
これってITエンジニアの仕事なんか?事務職とかに近くね?という疑問を抱きながら1年半くらい過ごしてた。
自分のイメージしてたITエンジニアっていうのは、スタバで私服でようわからん真っ黒な画面に向かってプログラミングしたりサーバやNWをいじってる人のことであって、ワードパワポエクセルとにらめっこしながらスーツのおっさんとおしゃべりして一日を終える人じゃなかった。(多方面に怒られそうな表現だけど...)
あとは、
全体的に、仕事と関係ないクソどうでもいいことにこだわらないといけないのが嫌だった。「もっと技術にコミットしたい」みたいな、エンジニアとして正しいであろうモチベはあんまりなかった
別に自分にはソフトウェアエンジニアリングを通して実現したい目標があるわけじゃない。三度の飯よりプログラミングが好きってわけでもない。
SIer、っていうか古き良き日本の大企業でエンカウントする嫌なことから距離を取りたい、というモチベだけで行動した結果Web系エンジニアになってた。
ただ、どうもWeb系エンジニアっていうのは技術が好きで好きでしょうがない人間がつく仕事っていうパブリックイメージがある気がするんだよね。なんでだろう?
そんなに技術好きじゃなくても、Web業界の成長のおこぼれにあずかる程度のエンジニアになることは難しくないと思う。あんま知らんけどエンジニア数十万人単位で足りてないんでしょ?
俺はほんとクソザコだし、はてなに常駐するようなつよつよエンジニア達からみたら関わり合いになりたくないタイプの人間であることは自覚しているけど、表に出ないだけで俺みたいな人結構いるんじゃねって思ってる。
