スプレッドシートで条件に合ったものをカウントする｜COUNTIF関数
僕がよく仕事で使っているのがGoogleスプレッドシートです。
いろんな機能や関数があって便利なのですが、「こんなこともできるんだ」と、知らない関数もたくさんあったりします。
今回は、そんなスプレッドシートの関数の中から、条件に合ったものをカウントするCOUNTIF関数を紹介します。
スプレッドシートでデータを管理する
スプレッドシートの使い方として、よく使うのがデータを管理することです。
例えば、以下のように出欠表をスプレッドシートで作ってみます。
名前と出欠を○×で入力するシートとします。
文字列をカウントするCOUNTA関数
続いて、出欠を集計する対象人数は何人いるのか、を表示します。
以下のように、人数合計セル（C9セル）を追加します。
C9セルには以下のように入力しています。
=COUNTA(B3:B7)
文字列をカウントするCOUNTA関数というのを使っています。
COUNTA関数とは？
COUNTA関数とは指定した範囲の中で、文字列のセルの数をカウントできる関数です。
COUNTA関数の構文
COUNTA(値1, [値2, ...])
・値1
セルの数を数える範囲を指定します。
本記事では、名前を元に人数をカウントしたいので、
B3:B7
というようにセル範囲を指定しています。
・値2
数える範囲は複数指定することができます。
本記事では単一範囲だけ数えることができれば良いので、指定していません。
文字列で条件に合ったものをカウントするCOUNTIF関数
続いて、出席の人数は何人いるのか、を表示します。
以下のように、出席人数合計セル（C10セル）を追加します。
C10セルには以下のように入力しています。
=COUNTIF(C3:C7,"○")
条件に合ったものをカウントするCOUNTIF関数というのを使っています。
COUNTIF関数とは？
COUNTIF関数とは指定した範囲の中で、条件に合ったセルの数をカウントできる関数です。
COUNTIF関数の構文
COUNTIF(範囲, 条件)
・範囲
セルの数を数える範囲を指定します。
本記事では、出欠を記載しているセルをカウントしたいので、
C3:C7
というように範囲を指定しています。
・条件
上記で指定した範囲の中で、カウントする条件を指定します。
本記事では出欠が「○」となっているものをカウントしたいので、
○
と指定しています。
COUNTIF関数を使用すると、条件に合ったものをカウントできる
COUNTIF関数を使用することで、条件を指定してカウントすることができました。
今回は出欠表というのを作成しましたが、アイデア次第でいろんな活用法があると思いますので、COUNTIF関数をぜひ使ってみてください。
エンジニアがコードクロニクルでゲーム感覚のプログラミングを体験
はてなブログ特別お題キャンペーンにて、コードクロニクルを使ってみました。
プログラミングをゲーム感覚で勉強できることは、非常に勉強しやすいなと感じるゲームでした。
エンジニア目線での感想です。
プログラミング学習にどれだけ楽しみを見出すかが大事
プログラミングに限らずですが、勉強する時は、どれだけ楽しくできるかというのが大事かなと思います。
プログラミングというものは、非常に頭を使うものなので、学習し初めの頃は、一杯一杯になってしまうことも多く、根気が必要かなと思うのですが、それをゲーム感覚で出来るというのが良いなと思いました。
ゲーム内では「クエスト」と呼ばれていますが、1つ1つの問題をクリアしていく感覚が、自分は出来ると思うことができたり、早く次の問題もクリアしたい、と思うのが、ゲーム特有の考え方かと思うので、それをプログラミングに応用できることに関心しました。
「プログラミングは魔法」という表現が素敵
ゲーム中では、プログラミングが魔法という表現で使われており、この表現がとても良いなと思いました。
僕も最近は魔法使いと呼ばれています。笑
プログラミングをして、システムを作る背景には、様々な課題が存在しています。
会社の業務フローに課題があったり、業務プロセスに課題があったり、と、多くの会社は課題を抱えていて、それを解決するために、僕らエンジニアは日々システム開発を行っています。
システムを作った結果、課題が解決できる様が魔法のように見えるようです。
ゲームの魔法のように、プログラミングが様々な場面で役に立っていると思うと嬉しいものですね。
コードクロニクルは、楽しくプログラミングが学習できるので、これからプログラミングを学習してみたいという方は、ぜひ利用してみてください。
エンジニアの勉強法は自分の強みを作ること
IT関係の技術は、どんどん新しくなっていきます。
その都度、勉強したりする訳ですが、正直大変です。笑
エンジニアの勉強法として、僕が大事だと思うポイントを書いていきます。
継続すること
これはエンジニアだから、という訳ではないですが、どんなことを勉強するのにも継続が大前提かなと思います。
僕は「石の上にも三年」という言葉が好きで、やっぱりある程度腰を据えてやるからこそ、身になるかなと感じてます。
僕自身、エンジニアの仕事を始めた当初は覚えることも多くて大変でしたが、3年を過ぎた頃から独り立ちできた感覚があり、継続することの大事さを学んだ3年でした。
トライアンドエラー
初めから完璧に全部覚えられたり、ってことは無いと思います。
分からないことや、つまずくこともありますが、都度トライアンドエラーでやってきました。
やってダメなら改善、それでもダメなら改善、という具合に、いろんな方法を試してみたり、忍耐強くやっていくことが大事かなと思います。
自分の強みを作る
これが一番大事かなというのが、自分の強みを作るということです。
エンジニアのプログラミング言語だと、僕はJavaが得意です。
いろんな言語を覚えれば、できることの幅が広がったりするメリットはあると思うのですが、まずは1つのものを極める、ことが、結果的に良いかなと感じてます。
それは、応用が効くからです。
得意なものが1つあることで、自分の自信にもなるし、ゼロから勉強していく時でも、「Javaだったらこういう風にできる」とか「Javaとの違いはこう」というように、置き換えて考えることができます。
このように、応用して勉強する、というのが非常に効果的だなと、今まで様々な言語を勉強してきて思います。
エンジニアとしては今でも勉強し続ける日々ですが、これからもたくさんのことを覚えて、自分の幅を広げていきたいです。
システムエンジニアが転職を考えたきっかけ 人間関係の板挟み編
システムエンジニアをやっていると、転職について考えたきっかけがたくさんありました。
収入、転勤と書いてきて、今回は、人間関係についてです。
ベースは仲良く楽しい人間関係
はじめに、僕の周りの人達は、とても良い人達だったなと思ってます。
仕事中でも面白い話をしたり、仕事の後は飲みに行ったり、僕はカラオケが好きなので、カラオケも行ったりしました。
それらは楽しく、僕が付き合ってきた人は仲良くさせていただいていて、すごい良い人間関係だったなと思います。
ただ、ここに仕事というものがあると、人間関係を全てうまくいかせる、というのは、すごく難しいものだと感じました。
仕事になると、みんな課題を持っている
なぜ仕事が絡むと、難しくなってしまうのかな、と考えた時、思ったのがこれです。
仕事を進める中では、課題があるから試行錯誤して仕事を進めているということです。
全てうまく進んでいる時は良いかもしれません。
仕事がうまく進まないとストレスを感じたり、イライラしたりしてしまいますよね。
そうなると、その矛先が周りに向いてしまうのかなと思っています。
僕はそうでした。
上司と後輩の板挟み
僕が一番悩んだのは、社会人5年目から10年目くらいの期間です。
こう書いてみると、悩んでいる期間が長いですね。笑
5年くらい経つと、後輩もできてきて自分が指導する立場になったり、1つのプロジェクトを任せられるリーダー的な立場になってきます。
ただ、僕はそこでキャパを超えたかな、と思います。
上司からは、
- 仕事を丸投げされる
- 業務の進捗が悪ければ、詰められる
- コストを下げろと言われる
一番、ひどかったのが、コストを下げるという部分です。
業務の進捗が悪い原因の1つに、人が足りないというのがあったのですが、それを相談しても「なんとかして」とか言われてました。
コストを下げる重要性は分かっていたのですが、言われようがひどかったですね。
その中で後輩と一緒に仕事をしていた訳ですが、人が足りない状況で仕事をしていたので、後輩にもたくさん仕事を振ったりしていました。
たくさん仕事を振っているのに、僕自身も仕事に追われる日々、そして、新人の後輩もいたりしたので、同時に後輩指導しながら仕事を進めるという日々です。
ここまで来ると、大体想像付きそうなものですが、仕事が回らなくなってきます。
後輩から質問を受けたりしても、ちゃんと回答できてなかったりとか、教えてあげられなかったり、振り返ると申し訳なかったなと思います。
そんな感じで、上司から色々言われ、後輩からも色々言われ、上司と後輩の板挟み状態になりました。
そして上司に全て吐き出す
これはもう無理だなと思って、上司に全て告げました。
その時は、部署を変え、担当している案件も変え、ようやく解決に至りました。
結局、こういう人間関係の悩みは、どう解決できるのか分かりません。
ただ、自分の言いたいことを伝えることが大事だなと強く感じた経験でした。
そして、できないことはできないとはっきり言うこと。
僕も含めて、SEはそういう人が多いのかもしれません。
自分の思っていることを伝える。
簡単そうに見えて難しいことかもしれません。
自分も周りの人たちも、思っていることを言い合える人間関係が理想だなと思いました。
システムエンジニアが転職を考えたきっかけ 転勤編
システムエンジニアをやっていると、転職について考えたきっかけがたくさんありました。
前回、収入について書きました。
今回は、転勤についてです。
地方から首都圏への転勤
僕は群馬出身で群馬の会社に就職して働いていました。
5年くらい経った時、転勤で群馬から埼玉の大宮へ出てきました。
当時、会社全体では、首都圏の仕事もしていたものの、まだまだ規模が小さく、首都圏での仕事規模拡大ということで、大宮へ支社を出すことになりました。
最初、転勤の話をもらった時、たくさん悩みましたね。
新しい環境に出ていくというのはドキドキするものですし、新しく支社を作るってのは大変だろうなというのも思っていました。
そして、前回の記事でも書きましたが、働いている中では収入に関する悩みも持っていて、この転勤というものは収入や生活の面を考えると、やっぱり大変だろうなと考えていたので、すごく悩んでいました。
悩んだ挙げ句に転勤を決める
最終的に転勤を決めたのは新しい環境に身を置くのが大事だと思ったからです。
収入や働く環境も大事だと思いますが、やっぱり仕事をしていくうえで、新しいことにチャレンジしていくというのを選びました。
この時、1人暮らしを始めたりと、自分のお金のやりくりは大変になりましたが、都会での生活というのは、地方出身の僕としては刺激があって楽しいものでした。
仕事をする環境が変わるのも、新鮮な気持ちで仕事ができたり、と有意義な時間になったと思います。
転勤でぶつかった壁は立ち上げの難しさ
最初は仕事も楽しく、順調に進んでいるように見えましたが、だんだんと課題が見えてくるようになりました。
最も感じたのは、立ち上げの難しさです。
僕の転勤は、支社の立ち上げでしたが、会社の立ち上げなど新しいことを始める時は困難が伴うものだと思います。
僕は、プロジェクトリーダーという立場だったのですが、めっちゃ仕事を抱え込みました。笑
上司があまり当てにならず、その中で顧客とのやり取り、後輩指導、パートナー会社さんとのやり取り、など、やる仕事の量がとても多く、次第に仕事が回らなくなりました。
この時は、立ち上げってどういうものなのか？ってのが分かっていませんでした。
そして過酷な労働の日々
とにかく働いて仕事を片付ける日々でした。
当時、電車通勤をしていたものの、会社からも（一応）歩ける距離に住んでたので、終電をなくして、よく歩いて帰ったものです。
26時とか27時とかに会社を出て家まで歩いて帰る、今でもよく思い出す経験です。笑
今考えると、すごいですね。（自分のことだけど）
また、気が気でなく、顧客や上司から掛かってくる電話に、イライラして対応したりということもありました。
転勤を通じて感じたこと
そんなこんなで怒涛の日々を送っていましたが、なんとか落ち着いて今があります。笑
その中で転勤で感じたことは、
- 新しいことにチャレンジすることは大事
- 目の前のことだけじゃなくて先を見ることが大事
- 経験が財産になる
ということです。
それが僕にとっては転勤でした。
人生のターニングポイントです。
よく考えたうえで転勤という選択をしましたが、その選択が正解かどうかは分かりません。
ただ、自分自身の選択を自分で正解にするために努力することが大事かなと思います。
あとは、やってみないと分からないですよね。
僕は地方で働いていたところから、首都圏で働くようになって、考え方がだいぶ変わりました。
地方と首都圏、それぞれに特性があり、メリット・デメリットは色々あるかもしれません。
でも、自分で経験してみて分かることが多いかなと感じます。
そんな僕は、将来は首都圏と地元を行ったり来たりで、仕事ができるようになれば良いなと思います。
システムエンジニアが転職を考えたきっかけ 収入編
- 収入は上がっていくのか？
- 継続していくと収入は上がっていくのか？
- 収入のメインは残業代
- お金があると無駄遣いしてしまうのが人間
- 逆に残業をしていないと手取りが大きく減る
- 時間を取るのか、収入を取るのか
システムエンジニアをやっていると多いのが、転職を考えることです。
SEという職種は、特に転職する人が多いのかもしれません。
僕自身も考えたきっかけが色々あるのですが、まずは収入に関してです。
収入は上がっていくのか？
働いていると真っ先に考えるのは、これかもしれません。
SEだと専門学校や大学を卒業して就職という人が多いですが、僕は高卒で就職しました。
高卒だと初任給が低いというのは分かっていたので、どれだけ上がっていくのかなという期待がありました。
ただ、最初の上がり幅は低いもので、2年目になってからの昇給というのも微々たるものでした。
しかも、2年目からは住民税の天引きが始まり、こうなると手取り金額は1年目よりも下がってしまい、周りでも転職していく人がちらほらいました。
大卒の方も、初任給こそ高卒に比べれば高いものの、同じような感覚かもしれません。
3年経たずに転職する人も多いと思います。
僕自身はこの時期、もうちょっと頑張っていけば上がる幅も大きくなっていくかなという期待を持っていました。
継続して頑張っていけば、という考え方の会社が多いのかもしれません。
継続していくと収入は上がっていくのか？
僕自身の感覚としては、継続していくと上がっていく感覚がありました。
1人暮らしはしていましたが、未婚で1人の生活だったので、1人で生活していく分には特に問題なかったかなと思います。
ただ、なぜ、収入が上がっていくのか？というところですが、そこに落とし穴があった訳ですね。笑
それは時間を取るのか、収入を取るのか、という落とし穴でした。
収入のメインは残業代
なぜ、収入が上がるのか、それが残業代が増えるからでした。
SEは忙しいという記事を前に書きました。
SEとして経験を積めば積むほど、増えていったのが残業でした。
仕事ができる人に仕事が集まるというものです。
僕の会社は残業代が全部出たので、残業代も含めると月の収入は結構多くなりました。
ただ、毎日帰りは遅くなったりと、お金はあっても趣味などに使う時間がない、といった感じでした。笑
しかし、他の会社を見ると、残業代はあまり出ずにサービス残業が多いなどの会社もたくさんありました。
お金があると無駄遣いしてしまうのが人間
忙しい日々の中で残業代を手にする訳ですが、使いみちのメインはストレス解消でした。
ストレス解消の代名詞と言えるのが、そう！お酒ですよね。笑
僕は一番忙しい時期は、月曜から金曜まで毎日終電で帰っていたのですが、家に帰ってから毎日晩酌をしていました。
お酒を飲むには、おつまみが必要だったり、僕は甘いものが好きなので、お菓子やチョコなど、たくさん買っていたのもあり、たくさん無駄遣いをしてきたな、と今では思います。笑
こういう部分も当時は全く気付かず、お金がなくなってから気付く、全く不思議なものです。
逆に残業をしていないと手取りが大きく減る
そして、残業というのも、ずっと続く訳ではなく、たまに落ち着いてる時も出てきます。
そうなると、早く帰れるのは良いのですが、残業がない＝残業代がない、ということになるので、収入は大きく減ります。
残業代があることで収入が成り立っていたので、それが無いと日々のお金のやりくりに直面する日々でした。
こうなると、仕事が忙しくても忙しくなくても、常に収入の悩みは消えませんでした。
時間を取るのか、収入を取るのか
これは働いていると、一生つきまとう問題かもしれません。
僕自身は、転職経験なく、新卒で入った会社も15年勤めてきたのですが、収入の面を考えた結果、転職ではなくて会社を辞めてフリーランスになる決断をしました。
この選択が正解かはまだ分からないですが、フリーランスになった経験についてはまた別途書きたいと思います。
システムエンジニア（SE）のプロジェクトリーダーとは？
目次
2ヶ月ほどの開発案件を（ほぼ）終えて、プロジェクトリーダーってなんだろ？と改めて考えるきっかけになりました。
僕の上にPLがいたのですが、あんまり機能していなかったと感じます。笑
僕のSE経験はもう15年ほど。
何年経っても、チームでうまく仕事をすることの難しさを知りました。
プロジェクトリーダーとは
プロジェクトリーダー（Project Leader）、略してPLと呼ばれますね。
主な仕事は
といったところでしょうか。
考えるきっかけになった案件
PL：Aさん
PLの下に僕。
僕の下にプログラマーが3名という状況でした。
僕は、自分の作業をやりながら、3名の進捗管理、タスク管理、マネージメントなどなど。
結局、僕がPLのようでした。
本来のPLがやっていたこと
- 毎週の作業時間把握
実際、このくらいでした。笑
進捗管理とは
最初に経てたスケジュールに沿って、完成予定から遅れなく進んでいるかをチェックするのが目的です。
今回の案件では、「xxxxの作業は今日までだけど、大丈夫？」とPLから聞かれてました。
ただ、進捗管理ってそういうことではなく、当日になってから確認しても遅くないでしょうか？
当日確認した時点で遅れていて、当日中に完了する見込みが立っていなかったらリカバリーできません。
そこに至るまでに数日前から状況を確認したり、コミュニケーションを取ったりすることが大事だと思っています。
数日前に確認して、スケジュール通り終わらなそうだったら、リカバリーできるようにプランを立て実行することが大事ですね。
タスク管理とは
各タスクの状況、期限までに終わっているか、期限過ぎても終わっていないタスクが無いかをチェックします。
進捗管理と近いが、期日までにタスクが完了するか、という段取りが大事だと思ってます。
終わらなそうであれば、リカバリーのプランを立て、実行していきます。
これは進捗管理と同じですね。
タスク管理するには、様々なツールがあるが、常に状況が可視化できていて、誰が見ても状況が分かることが大事です。
その仕組みをしっかり作る必要があります。
マネージメントとは
PLの一番の仕事ですね。
プロジェクトが遅延なく、問題なく進行しているかチェックし、進めていきます。
一番ダメなのが、丸投げです。
実際、どこのプロジェクトでも、丸投げしているリーダーが少なくない印象があります。
PLはマネージメントだけで作業は丸投げ、そういうのが一番失敗するパターンではないでしょうか？
やっぱりPLが現場にいて、メンバーと共に仕事をすることが大事かなと感じます。
プロジェクトリーダーは簡単そうで難しい
ここまで書いて、プロジェクトリーダーってのはやっぱり難しいなと思ってます。
ただ、だからこそ、経験が必要であり、そして達成感がありますね。
メンバーと一緒にプロジェクトを作り上げていくこと、ユーザーにより良いものを提供していくためには、PLが一番大事だと思います。
僕自身も、もっと力を付けていきたいなと改めて思った時間でした。
