【SQLserver】権限まわりのクエリを調べてみた
こんにちは、管理人のPaZooです。
最近、DB周りについて調べていて、ユーザー権限を調べることが多いので備忘録としてまとめてみました。
オブジェクトについて
--オブジェクトに読み取り権限を付与する
GRANT SELECT ON オブジェクト名TO ユーザー名またはロール名
--オブジェクトのインサート権限を剥奪する
REVOKE INSERT ON オブジェクト名TO ユーザー名またはロール名
--指定したオブジェクトの権限一覧を表示する
SELECT
OBJECT_NAME(major_id) AS オブジェクト
,USER_NAME(grantee_principal_id) AS ユーザー
,permission_name as 権限名
,state_desc as 権限の状態
FROM sys.database_permissions
WHERE major_id = OBJECT_ID('オブジェクト名')
--指定したユーザー(ロール)の権限一覧を表示する
SELECT
USER_NAME(grantee_principal_id) AS ユーザー
,OBJECT_NAME(major_id) AS オブジェクト
,permission_name as 権限名
,state_desc as 権限の状態
FROM sys.database_permissions
WHERE grantee_principal_id = USER_ID('ユーザー名またはロール名')
ユーザー個々に権限を設定するのは手間すから考えても実用的ではないです。
なので、グループ単位でDBへのアクセス権限を設定する方法を使って制御することも可能です。
その方法については、愛読書(?)である「@IT」様で紹介されているのでこのブログからリンクを送らせていただきます^^
まとめ
DB周りはまだまだ自信がありません。。
データの母体なので、もっと勉強せねばです!
テストとカバレッジについていろいろ調べて資料にまとめてみたよ
皆さんこにゃにゃちわ、管理人のPaZooです。
今回は「単体テスト」について、会社の勉強会で使用した資料をブログで紹介させていただきます。
単体テストとは
単体テストについてはご存知かと思いますが、簡単にご説明させていただきます。
PaZooが参画した現場で、一番最初に取り組んだことが「単体テスト」でした。
単体テストとは、プログラム作成完了後にメソッド単位で正しくプログラムが動いているか確認するために行うテストです。
たかがテスト、されどテスト
この資料では、主に単体テストとカバレッジについてちょろっとまとめてます〜。
えんじにゃーから見たユニットテストとカバレッジのはなし。
この資料では、主にカバレッジについてまとめました。
カバレッジカバレッジ言ってるけど、どのカバレッジを取るのか?そもそも何のテストをしたいのか?とかいろいろ考えた上でテストしよーね、ってことを書いてます。
皆さんのお役に立てれば幸いです〜。
Javaと愉快な仲間たち②Javaが住む世界。Webアプリケーションの仕組み
こんにちは、管理人のPaZooです。
皆さんご存知かと思いますが、JavaではWebアプリケーションの作成ができます。
しかし、恥ずかしながらそもそもJavaを使ったWebアプリケーションの仕組みを理解しておらず「???」の状態で今に至ります。
そんな時に、天から与えられしチャンスなのかスキルアップのための学習会がありWebアプリケーションについて調べる機会がありましたので、気になったところをまとめてみました。
※スライドにまとめていますので出来次第、いつものspeakerdeckにあげようと思います!
- ① WebクライアントとWebサーバー
- ②Webページを表示する流れ
- ③プロトコル
- ④静的コンテンツと動的コンテンツ
- ⑤動的なWebページを表示する流れ
- ⑥サーブレット(Servlet)/JSP
- ⑦MVCモデル
- ⑧GETとPOST
- ⑨ JavaによるWebアプリケーションの全体像
- まとめ
① WebクライアントとWebサーバー
まずはじめに、現在あなたがブラウザ上で見ているWebページはWebクライアントとWebサーバーというコンピュータにより実現されています。
Webクライアント:Webサーバーに保管してあるWebページにアクセスして利用できるもの。(例:GoogleChrome、IE、firefoxなど)
Webサーバー:Webクライアントからのアクセスに応じるもの。
(例:Apacheやnginxなど)
②Webページを表示する流れ
では、どのようにWebページを表示させているのでしょうか。
例えば、あなたが「○○について調べたい!」と思った時に、インターネットを使って検索しますよね。
例えばGoogleであれば、Googleにアクセスして一瞬でWebページが表示されます。
では、WebクライアントとWebサーバー間でどんな処理が行われているか見てみましょう。
ここで送受信しているメッセージは、「HTTP(またはHTTPS)」というプロトコルでやりとりを行っています。
③プロトコル
それでは、プロトコルについて説明します。
プロトコルとは、簡単にいうとコンピュータ同士がやりとりをする時に守らなくちゃいけないルールのようなものです。
WebクライアントとWebサーバーがやりとりをする際に、HTTPというプロトコル で送受信を行います。
そうすることで、クライアント側ではWebページを閲覧することができているのです。
しかし、単なるWebサーバーのみだと静的Webページを表示させることしか出来ず、動的なWebページを表示させるためには処理を実行させるためのソフトウェアが必要となります。
また、クライアントがWebサーバーに送るRequestメッセージとして
- GET
- POST
上記2種類の送信方法があり、この2つを上手く使い分けて動的なWebページを実現させていく必要があります。
それでは次に、静的コンテンツと動的コンテンツを比較してみましょう。
④静的コンテンツと動的コンテンツ
静的なWebページ
静的なWebページを表示する場合、WebクライアントがWebサーバーへ要求したWebページをそのまま応答としてWebクライアントへ返しています。
つまり、Webサーバーに予め保管してあるHTMLファイルをそのままクライアントに返すようなイメージ。
動的なWebページ
動的なWebページを表示する場合は、静的なWebページと何が違うのでしょうか。
それは、WebクライアントがWebサーバーへ要求し何らかの処理を行ってからWebページをWebクライアントへ返します。
つまり、Webサーバー側でプログラムが処理を行い、処理結果をもとにHTMLテキストを生成しているイメージです。
動的なページを作る上では、何らかの処理(プログラム)が必要で、その処理を実行させるためにプログラムを実行するソフトウェアが必要となります。
この何らかの処理(プログラム)というのを、プログラミング言語で実装していくことになります。
⑤動的なWebページを表示する流れ
Webサーバー内でアプリケーションを実行する場合
例としてWebページをPHPで実装した場合をイメージしてください。
WebサーバーにはPHPファイルを実行するモジュールがありません。
そのため、PHP実行用モジュールをWebサーバーに組み込んでWebサーバーを拡張させます。
WebサーバーがApacheを使用している場合は、PHP実行用モジュールを組み込んでPHPスクリプトを実行します。つまり、下記のような流れになります。
- WebクライアントがWebサーバーにRequestメッセージを送信
- Requestメッセージをもとに、Webサーバーに組み込まれたモジュールでアプリケーションを実行
- 実行されたアプリケーションがHTMLテキストを生成
- WebサーバーがWebクライアントにResponseメッセージを送信しWebページが表示
アプリケーションサーバーでアプリケーションを実行
では次に、WebページをJavaで実装する場合はどうなるかみていきましょう。
WebページをJavaで実装する場合、アプリケーションサーバーを用意します。
アプリケーションサーバーはアプリケーションを実行するためのソフトウェアです。
Javaのアプリケーションサーバーで代表的な例として、TomcatやJettyなどがあります。
注意点として、アプリケーションサーバーはWebサーバーとは別物なので簡単にやりとりは出来ません。
そこで、Webサーバーとアプリケーションサーバー間もやりとりをできるように何らかのプロトコルが必要になります。
WebサーバーをApache、アプリケーションサーバーをTomcatとした場合を説明すると、Apacheにはmod_jkと呼ばれる連携用モジュールが提供されています。これをApacheの拡張機能として組み込みます。
そして、連携用モジュールmod_jkがajp13というプロトコルを使用することでWebサーバーとアプリケーションサーバー間でのやりとりを実現させています。
ちなみにアプリケーションサーバーで紹介したTomcatは、簡易的なWebサーバーを持っているため連携しなくても動的なWebページを表示出来ます。
これは開発をスムーズに行えるよう、簡易的なWebサーバー機能が「おまけ」としてついています。
しかし、あくまでもおまけなので、多くの人が利用するような本番環境では大量のアクセスには耐えきれません。
APサーバーにあるWebサーバー機能はあくまでも補助機能なものと理解しておきましょう。
つまり、アプリケーションサーバーでアプリケーションを実行する流れは下記の通りです。
- WebクライアントがWebサーバーへHTTPプロトコルでRequestメッセージを送信
- Webサーバーがアプリケーションサーバー(Tomcat)へajp13プロトコルでRequestメッセージを送信
- Requestメッセージをもとに、アプリケーションサーバーがアプリケーションを実行
- 実行されたアプリケーションがHTMLテキストを生成
- アプリケーションサーバーがWebサーバーへajp13プロトコルでResponseメッセージを送信
- WebサーバーがWebクライアントへHTTPプロトコルでResponseメッセージを送信し、Webページが表示される
⑥サーブレット(Servlet)/JSP
サーブレット(Servlet)とは
JavaでWebアプリケーションを作る際、多くの場合はサーバーソフトウェアとして「Servletコンテナ」を使います。
Servletコンテナは自分で作るものではなく、既に開発され配布されているソフトウェアを使います。
開発者はServletコンテナ上で動作するプログラムを開発します。
サーブレットの利点
Webアプリケーションは「手軽に作れる」というイメージがあるかもしれませんが、Webサーバー機能が必要になります。
新しいWebアプリケーションを作る時に、Webサーバー部分を毎回作っていては時間がかかってしまいますよね。
また、そもそもWebサーバーを開発するには高度な知識と技術が必要になります。
そこで、Webサーバー部分は製品を使うのが主流です。
Webサーバーの仕様に合わせたプログラムを書くことでWebアプリケーションを作成します。
こうすることで、難しい部分を再開発することなく手軽にWebアプリケーションを作ることができるというわけです。
Javaにおいては、
という関係になっています。
ちなみにサーブレットはTomcatなどのアプリケーションサーバーによって実行されます。
JSPとは
Servletが出てきたからには切り離せないのが「JSP(Java Server Pages)」です。JSPはServletの弱点を補うとても大事な役割を持っています。
実は、ServletプログラムはJavaのプログラムそのものです。
ですので、データベースアクセスや計算処理のようなロジックを書くのには適していますがHTMLを書くのにはとても不向きです。
そこでJSPは、HTMLの中にJavaプログラムが埋め込めるようになっていて必要に応じてServletからJSPに処理を移せるようになっています。
役割分担としては
サーブレットとJSPについて説明しましたが、機能不足になりがちなので近年ではフレームワークを導入するのが一般的になってきています。フレームワークについては、下記の記事をご参考ください。
サーブレットとJSPにてどんな役割かを簡単に紹介しましたが、処理担当のサーブレットと表示担当のJSPで役割を分けることで開発しやすくなります。
しかし、何らかのデータ保存や管理をしながらWebアプリケーションを行いたい場合は単にJSPとサーブレットを分けるだけでは効率良く開発は出来ません。
また大量のデータを保存・管理することができるサーバーが必要となってきます。そんな時に役に立つのが、データベースサーバーです。
MySQLやOracle DataBase 、SQLserverなどが有名なデータベースサーバーソフトウェアです。
このようなデータベースサーバーを用いることでWebアプリケーションを通じて大量のデータを管理することが可能となります。
そして、大量のデータベースを扱ってWebアプリケーションを開発する場合、MVCモデルという開発手法を用いることでより大規模な開発を効率よく行うことが出来ます。
⑦MVCモデル
MVCモデルとは、アプリケーションソフトウェアをModel、View、Controller の3つの役割に分けて開発していく手法です。簡単に説明していきます。
Model
モデルはアプリケーションの処理を担当します。
例えば、データの管理やデータベースへのアクセスやメソッドの管理について行います。コントローラーからの指示により処理を実行します。一般的なJavaファイルがモデルにあたります。
View
ビューは、アプリケーションの表示を担当します。コントローラーから出力結果を渡されます。HTML形式に書かれているJSPファイルがビューにあたります。
Controller
コントローラーは、ビューからの情報入力を受け、モデルを呼び出し、ビューへの結果への出力を担当します。
つまり、一つのコントローラーにビューに対する処理や特定の処理の流れが書かれています。サーブレットクラスがコントローラーにあたります。
MVCモデルの流れ
MVCモデルの流れは下記のイメージです。
- クライアントがサーバーへRequestメッセージを送信
- アプリケーション内のControllerがRequestメッセージをもとに実行され、Modelの処理を呼び出し
- Controllerから呼び出されたModelがDBへアクセスもしくは処理実行
- Modelが処理結果をもとにControllerがViewへの出力指示(HTMLテキストの生成)
- サーバーがクライアントへResponseメッセージを送信し、Webページが表示
これがMVCモデルの簡単な流れですが、MVC2やMVVMなど様々な種類があり開発するアプリケーションによって手法が変わりますのでご注意ください。
⑧GETとPOST
それでは次に、動的なWebページのように表示内容をどのように変更しているかみていきましょう。
Webページの流れで見たように、WebクライアントはWebサーバーへ情報を送る方法として「Requestメッセージを送信すること」しか出来ません。
つまり、Webページの表示内容を変更させるにはRequestメッセージにパラメータを持たせて送信する必要があります。
そこで、Requestメッセージの送信方法として2種類の送信方法が存在します。それが、「GET」と「POST」です。
それぞれの違いについて、見ていきましょう。
GET
GETという送信方法を用いた場合、送信したパラメータはURLに組み込まれて、Webサーバーに届きます。
この場合のinputTextはキーで、入力した値はそのキーに対する値となります。
POST
POSTという送信方法を用いた場合、送信したパラメータをURLに組み込まずにRequestメッセージ内に組み込まれてWebサーバーに届きます。
GETとPOSTの使い分け
GETで送信する場合は、あとでページを見たいという時にブックマークしたりできるので再度簡単にアクセスすることが出来ます。
逆に、POSTは人に見られてはいけない内容を送信してアクセスする場合やデータベースを書き換えたりする場合に使用されます。2つの違いを簡単にまとめてみました。
違い | GETリクエスト | POSTリクエスト |
利用するメソッド | GET | POST |
パラメータの格納場所 | URL | メッセージボディ |
セキュリティ | 低い | 比較的高い |
パラメータの長さ | 古いソフトウェアでは255文字以内 | 制限なし |
パラメータの保存・再現 | しやすい | しにくい |
⑨ JavaによるWebアプリケーションの全体像
以上を踏まえ、JavaによるWebアプリケーションの全体の仕組みは以下のようになります。
クライアントサイドとしてはもちろん、Webクライアントが存在しサーバーサイドにはWebサーバーやアプリケーションサーバー、データベースサーバーがあります。
サーバーを構築する場合、Webサーバー、アプリケーションサーバー、データベースサーバーなどをインストールし、それぞれ実行することでWebアプリケーションにアクセスした際、正常に動作することが出来ます。
また、新しくアプリケーションを追加する場合もアプリケーションサーバーをインストールし実行すれば拡張させていくことが可能です。
まとめ
今回参考にした本書は、
- 小森 裕介 (2010/4/10)『「プロになるためのWeb技術入門」 ――なぜ、あなたはWebシステムを開発できないのか』技術評論社
- 山本 陽平(2010/4/8)『Webを支える技術 -HTTP、URI、HTML、そしてREST』WEB+DB PRESS plus
上記の本書です。初学者やある程度経験はあるがWebの知識に自信がない方はぜひご一読してみてください。とてもオススメです〜!
次回はTomcatについて書けたらいいな〜〜;;
Javaと愉快な仲間たち①Javaのそもそも
こんにちは皆さん、Java書いてますか?
この記事を投稿するにあたり、ネットで調べまくったり参考書を読みあさったりしました。
約2年前にJavaを使い始めてからというもの、Javaについて触れる機会が多いのですがなんと言っても序盤が眠くなりませんか?
やれJDKのAPIやれオブジェクト指向だから云々・・・めっちゃ眠たくなりませんか???
そこで今回からシリーズ記事として「Javaと愉快な仲間たち」について、まとめていきたいと思います。
目標としては、実際に手を動かしながらWebアプリケーションの作り方を簡潔にまとめたいな〜と。
ミドルウェアの説明や実際にJavaでのテストについても解説していきたいと思っていますので、優しく見守っててくださると嬉しいですw
そもそも何故書こうと思ったの?
私は最初「とりあえず参考書読もう」と文字から情報を得ようとしました。
参考書で説明されているように画面ポチポチしながら…みたいなやつをして、手を動かしながら覚えようと考えました。
実際に手を動かしながら取り組むので眠くなりません。
しかし、出てくる単語に不満を抱いてしまい「当分Java見たくない!」となっちゃった記憶があります。。
だって、そもそもJavaって何??の状態です。
JDKって?コンパイラって?開発ツールは何を使えばいいの?パッケージ構成ってどうしたらいいの?
そういう(初歩的な)疑問は解消されずに残ったままなわけです。
しかし、周りはスイスイと先を越してしまい聞くに聞けず…そんな状態が続き、ストレスを感じてしまいました。
当時を振り返ると、派手に躓いていた思い出が強くあるので今後新しい人に難しい序論を分かりやすく説明できるようにしようと思い、このシリーズを書こうと思いました。
Javaのそもそも
では、Javaについて簡単にまとめていきます。
Javaには様々な種類があります。Java SE、Java EE、Java ME…この人たち誰ですか??って状態ですよね。
上記はこの記事で後ほど説明するのでご安心ください。
Javaとは
Javaは、携帯電話から銀行のソフトウェアなどに使われていてサーバー等でも多く採用されているプログラム言語です。
Javaの大きな特徴として「Write once,Run anywhere(一度書けばどこでも使える)」というキャッチフレーズが印象的で、WindowsでもMacでもLinuxでもスーパーコンピューターでもプログラムが実行されます。
Javaのメリット・デメリット
それでは、Javaを使って開発をするメリットとデメリットについて書いていきます。
メリット①環境問わず実行できる
Javaはプラットフォームに依存しません。
その理由として、「JVM(Java Virtual Machine:Java仮想マシン)」で動いており、このJVMがOSの差分を吸収してくれます。
メリット②処理速度が速い
Javaは、数多くあるプログラミング言語の中でも処理速度はダントツです。その理由の一つが起動にコンパイル を必要とするコンパイラ言語であるから。
コンパイラとは、人間が書いたプログラムをPCが実行するためにPC側で処理が行えるように変換してくれるものです。
コンパイラ言語では、予めコンパイル 済みのファイルを用意し実行するためプログラム実行時にはコンパイル されずその分処理が速くなります。
メリット③セキュリティ面で優れている
Javaは開発当初からセキュリティを考慮した設計となっています。
セキュリティに考慮した設計の特徴として、主に下記が挙げられます。
JVMがJavaバイトコードを読む時に不正なコードが入っていないかチェックします。
Java Sandbox モデル
JVMがJavaプログラムがアクセスすべき領域の範囲を超えてアクセスしていないかチェエックします。
Javaバイトコードごとに信頼されるクラスか区別し、信頼されていないクラスをロードしメソッドを実行しようとすると例外が発生します。
しかし、Javaアプリケーションは信頼され、Javaアプレットではネットワークからロードされるクラスは全て信頼されないと言う仕様になっていたためJavaアプレットは制限だらけになってしまいできることが限られていました。Javaコード署名モデル
Java Sandboxモデルではアプレットの制約が非常に厳しかったのでネットワークを通じて組み込まれるJavaコードに電子署名し出所の明示及び改竄されていないことを保証する機構が加わりました。
メリット④ライブラリやAPIが充実している
プログラム言語には「ライブラリ」と呼ばれるプログラムの部品やJavaは特にライブラリが豊富で、多くのライブラリは無償で提供されています。
ライブラリを使えば、様々な機能を自分のプログラムに簡単に組み込むことができ開発時間を短縮させることが可能です。
デメリット①オブジェクト指向に対する理解が必要
オブジェクト指向は非常に優れた考え方ですが、理解するまでに時間がかかる理論でもあります。
オブジェクト指向を理解しなければ、プログラムの「独立性」「再利用性」「拡張性」を活かせずに結果的に質の高いプログラムを作ることは難しいでしょう。
オブジェクト指向についてはspeakerdeckでまとめた資料があるので、ぜひ参考にしてください。
デメリット②コンパイル が必要
Javaはコンパイル してプログラムを実行する必要があるので、開発者の中には「コンパイル するのが面倒だ」と言う方もいます。
Javaを動かすために必要なもの
Javaを動かすために必要なものは4つあります。
ソースコードだけは分かる!と言う方、多いのではないでしょうか?実は私もそうでしたw
今回は、ソースコード以外の3つを説明していきますね。
Java VM(Java Virtual Machine)
Java言語で作られたプログラムを実行するためのソフトウェアで、JREに含まれています。
実行するためには、ソースコードをコンパイル してクラスファイルを作成する必要があります。
コンパイラ
コンパイル と言う言葉が先ほど出てきましたが、コンパイル はプログラム言語をコンピュータが理解できる言語に変換することを指します。そのための翻訳ソフトウェアをコンパイラといいます。
ほとんどのコンパイラはコンピュータが直接実行できるコンピュータ特有の言語に合わせて翻訳し、直接実行を行います。
しかし、Javaは「どんな環境でも動く」と説明しました。
Javaが他の言語と違うところは、特定のコンピュータが理解できる機械語に翻訳するのではなく、どのコンピュータでも使える中間言語というものを作成します。
つまり、Javaが動くために中間言語に変換され、更にそれぞれのコンピュータにインストールされたJava仮想マシンが機械語に翻訳して実行する2段構えとなっています。
API
APIにはJavaSE、JavaEE、JavaMEがあります。
それぞれの違いは下記の通りです。
JavaSE:標準的な機能がまとめられたAPI。ちなみに、Javaのバージョンが2から5までをJ2SEとよび、6以降はJavaSEと表されます。
JavaEE:JavaSEにサーバ関係のライブラリなどを追加したもので、ベースはJavaSEそのもの。
JavaME:携帯電話、デジタルメディアデバイスなど組み込みデバイス環境で実行するアプリケーションのためのAPI。
絵に起こすとこんな感じ。
まとめ
今回はJavaの仲間たち①ということで、Javaのそもそもについて簡単にまとめてみましたがいかがだったでしょうか。
文字で説明すると長くなりますが、絵で表すと10枚程度の資料になるんだろうな〜と思いながら文字に起こしてますw
次回もJavaと愉快な仲間たちの続編を書いていこうと思います〜。
エンジニアの私が感じた、これだけは知っておいた方が良い3つのポイント
皆さんこんにちは。管理人のPaZooです。
今回のお話は、約2年ほど前に転職を機に駆け出しエンジニアとなったPaZooが感じた「これは絶対知っておくべき!」と思ったことを記事にまとめてみました。
初心を忘るべからず、ですからね!
当記事に書いているのはあくまでも私見です。
私見ですので、不快に感じる方もいらっしゃるかもしれません。その場合は「戻る」ボタンを押してさようならしてください(`・ω・´)
様々な意見や価値観があると思うので参考程度にご覧下さい。
1.技術力はソースの読み書きができるだけではない
これは最初に思ったことです。
と言いますのも、私は最初「エンジニアって技術力がある人」だと思ってました。
ばりばりコードを書いたり、テストしまくってバグを出したりする人だとイメージしていたのですが、実際はそうじゃない。
というか、コードの読み書きが出来るのは最低限に必要なスキルなのです。
コードの読み書きが出来るようになるのはあくまでも手段であって、最終的な目的は「システムを実現すること」なのです。
じゃあエンジニアとしてどんな能力が必要なのか。私がエンジニアとして必要なスキルについて感じたものを下記にまとめてみました。
- 本音に気付く会話力
- 様々な意見を吸収する素直さ
- 懐疑心(良い意味での)
- コードの読み書きが出来る
- システムの仕様を理解する
- システム設計を理解する
- DBの知識
- インフラの知識
- セキュリティの知識
- 顧客に伝わる資料作成能力
上記10点が、私の考える「技術力」です。
3つめの「懐疑心」については補足させていただきますが、設計書に書いてあることでもコードに実装されていることでも全てに対して疑いを抱くのは不具合を検知するきっかけとなることが多いです。
なので、きちんとした証拠がない限りは何も信じてはいけません。全てを疑いましょう…w
いろんな言語が扱えることも、もちろんエンジニアとして魅力的です。何故なら顧客が求めている要件を叶えるための引き出しが多いということですからね。
しかし、それだけなのです。言語を知っていてかつ使えるというのはあくまでも顧客の要望を叶えるための手段でしかないのです。
目的と手段を履き違えてはいけません。目的と手段を間違えてしまうと、その先には悲しい未来が待っています。。
2.エンジニアこそ人と話す能力が必要
私は元々、自分はコミュニケーション能力が低い人間だと思ってました。
なので、エンジニアになったら「ずっとPCと向き合うのかな〜それが楽そうだなぁ」と考えていました。
しかーーし、ところがどっこいです。
ずっとPCを触るどころか、ひたすらにお客様の要望を聴きながら考えてお客様に質問をする時間が圧倒的に多いのです。
そう感じているのは、私が携わっているプロジェクトが業務改善というものだからかもしれません。
ですが、圧倒的に人から話を聞く時間と人に伝える時間の方が多いのです。PCを使って行うことはあくまでも作業でしかないのです。
最終的にお客様に伝えるための材料をPCで作ったり調査したりするだけです。
ですので、今後エンジニアになりたい人は少なくとも人と会話することが苦ではないことが前提で目指した方がいいかもしれません。
私は今の仕事にやりがいを感じているので全く苦ではなく、むしろ楽しいと感じるくらいなのできっと人と話すのが好きなのかもしれませんね。新しい自分と出逢えたので、エンジニアになってよかったです。
3.自責と他責について知っていること
ビジネスシーンではよく取り上げられる「自責思考」と「他責思考」。
ご存知の方もいらっしゃると思いますが、それぞれがどんな意味なのか理解していますか?
自責思考:自分の問題のように考える
他責思考:問題を他者のせいだと考える
「これくらい知ってるよ!」と感じる方は多いかと思います。
では、ビジネスシーンで理想な思考は自責思考ですが、理想的な自責思考とは何かご存知でしょうか。また、自責思考である場合の問題点について、考えたことはあるでしょうか。
自責思考の問題点として、自責思考の持ち主は「自己満足に陥りがち」や「問題を複雑化してしまう」という傾向になりがちです。
そして、柔軟な解決策が生まれずにストレスを溜めてしまい抱え込んでしまう…というのがよく耳にするお話です。
自責思考についてきちんと理解をしていないと、自分を追い込んでしまい仕事に対して意欲が湧かなくなってしまいます。
では、どんな自責思考が理想なのか。これはエンジニアに限った話ではありませんが、周囲を巻き込んだ自責思考は会社にとって良い影響を与えると考えています。
周囲を巻き込んだ自責思考とは、ある問題に対して自責思考で取り組み顧客が満足する仕事を納めることができれば周囲は他責思考をすることができなくなります。
その結果、自責で考えざるをえないのです。このようにしていくと、チームの内部から少しずつ変えていくことが可能となります。
もちろん、よくない方向に進んでいく自責思考の持ち主もいます。その場合は、あなたが検知して周囲にアラートをあげましょう。
最後に
他にも取り上げたい内容はたくさんありますが、少なくともこれだけは知っておいた方がいいと感じたことをまとめてみました。
当記事をご覧になった皆さんはどう感じましたか?
エンジニアという職業は、とても大変です。(エンジニアに限った話ではありませんが)
ですが、努力したらその分だけ返ってきてくれます。この業界をもっとより良くしていくために一緒に頑張りましょう!
余談ではありますが、現職エンジニアの方で「これだけは知っておいた方がいい!」というものがあればぜひコメントください〜!
それでは、この辺で。
【書評】チーム・ジャーニーを読んでみた感想【ともに考え、ともにつくる】
皆さんこんにちは。管理人のPaZooです。
タイトルにもあります通り、2020年2月17日に発売された「チーム・ジャーニー 逆境を越える、変化に強いチームをつくりあげるまで」を読みました。
以前読んだ「カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで」と出逢ってからというもの、市谷聡啓さんに心を奪われてしまった読者としては、非常に楽しみでしたのでKindleで予約して今か今かと待っていました。
ちなみにカイゼン・ジャーニーを読んだ感想はこちらに書いてます。
チーム・ジャーニーを読み始めてからというもの、いろいろ考えてしまい全然読了できず、、なんだかんだすったもんだがあり、3月に書評をブログに起こすというなんともな感じですがそこはご愛嬌で。
当記事をご覧になっている皆さんに実際に手に取って読んでいただきたいので、読んだ感想をふわっとしか書いていません。
チーム・ジャーニーはどんな人にオススメ?
チーム・ジャーニーは下記に当てはまる人にオススメです!
- アジャイル開発をやっている。または導入を検討している。
- チームのあり方とは何かを見つけたい。
- チームビルディングに悩んでいる。
- 自分が考えるチームと、他の人が見ているチームについて知りたい。
チーム・ジャーニーってどんな本?
チーム・ジャーニーはカイゼン・ジャーニーと同じく、物語調で話が進んでいきます。
チーム開発を経験した主人公が新しいチームでPOに任命され、様々なチームメンバーと次々と発生する問題の壁を超えていくストーリーです。
構成は2部構成となっており、非常に読みやすくなっています。
第1部では、単一チームの成長について書かれています。
前半には「チームとグループの違い」と「チームになるためにやるべきプラクティス」をストーリーで読んでいくことができ、後半にはストーリーに出てきた用語や仕組みの解説が書かれています。
第2部では、単一チームが複数集まりひとつのチームとして開発することについて書かれています。
ここでは、それぞれ集まった単一チームが個々で動くのではなくプロダクトとして開発を行いリリースするための仕組みが説明されていました。
詳細については、ぜひチーム・ジャーニーを読んでみてください!
チーム・ジャーニーを読んだ感想
結論から申し上げると、「良著。共に作るを体現した本である。」の一言。
といいますのも、この本にはPOに任命されてから発生する問題の壁を超えていくストーリーでして、それぞれの壁を超えるための解決方法策が都度書かれています。
つまりケーススタディです。
多才な登場人物たちを通して「あ〜おるおるこんなやつ。自分の周りにもおるわ〜」なんて思いながら読むと、ただ本を読んだだけでなく完全に走りきった感じがして気付いたら体力を持ってかれてます。気をつけてください。
いろいろ考えさせられた、チーム・ジャーニー。
チームで開発をしていると「誰が問題を解決するか」という悩みも「気付いた人から始める」というのが結論なのです。
時間軸をどれだけ伸ばしても状況が変わる見込みがないのであれば、そこにいる人間でどうにかするしかないそして、その状況を変えられるのは必要性に気がついている人間だけなのです。
「そうだよね〜〜あ〜〜分かる〜〜〜」と首が取れるんじゃないかってくらいに首を縦に振りまくりました。いや〜〜〜さすがです、市谷さん。。
まとめ
物語調でかつ解説もあるため、イメージしやすく思わず世界観に入り込んでしまうほど面白い本でした。
タイトルにもある通り、チーム活動について最初から最後まで考えさせれます。
ちなみに蔵屋敷さんをずっと「産屋敷さん」と思っていたことをここに報告します。
鬼滅の刃にハマりすぎですね。反省してます。
チーム開発に興味がある方は、ぜひ読んでみてはいかがでしょうか?
【書評】やり抜く人の9つの習慣~コロンビア大学の成功の科学~【要約】
皆さんこんにちは。管理人のPaZooです。
あっという間に年明けてもうすぐ1ヶ月経とうとしていますね。最近時間の経過が非常に早く感じます。
年末休暇中に「やり抜く人の9つの習慣~コロンビア大学の成功の科学~」をKindleで購入しました。
個人的な感想になりますが、結論めっちゃ良著です!!!!!
ページ数はおよそ100ページあまりで、内容が非常に読みやすく要約されています。
ちなみに、メンタリストDaiGoさんの動画にてご紹介されています。
- 「やり抜く人の9つの習慣」はどんな人にオススメ?
- 「やり抜く人の9つの習慣」の内容・構成
- やり抜く力を身に付ける9つの習慣・行動
- 「これまで思考」から「これから思考」に
- 現実的な楽観主義者になる
- 最後に
「やり抜く人の9つの習慣」はどんな人にオススメ?
さて、この本はどんな人にオススメなのかまとめてみました。
- やり抜けない人
- 「才能が無いから出来ない」と思い込んでいる人
- 時間が無いけどやり抜く力を身に付けたい人
タイトルにもあるように「やり抜く人の習慣」が書いてある本なので、やりたいという熱意があっても長続きしない、今まで何やってもうまくいかなかった、時間が無いけど「やり抜く力」を身に付けたい人にぜひオススメです。
「やり抜く人の9つの習慣」の内容・構成
この本では”成功者”と呼ばれる人たちに共通する思考や行動パターンがあることを述べ、それらを9つの習慣として要約してまとめています。
構成としては、全9章からなる1冊ですが【1章あたり10ページ】と少なく、更に最後には「まとめ」も用意されています。
無駄がなく、すっきりと簡潔にまとめられている本書は【マインドセット】について他の著書でご存知の場合は少し物足りないかもしれません。
やり抜く力を身に付ける9つの習慣・行動
各章のタイトルですが、ざっくりと書いてみます。
- 目標に「具体性」を与える
- if-thenプランの形で「○○になったらやる」と計画する
- 現状と目標までの距離に目を向けて「目標に近付くために何をすべきか」に焦点を当て、モチベーションを維持している。
- 成功できると信じている。同時に成功は簡単に手に入らないと考えて努力を怠らない。
- 最初から完璧を目指さない。失敗を恐れることなく少しずつでも進歩することを考えている。
- どんな能力でも努力で身に付けられると信じている。どんな困難でも「やり抜く力」を持って取り組むことができる。
- 意志力を鍛えれば強くなることを知っていて、習慣的に鍛えている。筋力と同じように、意志力も使い過ぎれば消耗する。
- 誘惑を出来るだけ近づけないようにする。意志力で誘惑に打ち勝とうとしない。
- 「やらないこと」ではなく「やること」に焦点を置く。
中でも印象に残った章をご紹介させていただきます!
「これまで思考」から「これから思考」に
これまで思考(to-date thinking)…「どこまでやり遂げたか」に視点を向けるスタイル
これから思考(to-go thinking)…「あとどれだけやらなければいけないのか」に視点を向けるスタイル
著書によれば、人は誰でも「これまで思考」と「これから思考」を行ったりきたりしているのだといいます。
どちらも目標達成のために同じように大切な考え方なのですが、注意が必要です。
その注意とは、「これまで思考」が強くなるとモチベーションが下がる危険性があると言うこと。
人は「目標に対して自分はこれだけ進捗したのだ」と言うことに目を向けると達成感を得ることが出来ます。
「これまで思考」の傾向が強い人は、早い段階で達成感を持ってしまうため気が緩むのが早いです。逆に「これから思考」の人は目標までの距離を測るとモチベーションは維持され「これからやるべきこと」を意識することでモチベーションを高めることもできるそうです。
現実的な楽観主義者になる
目標に向かって努力をするときにポジティブに考えることはもちろん大切です。
しかし、目標達成を甘くてみてはいけません。目標が価値があればあるほど、時間・計画・汗が必要になるからです。
事実「望むことは簡単にできる」「欲しいものは簡単に手に入る」と考えると失敗の確率が高くなってしまいます。
その理由として、「簡単にできる」と考えただけで必要な準備を怠ってしまうからです。
「望めば手に入る」と”引き寄せ”に取り組んでも、目標達成には役立たず、それどころか目標を阻害する可能性すらあります。
ただし、「引き寄せの法則」が役に立つケースが一つだけあるそうです。
それは、目標を達成したくないとき。つまり著書は「引き寄せの法則」は「失敗の法則」だと主張しています。
「目標は達成できる」と信じるのはもちろん大事です。
しかし、「目標は簡単に達成できる」と見積もってはいけません。ここが注意すべき考え方です。
言い換えれば、「”非現実的な楽観主義者”ではなく”現実的な楽観主義者”であれ」と言うこと。
それはどういうことかと説明しますと、「成功を望み、それに相応しい努力をする人
」です。つまり、目標を達成するために詳細なプランを立て、正しい戦略を練り、成功を掴むまで努力する人だと言うことです。
最後に
上記に記載したものだけでなく、他にもたくさんの面白い内容が書かれています。
もっと知りたい、読んでみたい!と思ってもらえると嬉しいです。
ちなみに、Kindle版だと1,000円以下で購入できちゃいます!
ぜひ興味がある方は、本書を手にとってみてください!